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

本文是《敏捷宣言》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：我们引用了访谈中受访者的一些原话，以展示我们的发现；为体现匿名性，真实姓名已经隐去。

---

原文：http://www.infoq.com/cn/articles/art-whole-teams