项目敏捷跑起来---
序
TOC，Theory of Constraints，也称为制约理论、限制理论、约束理论或瓶颈理论，是由以色列物理学家高德拉特（Eliyahu M.
Goldratt）博士创立，与精益生产、六西格玛并称为全球三大管理理论。
TOC基于这样的假设：任何系统，无论它看起来多么复杂，都只受几个因素的支配，即组织由于一个或多个制约因素而无法实现其目标。识别出系统制约因素并相应地管理它们可以产生快节奏的结果并促进整个系统的和谐。敏捷或任何类型的软件产品开发中的制约因素可能是价值流中的某个团队或个人，该价值流经过“订单—生产—检查—交付”这种特性的过程生成（即价值的产生）。或者，限制因素可能是产品质量，因为质量差会阻碍快速交付。
TOC现已涵盖的领域包括：运营管理（包括生产管理）、供应链、金融、项目管理、配销、营销、零售、财务及业绩衡量、人事管理、策略及战术、教育以及医疗等。
现在，专门通过敏捷（但不仅限于敏捷）在软件开发领域应用的视角，让我们了解一下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/CD等）集合于敏捷实施的方案中，他们会很容易识别出反模式或不良做法，并在解决它们时“全力以赴”。比如发现没有可视化工具（看板）、不完整的Scrum框架、没有TDD/UT、没有ATC、没有CI/CD、没有用Story表达需求、Story没有AC等，然后迅速对这些发现进行改进（当然有些实践不会那么迅速落地，但团队始终会在落地的路上一直努力），这是因为精益和敏捷采取的是一种“处处改进”的方式。改进系统是一件好事……但是，改进我们看到的每一个问题都不一定会改进系统——“即使花费大量精力改进了非制约因素工序的工作效率，也无法提高整体的工作效率”。
在软件开发中的敏捷支持者首先将组织的关注点落在了构建看板系统类似Scrum的一套包含多种实践组合的框架上。敏捷支持者往往过分关注交付系统（一整套流程的落地），却对业务层面的问题关注不足。假设制约因素是团队产能，并且识别到了某个瓶颈团队，敏捷支持者会非常容易意识到，可以通过提高其他团队（非瓶颈）的效率来弥补（或帮助）瓶颈团队损失的产能，这样做是有助于实现整体的目标。然后以这样的方式识别下一个制约因素，针对每个制约因素采用相同的执行步骤。虽然这种方式有效果，但这并不是最简单的方法。
看板中的WIP可以帮助敏捷团队比较容易地发现瓶颈。比如说当前的看板出现这样的状态：
测试工序是瓶颈
通过上面的看板状态会很明显地发现，测试工序中和测试工序前（已完成的开发工作）堆积了很多需求，虽然每个工序都没有超过WIP限制，但能够发现测试工序中的“完成”一列已经空了，这直接影响到后续交付工序在完成正在进行的需求交付工作后没有更多的需求交付任务，从而增大了中断系统持续交付产出的概率。此时不能认为没有问题（没有WIP限制报警）或简单地认为测试工序进展的慢，从而认为测试工序就是制约因素，认为是测试工序限制着系统交付表现，从而做了一些错误的决定。
在这种情况下，有的团队会认为测试工序进展慢的原因是测试没有使用自动化测试或测试人员能力不足或测试人手不足，从而做出决定：增加自动化测试的力度、或增加测试人员能力的培训、或招聘（借调）更多的测试人手，或安排其他工序上的人手（比如开发人员）直接协助测试工作，这些决定都是需要额外投资的（虽然有些决定并不需要额外的预算成本），这些投资比起不用投资就能缓解这种情况的作法更加昂贵，而最后很有可能问题本质依然存在。
而有的敏捷团队会尝试去挖掘需求堆积在测试工序前的深层原因，比如，开发工序的产出速度真的高于测试的速度，或者是开发工序的产出质量低阻碍着测试工序，或者是开发人员和测试人员对需求的理解上未完全同步造成的偏差等。
正确地识别出制约因素，仅仅是给提升系统一个可能性。出自丰田的“五个为什么（5Why）”方法，经常在敏捷的“回顾会议”上被用来寻找类似制约因素的根源问题，但是仅用5Why法还不足够。如何正确识别出制约因素，TOC也给出了相应的方法——现状树（Current Reality Tree）和冲突图（Evaporating Cloud），这两个工具的使用说明不在本文范围之内。
第二步：决定如何挖尽系统的制约因素
当识别出系统的制约因素后，第二步要聚焦的是让你如何挖尽制约因素（的产能），这一步是非常容易跳过去的一步。通常会采取的步骤是增加投资，比如说看起来资源不够而决定投入更多资源（购买设备、增加人手或加班等）。这是非常容易犯的一个错误。
【工厂管理】项目敏捷跑起来---
