本文是《敏捷宣言》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 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
评论