我大概是在2003年接触到敏捷软件开发的概念，在那之前无论是在学校的小项目还是工作之后的项目，都是典型的瀑布式开发模式。设计自上而下，层层分解，设计、实现、测试、上线井然有序。这不是一篇介绍敏捷开发的入门文章，而是我学习和实施敏捷的一些感悟。如果你没有实践过敏捷软件开发，不妨阅读文末的书籍推荐。我大概是在2003年接触到敏捷软件开发的概念，在那之前无论是在学校的小项目还是工作之后的项目，都是典型的瀑布式开发模式。设计从上到下逐层分解。、实施、测试、上线有序进行。除了我大学做的一个个人项目，客户不断提需求外，基本上没遇到过很多需求的剧烈变化（可能和我做的项目有关，不是定制软件开发），所以我觉得瀑布也是很好。嗯，大学的《软件工程》课上讲的瀑布开发还是很有用的。但是看到敏捷宣言后，我的心还是震撼的：原来软件开发还可以这样啊！宣言是这样说的：注意细则：虽然右边的项目有价值，但我们更看重左边的项目。这17位软件开发领军人物的呐喊，无疑刷新了我对软件开发的三观：我们的最终目标是按时、高质量地交付可工作的软件，而不是编写非常容易过时的文档，或者不遵循严格的规范审查过程。客户需要深度参与开发，我们会经常给他们演示，得到他们及时的反馈，而不是到最后一刻才知道我们做的不是客户想要的。我们欢迎不断变化的需求（甚至在项目后期！），为了实现这一点，我们迭代开发，频繁交付工作软件。理解了概念之后，很快就接触到了敏捷开发的一个重要流派：XP（ExtremeProgramming），由KentBeck提出，这哥们更厉害：如果一个编程实践好，我们就做***！测试不是很好吗？然后我们会先测试，用测试来驱动代码生成。这是测试驱动开发。代码审查不是很棒吗？然后我们边编程边复习，两个人同时在同一台电脑上编程，这就是结对编程。......我被XP迷住了，开始自学JUnit，测试驱动开发，重构代码，这些编程层面的实践。毫无疑问，这些实践确实可以提高代码质量，但一直没有机会在团队中大规模铺开和使用。2008年，公司突然想转型敏捷，实施Scrum，于是又开始了新一轮的学习。作为一个XP的粉丝，一开始有点抗拒，后来发现Scrum只是一个框架。我在敏捷实践之前学到的一些东西在这里仍然可以应用。有了新东西，大家忙起来，立产品负责人，scrummaster。学习将需求更改为用户故事、拆分任务以及创建燃尽图。与Scrum保持一致，召开Sprint计划会议、每日站立会议、Sprint评审会议、反思会议等。当然在工程层面也少不了自动化测试和自动化Build。热度过去后，我不禁有些疑惑：这真的是敏捷吗？我们并没有因为采用Scrum而变得更好更快地交付软件，我们仍然按照原来的节奏每年发布几个版本。我期盼的特性团队，即需求人员、开发人员、测试人员、文档人员兼有的团队并没有成立。负责需求的业务分析师与开发团队分开，测试团队仍然按照自己的步骤工作，无法深度参与完成一个用户故事的活动。每个Sprint结束后，很难生产出一款可以供客户演示甚至发布到生产环境的软件。开发团队的本质还是一样的，还是靠项目经理或组长带动每个开发人员工作，看不到自我指导的力量。在评估用户故事的工作量时，大家还是会关注资深开发人员和架构师的意见，不可能所有员工都参与。每天的站立会议完全变成了汇报会议，向项目经理汇报。Sprint指的是足球比赛中的冲刺。大家团结一心，疯狂向前冲刺，完成冲刺的目标。实际开发中很难实现。总而言之，我们似乎变的是形式，而不是精神。2009年和2010年，我也有幸走出去实施了几个敏捷咨询服务，包括工商银行广州发展中心、华为杭州研究院、TDBridge等。我发现不仅是我们，每个人都有类似的问题，没有灵魂地实施敏捷形式。听上去很美的敏捷软件开发，实施起来难，生根开花结果。这些情况让我反思：理想中的敏捷开发是不是根本不存在？为什么敏捷开发这么难实施？经过一段时间的思考，我认为实施敏捷最重要的有以下几点。如果不能做到这几点，敏捷就很难真正成功：1.如果还维持需求/产品团队，必须改变组织结构，开发团队，测试团队，每个团队的方式我行我素，互不交流，敏捷注定失败。一个由具有各种技能的人组成的特性团队非常重要。对于小公司来说，建立一个特性团队是比较容易的，但是对于大公司来说，这简直就是一场革命，肯定会触及到很多人的利益。既得利益者阻挠是非常困难的。所以，很多大公司也明白敏捷的好处，在小范围内进行过试点，然后说敏捷好，但是现阶段不适合我们，还是算了吧。2.人们的技能和意识必须提高。先说技能吧。敏捷开发对团队成员的要求没有降低，而是提高了。开发人员必须能够编写代码、编写测试、进行重构和构建，还必须具有处理遗留代码的能力。写出来的代码质量一定要高，可扩展性要强，才能“拥抱”客户的变化。这比过去随便写代码时完成功能的要求要高很多。在pre-Agile团队中，有些人致力于设计，有些人致力于开发。敏捷之后，界限变得模糊了，大多数人不得不同时做设计和开发。这对于习惯于做最基础开发的程序员来说是一个很大的挑战。同样，开发角色和测试角色之间的界限开始变得模糊。开发人员必须能够做一些测试工作，测试人员也必须能够协助进行一些开发工作。只有这样，才能在战斗中相互掩护，勇猛冲锋。当一个人出现问题时，很快就会有人弥补。特色小分队的队员们都像军队里的特种兵一样坚韧。二是意识。前面说到，很多组员都不是很主动，被动等待任务分配，不敢大胆提出自己的看法和意见。这与敏捷开发不同。要求是矛盾的。一些公司使用大量外包人员参与开发。这些人在工作中都会出现上述情况。这并不是贬低外包。我也见过非常优秀的外包人员，但大多不够主动。敏捷开发是做不到的。我记得华为有一个非常强大的小团队，就那么几个人，总能把事情做的很漂亮。相信不管他们采用什么样的开发方式，对他们来说都不是问题。说到底，还是人的问题。对于想学习敏捷开发的同学，推荐几本书：《硝烟中的Scrum和XP》：短小精悍，快速了解敏捷软件开发。《敏捷软件开发：原则、模式、实践》：除了面向对象设计，保龄球的例子也是一个非常好的TDD案例。《重构 : 改善既有代码的设计》：敏捷编程实践中最基本的技能。《解析极限编程：拥抱变化》：XP大师肯特贝克的经典之作。《用户故事与敏捷开发》:描述用户故事的经典书籍。《敏捷估计与规划》：关于如何规划敏捷项目的讲师《持续集成》：有点老，但是理解敏捷开发的基石还是不错的。
