为何极限编程难以规模化，以及规模化敏捷的必备要素

极限编程落地之难，实际上不是难在学的这一方，而是难在教的这一方。关于「怎么教新手学编程」这事，极限编程有一个固化在其方法论内的实践：结对编程。而「结对」这事，实际上隐含了一个假设：新手与熟手的人数之比，不能高于1:1，否则就会出现新手没人结对的情况。

团队中新手与熟手的人数之比，或者叫团队的杠杆率，是影响极限编程落地的关键因素。

发源自美国的极限编程，隐含了一个对团队结构的假设：团队中新手的人数不多于熟手的人数（或者说，杠杆率不高于1）。这个假设在北美、西欧、澳洲的IT行业是普遍成立的。有位在德国的朋友说，他们团队的杠杆率低至1:3——即，熟手人数是新手人数的3倍。在这样的团队结构下，结对编程无疑能非常有效地向新手传递靠谱的工作方式、保持团队基本功水平。

然而「杠杆率不高于1」在中国的IT行业是一种奢侈。中国有太多软件开发团队，杠杆率是3:1、5:1，甚至8:1。在这样的团队结构下，熟手程序员无法与所有新手程序员结对，导致新手程序员缺乏指导和监督。尽管试图通过培训、流程、文档等方式来规范新手的工作，然而基本功的缺失仍然导致新手无法以合格的质量和效率完成应有的动作。 高杠杆环境下结对编程的不可行，是极限编程在中国难以规模化推广的根本原因。

很多团队尝试解决这个挑战的办法是，让新手只从事软件开发中某一细分环节的工作，例如只管编码，前面有人给他做详细的设计，后面有人给他做测试。 这是完全错误的做法。反复练习和从事某一细分环节的工作，无法使新手获得完整交付软件所需的基本功。这种办法造成的结果我们已经屡见不鲜了：哪怕经过1~2年的编码，大量的程序员仍然无法将需求转化为适当的软件设计、无法交付符合质量要求的软件产品。原因很简单：因为他们在工作中没有练习软件设计和质量保障。 这种按环节细分的分工方式，对于提升整个团队的基本功水平毫无帮助，这样做的团队注定被锁死在低效率、低质量的状态。

Royce第一次在他的论文里用这张图的时候，他就想说这样一个分工模型是不可行的 ↓

与熟手相比，新手程序员并不是不会理解需求、设计软件、保障代码质量，他们只是因为缺乏练习无法在较大的尺度上准确地进行这些动作。根据我的观察，对于4小时内能完成的需求颗粒，只需要稍加训练，新手就可以很好地解决，质量符合要求。由此可见，新手完全可以胜任软件端到端的交付任务。

然而，对于预期工作量2~3天的需求颗粒（正是用户故事一般而言比较适当的颗粒度），新手无法有效地将其拆分。更具体而言，新手无法对较大尺度的需求进行下列操作将其变成较小尺度的开发任务：

提出诊断性的问题，明确需求的范围和边界；

进行分析性思考，列举明确的需求验收条件；

运用概念性思考，用适当的对象模型映射需求。

可见，新手最缺的不是端到端交付的开发能力——这种能力，我们已经验证过，经过很短时间的训练即可具备。新手欠缺而难以快速获得的关键能力，是对较为复杂的问题进行明确、分析和拆解的认知能力。在高杠杆环境下的分工，必须基于这一关键能力的短缺来定义。

于是我们识别出在高杠杆环境下，规模化极限编程（以及，任何形式的规模化敏捷）的必备要素：

所有程序员，不论熟手还是新手，都进行端到端的需求交付；

通过比经典的用户故事更细的需求拆分，降低对新手的认知要求；

以少于4小时工作量的开发任务为基准，通过刻意练习快速训练新手的交付基本功；

起源

流派

视频

书籍

敏捷动态

培训

关于我们