我的敏捷观

    早在2009年，我已经接触了敏捷开发，我们的项目作为敏捷试点项目进行运作。一直到2012年，我参加的项目全部是以敏捷开发流程进行的。直到现在，公司引入敏捷，最大的好处是：随敏捷一起引入的优秀实践，虽然我们的培训材料上说，敏捷是思想和优秀实践的组合。当然我们现在已经知道，那些伴随着敏捷而来的优秀实践，并不是敏捷人士发明的，而是一直以来就存在于软件开发行业，只是我们不知道或者知道而没有实践而已。即使是这样，我认为敏捷把那些优秀实践打包并应用在项目管理和软件开发的整个过程，就凭这一点，已经让我们的公司获得了与之前完全不同的软件开发质量和效率。

    我在《真诚的程序员》中提到了我们之前的软件开发状况：无穷无尽的文档，主干上的版本无法编译，好不容易编译出版本，问题也一大堆，测试人员根本无法开展测试，更别提要进行回归测试了。这些问题在引入敏捷实践后就都很好的解决了。

    对于文档，敏捷尽可能的减少文档，对于我们开发人员来说，只要完成测试描述文档就可以了，当然这个是绝对必要的，相当于在编码前捋一遍需求，也防止编码时间过长后，无法回忆起需求的细节。而在编码后，只要对着测试描述文档，逐条用例测试一遍就可以了。这相当于是系统级或者模块级的TDD了。对于我们为什么没有采纳XP中的单元TDD，也许以后可以单独再谈。

    对于版本的问题，敏捷的持续集成（CI Continual Integration）可以很好的解决。只要有人合入代码，CI除了编译代码以外，还会对程序进行自动化测试，包括单元测试、集成测试、系统测试。测试用例全部通过了以后，代码才会最终合入主干，保证了主干代码的质量。同时，随着测试用例的完善，最终发布的版本质量也得到了保证，连回归测试也免去了。

    当然以上只是我们改进的主要部分，还有一些优秀实践：结对编程、早例会、回顾会议等，在应用中也起到了很好的作用。

    我是切身体会到这些优秀实践带给项目、带给产品的好处，这种体会对我这样经历过开发之苦的人感受尤为真切。虽然目前在敏捷推广上存在一些争议，例如在程序员杂志2013年第一期中周爱民老师的《敏捷：工程方法论的自优化机制》，他把敏捷比喻成”黑洞“，你实施得好，项目成功了，你就敏捷了；相反，那一定是你还不够敏捷。这有点像把敏捷放到了道德制高点上了，容不得你反驳。其实我们在实施敏捷的过程中，所有项目都是一边倒的成功，一边倒的支持敏捷。那时就有人提出来，难道就没有失败的例子吗？难道敏捷的一切对于我们来说都是好的吗？目前业界对于这些优秀实践基本还是持赞同的态度，只有TDD，反对的声音比较多。

    敏捷从来不是银弹，更何况那些从嘴里说出来的敏捷，光说不练假把式。把敏捷的优秀实践结合自身团队的特点，真诚的落地实施，我相信对于任何团队和项目都是有益的。这就是我的敏捷观。