写点什么

创建完整团队的艺术:敏捷如何改变我们与客户的工作方式

  • 2011-03-22
  • 本文字数:3592 字

    阅读完需:约 12 分钟

本文是《敏捷宣言》10 年系列纪念文章之一,该系列文章将陆续在 InfoQ 上发布。

十年前,《敏捷宣言》的作者们希望我们重新思考:我们作为程序员与客户协作的方式。我和我的博士学位顾问 Robert Biddle 以及 James Noble 都深受启发,充满希望,并渴望了解如何在实践中让这种协作发挥作用。不是人们常说的它应该如何起作用,而是它如何真正有效果。接下来的 6 年中,我们努力了解这一点,访问了 5 个国家的 11 个敏捷团队【注 1】。这些团队处于多个不同行业,大小从 5 人到 60 人不等。

那么是什么让敏捷如此与众不同?首先,时间盒(也被称为迭代或是 sprint,看你喜欢哪种术语)让客户能够随时间推移了解自己对软件的真实需求:要开发的“真正的东西”到底是什么。我们研究的一个客户是这么说的:

“如果我们在一开始就深入到底层需求,我觉得那将会非常困难,因为我从未接触过新的软件和业务流程,因此很多时候,我也是一边前进一边学习。看到真正的东西之后,就能很容易地指导下一个层面要做什么样的详细决策了。” ——KiwiCorp 客户

敏捷也鼓励我们这些程序员与客户每天互动,并获取反馈,而且将其视为常态。我们不应该指望“从墙那边”扔过来一个文档,其中描述了客户的完美系统。实际上,我们应该成为客户了解系统真实需求这个过程的一部分。在我们的研究中有一个好消息,我们发现客户喜欢这种软件开发的新方法:

“总体来说,我喜欢这种开发方法,而且在未来我能够参与的所有项目中,我也非常愿意再次使用这种方法。” ——KiwiCorp 客户

客户还特别提到:他们非常珍视与程序员建立起来的新型协作关系。比如:

“以前,你撰写文档,然后在文档上获得反馈,这就变成了传统瀑布流程中的技术设计规范,不到产品最后产出的时候,你不会知道:有人搞砸了一些东西……但是在极限编程中,你可以及时在正确时机定义产品,并与之产生非常非常紧密的关系……极限编程之于我,最有力的一点在于:我能够调动和我一起工作的、整个开发人员小组的集体智慧……” ——EagleCorp 客户

在我们研究的团队中,是不是一切都非常完美?并非如此。我们都是人。人是不完美的,不管我们多么希望他们完美。人也能够非常出色地解决问题,在本文中,我们讲述两种实践,这两种实践显现在我们研究的成功完整团队之中。

第一个完整团队实践,我们称之为“客户的学徒(Customer’s Apprentice)”。讲一个我们最初遇到的团队的故事,这个故事能完美阐述这个实践。在这个团队中,客户让程序员们感到越来越郁闷。客户没有提供足够的用户故事,程序员常常很空闲。几个月之后,有一个程序员实在是太郁闷了,他自愿帮助客户撰写用户故事。团队的教练是这么说的:

“那个程序员说:我还不如花上一天与客户一起写用户故事呢,这能在以下几个方面帮助客户:首先,多一个人写用户故事;其次,可以回答客户任何技术问题;第三,让我知道项目困难程度到底如何。如果真得很简单,我们就可以继续不断敲打客户,以了解他们的真实情况。但是事情不是这样。程序员回来之后,他说:还真是有一个与写用户故事相关的流程,要去挖掘需求,然后找到业务相关人士,让他们解释需要什么东西,以及类似的过程。这让程序员们变得谦虚了,而且与客户的关系也变得更有效率。事情因此变得完全不同。了解了一些情况后,开发人员们对客户的痛苦也有了一些深入的了解。” ——SwiftCorp 团队教练

花费两个迭代成为客户的学徒,这的确让程序员帮助客户取得了进展。但是,也许更重要的是,对于客户的任务范畴,他有了更深入的了解和理解。在这个故事中,客户方面的两家公司刚刚合并,要开发的系统即将成为咨询公司的标准系统。客户遇到了很多公司政治层面问题。较大的业务组织非常害怕改变会影响他们的工作。程序员也看到了客户为了开发系统所处的困难境地,他可以把这个理解带回团队,让大家感同身受。

