自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年的各大互联网厂商的裁员潮也可以证明了这一点。因为没有极限编程的支撑，没有办法做到长期的持续交付。时间被压缩的情况下，靠人力的超规模投入（人员数量和时间）的方式，无法做到可持续发展。当行情不好时，只能通过裁员来达到“省”的目的。
所以我认为，要想做好敏捷，极限编程是必要条件。从禅道团队的自身实践来讲，极限编程的推广可以循序渐进，从团队比较容易采纳的实践入手，比如编码规范。每个团队都有自己的编码规范，但有几个团队可以认真执行呢？对团队来说，编码规范这一点能够认真执行好，收益就很大了。编码规范可以是后续一系列极限编程实践的基础。比如，只有真正做到统一的编码规范，才有可能做到代码的集体所有权。请试想，如果一个团队中每个人都有不同的编码规范，能做到代码集体所有权吗？每个程序员都会说“这是谁写的代码，好烂啊”！再比如结对编程，如果结对的两个人编码规范都不一样，怎么做结对编程呢，不打架才怪。
所以大家不要觉得极限编程是一件很难的事，不必面对极限编程的诸多实践望而生畏。从最简单的实践入手并不难，但做好了就是一件收益很高的事。天下大事必作于细，做一分，就有一分的收获。