极限编程的一次冒险尝试

引言

在 2003 年早期，我们十个开发人员的团队接到任务，研究为 IBM 大型中间件产品之一的 WebSphere Application Server 交付内部组件。我们都认识到需要适应不断变化的需求，也要吸取经验并且在此过程中学习新技术。我们需要一条对开发流程而言更灵活的途径来有效地衡量我们进展，并且使我们能将庞大的、看似很难处理的大块工作分解成更容易理解的部分。在对不同的灵活交付方法进行分析之后，XP 似乎最符合我们的需求。

与组成我们集体背景的传统软件开发方法背道而驰既危险又令人兴奋。然而，当我们的管理团队允许我们尝试这种激进的、崭新的开发方式后，我们决定一心一意的采用 XP 的思想。

项目持续了将近一年，我们最终按时取得成功，顺利的完成了组件的交付工作。这篇文章描述了通过我们对极限编程的首次尝试而得出的一些高级项目原理、经验和想法。

本文假设您熟悉 XP 核心实践，这在 XProgramming.com中有定义。  

项目的开始

开发团队
开始，我们的开发团队由一些热衷于尝试 XP 的人员组成。基于在其它项目中的书籍、传闻和经验，我们开始着手定义 XP 流程。我们讨论的许多方面让人感觉并不合意，例如，反复的设计而不考虑更长周期（除非必要）的观念。可是，我们同意进行尝试。我们根据 XP 的原则定义基本的流程，并开始工作。定期的对过程（每周或两星期）的重审使得流程的改进贯穿于整个项目。

开发项目
我们的项目需求和范围在开始时非常模糊，并且我们知道它们可能会随时改变。XP 允许我们确保从开始就包含整个团队，包括建立我们的工作环境和提供初始需求。我们知道有些工作项目是可以被替代的，但这种机制使得团队工作高效快速并维持一种浓厚、乐观、协作的氛围。

用户
在最高级别上，中间件项目按照它的体系结构和组件如何交互来定义。因此我们将组件的体系结构视作用户需求。幸运的是，我们交付的组件只被一个其它组件直接使用，因此我们只有一个单独的主要用户。

开发环境
我们在工作的基本原则和关于如何展开工作上达成一致。例如，不能在测试前编写产品代码、所有代码成对的编写、日常的状况会议、坚持编码规范等等。然后我们着手创建合适的开发环境。该环境基于 Eclipse 并使用 JUnit 作为单元测试工具。配置了集成的计算机，然后我们准备开始工作。

万事俱备

我们最后的障碍是物理工作环境；也就是，在项目开发期间有可用的，单独的足够大的空间来容纳整个团队。我们花费了数周和大量的劝说来获得这样一个工作空间，但我们一旦可以在同一个工作间里相互交流，XP 流程立刻变得更有意义。强烈的团队精神发展起来并且效率显著提高。另外，由于开发人员和测试人员工作环境挨的很近，这样便确立了一种新的工作关系，每个人贡献他们的专业技术来促进交付方案的进展。

获得独立的团队工作间是项目真正开始受益于 XP 的起点。

全力开展工作

项目开发计划
不同于那些计划由项目计划者和团队领导者独立制定的传统开发方法，XP 团队详细说明并严格规定了每个人的任务内容以及相关的交付日期，这样使得每个团队成员都具有成功实现目标的责任感。

我们的项目以两个用户情景开头，并与我们的客户一起工作。然后，按照我们要交付的产品的先后关系来确认同其它团队间的主要依赖关系并将项目分解成几个独立的块。最初，我们有 4 个版本，每个发布时间都在 6 到 10 周之间，并且每个一般包含 15 到 30 个用户情景。后来，随后的需求和交付日期延长（都由于用户）意味着需要添加第五个版本。

这样，一项发布计划产生了，它用来确认预定用户情景以在每个发布期间内每次迭代的交付。基于用户的输入，最高优先级用户的情景在版本的开始被制定，因此我们可以将精力先集中在最重要的功能上。这种方式的实行对保证最重要功能可以成功交付，提供了最大的信心。

迭代交付
我们紧密地按照 XP 进行以反复的提交我们的代码。我们选择每两周重复一次，并且每天进行 15 分钟会议。我们花费了几个迭代周期来寻找迭代开始的最合适的天数和何时进行会议。我们安排周一开始迭代，并于下午一点进行会议。我们也发现我们需要在迭代中期进行检验会议，这样我们可以问这个问题“在这个反复中我们还需要做多少的工作？我们将全部做完么？”问这个问题使我们可以及早确认潜在的问题并确立适当的补救措施。

