重要的成功因素

·         尝试它——如果你不去尝试，你就永远不了解它。

·         时间——给你小组（足够的）时间来尝试，并一步一步来完成。

·         沟通——配对编程会暴露一些有争议的问题——要保证沟通的渠道畅通。

·         配对恐惧症——你可能会碰到拒绝或者不希望与别人搭配工作的人。通常情况都是有别的原因驱使他们这样做，所以你需要找出并解决这些原因。

·         花时间思考——开发人员需要时间来思考并想出主意——确信给他们留出了时间做别的事情。

　　从整体上讲，我们在这里说的是要尝试这种方法——首先尝试测试－编码－重整循环，一旦你让它运转起来，就尝试一下配对编程。你应该马上就可以看到质量的提升，以及团队里沟通层次的提高。

　　我们在本文没有谈及的内容很简单——增量设计。敏捷编程喜欢简单的增量、改进的设计，而不是在编写代码之前的大型设计。很多人都认为敏捷编程不喜欢设计——事实并不是如此，而应该是只要满足最低需要就行了。

　　在本系列的第二部分里，我们将更加仔细地探讨简单设计以及一套的开发团队做法。
 

　　在《敏捷软件开发》上中下系列的上篇里，我们探讨了开发人员做法，也回顾了技术优势如何大幅提高软件质量。第一部分把重点主要放在了测试－编码－重整循环上。现在我们转到中间一个圆环，看看敏捷开发做法如何在小组这一层次发挥作用。

让小组高效工作——小组做法
　　一旦每个开发人员都在紧密围绕中心圆环的反馈循环工作时，我们就可以看看整个开发小组能够如何以更加敏捷的方式工作。小组这一层次的做法是敏捷开发的核心，因为它们能够显示出小组成员可以如何更加高效地一起工作并推动共同进行技术决策。我们将分别从四个方面来讨论小组的这种改变——设定基调、基于小组的代码编写标准、提高和保持效率、采用“统一小组”方式（包括与开发小组直接相关的东西）的首要步骤。我们给你举的例子来自于3Q Solutions公司，这是一家生产财物管理系统并完全使用敏捷开发方法的软件公司。

设定基调——第一步
　　敏捷软件开发的一个中心思想是小组朝着一个共同的目标工作。尽管很多流程都提倡小组工作，但是敏捷开发（真正）融合了支持小组工作的做法，并将小组工作放到了日常做法里。在开始讨论小组做法之前，我们需要先为小组设定一个基调，让他们开始感觉更像是一个真正的小组。

开放的工作空间
　　为更加开放的、基于小组的敏捷开发方式设定基调的一种最佳方法是为小组创造一种开放的工作空间（open workplace）。这意味着要建立一个或多个开放的区域，并尽最大可能进行沟通和合作。你想要专门了解什么样的环境能够让配对编程更容易。小格间和办公室是与敏捷开发开放工作空间格格不入的，所以应该避免其出现。在一家与Exoftware有合作关系的公司里，开放空间区域只被用于工作，里面只有用于配对编程、集成和构建软件的机器。其它的所有区域都留给带有Internet连接和电话的个人计算机。如果你有这样的空间，这就是应该考虑的东西，因为它有助于清楚地表明“当我们在工作区的时候，我们在工作”。

　　不要低估开放的工作空间对于小组的重要性——这就是为什么我们将其作为第一步的原因。下面的一幅照片就是是3Q Solutions开发小组的工作空间。

　　请注意，两张大桌子（下面没有文件柜）被摆在一起，构成了最适合配对编程的办公桌。

集体主义主人翁精神
　　我们想要介绍的下一个思想是集体主义主人翁精神（Collective Ownership）。敏捷编程的这种中心思想是让每一个人都对整个系统负责，每一个人都有更改代码的自由。这是一种重要的思维方法，因为它让小组的注意力都集中到了项目上，从而确保有一个共同的目标。与配对编程相关的其它步骤也强调这种思想，但是尽早引入这种思想是非常好的。

简单设计
　　敏捷开发崇尚简单的渐进设计，而不是剧烈的颠覆式设计。其目标是（首先）只指设计我们所了解的项目的那些部分，仅此而已，然后让该设计随着时间的推移而逐渐改进，这有助于提高灵活性并将变化导致的成本最小化。

　　我们就从3Q Solutions公司举一个例子，有一个客户要求获得一个规则引擎（rules engine）。小组传统的做法是花上数月时间开发规则引擎，然后可能还是无法把它卖出去。在与客户共同协商的情况下，小组决定设计一个满足规则引擎工作要求的最简单系统，并为每一条规则创建一个瘦垂直系统（a thin vertical system）。这就给予了客户他们真正需要的东西——可证明的规则——并确保投资抵消了投入的时间。这样小组可以在保持灵活性的同时从一开始就不断改进设计。简单设计是一个复杂的领域，研究它的最佳方法是获得外部的帮助。

重要的成功因素

·         赞同——整个开发小组坚持尝试使用敏捷开发以及开发小组圆环里的做法极其重要。如果不能这样坚持，开始甚至保持这样的做法都是非常困难的。

·         沟通——这一点怎么强调都不够。保证小组里高层次的沟通和对诸如集体主义主人翁精神这样的概念的理解非常重要。

·         配对编程——配对编程为很多小组做法提供支持，并将加强小组的沟通和凝聚力。

·         行政——如果没有行政上的支持，创造开放工作空间将会非常困难。在某些情况下，当行政机构的官僚主义作风盛行的时候，我们只用进行一些改变就行了。

·         每日例会——这一个每天早上进行的简单会议，供开发人员讨论当日面临的工作和问题。这样的会议应该是站着开的，因为其时间不应该超过几分钟。

小组编写代码——第二步
　　既然我们已经安置好了工作空间，并设定了小组的基调，我们现在就需要看看小组是如何处理代码的。我们这里的目标是确保所有通过配对编程编写的代码都能无缝地集成在一起，并且符合小组所承认的标准。通过推动第二步的进行，我们为支持第一步还有很大一段路要走。

代码编写标准
　　无论你是否决定采用敏捷编程，代码编写标准（coding standard）是一个非常好的最佳做法。这一步骤涉及让小组创立一套他们能够完全理解和坚持使用的代码编写标准。代码编写标准给予我们下列优势：

·         它让我们能够轻松地读懂别人的代码，这样所有人都可以进行（代码）交换。

·         代码为未来接手的小组提供了一个绝佳的信息源，即使有小组成员离队。

·         新的小组成员有一套指导方针——而不是瞎猜。

　　大多数小组都会利用已有的框架，并围绕其构建自己的一套标准。这里的关键要素是开始，立即解决小组正在奋力解决的问题，然后根据需要向前推进。也不要为了标准而去强行推行标准——这毕竟是整个小组需要共同认可、相信和使用的东西。下面是3Q公司代码编写标准文档的一小段。