敏捷软件开发绝不再是一个新名词了，但理解还是时时有偏差。敏捷宣言中的第一条“个体和互动高于流程和工具”，有人就误读为“有了沟通，一切都迎刃而解” ，因此花费大量精力整顿团队合作，却轻视了工具（技术）。其实宣言中的意思只是想强调个人和沟通更重要而已。

实际上，既然是软件开发，在所难免得面临工具的选择，而且很多优秀软件实践离开强有力的工具支持都玩不转。在如今的软件开发世界中，工具（这里谈的是软件工具）层出不穷，数不胜数，那么到底该怎么去选择适合的工具呢？

本文将根据我十几年的企业级软件开发经验给出一点建议，和大家一起来探讨敏捷和工具（特别是在企业实施中的工具）这个话题。

为了避免不必要的麻烦，文中尽量用开源软件作为介绍，但这并不是说我排斥商业软件，恰恰相反，在很多时候，只有商业软件才提供了你需要的功能（当然大部分情况下开源软件会很快迎头赶上）。

背景知识：应用程序生命周期管理

聊到软件开发中的工具，一般都会提到这个术语“应用程序生命周期管理（Application Lifecycle Management ，ALM）” ，说句老实话，有点烂，谁都想把自己往上靠，谁都有自己的一套说法，图1为我心中贯穿企业开发项目全程的ALM全局观。

图1中列出了ALM中的各个子系统，以及我略有研究的相对应工具的名称，让我们一起先来简单地过一遍整个过程。

图1 开发项目中应用程序生命周期管理及其工具

产品开发始于一定的需求，需求有好几个层次，从产品需求到项目需求，进而产生出用户故事（User Story）， 然后团队会分解出任务（Task）。团队开发者利用IDE（如Eclipse）去完成相应的代码，单元测试完成后，再推送到代码库（git），这些和软件配置管理（Software Configuration Management，SCM）相关。

构建系统会从代码库中获取最新的代码，进行编译、打包、功能测试和系统测试，可以设置在质量系统中显示一些相关信息，如果一切顺利，甚至能直接上传到在线系统更新上线。此外不管是开发中还是运行中一般还都会有一个缺陷管理系统。

BugZilla大家应该很熟悉了，用Redmine的人少一些，但它实际上是一个非常灵活的项目管理系统，国内也有越来越多的公司在使用了，Nexus是一个Java软件包的管理工具，需要和Maven结合使用，Sonar是一个Java项目的质量控制工具，它集成了如单元测试、覆盖率、静态质量检查等内容。为什么任务管理下的Redmine有红叉呢？我们稍后会解释。

限于篇幅，本文只会谈到其中的一部分工具。作为参考，可以阅读Manning出版社的新书《Agile ALM》，它对SCM、单元测试、功能测试等话题进行了更深入的探讨。

敏捷中有些工具是必需的