在每次迭代的结尾，将我们可交付使用的产品打包，并将支持文档以版本注释的形式一起交付给用户。

跟踪和监视状态
为追踪和监视我们的进程，我们选择一种低技术、高可见度的方式：我们使用墙、手写的索引卡和 XP 房间的白板来记录项目进程和计划。

然而，我们仍然必须坚持由父项目施于我们的标准，这意味这要完成许多文档来为大项目提供进度状况。尽管这是额外的，但我们认为这是用户需求，换句话说，我们的用户希望我们用某种方式追踪项目进程，所以我们恭敬地遵循。

交付的完成
我们构建的组件只是主要产品发布的一部分。随着在我们项目结束的临近，我们不得不开始考虑下一个产品发布可能需要什么。在临近我们倒数第二个版本时，我们决定将团队平均划分为更小的组。在最终版本进行过程中，我们需要将团队成员转移到下一个项目中，跟非 XP 项目的需求完全相同。团队人数的减少使得成对编程更为困难。尽管如此，我们坚持并准时递交我们可交付使用的项目，解除剩下的团队成员，让他们加入其他的同事，参与下一个项目版本的工作。

对项目管理的影响

在更大的非 XP 环境中实践 XP
中间件产品很复杂，它包含许多团队和许多组件，所有的这些都需要进行交互。因此，最初的高层次的计划和体系结构的设计是必要的。这与 XP 的 “just in time”的计划方式相抵触。可是，由于高层次的体系结构对于我们的组件如何更好的与产品的其它组件整合提供了更好的前景，因此我们觉得这个产品体系结构有利于我们 XP 的可交付性。

团队需要坚持我们父项目中所有非 XP 的流程。正如提到的，这意味这在我们需要两倍的努力。这也意味着不得不坚持与 XP 模型不一致的最终期限。例如，尽管我们所有的代码全部通过了验收测试，我们仍然不得不按照父计划的 DCUT（设计，编码和单元测试）日期递交它，而不是较迟的 FVT（功能验证测试）日期。通过 FVT 验证的代码与我们提交的每次迭代中验收测试的代码品质都一样。除了递交按 DCUT 日期的高质量代码和以之作为下一个可交付版本的参考点之外，很难决定我们这里对项目产生的影响。

评估、计划和状况
评估总是难以进行。XP 的一个好处是评估的精确性，从项目范围阶段高层次的含糊花费开始，将在版本计划和迭代计划阶段得以进一步细化。

使每个编码对（coding pair）提供对它们工作的估计，确保了对所有涉及的方面进行评估，同时提醒其他团队成员成本内的所有单元的编程对，这潜在的增加了进一步评估的精确性。我们并没有这么做－－并且我们可能在此得益于 XP－－精确的使用项目速率来指示我们在未来的迭代中能交付多少内容。项目速率是衡量团队表现的一种技术，它将下一个迭代的可用产品数量基于前一个迭代中完成的用户情景数目。如果我们更好的使用项目速率，将可以更快的评估并突出存在的问题，因此，不仅要提高我们评估的精确性，还要提高我们的整体效率。

重要的是，这个项目所有可交付使用版本的状况由大老板（big boss）定期的追踪以保证没有遗漏。（big boss 是 XP 术语，代表对之汇报状况的人；这个角色类似于交付管理员）。编码和交付标准有助于减少风险。另外，确保所有问题和任务（如在迭代的结尾编写版本注释）都有负责人，这意味着项目事务不会被忽略。日常会议允许我们跟踪进程并及时处理问题和利害关系。这相比更传统的定期的进展状况会议的方式更为有利。会议不要求正式的记录；在会议上所有不能回答的问题要写下并粘贴在墙上。

对可交付性的影响

生产率
在某些方面，我们发现我们的 XP 项目相比其他类似规模和复杂度的 IBM 非 XP 项目来说，生产能力较低。生产能力的一个关键因素可能会连累整个团队的决策制定和计划编制。尽管这样有很多有利方面，但它显然比非 XP 项目需要更多资源，对于非 XP 项目来说，相同的工作可以由更少的团队成员来完成。将任务划分为更小的、易于管理的子任务在传统上可能由个人来完成，但在我们的 XP 项目中这由整个团队来进行。

