制约理论（Theory of Constraints，TOC，也称为限制理论、约束理论、瓶颈理论等）由以色列物理学家高德拉特（Eliyahu M. Goldratt）博士创立，与精益生产、六西格玛并称为全球三大管理理论。制约理论基于这样的假设：任何系统，无论它看起来多么复杂，都只受几个因素的支配，即组织由于一个或多个制约因素而无法实现其目标。识别出系统制约因素并相应地管理它们可以产生快节奏的结果并促进整个系统的和谐。敏捷或任何类型的软件产品开发中的制约因素可能是价值流中的某个团队或个人，该价值流经过“订单—生产—检查—交付”这种特性的过程生成（即价值的产生）。或者，限制因素可能是产品质量，因为质量差会阻碍快速交付。
TOC现已涵盖的领域包括：运营管理（包括生产管理）、供应链、金融、项目管理、配销、营销、零售、财务及业绩衡量、人事管理、策略及战术、教育以及医疗等。现在，专门通过敏捷在软件开发（但不仅限于）领域应用的视角，让我们了解一下TOC如何帮助敏捷软件开发让其应用更为行之有效。
TOC利用“聚焦五步骤”程序来打破制约因素。打破意味着不断改进系统，让现阶段的制约因素受到保护或改进，使它不再是制约因素。重复“聚焦五步骤”以不断打破各个制约因素，实现持续改进。
制约因素，需要和经常说的“瓶颈”进行区分。比如，将瓶子里的水快速倒出这个过程，目的是“将瓶子里的水快速倒出”。瓶颈是瓶子的颈部——决定着出水横切面积，制约因素是瓶子内空气的压力——限制着出水的速度（因为瓶内外空气形成的压力差，“吸附着”瓶内的水不让其留出）。如果能增加瓶子内空气的压力（比如使用一根吸管连通瓶内外的空气），从而打破对水的流出速度的限制——即打破制约因素，那么就能实现“将瓶子里的水快速倒出”。比起“扩张”瓶颈（比如换一个瓶颈宽大一点瓶子），打破制约因素需要额外的投资要少很多，同时还能实现快速获得收益。
本文模拟一个敏捷案例，对“聚焦五步骤”的每个步骤进行简单说明，看如何将制约理论应用于敏捷。
在软件开发中，无论是敏捷还是非敏捷，价值流是通过“需求—开发—测试—交付”这样的工序过程产生，这个过程存在一种依存关系——前一个工序的输出是后一个工序的输入。在敏捷中，习惯采用可视化工具（比如看板）的方式来跟踪价值流交付的全过程，如下图：
其中WIP（Work In Process，在制品）后面的数字为WIP限制数量，即在该工序正在处理的和已经处理完的任务的最大数量。如果处在某工序的任务数量达到了WIP限制数量，那么该工序就要停止从上游获取并处理更多的任务。
有些组织会将这种精益（看板）方法引入敏捷中，在敏捷持续改进的目标下追求“终极”精益的“单件流”理想方式，即WIP限制为1，从而加快价值的流动。精益方式可以让敏捷在持续改进的方向上更加主动，但下文我会谈及追求“单件流”的想法会面对的问题。
好了，案例的准备条件已经就绪，让我们正式进入讨论使用TOC的“聚焦五步骤”在敏捷软件开发中的应用。
第一步：识别系统的制约因素
想象一下用力拉扯一条很多环的链子，它会从哪里断开？在最弱的一环……假如这条链子的目标是要能够承受更强的拉扯力，我们要在哪里下功夫以便改善它的表现？应该加强它最弱的一环，也就是系统的制约因素。
再想象一下流水生产线的作业情况。生产线中有5名员工分别负责不同的生产工序，只有当5个工序分别完成后，才能生产出1件产品。他们的工作效率分别为每小时20个、15个、10个、12个和16个。那么在这一工序中，每小时可以生产多少件产品，是20件，还是16件呢？实际上都不是，每小时最多只能生产10件。这是因为在整个流水生产过程中，对整体工作效率起决定作用的并不是效率最高的员工，而是效率最低的员工。在这种情况下，我们该怎么办呢？从直观感觉来看，我们应该从最中间的工序出发，采取适当的措施来改进这个工序的效率，它就是制约因素。可以说，以制约因素为中心来改进工作效率是合乎情理的。换句话说，即使花费大量精力改进了非制约因素工序的工作效率，也无法提高整体的工作效率。
从表面上看，这第一步看起来非常简单。精益和敏捷的支持者将多种实践（比如ATDD、TDD、CI等）集合于敏捷实施的方案中，他们会很容易识别出反模式或不良做法，并在解决它们时“全力以赴”。比如发现没有可视化工具（看板）、不完整的Scrum框架、没有TDD/UT、没有ATC、没有CI/CD、没有用Story表达需求、Story没有AC等，然后迅速对这些发现进行改进（当然有些实践不会那么迅速落地，但团队始终会在落地的路上一直努力）。改进系统是一件好事……但，改进我们看到的每一个问题都不一定会改进系统——“即使花费大量精力改进了非制约因素工序的工作效率，也无法提高整体的工作效率”。
在软件开发中的敏捷支持者首先将组织的关注点落在了构建看板系统类似Scrum的一套包含多种实践组合的框架上。敏捷支持者往往过分关注交付系统（一整套流程的落地），却对业务层面的问题关注不足。假设制约因素是团队产能，并且识别到了某个瓶颈团队，敏捷支持者会非常容易意识到，可以通过提高其他团队（非瓶颈）的效率来弥补（或帮助）瓶颈团队损失的产能，这样做是有助于实现整体的目标。然后以这样的方式识别下一个制约因素，针对每个制约因素采用相同的执行步骤。虽然这种方式有效果，但这并不是最简单的方法。
看板中的WIP可以帮助敏捷团队比较容易地发现瓶颈。比如说当前的看板出现这样的状态：
通过上面的看板状态会很明显地发现，测试工序中和测试工序前（已完成的开发工作）堆积了很多需求，虽然每个工序都没有超过WIP限制，但能够发现测试工序中的“完成”一列已经空了，这直接影响到后续交付工序在完成正在进行的需求交付工作后没有更多的需求交付任务，从而增大了中断系统持续交付产出的概率。此时不能认为没有问题（没有WIP限制报警）或简单地认为测试工序进展的慢，从而认为测试工序就是制约因素，认为是测试工序限制着系统交付表现，从而做了一些错误的决定。
在这种情况下，有的团队会认为测试工序进展慢的原因是测试没有使用自动化测试或测试人员能力不足或测试人手不足，从而做出决定：增加自动化测试的力度、或增加测试人员能力的培训、或招聘（借调）更多的测试人手，或安排其他工序上的人手（比如开发人员）直接协助测试工作，这些决定都是需要额外投资的（虽然有些决定并不需要额外的预算成本），这些投资比起不用投资就能缓解这种情况的作法更加昂贵，而最后很有可能问题本质依然存在。
而有的敏捷团队会尝试去挖掘需求堆积在测试工序前的深层原因，比如，开发工序的产出速度真的高于测试的速度，或者是开发工序的产出质量低阻碍着测试工序，或者是开发人员和测试人员对需求的理解上未完全同步造成的偏差等。
正确地识别出制约因素，仅仅是给提升系统一个可能性。出自丰田的“五个为什么（5Why）”方法，经常在敏捷的“回顾会议”上被用来寻找类似制约因素的根源问题，但是仅用5Why法还不足够。如何正确识别出制约因素，TOC也给出了相应的方法——现状树（Current Reality Tree）和冲突图（Evaporating Cloud），这两个工具的使用说明不在本文范围之内。
第二步：决定如何挖尽系统的制约因素
当识别出系统的制约因素后，第二步要聚焦的是让你如何挖尽制约因素（的产能），这一步是非常容易跳过去的一步。通常会采取的步骤是增加投资，比如说看起来资源不够而决定投入更多资源（购买设备、增加人手或加班等）。这是非常容易犯的一个错误。
对现有的制约因素（的产能）进行挖尽，我们应该全神贯注的盯着制约因素，确认制约因素是否已经充分利用了，是否还能挤出更多的产能？例如，当员工休息或换班时，设备是否也停止生产了？当其他流水线的产品或零件误期时，设备是否也暂时停工了？在设备生产前是否进行质检避免经过这道工序是有缺陷的零件？由于制约因素会决定整体的工作效率，所以我们必须充分发挥这些因素的作用，以便在最短的时间内，以最快的速度提高整个生产线的产量。
制约因素的最大产能并不一定达不到外部对系统产能的要求，而是因为在制约因素上出现了很多产能浪费，最直接的方式就是观察制约因素的细节动作——哪些细节动作是直接影响制约因素的产能，哪些可以进行转移。浪费制约因素的方式有很多种，消除在制约因素上的浪费，系统整体表现就会得到提升。
下面的方式在敏捷软件开发中需要留意：
在待办事项列表（Backlog）中获取足够清晰的信息，这样就不会向制约因素（需求之后的工序）输入劣质需求。
确保提前很好地解决了所有依存关系，以不至于需求在某个工序上出现等待。
消除每天上下班所需的通勤时间——至少对那些制约因素团队而言是这样。
我们继续以下图的状态进行说明：
面对上图的情况，你会同意测试工序上的资源以加班的方式完成工作吗？你会赞同他们加班这一决定吗？
如果识别到测试工序是系统整体表现的制约因素，只要想办法加快测试工序的产能就可以直接提升系统的表现。根据前面说到，只要能消除在测试工序（制约因素）上的浪费，就可以打破限制。通过观察测试工序上细节行为后发现，浪费掉测试工序产能的并不是因为测试人员的能力，而是由于开发工序的低质量输出造成测试工序不断停工等待而导致无法完成测试工序上的工作——开发工序的低质量输出在不断浪费制约因素的产能。
不要破坏制约因素的输出，浪费制约因素的产能。例如，制约因素工序的输出可能需要集成另一个工序的工作以获得业务价值。如果另一个工序未能尽到自己的职责，那么就会在系统的制约因素上产生产能浪费。或者，如果推迟了产品的生产，或者搞砸了营销或销售过程，你可能会错过一个客户，从而浪费制约因素的努力。以上面的例子就是开发工序未尽到自己应负的质量责任，造成了在测试工序处的浪费，从而降低了整个系统的产能。
现在这种情况下（测试工序是制约因素），我们应该做的并不是增加自动化测试，也不是培训测试人员，虽然这些也可以增加测试工序的产出速度。应该做的是提高开发工序的输出质量，而不让测试工序上的工作因开发工序的低质量输出而中止。为了达到这个目的，我们可以加入相应的实践，比如单元测试、TDD、代码规范与评审、结对编程、用例演示等，这些实践并不需要额外的投资，虽然这些新加的实践可能会暂时拖慢开发工序的输出速度，但是可以提高开发工序输出的质量，同时促进测试工序的输出速度，从而保证交付工序持续地输出。这时要清楚，造成测试工序产能的浪费仅仅是开发工序的低质量，和需求与交付工序没有任何关系，任何在需求与交付工序上增加和投入的实践对整个系统的产能提升都是无效的——在制约因素上的浪费是产能上的浪费，在非制约因素上的浪费是投资上的浪费。
不要把时间花在他人能做的事情上——这是针对在瓶颈资源上的所有行为而言。要彻查瓶颈资源（制约因素上的资源）所做的一切行为。指派其他人来处理支持工作、文档、测试、估算、状态会议等都是他人能做的事情。考虑卸下一些私人事务，比如去取干洗衣物，帮其配偶买生日礼物，去学校或托儿所接孩子，去取午餐或晚餐。是的，你没有看错。这很可能比增加有技能的人手来缓解制约因素要便宜得多。这时不需要瓶颈资源的能力提升，而是将瓶颈上的行为重新组合。让瓶颈资源不去做那些非瓶颈资源有能力做的事，从而为瓶颈资源释放出更多的精力，这样瓶颈资源才会做瓶颈上应该做的事——这其实就是TOC对“聚焦（Focus）”的定义。
识别到测试工序是系统整体表现的制约因素，浪费测试工序产能的行为是测试人员将部分精力花在了准备测试数据上，并没有持续地执行测试用例。准备测试数据这个行为完全可以指派给团队其他人员（甚至是测试工序上的其他测试人员），与开发工序并行（或者在开发工序之前）准备好高质量的测试数据，到了测试工序时直接使用测试数据即可（节省了测试数据的准备时间，从而缩短了测试工序时间）。可以参考这篇文章以实际的案例进一步了解这种方式的有效性。在这种情况下，为什么在第二步不建议增加自动化测试？测试工序（制约因素）的产能不能达到外部对系统的产能要求是因为测试工序上存在浪费，在没有任何投资的情况下将这些浪费消除后，测试工序的产能则会大大提升，说不定已经满足了外部对系统的产能要求——即制约因素不再是制约因素，那么就没有必要在测试工序（已经是非制约因素）上面增加额外的投资（增加自动化测试）——非制约因素上的任何提升都不会转化成系统的提升。
经过对测试工序的提升，可能会慢慢沉淀下来一些实践和规则：代码审查、单元测试、结对编程、面对面沟通、用例演示等。这些都会形成一种习惯，在这些实践上长期安排（投资）了人员进行强化，“聚焦五步骤”最后一步警告我们，由于制约因素的转移（测试工序不再是制约因素）到下一个，使得这些没有额外投资的投资失去原有的效用。所以要想办法控制涉及制约因素的人员数量，并减少阻碍制约因素的规则。
第三步：使其它一切事情遵从上述的决定。
为了充分发挥制约因素工序的产能，必须确保非制约因素工序与之保持同步。在第二步做出了挖尽（制约因素）的决定，接着就要执行这个决定，需要系统内一切事情遵从挖尽制约因素这一决定。继续上文流水生产线的例子，如果制约因素工序每小时只能生产10个零件，那么其他非制约因素工序就算（提升）能生产30个也无济于事。由此可见，从最初阶段开始，就应该减少（在非制约因素工序上的）投入，按照10个零件的标准来生产。
从逻辑上讲，第三步是非常正常的，但实际操作起来，会遇到很大的阻力，可谓困难重重。因为企业一般都把生产效率作为评价指标，如果生产效率由每小时20个降为10个，就意味着生产效率降低到了原来的一半。从流水线负责人的角度来看，肯定会觉得难以接受。由于工作现场是充满变数的，再加上对市场需求缺乏及时的了解，很可能会造成一种错误假设，认为生产的产品越多越保险。就人类而言，存在这种思维方式是非常正常的。但实际上这种想法的危害是非常明显的，会给企业带来巨大的负面影响。在生产过程中，会造成大量的半成品库存积压，严重影响资金周转。
所有其他的决定都应该遵从我们如何管理制约因素的决定，这一步是最难的一步。应该确保每个人都知道制约因素在何处，如果制约因素需要协助，他们就应该放下正在做的事情，确保制约因素永远不必等待专家的协助。可以通过指定一个专家团队来完成：让专家呆在团队附近、确立明确的工作协议、重构代码或流程以消除对专家的依赖等等。比如应用Scrum框架的团队，现场PO（Product Owner）是一种很好的方法，随时会解答和确认Development Team在需求上的细节问题，而不需要让Development Team等待（离岸）PO上线后回复。这意味着你应该将许多管理需要（或习惯）遵从于制约因素，例如参加状态会议和提交报告。其他工序不需要产出很多，但每个工序的质量必须刚好足够，以避免浪费制约因素的产能。
比如，开发工序的低质量输出浪费了测试工序的产能，那么在引入一些实践以提高开发工序的质量时，开发工序的输出速度可能会下降，那么需求工序的输出就要做适当地控制，降低对开发工序的输入速度，不能按照之前的产出速度进行输出。
最后，在非制约因素工序中留出空闲时间。一个原因是他们可以处理计划外的工作。你不希望制约因素上游任何工序的人发现自己太忙，而饿死制约因素（上游非制约因素工序没有输出）或打破对制约因素团队的承诺（没能输出应该保证的质量或数量）。此外，一个使用繁忙的系统可能会更轻易让更多的工作流过制约因素，而让制约因素所依赖的团队感到竭力。不对系统的工作进行限制（限制非制约因素的效率和对制约因素的无效利用），系统中宝贵的资源就会不断浪费。
这里需要特别指出，效率在非制约因素工序中是可以牺牲的。比如开发工序单位时间可以产出5个需求任务，测试工序单位时间可以产出3个需求任务，很明显测试工序是系统的制约因素（如下图），开发工序是非制约因素。那么要求开发工序达到100%的效率指标（可能也还会要求需求工序达到100%的效率指标）对系统的整体表现并没有任何贡献，同时还会增加在测试工序前的WIP数量（WIP数量越高，价值的流动就会越慢）。敏捷通常采取的方式要让开发工序的WIP限制降低。
但也不应该要求开发工序只达到60%的效率——只达到下游测试工序的输入要求。根据墨菲定律——凡是可能出错的事就一定会出错，在整个系统中，制约因素比非制约因素的占比要少得多，墨菲攻击非制约因素的机率很大。如果仅要求开发工序只达到60%的效率，当墨菲攻击到开发工序时，开发工序的输出会降低到3个（需求任务）以下，那么测试工序的输入量将得不到满足，从而影响了系统整体的交付能力。所以要求开发工序的效率应存有一定的保护产能（比如要求开发工序的产出为4个）——为了保证在墨菲攻击时制约因素工序不会发生中断。
可以想象一下，如果所有工序（包括工序中的不同状态）的WIP限制为1——即精益的单件流（如上图），非瓶颈工序上是没有足够的保护产能的，墨菲在任何一个工序上的攻击，就会直接造成系统整体产出的损失。
这时（如上图），经过对制约因素的上游工序的输出限制（同时提高了对上游工序的输出质量的要求，从而保证不因质量问题造成浪费），达到了保护制约因素工序的输入。制约因素的上游工序会出现低效率的现象，那么这将是组织决定裁员的合适时机吗？
第四步：提升系统制约因素。
在确保其他一切遵从挖尽制约因素的决定后，已经把系统的制约因素充分挖尽，没有可能更多地利用制约因素了，这时需要做的事情就是集中精力采取一些提升的手段提高制约因素工序的能力。仅仅通过前三步就可以激发出潜能。一般情况下，大家往往觉得可以省略前三步，直接进入第四步，这种情况在敏捷软件开发中也非常容易发生。但是，在解决制约因素的问题时，并不是依靠单纯的金钱投资就能实现的，往往需要面对技术问题或者由于某种原因造成的长期顽疾，难以在短期内彻底解决。当然，有时依靠加大投资也可以解决问题，但这种做法大都需要投入大量资金，并且要承担较高风险。
例如，除了制约因素以外，其他的生产能力都有富裕，可以对制约工序进行支援。同时可以在前三步节省下来的资金进行投资。由此可见，前三个步骤是一个实践的过程。在这一过程中，可以在付出最小投资代价的条件下，创造出最大的成果效益。在最大限度地发挥制约因素工序的作用之前，如果一味地追加投资，很可能会导致无谓的浪费。因为需要额外投资，所以这一步是非常昂贵的选择，通常在投资后获得收益前会有一个延迟。这也是为什么这一个聚焦步骤比较靠后的原因。换句话说，真正科学的投资方法应该是，在最大限度地发挥制约因素工序的作用之后，再根据当时的情况决定是否仅且只能向系统的制约因素进行投资，——因为除了向系统的制约因素投资外，已经没有其他办法可以提升制约因素（的产能）了，而非制约因素因为有富裕产能，则不需要进行任何投资。
有许多方法可以提升制约因素，在敏捷软件开发中，针对第四步的一些比较好的方法是：
提供培训
改进工具
采用自动化
购买设备
加班
增加人员等
所有这些都会直接影响制约因素，并会在短期内会产生负面影响。如果提供培训，则会占用制约因素的正常工作时间，或者占用制约因素的额外工作时间。如果改进工具和采用自动化，则学习使用工具的投入和适应自动化环境的部署等都会占用制约因素的产能。因此，在实施第四步时，还要在团队建设、团队效率、认可和让人员对团队和老板（领导）感觉良好的事情上做一些投资。
由于学习曲线，花在培训上的时间、以及花在建立新工作站而不是生产所花费的时间，增加人手往往会在短期内降低制约因素的能力、效率和有效产出。更糟糕的是相互沟通的负担。根据布鲁克斯定律，增加人手会增加所需的协调能力，所以增加人手可能是你应该考虑的最后一个选项。
增加培训、改进工具、采用自动化等都是敏捷的支持者喜闻乐见的。这些选择需要额外的投资，但不要忽略第二步和第三步的提升效果。很多组织遵照聚焦五步骤进行打破制约因素来提升系统产能时，往往在第三步时制约因素就已经转移，还没有机会进入第四步，也就是还不需要增加额外的投资。那么看到这些喜闻乐见的实践时，我们是否有必要回头检视一下第二步和第三步的工作做得是否足够到位呢？这里存在着两个“是否”。
第五步：警告！！！！当一个制约因素被打破后，回到第一步，不要允许惰性成为系统的制约因素。
世界是在不断变化发展的。当你花费精力改进了制约因素后，制约因素很可能会转移到其他工序中。比如我们将制约工序的产量从10个改进到13个，这时整体工作的效率已不再受这个工序限制，而是受另一个最高产量为12个的工序限制，制约因素已经转移到了其他工序中。当制约因素这样移动而企业还没有准备好时，企业的表现就会直线下降，这也是“警告”二字之后有四个惊叹号的原因。
我们经常会用“持续改进”这个词，说起来非常简单，但实际做起来就没那么容易了。一般说来，前四个步骤（也是四个阶段）取得的成绩越大，就越容易产生懒惰情绪，变得安于现状，不思进取。对此我们应该警钟长鸣，尽量避免产生惰性，从第一个步骤开始，重新努力，以求取得更大的进步。
重复这个过程，但不要让惰性成为制约因素。高德拉特解释说：“我们不能过分强调这一警告。经常发生的事是，在我们的组织内，我们从当前制约因素的存在中衍生出许多规则。有时是形式上的，很多时候只是直觉上的。当制约因素被打破时，我们似乎不愿意回过头去查看这些规则。因此，我们今天的系统主要受到政策的限制。”
这也是实施敏捷组织容易忽略的一种情况：当制约因素为测试工序时，在提升测试工序的产能时制定的很多规则——应用在测试工序（制约因素）上的规则（以100%效率工作）和在开发工序（非制约因素）上的规则（不能以100%效率工作），并且形成了一种行为惯性。当制约因素转移到了开发工序后，之前的规则就会完全失效——以100%效率工作在测试工序（非制约因素）上不会对整个系统提升有任何影响，而让开发工序不能以100%效率工作的规则却限制着新制约因素的产能。这些规则成为最终的制约因素，只有打破这些制约因素（规则），那能识别出新的制约因素（开发工序）。
综上所述，在制约因素上的任何浪费都会转化成系统的浪费，在非制约因素上的任何提升都不会转化成系统的提升。而非制约因素远远比制约因素多，在非制约因素上进行改进的收益犹如只赚取了“一分钱”，而“一分钱加一分钱加一分钱加一分钱加一分钱加一分钱加一分钱加一分钱加一分钱仍然不足一角钱”。
制约因素仅是一个系统里百十个环节中的一个或几个环节，占比非常少，相对的非制约因素就占比非常多。一个系统中的解决方案是聚焦在制约因素上，所以产生了预期良好的效果。而随着时间的推移，制约因素被打破后（出现了新的制约因素），这个解决方案就会面临失效。在同一个系统中，因为时间阶段的不同，制约因素也会发生变化，那么同一个解决方案很难持续有效——去年的成功方案应用在此时，很可能就是失效的。而一个系统与另一个系统相比较可能会千差万别，即便是从系统的表征上看是相似的（产出都很缓慢的两个不同系统的制约因素会是相同的吗？）。在没有识别出当前系统的制约因素的情况下，去应用（甚至是重点参考）另一个系统的成功的解决方案（美其名曰——干货）至当前系统，因为制约因素和非制约因素的占比悬殊，这个解决方案能聚焦在制约因素上概率很小，很容易让系统聚焦在了非制约因素上，很努力地实施方案但从改进的效果看又似白费——“手术很成功但病人死了”。如果在你的系统中敏捷转型的效果不甚显著，那么慎重考虑一下你所实施的方案（敏捷实践）是不是聚焦在了你的系统的非制约因素上，是否分散了系统的精力去做了很多不必要的事情。
“他山之玉”真的不一定“可以攻玉”。网络上充斥的很多“干货”是非常容易吸引我们的注意力的，可是我们不能轻易地相信它而尽快将其应用在自己的系统中，做了适当调整后再应用可能也不行。这种“到处寻找提升”的方式是不能快速提升整个系统的产能的。常常有人说，敏捷落地难实施慢，认定“敏捷转型”是一个漫长的过程，这种“漫长”和把大多数“干货”或新的实践方法应用在非制约因素上是有着必然联系的。为什么我会下此结论呢？我们一起采用概率进行分析吧。假设在一个系统中有10个相互依存的工序（真实的环境中有相互依存关系的工序可不止这么多，对吧？），从物理的角度（TOC视角）观察这些系统，肯定有一个最弱的点（工序）——即瓶颈。也就是说，瓶颈仅占整个系统的10%，而非瓶颈占90%。从外部获得的一个好的实践（干货、方案等）直接（或适当调整后）应用到系统中来，作用在瓶颈上的概率是10%，同时在同一个瓶颈上又存在多种制约因素，那直接作用在核心制约因素上的概率肯定是小于10%的；另一方面，作用在非瓶颈上的概率将是90%以上。别忘记——在非制约因素上的任何提升都不会转化成系统的提升。那就是说，在没有识别出系统的制约因素的情况下，直接应用“他山之玉”在自己的系统中，可能会“落地”成功（应用中没有什么大的问题，可能要对“成功”做重新定义了），但90%以上的可能性（大概率的“失败”），整个系统的整体产能不会有任何提升。所以说，“到处寻找提升”的方式只是让那些外部方案能应用虽不会出事，但对于整个系统产能的提升，将是“漫长又困难的”。同时也可能从侧面印证一句古话——尽信书不如无书。
TOC“聚焦五步骤”为敏捷软件开发提供了更加精准、更加经济地提升能力，用TOC“聚焦五步骤”持续改进程序检视一下与敏捷（落地）实施有关的问题，这些问题全部扩展自一个核心问题——“正在实施的敏捷实践是否聚焦在系统的制约因素的改进上？”：
如果制约因素不是需求（工序），是否有必要花精力去培训需求人员写好一个Story？如果制约因素不是开发质量，是否有必要花精力让开发团队引入TDD/UT？如果制约因素不在交付（工序），是否有必要花精力去搭建CD？如果制约因素是测试（工序），是否应该让开发人员去帮忙执行测试用例，或是否说服团队开始采用ATC，或是否让测试人员去加班？如果制约因素是政策规则，是否有必要花精力继续抓开发团队的工作效率以保证考核标准？
好了，以上说明了让TOC的“聚焦五步骤”如何应用在敏捷软件开发中，并让敏捷软件开发的持续改进更加行之有效。
参考：
1. 《高德拉特问题解决法》 [日] 岸良裕司 著
2. 《醒悟》[以] 艾利·高德拉特 著
3. 《目标》[以] 艾利·高德拉特 杰夫·科克斯 著
4. 《抉择》[以] 艾利·高德拉特 著
本文内容会不断进行补充和勘误以持续改进。