这是一个有关软件重构项目的真实故事。为了公司业务保密和方便不熟悉软件项目的读者们阅读，故事内容稍作修改。

BMS系统是一家企业的后台系统集群当中占据着绝对重要位置的子系统，直接影响着客户服务部门对客户的服务效率和水平。因为计算机系统环境的升级，两年后将不再支持BMS系统当前版本的运行，所以需要尽快重构BMS系统。重构项目已经两次交付延期，正准备提出第三次延期交付申请，客户已经非常着急。

公司不得不再次派项目经理C出手援助。C是一位TOC理论爱好者，在项目管理方面有自己独特的见解，对一些形势严峻的项目的援助经常屡见奇效。

BMS系统的现任项目经理M曾经是维护BMS系统的一名高级开发人员，后被提拔任命为BMS系统的项目经理，后考取了PMP认证，负责管理BMS系统和开发团队已经好几个年头。

在开始重构BMS系统前，公司极其重视，特批了的M的多个申请——为了提高团队的开发效率，给一部分人升级了机器配置，如扩充内存、升级SSD硬盘、更换宽屏显示器，有的直接更换成全新的机器，双显示器已是团队工作的标配。同时，部分人的新装备和新机器正在采购流程中，招聘补员也是优先考虑BMS团队的人员需求，前期缺的几名测试人员也已经补齐。但即便如此，半年多时间已经过去了，核心模块还没有完成交付。

公司和C得到M的工作汇报：

“我根据PMP做了很多尝试，项目现在难以把控，团队成员每天都在加班、都非常忙，希望能向客户提出最后一次延期。

“现在项目主要在内部测试，测试人员一旦发现缺陷后，将缺陷记录至缺陷追踪系统，开发人员就会及时获取并开始修复，开发人员同时还继续写着一些小功能。缺陷追踪系统中有几百条已经被开发人员标记为“已修复”的缺陷，等待测试人员进行验证，同时部分新提交的小功能也在等待测试人员开始测试。

“非常明显，测试工作进展缓慢，成了项目的瓶颈。测试人员的加班已成必然，同时已经从其他团队临时调来两名测试人员协助。为了随时能修复测试人员发现的缺陷，开发人员也一同加班，从而不影响整个项目的进度。

“我觉得很难进行进一步的改善，我希望能借调更多的测试人员来协助，而不是项目经理。”（估计M认为项目经理是不干活的人吧。）

C听完M的总结汇报，并没有和M进行过多的讨论。C明白，和管理思维不同的人进行讨论如何管理项目只是在浪费时间，C对此已颇有体会——就在半年多前的一个援助项目中，C就与另一个项目经理进行过一次无果的讨论。C虽然对BMS系统的业务不甚了解，但是凭多年的项目管理经验，C认定项目进度的最佳表现指标应该是标记为绿色的“PASS”的测试用例数量持续地出现。

C正式进入项目。第一天C同团队一起加班时，观察了测试人员E执行一个测试用例的完整流程：

测试人员E在左屏上切换到已经加载好BMS系统核心模块界面，刷新后，随即切换到打开的测试用例文档，将其中一条测试用例从头到尾看了一遍，然后转向右屏。测试人员E在已经打开的数据库查询软件中，在打开的好几个标签页里选中了一个（每个标签页上显示着查询文件的名字），几十行的数据查询语句展示了出来（这些语句都是在测试之前的项目时团队积攒下来的）。测试人员E在几十行语句中找到并执行了其中一条，不到两秒钟多行数据结果集就显示了出来，借助横向滚动后，复制了在结果集右半部的一个数据。测试人员E又选中另一个标签页，在几十行语句中好像没有找到，向上滚轮动屏幕后才找到一段语句。测试人员E将刚复制的数据粘贴到这条语句段末尾后执行，这次多等了几秒钟才出现了结果集，和之前一样，迅速复制了结果集中一个数据。测试人员E迅速转向左屏，熟练地从测试用例文件切换至已经刷新好的BMS系统界面，测试人员E将复制的数据粘贴到界面顶端的一个文本框中，点了一下带有查询图标的按钮，系统弹出正在查询的友好提示大概几秒钟，数据就布满了屏幕。这时测试人员E好像有一点喜悦。她复制了一个数据，再次转向右屏，选中一个标签页后再次找到一条语句段，将复制的数据粘贴到语句段末尾并执行，几秒钟后就显示出了结果。此后，测试人员E开始在左屏和右屏之间来回转头进行数据验证，充分利用了双屏优势，从而减少了在一个屏幕上来回切换界面的时间。最后，测试人员E在左屏上切换到测试用例文档，将那一条测试用例标记为绿色的“PASS”。测试人员E此刻显露出非常高兴的表情——这个测试用例验证的很顺利，没有发现任何缺陷。

C大概计算了一下，从第一步开始准备BMS系统界面开始，到最后绿色的“PASS”大概10分钟左右。C同时猜测，开发人员可能也是用类似的操作流程来进行自我工作检测的。在当晚加班结束前，C得到了几名开发人员的口头证实C的猜测。C这次观察到的正是TOC理论中提及的“活跃的瘫痪”。

第二天一早，C告诉公司领导：通过昨天的观察，C认为存在大幅改善的机会，决定取消第三次延期交付申请，并停止从其他团队借调更多测试人员的行动。（公司领导非常高兴，因为他们正在为怎样从其他项目中调配测试资源而头疼。）

随后，C和团队所有成员开会，会上C提出两个调整，在对调整内容作了解释和原因说明后，团队所有成员一致投票通过。C提出的两个调整如下：
1. 将核心模块以开发主导的“模块”需求方式改成以测试主导的“独立业务线”小需求方式进行拆分，拆分工作由全体成员一起参与进行；对拆分后的小需求进行优先级排序，集中完成优先级最高的小需求进行交付后，再开始实现下一个小需求；
2. 将“独立业务线”小需求拆分成多个小任务，一个小任务对应一个“测试用例”，安排一名熟练的开发人员和一名熟练的测试人员专门提前为每个小任务准备3份测试数据，一份用来开发自测，一份用来测试验证，一份用来发现缺陷后的修复验证。数据没有准备好时，任务不能释放给其他人员，其他人员也不必再重复找测试数据而花费额外的时间。之前发现的缺陷进行分类后放置对应的小需求中一并修复或验证。小需求中所有小任务对应的测试用例被标记为绿色的“PASS”后，小需求被视作完成，进行发布交给验收团队验收。

C随后说服验收团队：验收团队不再等到大量的需求功能集合完成交付才开始验证，而是接受小需求发布方式进行不断验证。

经过以上调整，标记测试用例状态为绿色的“PASS”的速度越来越快，每个小需求的完成时间大幅缩短，团队可以对每个小需求的交付验收时间进行承诺；新的测试缺陷数量有明显下降趋势，即使发现新的缺陷也是非常容易修复的；验收团队发现的缺陷数量也较以往的项目明显下降，即使有新的验收缺陷也会在下一个小需求的发布中迅速修复；团队成员不再充当业务的螺丝钉，每个人都提升了对业务的理解和掌握；大量的加班逐渐消失了，团队开始了有规律的工作节奏。

一个多月后，核心模块全部交付，虽没有赶上最初不延期的项目完成计划，但如C所言，不需要第三次延期交付申请。

在这次项目援助后，C表示，此次实施的调整方案是受TOC业内流传的“蓝光”故事的启发，自己不断追求更多更快的有效产出信号——绿色的“PASS”，来改善系统的整体流动性。