如何实施极限编程？

极限编程虽然是敏捷开发的一种主要方法，但真正实施极限编程的团队比率很低，只有可怜的7%（数据来源：《2021年度敏捷状态报告》）。是什么原因阻碍了极限编程的推广和实施呢？结合我们自身实施极限编程的经验体会来看，我觉得可能有如下的原因：

首先极限编程并没有Scrum和看板那么酷。Scrum会对流程有明显的改动，很容易让团队感知到变化。作为改革的推动者，Scrum教练也更能体现自己的价值。看板本身就非常强调可视化，所以在价值呈现方面有先天的优势。但是极限编程的实践更多的是集中在工程侧，流程方面相关的实践又与Scrum有相似的地方，不太容易体现自己的价值。

其次极限编程的实施需要长期的过程，坚持下来并没有那么容易。就拿极限编程里面最简单的实践编码规范来讲，相信每一个研发团队都有自己的编码规范，但实际的执行情况如何呢？我想大部分的团队是形同虚设吧。

还有些实践的落地实施比较有争议。极限编程大多是修炼内功，做内部质量，但这些对于交付项目和功能、满足交付时间来说，贡献在于长期，而短期看来是会影响交付日期的。

比如结对编程是一个很好的的实践，但很多团队的管理者第一反应就是：太浪费时间了，怎么可能用两个人的时间做同一件事呢？再比如测试驱动开发（TDD），有的敏捷教练会坚持认为不做TDD就不是敏捷。但在实践中，TDD除了写功能代码之外还要写测试代码，对开发人员对编码习惯和意识也是很大的挑战，时间上的投入也会比较多，这些因素都会阻碍TDD的推行。代码Review也是同理，这段时间并没有短期内的产出，在管理者看来就是花费了额外的时间。

有的实践落地实施起来比较有难度和挑战。比如重构，在没有充分的自动化测试覆盖的前提下，对现有的代码进行重构很可能是一件费力不讨好的事情。很有可能改了一个地方，反而引发了更多的问题——那就多一事不如少一事。

阻碍团队实施极限编程还有一个客观原因是研发团队普遍处在资源极度紧张的状态。时间和人力资源都要最大限度地做新功能，在这种状态下没有人会主动来做自动化测试、做重构。