极限编程虽然是敏捷开发的一种主要方法，但真正实施极限编程的团队比率很低，只有可怜的7%（数据来源：《2021年度敏捷状态报告》）。是什么原因阻碍了极限编程的推广和实施呢？结合我们自身实施极限编程的经验体会来看，我觉得可能有如下的原因：
首先极限编程并没有Scrum和看板那么酷。Scrum会对流程有明显的改动，很容易让团队感知到变化。作为改革的推动者，Scrum教练也更能体现自己的价值。看板本身就非常强调可视化，所以在价值呈现方面有先天的优势。但是极限编程的实践更多的是集中在工程侧，流程方面相关的实践又与Scrum有相似的地方，不太容易体现自己的价值。
其次极限编程的实施需要长期的过程，坚持下来并没有那么容易。就拿极限编程里面最简单的实践编码规范来讲，相信每一个研发团队都有自己的编码规范，但实际的执行情况如何呢？我想大部分的团队是形同虚设吧。
还有些实践的落地实施比较有争议。极限编程大多是修炼内功，做内部质量，但这些对于交付项目和功能、满足交付时间来说，贡献在于长期，而短期看来是会影响交付日期的。
比如结对编程是一个很好的的实践，但很多团队的管理者第一反应就是：太浪费时间了，怎么可能用两个人的时间做同一件事呢？再比如测试驱动开发（TDD），有的敏捷教练会坚持认为不做TDD就不是敏捷。但在实践中，TDD除了写功能代码之外还要写测试代码，对开发人员对编码习惯和意识也是很大的挑战，时间上的投入也会比较多，这些因素都会阻碍TDD的推行。代码Review也是同理，这段时间并没有短期内的产出，在管理者看来就是花费了额外的时间。
有的实践落地实施起来比较有难度和挑战。比如重构，在没有充分的自动化测试覆盖的前提下，对现有的代码进行重构很可能是一件费力不讨好的事情。很有可能改了一个地方，反而引发了更多的问题——那就多一事不如少一事。
阻碍团队实施极限编程还有一个客观原因是研发团队普遍处在资源极度紧张的状态。时间和人力资源都要最大限度地做新功能，在这种状态下没有人会主动来做自动化测试、做重构。
极限编程实施的效果也很难度量。现在的研发团队普遍缺少有效的度量体系，所以实施极限编程前后的变化很难让团队和公司的管理层认知到。
总结下来，一个并不是那么酷的方法，容易做的不容易坚持，有挑战的又做不来，即使做下来效果又没有那么明显，再加上时间又很紧，所以很少有人采用也是常理。
尽管极限编程实施起来有各种的困难，团队更应该实施极限编程，而且应该尽早实施。一个团队要想做到持续交付，工程能力是基础。极限编程是目前市面上提升研发团队工程能力最有效办法。通过实施极限编程，提高团队的工程交付能力，可以在竞争
建立自己的优势。而且极限编程是一种复利型的投资，越早实施，回报率越高。
那么应该如何做来真正实施极限编程呢？
首先极限编程需要一位对团队有足够影响力的管理者来推动。如果有可能的话，这个角色最好是CTO这样level的管理者。只有自上而下的推广，才有可能真正促进极限编程实践的落地。毕竟做极限编程是需要做一些资源投入，如果高层不给足够的支持和授权，单纯靠研发团队自发推动，是很难坚持的。
其次逐步实施极限编程。实施极限编程不会对现有的项目管理流程进行变革性的改动，团队可以从比较简单的实践开始，到逐步采用比较复杂的实践。比如编码规范、代码集体所有权等，都是比较简单易行的实践，而且实施效果比较好。而有一些比较有挑战的实践，则可以先从细小的地方开始。比如持续集成，我们可以先做到每日提交。只要能够及时更新代码并将自己的改动提交到库里面，其他同事也及时更新代码并及时提交，这就是一个集成的过程。再比如TDD，可以先从单元测试开始。如果单元测试还有难度，可以先从整理测试用例开始。
通过整理测试用例，培养开发人员的测试意识。当一位开发人员有了测试意识之后，再来写代码的时候就会有相应的标准，从而写的更稳重、更严谨。
把“公司要求做极限编程”变为“我要做极限编程”。可以在平时的迭代过程中，给团队预留一定的时间，让大家来尝试一些以前没有做过的实践，并鼓励大家在团队内部进行分享。每个团队都会有比较积极活跃的开发者，他们也会有提升自己的诉求。只要给他们一些支持，他们会很乐意尝试新东西的。万事开头难，只要有人开始做，就可以慢慢地影响其他人。
积极地推进结对编程和代码评审实践。如果一个团队决定开始做极限编程，在做好编码规范的前提下，可以积极推进结对编程和代码评审。这两个实践非常有利于好的规范、知识和经验在团队内部传承。我们团队的结对编程和代码评审是常态，随时都会进行。
万事开头难，决定了就去做，一份努力就有一份的收获。种一棵树最好的时间是十年前，其次是现在，实施极限编程，任何时候都不会晚。