在另一个故事中,客户没有让程序员们感到郁闷,可是他们的工作过于繁重,程序员们注意到了这一点。两个程序员自愿在一个迭代之内成为客户的学徒。程序员与客户紧密工作,帮助客户完成每天的工作,帮他们扛一些担子。

这就是程序员所能提供的典型帮助,有助于创造出将客户包括在内的完整团队。将上两个故事与接下来这个对比:在一个团队中,客户在过去的 12 月中,每周都要工作 70 到 80 个小时。此案例中,程序员(还有教练)将自己每周工作 40 个小时的权利奉若神明,根本没有意识到客户已经超负荷工作很久了。

有时,作为程序员,我们常常不知道客户为什么对我们生气,或是为什么他们那么忙,无法满足我们的要求。这个实践可以让程序员“穿上客户的鞋子”,只是一小段时间,就可以深入了解和感受客户的工作状况。我们作为程序员,每天工作,是无法了解这些情况的。我们发现:最高效的团队至少每三个月就要使用一次该实践。它不必是一个过于正式的实践,程序员只要自愿“帮忙”,就可以起到非常好的效果。

第二个完整团队实践,我们称之为“现场程序员(Programmer On-site)”。我们用故事来讲述这个实践。此案例选自我最近指导的一个团队。其中一个程序员非常担心应用的用户界面。他觉得这个界面的设计非常糟糕:在界面中,呼叫中心的操作员在接电话时,需要翻滚好几页数据。现场的呼叫中心代表不管说什么,都无法说服他这个设计很有效。程序员在接下来的一个月中多次提出他的担心。在程序员和呼叫中心操作员之间的紧张情绪不断升温,原本有效的协作陷于停滞。

一个机会出现了,程序员可以访问呼叫中心。呼叫中心位于项目办公室三个小时火车车程之外。当他到达呼叫中心后,有人让这个程序员去观察一个操作员的工作。开始时,程序员告诉操作员:用户界面一定“很难用”。年轻的操作员说:“不是这样的,我来告诉你为什么。”程序员接下来用了一个小时观察操作员接听电话,使用应用,他突然明白了为什么用户界面要这样设计。尽管过去有多次讨论,对他来说,只有亲眼见到实际使用情况,他才能明白。但是,我们的故事没有就此结束。程序员在观察操作员使用应用的过程中,他观察到一个步骤,认为自己可以通过自动化手段免去这个步骤。操作员在过去的研讨会中没有提起这一点。在程序员离开呼叫中心之前,他与操作员一起编写了一个用户故事,把想法记录下来。团队在接下来的迭代中开发了这个用户故事,一个月之后,这个功能发布了,而且节省了操作员在每次通话中耗费的时间。

仅仅跟最终用户“谈话”还不够。我们有时会忘记:要构建什么样的东西,是软件开发中最难的部分:

“构建软件系统最困难的工作,就是精确判断出要构建什么……软件开发人员为客户所做的最重要的事情,就是对产品需求的反复抽象和修正。因为真相在于:客户不知道自己要什么。他们常常不知道要回答什么样的问题,而且他们几乎从未想过待解决问题的细节如何。” Fred Brooks,1995,《人月神话·周年纪念版》,Addison-Wesley 出版社。

现场程序员是一个很简单的实践,与时间盒或迭代开发一起使用,帮助客户与我们一起工作,判断什么是我们要构建的“正确的东西”。在实际中,组织程序员观察最终用户实际工作,要比想象中简单。有时我们需要一点非常规的想法。比如,一个在能源交易领域中的团队,他们最初认为自己无法观察交易员,因为交易场地在交易时间内是禁止进入的。然而,跟交易员简单聊过几句之后,他们制定出一个能让大家都满足的计划。交易员后来受邀与程序员共同参加一个午餐会议,会上,在程序员观看视频的时候,交易员向大家解释自己当时在做什么,想什么。交易员跟人说:他当时觉得自己像一个“明星”。他喜欢得到的注意力。更重要的是,他突然可以与程序员说明:为什么他认为系统如此难以使用。他有特定的例子可以讨论,而程序员也可以看到他说到的问题产生的直接影响。最终,大家达成了一致,并且可以协作,产生解决方案。

作为总结,《敏捷宣言》的作者们在 10 年前希望我们重新思考:我们作为软件开发人员与业务人员交互的方式。在创建协作伙伴关系方面,我们已经有了很大的进步。但这还不够完美,其中涉及到人与人之间的关系。很重要的一点,是要记住:我们“身处同一条战线”,这不是“我们”与“他们”之间的对抗。本文列出的两个实践,有助于我们记住这一点。我们使用敏捷开发,就是要开发出出色的软件,解决最终用户的问题,让世界更美好。

