兴工具之利 善敏捷之事

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

详细信息请参见: http://media.ccidnet.com/art/3025/20070424/1069153_1.html

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

当我询问一个研发经理关于敏捷开发所需的工具时,他开玩笑地说,一张白板和两杯咖啡。这也反映出开发人员对于敏捷方法的普遍认知。事 实上,许多开发项目主管虽然认同敏捷开发所强调的快速反应和沟通的理念,却担心它的“杂乱无章”带来的“不安定因素”。因为它极度地强调人的因素,使得人 员的素质对敏捷团队的影响,远比对其他团队更大。举例来说,配对检入是个保证代码质量很好的方法。但编程人员不了解其重要性,可能为了进度,常常一个人草 草就检入了。因此,在采用敏捷方法时,若能适当地使用工具来保存累积的知识并固化关键过程,必能使敏捷项目更加成功。我们试以敏捷开发的几个主要特点为 例,探讨工具在敏捷开发中扮演的角色。

特点一:测试驱动开发

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

特点二:简单设计

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

特点三:配对编程

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

特点四:小型发布

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

工具所扮演之角色布

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

敏捷团队的成功案例总结

毫无疑问,DevAgile 团队最终用敏捷开发方式取得了项目成功。让我们再来总结一下,他们是如何具体做到的呢?首先,需求被搜集和整理,产品功能和简单设计产生,将这些结构框架 和相关文档存入DevSpec 之后,开始制定迭代计划,并定义模块接口。紧跟着,针对接口做出测试代码。这些知识文档全由DevSpec 来管理,因此DevSpec 中形成了由需求、功能和知识文档组成的“概念产品”。最后,功能点被导入DevTest 而产生一个或多个测试任务,每一个测试任务都能按照DevTrack中定义的工作流(图2)进行。

图2的工作流被启动之后,编码人员在第一状态负责编写代码、重构和白盒测试。项目经理为了实现配对检入,把第二状态设为需有A和B两 人一起检入的“配对检入”。每一个状态都有明确的负责人。A可以是第一状态负责人,而与A配对的人员则可以是跟A 所做的任务有关的人员。第三状态负责人可以是测试人员,在单元测试成功后便完成了整个流程。反之,则重新回到第一状态。

以上的案例中,对所提到的四个敏捷特点都有所注解。当然,这是一个可行的方案,而绝非唯一。另外,面对面沟通也是个很好的敏捷操作, 但是实际上却不易实现。客户或熟知商业逻辑的同事通常是无法长时间和开发设计人员在一起工作的。若一定要面对面,很可能会以高昂的费用为代价。更实际的方 式是通过一定的沟通平台(如一些即时语音或视频通讯工具)来达到类似面对面的沟通。无论采用何种方式,沟通后的结果都要能妥善地记录下来。知识的分类和历 史的记录会使清晰度达到最高,进而使后来的一切活动,包括编码、测试、分析等,都变得容易。

除了以上所提到的工具,软件配置管理、单元测试、软件的基础架构管理等工具,都是决定敏 捷开发项目是否能够取得成功的关键因素。总的来说,工具的使用要能帮助敏捷团队达到下列几项目的:能针对迭代进行灵活的计划,能管理需求变更,能始终体现 最终产品的框架,能将关键过程既用流程固化又随时可调整,能对需求和供能点排列优先级,能使各方沟通更加便利等等。只有这样,才能使敏捷方法真正受益于工 具,而不是受工具所累。