【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》

我大概是在2003年接触敏捷软件开发这个概念，之前无论是在学校的小打小闹项目，还是工作后的项目都是典型的瀑布式开发模式， 设计上自顶向下逐层分解， 设计、实现、测试、上线有条不紊。这不是一篇介绍敏捷开发的入门文章， 而是我学习、实施敏捷的一些感想， 如果你没有实践过敏捷软件开发， 不妨到文末看看书籍推荐。

我大概是在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的经典。

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

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

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