为什么敏捷实施或是任何一点的过程改进都步履维艰？即使是十几人的楼宇运营管理平台开发团队，也会出现“写自动化测试”→“不写自动化测试”→“写自动化测试”→“不写自动化测试”这种循环往复的过程？

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

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

      案例1——舍本逐末

      有一个大连人力资源软件二次开发测试团队的负责人找到我们说：“我觉得现在的自动化测试问题很大，执行时间长，也不稳定，有的时候是测试写错了，也要花很长时间修。我打算组织一批人，重新设计一下测试楼宇运营管理平台开发代码的架构，把常用的底层功能封装成设计良好的API。”

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

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

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

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

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

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