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

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

　　敏捷开发强调以人为本认为面对面沟通是软件Software项目成功个重要原因

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

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

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

　　特点:测试驱动开发

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

　　特点 2:简单设计

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

　　特点 3:配对编程

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

　　特点 4:小型发布

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

　　工具所扮演的角色

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



　　图2:DevTrack中定义测试任务工作流举例

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

　　以上案例中对所提到 4个敏捷特点都有所注解当然这是个可行方案而绝非唯

　　另外面对面沟通也是个很好敏捷操作但是实际上却不易实现客户或熟知商业逻辑同事通常是无法长时间和开发设计人员在起工作若定要面对面很可能会以高昂费用为代价更实际方式是通过定沟通平台(如些即时语音或视频通讯工具)来达到类似面对面沟通

　　无论采用何种方式沟通后结果都要能妥善地记录下来知识分类和历史记录会使清晰度达到最高进而使后来切活动包括编码、测试、分析等都变得容易

　　除了以上所提到工具软件Software配置管理、单元测试、软件Software基础架构管理等工具都是决定敏捷开发项目是否能够取得成功关键原因

　　总来说工具使用要能帮助敏捷团队(Team)达到下列几项目:能针对迭代进行灵活计划能管理需求变更能始终体现最终产品框架能将关键过程既用流程固化又随时可调整能对需求和供能点排列优先级能使各方沟通更加便利等等只有这样才能使敏捷思路方法真正受益于工具而不是受工具所累



　　链 接

　　配对编程

　　开发人员每两人组编写所有代码其中人作为“驱动者”关注是为实现眼前目标而涉及编码细节而另个人同驱动者道解决问题和规划更大图景这两个角色可以按需要进行轮换