兴工具之利 善敏捷之事(1)

虽然在敏捷开发过程中，工具的使用已经不会再被反复地强调，但是实践证明，我们仍然无法忽视工具对敏捷开发项目的重要意义。合理的选择和使用工具，将使敏捷开发真正受益于工具，而不是受工具所累。

随着软件规模和复杂度的不断加大，想在计划的时间和预算内完成一个项目似乎越来越难。主要原因就是不可控制的因素对整个开发过程的影响日益凸现，如人员流失、需求变更、分布式团队难于协调等。针对于此，一些被广泛认可的方法，譬如敏捷和CMMI，越来越受欢迎。根据VersionOne在2006年的调查报告，大约有80％的公司在采用敏捷方法后生产力提高或明显地提高。

敏捷开发强调以人为本，认为面对面沟通是软件项目成功的一个重要因素。

当我询问一个研发经理关于敏捷开发所需的工具时，他开玩笑地说，一张白板和两杯咖啡。这也反映出开发人员对于敏捷方法的普遍认知。

事实上，许多开发项目主管虽然认同敏捷开发所强调的快速反应和沟通的理念，却担心它的“杂乱无章”带来的“不安定因素”。因为它极度地强调人的因素，使得人员的素质对敏捷团队的影响，远比对其他团队更大。

举例来说，配对检入是个保证代码质量很好的方法。但编程人员不了解其重要性，可能为了进度，常常一个人草草就检入了。因此，在采用敏捷方法时，若能适当地使用工具来保存累积的知识并固化关键过程，必能使敏捷项目更加成功。我们试以敏捷开发的几个主要特点为例，探讨工具在敏捷开发中扮演的角色。

特点一：测试驱动开发

传统的瀑布方法先编码再测试，等到发现需求和设计上的问题，为了节省费用，常常不了了之。测试驱动开发是在需求产生后，设计模块和其之间的接口，并将单元测试代码完成。在此过程中，需求和设计上的偏差将会被发现。由于编码尚未进行，只需更改需求和设计即可，避免造成太大浪费。

特点二：简单设计

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

特点三：配对编程

尽管两人一组的配对编程从理论上看使眼前目标和长远目标都得以保证，这却是敏捷方法中备受争议的做法，反对者普遍认为它会导致耗时加倍。广义的配对编程也包括前面提到的配对检入(Pair Check-in)，也就是由两人一起检验代码的正确性，然后才检入。

特点四：小型发布

发布周期短可使对项目的评估提前，进而降低了风险性。但这所带来是大量的可执行文档，造成管理上的困难。

工具所扮演之角色

现在让我们以一个典型的敏捷团队DevAgile为例，看看该如何用工具实现其敏捷过程和设想（图1）。Smart先生是DevAgile团队的项目经理，他被要求在开发过程中体现我们以上所列的几方面特点，在配对编程方面还要求配对检入。

角色1：需求管理的利器

对项目需求和设计文档的管理是DevAgile必须首先面对的问题。他们要完成的，恰恰是一个需求变更很快的项目，这也是他们选择敏捷开发的重要原因。在敏捷开发中，需求的变化常常是为下一次迭代提供信息和进度计划的依据。

因此，DevAgile的大多数成员认为，记录下每一次关键的需求变更很重要，尽管最初有些人坚持敏捷开发并不需要文档。

同时，他们也注意到，要遵循简单设计的原则，并非意味着设计文档不需管理。相反，文档的数量和版本都会比采用其他开发方式更多。这些设计文档及其历史应该被妥善地管理，也要和相对应的配置项链接。

另外，小型发布意味着整个生命周期中有更多的发布，如何对这些发布进行系统化管理也是DevAgile团队必须解决的问题。

综合以上这几点考虑，Smart先生认为，应该找到一种需求管理的武器。DevAgile团队在进行了一番市场调研后，决定尝试TechExcel DevSpec这种需求管理工具。它不仅提出“以知识为核心”的概念，满足需求和设计文档管理的要求，还实现了真正的“功能驱动开发”。

尽管DevAgile目前没有清楚的看到后者如何实现，但DevSpec对产品需求、产品功能及知识文档的系统管理还是吸引了他们。

它成全了设计团队的敏捷性，支持简单设计，并对他们经常修改设计的做法提供了管理上的帮助。一些成员还指出，在敏捷开发的道路上，太多的不确定因素和灵活性难免会影响大家对最终产品的认识，有一个这样的工具能够时时刻刻描绘出要发布产品的清晰轮廓，记录下产品需求和功能变更的每一步，实在是很令人欣慰。

另外，为了配合数量多的小型发布，DevSpec还有整理发布功能点的能力。也就是说，将和某一发布有关的新功能、功能变更，以及缺陷修复，全都进行统一组织和管理。

例如，要完成6.1的发布，他们只需把6.1功能文件夹里所有的新功能、功能变更，以及缺陷修复全都做完，6.1版本也就可以发布了。为了更大程度上提高开发效率，Smart先生还别出心裁的对这些功能及缺陷设定了优先级，优先级低的任务可能被延缓执行。实践证明，这种具灵活性且针对发布来管理的系统使小型发布越发容易。