XP 自身的特性导致工作步调的减缓。我们注意到很少有吸引人的项目会花费比预期更长的时间。也许 Big Boss 的更权威的姿态会在此时有帮助。并且，当试图解决复杂且影响广泛的问题时，公用所有权会对此产生阻碍。将难题分解为分布到对之间的更小的任务，这就不允许用整体方式来解决问题。我们发现即使要解决的问题涉及到团队中的其他人，将复杂的问题分配给团队中的单个成员也是有好处的。

另外值得注意我们的团队中相对没有经验的开发人员的百分比很合理（与我们身边的其他团队相比）。这个因素也将影响到生产率，而与采用什么方法无关。

在项目即将结束之际，我们发现工作负担减轻了。我们把这归结于遍及整个项目突出难题的反复的代码验收测试，这样，比起跟随传统的项目开发计划来，我们能更好的解决处理。

品质
测试驱动开发的结合，用完全自动的回归测试进行连续化集成，组对编程和团队设计理所当然会提高我们的代码质量。另外，也非常鼓励使用 refactoring，refactoring 可以随着时间的推移对代码进行精简和更新。一致认可的代码标准确保了一致性。缺乏代码所有权，缺乏经验以及我们对单元测试的依赖，有时会产生不当的代码，但是随后的项目重审时会用 refactoring 对此调整。

对团队和用户的影响

教育价值
XP 的许多方面对非 XP 环境的好处进行了加工 --- 也得益于许多有经验的专业人员的实践。例如，我们缺乏经验的团队成员现在也完全可以胜任分析复杂的问题，这是因为 XP 使该流程形式化，并且广泛的单元测试组使成员对重构（refactor）代码充满信心。

一些人喜欢在 XP 环境中工作，而有些人不是。也许这和每个人的个性、工作的风格或是其他的一些因素有关。喜欢沉思的人们会发现 XP 团队会有些约束，因为难以找到安静的时间来坐着思考问题。他们疑虑的状态也会因为兴趣和能力的不足而被发觉。另一方面，那些思维活跃的人们能使 XP 团队旺盛起来，即使这会对他们的工作产生不同程度的影响。

组对编程会因为互相冲突的工作风格而变得困难；有思想有想法的员工会对和那些工作方法杂乱无章的人一起工作而感到灰心等等。我们同样注意到一些人总是一贯冷落那些相对乏味的任务。在更多的情况下，这是因为每个人都愿意对团队的整体合作和成就贡献力量，而不是选择那些基于个人爱好的任务。

这些喜欢 XP 的人们会享受开阔的，协作的环境，使团队成员都溶入整个项目周期的方方面面，包括设计和项目管理。

对用户的影响
所有这些中最重要的角色是：用户。在 XP 中，用户是驱动力。需要在 XP 中对用户进行指导并让他们知道 XP 对他们来说意味着什么。有时也是挑战，因为用户经常预先在功能测试开始之前指定那些没有更进一步交互的需求。这些冲突的解决需要更多的努力，主要是因为我们要用 XP 和非 XP 的方法收集需求，然后在两种模型中进行映射。最后，用户会由于我们全力以赴的结果而满意。

结束语

最后，我们实现了预期目标：在规定的时间范围内，使用全新的交付方法，将新组件交付到复杂的中间件产品里。

那么我们从中学到了什么呢？

XP 的经验是非常有价值的，并且戏剧性的改变了我们对如何交付软件的看法，特别是关于场景驱动的开发和测试。可以简单的认为 XP 不过是工具和技术的组合而已。事实上，它更是一种涵盖了项目的各个方面的哲学。也就是说，不该把 XP 视作所有软件开发的万能药。由于缺乏仲裁而导致在技术和项目层面上无止尽的争论和偶尔不恰当的决策，我们都还能清晰的记得许多这样的挫折。同样，由于某些成员发觉 XP 不是最合意的开发环境，所以我们觉得考虑团队成员个性的平衡也是很重要的。

如果您想尝试 XP，我们强烈推荐您进行 XP 培训，这个是我们发觉以前忽略了的。培训将使项目开发更容易上手，是极好的指路明灯，特别是针对最开始的基本学习阶段。

最后，很有可能您现在的项目已经从 XP 认可的实践中获益了。实际上，IBM 的开发团队已经拥有迭代交付、测试驱动开发、refactoring、代码评审、连续的集成、自动的回归测试和公共代码标准。所有的这些会通过适时的高质量软件的交付，从而导致用户满意度的改良。XP 不是所有软件开发项目或问题的答案，但是它的确是您可以考虑的备选交付途径。

或许这些理解能帮助您判断极限编程是否适合您，并且如果适合的话，还能在您打算尝试之前帮助您对前景有自己的想法。