禅道博客

分享专业技术知识,文章内容干货满满

为什么必须要做极限编程?

2022-08-25 09:00:00
春哥
原创 93
摘要:从某种程度上讲,如果我们不严格执行极限编程,今天也许就只能对禅道进行修修补补了。
自2001年《敏捷宣言》发布之后,敏捷开发已经流行了20多年。这20年来,敏捷开发取得的成果如何?根据The Standish Group的The Chaos Report 2020,敏捷项目的成功率是远高于瀑布开发模式的,但尽管如此,仍有超过一半的敏捷项目是充满挑战、乃至失败的。其中的原因是什么呢?

根据《2021年度敏捷状态报告》,实施Scrum的占66%,实施Scrum + XP的有6%,仅实施XP的为1%,总体来看,做极限编程的只有7%。

禅道项目管理软件的《2020年IT行业项目管理调查报告》中也同样有类似的占比,实践极限编程的团队所占比例较低,为6.39%—— 国内外不同基数、不同人群的报告得出了相对一致的结论: 实施极限编程的团队比例较低


那我们是否可以做出一个推测: 这也许就是敏捷开发流行这么久,但失败的项目还是居高不下的原因之一。

我是在2004年的时候就接触了极限编程,跟团队一起开始尝试极限编程的实践。当时也只是执行了极限编程里面相对简单的实践,比如编码规范、集体所有权、small release、结对编程等,但实践下来的效果还是比较明显。那时候团队基本上保持了两周一次的发布,团队的积极性也很高,成就感也很强。

后来2006年我加入阿里巴巴,当时是在雅虎中国北京办公室,我们团队的Leader带着大家实践Scrum。虽然也是小步快跑的节奏,但是并没有实施极限编程相关的实践,实施下来之后就总感觉慌里慌张的,产品也没有保持持续改进的节奏,加班很严重。

后来自己创业,就组合使用Scrum + XP,严格地执行极限编程实践。这十三年下来,我们基本上保持了高频的发布,产品历经了N多次的重构(每个文件都动过的那种重构),产品也在不断地迭代,目前基本上可以保持在每两周发布新版本的健康频率,十三年来累计数据如下:

这数据的背后,与我们严格执行极限编程的实践是分不开的。从某种程度上讲, 如果我们不严格执行极限编程,今天也许就只能对禅道进行修修补补了。

那为什么我们会认为极限编程这么重要呢?可以尝试从如下角度来分析一下:

敏捷开发出现的原因是,随着时代发展,需求的变化越来越快,竞争越来越激烈。这种市场大环境的变化迫使团队也要快速响应变化,所以敏捷开发都强调通过小步快跑的方式来快速获得用户的反馈、通过及时快速响应来应对来自市场和客户的变化。

与以前相比,项目的周期被极度压缩,但质量又不能牺牲,那怎么办呢?
答案是:提高人的素质。
这样才可能 在时间被压缩的情况下,保证快速交付有价值、有质量的产品或服务——这才是敏捷

如何做到这一点呢?做极限编程。如果不做极限编程,只是单纯改变项目的迭代周期,是无法做到持续交付的。某些具体实践中,也许前几期迭代因为缩减了项目周期会显得比较快,再加上中国特有的“奋斗文化”,可以让项目看上去还算可以持续交付。但长期来看,这根本不可持续。2022年的各大互联网厂商的裁员潮也可以证明了这一点。因为没有极限编程的支撑,没有办法做到长期的持续交付。时间被压缩的情况下,靠人力的超规模投入(人员数量和时间)的方式,无法做到可持续发展。当行情不好时,只能通过裁员来达到“省”的目的。

所以我认为, 要想做好敏捷,极限编程是必要条件。从禅道团队的自身实践来讲,极限编程的推广可以循序渐进,从团队比较容易采纳的实践入手,比如编码规范。每个团队都有自己的编码规范,但有几个团队可以认真执行呢?对团队来说,编码规范这一点能够认真执行好,收益就很大了。编码规范可以是后续一系列极限编程实践的基础。比如,只有真正做到统一的编码规范,才有可能做到代码的集体所有权。请试想,如果一个团队中每个人都有不同的编码规范,能做到代码集体所有权吗?每个程序员都会说“这是谁写的代码,好烂啊”!再比如结对编程,如果结对的两个人编码规范都不一样,怎么做结对编程呢,不打架才怪。

所以大家不要觉得极限编程是一件很难的事,不必面对极限编程的诸多实践望而生畏。从最简单的实践入手并不难,但做好了就是一件收益很高的事。天下大事必作于细,做一分,就有一分的收获。
发表评论
评论通过审核后显示。