为什么敏捷实施，或是任何一点的过程改进都步履维艰？即使是十几人的团队中，也会出现“写自动化测试”──“不写自动化测试”──“写自动化测试”──“不写自动化测试”这种循环往复的过程？

　　除了人们常常总结的“敏捷实施模式”，或是“敏捷失败经验分享”这样的具体话题之外，是不是还有一些存在于思维模式中的更加根本性的因素，阻碍了我们对系统全景的认知，从而导致改革先行者的黯然退场？

　　本文将通过两个案例来讲述如何使用系统思考，从全局掌握我们所处的复杂环境，做到既见树木，又见森林。

　　案例1：舍本逐末

　　有一个测试团队的负责人找到我们说，“我觉得现在的自动化测试问题很大，执行时间长，也不稳定，有的时候是测试写错了，也要花很长时间修。我打算组织一批人，重新设计一下测试代码的架构，把常用的底层功能封装成设计良好的API。”

　　我的同事说，“好啊，你们打算怎么做呢？”

　　他说，“我也还没想好，所以想过来商量一下。我希望这个东西做成以后，能够让不会写程序的QA们都能用它来写自动化测试脚本了，他们现在就是这样，又要做测试，又要学着写程序，我觉得太辛苦了。能让他们不用学编程就能写测试脚本就好了。”

　　“呃……要不我们先看一下现在的代码，了解一下都有什么问题，然后再讨论？”我们内心有点小小的纠结。

　　“好吧，我来给你们开通访问权限，找人给你们讲代码”。他很爽快的答应了。

　　打开代码之后我们就忍不住风中凌乱了，满屏都是重复的代码片段，让人一阵阵的眩晕。两天之内，我们仅仅用了“提取方法”这一个重构手法，就删掉了1200行代码。期间还发现，不知道谁在调试的时候把一处代码从等待3秒改成了等待10秒忘了改回来，于是其他人再复制粘贴的时候，就全变成了等待10秒。

　　于是事情就明朗化了。

　　依赖于一小拨人重新设计代码结构，提炼API，确实会在短期内使问题得到缓解。但使用这些API的人依然是那些不懂得如何编程的QA，他们依然会使用复制粘贴来解决问题。再好的架构、再优秀的设计，最终还是会淹没在大量重复的代码中，犹如黄金深埋浮沙之下。而且如果问题表象得到暂时解决，人们就会缺少动力从根本上提升QA的编码能力，随着设计一点一点腐化，就又需要精兵强将充当救火队员。如此不断反复，直到有一天又回到重新设计乃至重写的老路上来。

　　这是个典型的“舍本逐末”的模型。

　　分析

　　在上面的场景中，对于“测试代码质量低劣”这个问题有两种解决方案，一种是精兵强将解决，另一种是测试人员自己解决，每一种方案都会削弱代码质量不断下滑的趋势，从而让系统处于一种平衡状态。如下图所示：

　　图中的“S”表示同向连接，即箭头起点所示变量的增长会导致另一方变量的增长；“O”表示反向连接，即箭头起点变量的增长会导致另一方的减少。天平表示调节环路，该回路会趋于平衡稳定。

　　但是，由精兵强将出马可以让问题症状迅速得到缓解，提升测试人员的编码能力则需要长期的辅导训练，不可能一蹴而就，所以图中下方的调节环路实际上是有时间滞延存在的：

　　与此同时，由精兵强将解决问题会减少测试人员锻炼的机会，从而削弱测试人员的编码能力，进一步使人们不倾向于让测试人员自己解决问题，又转过头来增强了对于精兵强将的依赖。所以还要在图中增加另外一条回路：