如果你说敏捷实施大半年了，但持续集成 (Continuous Integration，CI）服务器却还没有架起来，那我实在是不晓得你都在敏捷些啥东西了。无论你究竟“信仰”哪种敏捷，产品开发各个方面的自动化（Automation）和持续集成都必不可少。要了解持续集成，可以看看Martin Fowler的文章，可谓白皮书级别的经典，有中文翻译版。

使用CI就一定会用到CI服务器，可选的有很多，其中Jenkins是现在最流行的一个，而且架设起来也很方便。它是从Hudson继承而来（自从2011年5月Oracle决定把Hudson捐献给Eclipse组织，两者的关系和将来的发展方向也可能带来更多变数）。

在Jenkins构建服务器中，可以定义任务（在Jenkins中叫job），以完成一些构建步骤（如签出代码、编译、各种类型的测试、打包等），它有极丰富的插件（plugin）资源作为支撑，可以来集成产品软件开发的各个要素，它把你所需要的一切都自动化起来。

图2 Jenkins项目自己的Jenkins构建服务器

在Jenkins构建服务器的首页，每个任务还都有一个天气图标表示其状态，非常直观，例如“太阳”就代表着一切正常（至少从构建结果来看）。它是产品项目开发的晴雨表，项目状态是否正常一目了然。不管是对Jenkins不了解还是想提高，我强烈推荐阅读John Ferguson Smart的Jenkins开源书：Jenkins: The Definitive Guide。

对敏捷来说，并没有“CI服务器要还是不要”一说，它就是必须的，一定要好好地实施。基于持续集成再往前走，就是持续交付（Continuous Delivery）了，这也是敏捷的一个新热点，其中加入了很多新元素（如自动化验收测试、持续部署等）。

别让工具牵着鼻子走

工具很重要，但会不会有些误区呢？当然有，我们一起来看个我经常碰到的一个例子。

讲到敏捷实施一直都会提到白板（Whiteboard）的使用，先得提醒大家，它也是一个“工具” ，白板的其中一种用法叫任务白板，主要是提供给团队使用的。

图3 每日例会用的任务白板（图来自《硝烟中的Scrum和XP 》一书）

图3就是常见的任务白板，团队的需求，一般是用户故事（User Story），被放在最左边一栏“NOT CHECKED OUT”，作为团队一个迭代的输入，然后分解成任务（Task）用报事贴（俗称黄贴）贴在白板上“CHECKED OUT”那一栏，并签上自己的名字，就算是领任务啦。当做完了一个任务就把它（黄贴）挪到下一栏“DONE！:o)”，代表做完了，最右边一般还会留出部分空间，用来记录进度条和注意事项来提醒团队一些重要的事情。

如果说Jenkins构建服务器是产品开发的晴雨表，那么任务白板就是团队开发的晴雨表。

一般一大早在每日的站立会议（Daily Standup Meeting）上，整个团队所有人都会围在白板前，分享所负责任务的进度，顺便挪动一下任务到相应的状态栏，用这种方式能够减少很多不必要的汇报型会议，而且团队成员也能很快地了解开发的整体状况。相信如果某个黄贴在白板上连着三天都没动，团队里一定会有人站出来帮忙的。（没有？！那还是先组织他们参加团队合作的培训吧。）

有时候团队坐得比较分散，或者有人喜欢流行的在家办公方式，这时可能会开始使用一些图形化的电子白板来管理团队任务，大家对着屏幕介绍进度，效果似乎还不错，其他人（包括经理们）也非常高兴，因为他们可以随时从网上了解到团队的进度了。慢慢地，面对面的时间看起来也可以节省下来，只要窝在座位上点点鼠标，挪挪电子黄贴（如果支持漂亮的拖拉就更好了）就已经足够了。

这是敏捷的好实践吗？

是否嗅到了一点怪味道？它就是我想谈的工具带来的误区，电子白板会削减团队之间的沟通，降低团队的透明度，违背了敏捷重视人和团队的原则。如果你的团队成员不经常去更新电子白板上的任务时间，慢慢地你看到的都是不太准确的信息了。有人可能说我们还是面对着电子白板开每日站立会议呀，那我希望你有个很大的屏幕吧（否则这样子效果会更差）。

那为什么没说它不对呢，因为在一些场合下，它还是有作用的。关键是团队要能充分认识到它的局限性，因此我极力反对在团队组建初期用电子白板，可以等团队充分领会到敏捷中人与人沟通的重要性后再引入。

这也是在图1中特意用红叉提醒不要用Redmine来管理任务（这个白板功能的插件也很差，因为没人用）。

所以要了解你的需求，不要让一些工具牵着鼻子走，要了解敏捷实施的目的，否则出了问题还以为工具不到位，拼命要更强的功能，结果陷入大误区。

有些工具会带来意想不到的好处

传统的敏捷著述中通常会提到CI的部分，然而工具的运用并不限于此，例如我在实际项目中用到的Gerrit，它非常契合敏捷的宗旨，也给我们带来了意想不到的好处。

