掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务

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

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

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

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

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

(完)

 更多精彩文章,尽在“码农翻身” 微信公众号

微信截图_20170112153212.png

原文来自:码农翻身

声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com

0512-88869195
数 据 驱 动 未 来
Data Drives The Future