敏捷开发中应该使用那些敏捷工具

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

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

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

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

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

　　聊到软件开发中的工具，一般都会提到这个术语“应用程序生命周期管理(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)上，整个团队所有人都会围在白板前，分享所负责任务的进度，顺便挪动一下任务到相应的状态栏，用这种方式能够减少很多不必要的汇报型会议，而且团队成员也能很快地了解开发的整体状况。相信如果某个黄贴在白板上连着三天都没动，团队里一定会有人站出来帮忙的。(没有?!那还是先组织他们参加团队合作的培训吧。)

原文转自：http://www.ltesting.net