代码审阅是一个不错的敏捷开发实践，让人非常头疼的是实施。大企业中通常是制定出一大堆相关的规范和流程来指导代码审阅。我听说好多公司都会把代码打印出来，进行走读，这可真是累啊。这种方式会给人不信任的感觉，而且应该是挺浪费时间的。

结对编程（Pair Programming）也是非常好的一种代码审阅的方式，值得好好地学一学，只是我对它并不太感冒，体会是在大企业实行结对编程的难度很大，当然如果能找到合适的推动者，那还是可以尝试尝试的。

那看看开源社区是怎么解决这个问题的呢，使用的又是什么工具呢？Google的Android系统是现在非常热门的开源项目，它的代码审阅（包括贡献者的代码）使用的是Gerrit，非常棒的东西，在自己的企业中架设起来也非常方便，我一用就爱上它了。

Gerrit是一个基于Web的代码评审和项目管理的工具，面向基于Git版本控制系统的项目，所以如果你没用git（干嘛不用呢），就没法用Gerrit了，接下来来看看在Gerrit中怎么实施代码评审的。

• 首先开发者（贡献者）的代码变更通过 git 命令被推送（push）到Gerrit管理下的Git 版本库，推送的提交转化为一个一个的代码审核任务（见图4）。
• 代码审核者可以通过Web界面查看审核任务、代码变更，通过Web界面做出通过代码审核（Review）或者拒绝（Reject）等决定。
• 测试者（一般可以设定为CI服务器执行）可以通过访问来获取（fetch）代码变更进行相应测试，如果测试通过，就可以把这个评审任务设置为校验通过（Verified）。
• 最后经过了审核（Review）和校验（Verified）的代码变更可以通过Gerrit界面中提交动作合并到版本库的对应分支。

相比代码走读，它的好处在于，审阅动作发生在向主干提交代码前，可以只看变更的部分显得很贴心，网上随时随地审阅起来也很方便，这也是有别于结对编程的一个好处。

任何人都可以审阅提交的代码，整个团队的代码都一目了然，审阅起来更方便，非常符合开放、透明的敏捷精神。使用之后能够显著提高代码质量，甚至于等到习惯了以后，代码不被审阅一下，都觉得实在是不好意思提交代码到主干上去。

Gerrit中，通过特定分支，任何审核任务的代码变更都能访问，所以如果需要细看或是合并到本地都异常方便。

Gerrit刚开始实施可能会有点不习惯，毕竟整个工作流有所变化，因此实施时需要通盘考虑。

如上只是近期我特别喜欢的一个工具，其实类似的工具还有许许多多，这不过是沧海一粟而已。

总结

水能载舟，也能覆舟，工具和敏捷的关系亦如此，下面我给出几点建议：

• 积极尝试新工具，如今的软件开发世界中，工具层出不穷，要不断与时俱进，了解最新动向和如何用有效的工具去辅助敏捷的实施，在自己的软件开发环境中去尝试和了解这些工具，尝试这一点很重要，不要只看说明或戴有色眼睛去看待这些工具，应该通过实践摸索找到最适合你的选择。
• 人总是第一位的，要了解你的团队，了解他们的需求，有些时候甚至可以为了团队，冒险一下采用新技术、新工具，这样可以提高团队的凝聚力（敏捷要素之一）。我待过的一些部门推动Git时，就是这么来的，很多时候过多的讨论其优缺点反而是浪费时间，不如多花点时间多试试。
• 实施敏捷也离不开组织的支持，特别大型企业涉及到的人很多（可能水平不一），这时候推动者就必须用专业的手段建立一个持续渐进的工具引入过程，这样会使得实施更容易些。
• 唠叨这么多，实际上也只是讲到一些皮毛，还有很多东西需要我们继续研究下去，本文得到了《Maven实战》作者许晓斌，敏捷宣言简体中文版翻译的协调者徐毅，敏捷之旅中国组织者滕振宇和同事代鹏的帮助，他们提供了很多宝贵的意见，特此致谢！