分享、发现微信公众号

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

2017-01-09码农翻身

前言: 这不是一篇介绍敏捷开发的入门文章, 而是我学习、实施敏捷的一些感想, 如果你没有实践过敏捷软件开发, 不妨到文末看看书籍推荐。


我大概是在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


公众号:码农翻身

“码农翻身”公众号由工作15年的前IBM架构师创建,分享编程和职场的经验教训。


提交公众号
工作15年的前IBM架构师分享好玩有趣的编程知识和职场的经验教训, 不容错过.

码农翻身的二维码

微信扫一扫

码农翻身的标签

广告一下^_^