关于作者

Angela Martin 在新西兰惠灵顿的 Victoria 大学完成了自己的博士论文《客户在极限编程项目中的职责》。本文基于她的论文完成。她目前是新西兰汉密尔顿 Waikato 大学的讲师。她也在英国的牛津大学教授软件工程系列科目中的敏捷方法课程。她有 14 年行业经验,包括敏捷教练的经历,并曾担任两年敏捷联盟董事会成员。

注 1:我们引用了访谈中受访者的一些原话,以展示我们的发现;为体现匿名性,真实姓名已经隐去。


给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2011-03-22 00:002288
用户头像

发布了 479 篇内容, 共 151.8 次阅读, 收获喜欢 47 次。

关注

评论

发布
暂无评论
发现更多内容

一文了解路由平台的 Cisco IOS 和 IOS XE 命名约定,看这篇就够了!

Ethereal

知识管理——企业数字化转型的新挑战

小炮

干货|性能提升密钥,由代码细节带来的极致体验

SphereEx

Apache 数据库 开源 ShardingSphere SphereEx

Hadoop HDFS 3.3.1分布式存储搭建

KunlunBase昆仑数据库

国产数据库

建设领先的AI原生云,百度智能云落地新一代高性能AI计算集群

百度开发者中心

网络安全之文件包含漏洞总结

网络安全学海

黑客 网络安全 信息安全 渗透测试 WEB安全

【技术学习】一次Node.js站点渗透

H

node.js 网络安全 渗透测试

ARP欺骗攻击

喀拉峻

网络安全

什么是单臂路由器?如何配置单臂路由?

Ethereal

视频质量评价VMAF,为何让人又喜又忧?

微帧Visionular

视频编码

昆仑分布式数据库独特的变量读写功能介绍

KunlunBase昆仑数据库

数据库 读写分离

吉利控股集团与百度深化战略合作

百度开发者中心

2022年2月云主机性能评测报告

博睿数据

如何基于制品元数据提升交付效率 | 阿里巴巴DevOps实践指南

阿里云云效

云计算 阿里云 云原生 软件开发 持续交付

阿里巴巴在开源压测工具 JMeter 上的实践和优化

阿里巴巴云原生

Apache 阿里云 云原生 Jmeter

Gartner发布服务器虚拟化市场指南 灵雀云作为唯一本土容器厂商入选

York

容器 云原生 数据中心

华为SmartCare和AUTIN品牌升级:助力运营商走出5G发展迷宫

脑极体

Meetup预告|面向云原生的架构及演进

云智慧AIOps社区

开源 云原生 AIOPS 智能运维

见证中国云势力崛起!博睿数据实力入围2021~2022 Cloud 100 榜单

博睿数据

干货分享 | 推荐两款好用的企业文档管理软件

小炮

网易X工行:云原生日志系统 Loggie 正式开源!

网易数帆

开源 云原生 日志 Filebeat Loggie

培训第二弹!全国大学生智能汽车竞赛百度竞速组预告

百度开发者中心

投稿开奖丨轻量应用服务器征文活动(2月)奖励公布

阿里云弹性计算

轻量征文

什么是广域网WAN?学WAN,看这篇文章就够了!

Ethereal

业内首家!百度智能云智慧金融业务通过ISO37301合规管理体系认证

百度开发者中心

VuePress 博客优化之增加 Vssue 评论功能

冴羽

JavaScript Vue 前端 vuepress vssues

如何限制Linux终端中tree命令递归文件列表的深度?

Ethereal

以领先NLP技术构建AI数字疗法体系,聆心智能致力于解开更多“心结”

硬科技星球

阿里巴巴如何提升构建的效率 | 阿里巴巴DevOps实践指南

阿里云云效

阿里巴巴 阿里云 CI/CD 持续交付 构建工具

DSTC10 赛道最佳论文揭晓!文心 PLATO 再获殊荣

百度开发者中心

开发者们看过来~填问卷参与抽奖,双重周边奖励仅限本周!

InfoQ写作社区官方

OpenHarmony 热门活动

创建完整团队的艺术:敏捷如何改变我们与客户的工作方式_研发效能_Angela Martin_InfoQ精选文章