为什么敏捷开发难于成功？

我大概是在2003年接触敏捷软件开发这个概念，之前无论是在学校的小打小闹项目，还是工作后的项目都是典型的瀑布式开发模式， 设计上自顶向下逐层分解， 设计、实现、测试、上线有条不紊。

除了大学时做的某个人项目， 客户在不停的提需求之外， 基本上没遇到多少需求剧烈变更的情况（可能和做的项目有关，不是定制化软件开发），所以觉得瀑布也挺好啊， 大学里《软件工程》这么课讲的瀑布开发还是很有用的嘛。

但是看到敏捷宣言以后，内心还是被狠狠的震撼了一下： 原来软件开发还可以这么做！

这个宣言是这么说的：

注意下面的小字：尽管右项有其价值，我们更重视左项的价值。

这17位软件开发的领军人物所做出的呐喊绝对刷新了我的软件开发三观： 

我们的终极目标是按时高质量的交付可以工作的软件， 不是编写那些非常容易过时的文档，也不是遵循严格的评审流程。  

客户要深度的参与到开发中来，我们会经常的给他们做演示，获取他们的及时反馈， 而不是到最后一刻才得知，我们做的并不是客户想要的。

我们欢迎需求变化(即使在项目的后期！) ，为了达到这个目标， 我们会采用迭代化的开发方式，经常的交付可以工作的软件。

了解理念之后， 很快我就接触到敏捷开发的一个重要流派： 

XP(极限编程)， 提出者是Kent Beck, 这哥们搞的更绝：如果一个编程实践很好， 我们就把它做到极致！

测试不是很好吗？ 那我们就测试先行， 用测试来驱动代码的生成， 这就是TDD。

代码评审不是很好吗？ 那我们就一边编程，一边评审， 两个人同时在一个电脑上编程，这就是结对编程。

......

我被XP给迷住了， 开始自学JUnit,   测试驱动开发， 重构代码这些编程层面的实践。

毫无疑问，这些实践确实能提升代码的质量，但是一直没有机会在一个团队中大规模的铺开使用。

到了2008年， 公司突然间要做敏捷转型，要实施Scrum, 于是又开始了新一轮学习，我这个XP粉丝刚开始还有点小抵触， 后来发现Scrum仅仅是一个框架而已， 我以前学的一些敏捷实践仍然可以运用到其中去。

有了新东西，大家忙活的热火朝天，设立product owner, scrum master。

学习把需求改成用户故事，拆分task,  创建燃尽图。

开Sprint计划会议， 每日站会，Sprint评审会，反思会等等符合Scrum的东西。

当然自动化测试，  自动化Build这些工程层面的东西也少不了。

热乎劲儿过了以后，我不由的困惑起来：这真的

是敏捷吗？

我们并没有因为采用Scrum而变得更好更快的交付软件，仍然是按照原来的节奏每年发布几个release。

我非常期待的特性团队，即一个团队中既有需求人员， 又有开发人员，还有测试人员，文档人员等并没有建立起来。负责需求的业务分析师和开发团队若即若离，测试团队还是按照自己的步点来干活， 无法深度的参与到完成一个用户故事的活动中来。

每个Sprint结束以后很难产生一个可供客户演示、甚至发布到产品环境的软件。

开发团队的本质仍然是老一套，还是依赖项目经理、或者team leader 去驱动各个developer去干活， 看不到自组织（self-directive）的力量。

对用户故事进行工作量评估的时候，大家还是关注资深开发和架构师的意见，做不到全员参与。

那个每日站会完全变成了一个汇报会，向项目经理汇报。

Sprint 说的是橄榄球比赛中的冲刺， 大家团结一致，为了完成该Sprint的目标疯狂向前冲。 实际开发中却很难体会到。

总而言之，我们似乎只是改了形式， 而没有改变精神。

2009年和2010年， 我也有幸走出去实施了几次敏捷咨询服务，包括工行广州开发中心，华为杭州研究所，鼎桥等等。 我发现不仅是我们， 大家都有类似的问题， 实施了敏捷形式而缺乏灵魂。

听起来很美好的敏捷软件开发很难落地，生根发芽，开花结果， 这些情况引起我的反思： 难道理想中的敏捷开发根本就不存在？  为什么敏捷开发这么难于实施？

经过一段时间的思考，我觉得实施敏捷最重要的有以下几点， 如果做不到这几点，敏捷是很难真正成功的：

1.  组织结构一定得变革

如果还是维持那种需求/产品团队， 开发团队，测试团队的方式，各个团队各自为政，老死不相往来的方式，敏捷肯定要失败。

由多种技能人员组成的特性团队是非常重要的，对小公司来说， 建立特性团队相对容易， 但对大公司来说，这简直就是一场革命，肯定要触动不少人的利益，有既得利益者的阻挠， 这是非常难的。

所以很多大公司也了解敏捷的好处， 在小范围内做了试点，然后说敏捷不错， 但现阶段还不适合我们， 最后不了了之。

2. 人的技能和意识一定得提高

先说技能，敏捷开发对团队成员的要求是提高了，而不是降低了。

开发人员要能写代码、写测试、做重构、做Build， 还得具备处理遗留代码的能力。 

写出的代码质量一定得高，扩展性强， 这样才能“拥抱”客户的变化，这比以前随便写代码，完成功能的要求不知道要高了多少。 

敏捷之前的团队有人专门做设计， 有人专门做开发， 敏捷之后这个界限模糊了， 大部分人设计和开发都得做， 对那些习惯做最基本开发的程序员是重大挑战。 

同样，开发角色和测试角色的界限也开始模糊，开发人员要能做些测试工作， 测试人员也要能协助做点开发工作。这样才能够在打仗的时候互相掩护， 奋勇冲锋。 一个人出了状况很快就有人能补上去。 

特性团队中的成员，最好是像军队中的特种兵那样强悍。

其次是意识，正如我前边所提到的，现在的很多团队成员主动性并不强，都是在被动的等待任务的分配， 也不敢大胆的提出自己的观点和见解， 这和敏捷开发的要求是相悖的。

有些公司在大量使用外包人员参与开发， 这些人在工作中就会出现上面的情况，  并不是贬低外包， 我也见过非常优秀的外包人员，  但是大部分人的主动性都不够，  敏捷开发是搞不起来的。

我记得华为有个很强悍的小团队，就几个人， 总是能把事情做的漂漂亮亮， 我相信无论用什么样的开发方法对他们来说都不是问题。 归根结底，还是人的问题。

对于想了解敏捷开发的同学，推荐几本书：

《硝烟中的Scrum和XP》：短小精悍，迅速了解敏捷软件开发。

《敏捷软件开发：原则、模式、实践》： 除了面向对象的设计之外，里边那个打保龄球的例子是个非常好的TDD案例。

《重构 : 改善既有代码的设计》： 敏捷编程实践中最基本技能。

《解析极限编程：拥抱变化》：XP的大师Kent beck的经典。

《用户故事与敏捷开发》 ： 描述用户故事的经典图书。

《敏捷估计与规划》： 主讲如何规划一个敏捷项目

《持续集成》：有点老，但是了解下敏捷开发的基石还是不错的。

（完）

你看到的只是冰山一角， 更多精彩文章，尽在“码农翻身” 微信公众号， 回复消息"m"或"目录" 查看更多文章

有心得想和大家分享？ 欢迎投稿 ！ 我的联系方式：微信：liuxinlehan  QQ: 3340792577