运用系统思考,走上改善之路

2011 年 8 月 25 日

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

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

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

案例 1:舍本逐末

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

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

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

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

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

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

于是事情就明朗化了。

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

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

分析

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

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

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

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

滚雪球表示增强环路,该回路会使得回路上的所有节点持续增强

这幅图的全貌便构成了“舍本逐末”的模型。彼得·圣吉在《第五项修炼》中对此解释到:

上面的环路代表快速见效的症状解,它迅速解决问题症状,但只是暂时的。下面的环路包含了时间延滞,它代表较根本的解决方案,但其效果要较长的时间才会显现出来。然而它可能是惟一持久见效的方式。有时候舍本逐末的结构中,会多出一个由症状解所带来的副作用所形成的增强环路。发生这样的情形时,副作用常使问题更难以解决。

人们或者是因为没有找到问题的根源,或者是因为时间延滞的存在,倾向于采取一种简单易行又可以立竿见影的方案,这便是症状解了。但是症状消除以后,问题就不再令人重视,从而丧失了从根本上解决问题的能力。而问题依然深藏,等到它有一天再度浮上水面时,症状就会更重,更难解决。

这是一条不断衰减的增强环路。在回路上每走一步,情况就会更恶劣一分。

面对“舍本逐末”,通常的解决方案有两条:

  1. 必须要认识到症状解只是短期止痛的手段,切不能形成依赖;
  2. 在症状得到缓解之后,要继续加强对根本解的重视。

但见招拆招总是相对容易一些的,更关键的地方是,如何才能识别出“舍本逐末”这样的模型?当我们采取某些理所当然的对策却得到了不合理的结果,有什么办法可以帮助我们分析问题根源,找到解决方案?

要认清问题的本质,就必须要认识到,我们所处的是各个因素之间紧密连接相互影响的复杂系统,当前采取的行动,会从多方面对这个系统产生影响,而这些影响之间或推波助澜,或相互牵制,从而导致相同的行动在长期和短期来看具有不同的结果。

比如,当代码中发现 bug 的时候,很多人的常见反应都是“调试──定位──解决”这样的思路。从眼前来看,发现 bug 立即修复是可以最快见效的手段,但却丧失了将测试进行完善的机会,相当于是安全网上明明出现了漏洞却听之任之。等到以后因为需求变更等原因影响了这块代码的时候,就再也无法通过执行测试来得到快速而完整的反馈了。

丹尼斯·舍伍德在《系统思考》中说,

如果你希望了解一个系统,并进而能够预测它的行为,那么,就非常有必要将系统作为一个整体来研究。将系统各部分割裂开来研究,很可能破坏系统内部的连接,从而破坏系统本身。

如果你希望影响或控制系统的行为,你必须将系统作为一个整体来采取行动。在某些地方采取行动并希望其他地方不受影响的想法注定要失败──这也就是连接的意义所在。

为了帮助人们更好的从整体上研究复杂系统的行为,丹尼斯在书中提供了一套完整的工具──系统循环图。

系统循环图中共有三个基本要素:

  1. 增强环路。在增强环路中共有偶数个 O 型连接,增强环路上的各个节点会呈现指数增长或指数衰退。
  2. 调节环路。在调节环路上共有奇数个 O 型连接,调节环路上的各个节点会趋于平衡状态。它会消化掉外界的影响力,使改变难以发生。
  3. 时间滞延。时间滞延是一个不容忽视的影响力,由于滞延的存在,人们常常会发现某个行为在短期内没有产生预想的结果,从而加大投入力度,当行为的后果出现在眼前时,却已经矫枉过正。

下面我将通过另一个真实的案例来讲述“系统循环图”的应用。

案例 2:历史不断重演

一天中午,我忽然听到有人说,“我们又开始讨论要不要放弃自动化功能测试了。”

“咦?你为什么要说又呢?”我忍不住问道。

“因为我们半年前已经讨论过一次,当时得出的结论是不再写自动化测试了。后来不记得是什么原因了,又用 Cucumber 来写,最近发现每次上线还是要做大量的手工测试,这些自动化测试又要浪费很多时间来修,所以我们准备讨论一下到底还要不要继续写。”

当天下午,我参加了这个团队的讨论,终于弄清楚了事情的来龙去脉:

大概是一年前,为了减少手工测试的成本,团队决定一步步把上线时需要手工回归的测试用例转换成自动化,同时决定每个 story 做完以后都要加入自动化测试。研究了几天 webdriver 以后,就开始了自动化测试的尝试。

但麻烦很快就出现了。第一,开发人员用 Java 代码写的测试,QA 不好理解,也不是很清楚哪些场景被测试覆盖到,哪些没有,所以无法信赖测试结果;第二,测试跟开发共用一套数据库,数据总是受到污染,因此造成测试失败,浪费大量定位和修复的时间。而数据库是由国外的客户控制的,催促了很长时间也没能给测试分离出一套专用的数据库来。

测试红啊红,修啊修,后来一算时间,在自动化测试上投入了 120 多人天,却依然得不到一套稳定执行的测试用例,不但没办法保证交付质量,还让每个人心力交瘁。于是毅然决然的停掉了。

过了两三个月,客户终于准备好了一套专门用来跑功能测试的数据库,开发团队也对行为驱动开发有了一定的认识。于是又开始写自动化测试,这次用了 Cucumber,QA 写场景,Dev 写实现。

写了大概有 100 多个场景的测试,又有人开始质疑这一切:第一,整套系统实在是太庞大复杂了,写到现在为止,连 1/4 都没覆盖到,所以上线还是手工回归。我们到底要花多大的精力才能把所有的场景都自动化起来,这些投入是不是值得?第二,测试环境还是不稳定,比如本地数据跟 CI 用的数据不一致,比如 Tomcat 里面部署的应用常常启动不起来,等等。每个问题都要消耗大量的人力。这些浪费能不能平衡自动化测试到最后能够带来的收益?

但团队中还有其他人对自动化测试持有乐观态度,认为问题总是可以解决的,只要坚持不懈就能够看到长期的回报。于是就有了这次讨论。

分析

绘制系统循环图的第二条法则是:“从有趣的地方开始”。在这个案例的场景下,开发团队最关心的是该不该写自动化测试,它对交付能力会带来什么影响,于是我们选择“自动化测试的数量”作为起始点。

接下来是第三条法则──“询问‘它将驱动什么’,以及‘它的驱动力是什么’”

我们首先可以想到的是,自动化测试的数量增加,会缩短发现 Bug 的周期,但是这个作用是需要测试数量积累到一定程度才会发挥出来的。它同时还会增加测试的开发和维护成本,增加测试执行时间,缩短手工测试周期。见下图:

手工测试周期的缩短会带来交付周期的缩短,提升产品收益,从而使人们更倾向于编写自动化测试。于是在图中就出现了一个增强环路:

而测试的开发维护成本增加,会导致开发进度放缓,从而削弱收益,于是在图的下方出现了调节环路,这条调节环路的存在,会阻碍人们在自动化测试上的投入。

与此类推,我们同样在图中可以发现其他的增强环路与调节环路:

而在这四条回路之外,还会有其他因素对这个结构造成影响:

画出系统循环图以后,就可以结合团队的状况进行整体分析:

首先回到质疑的声音上来,有人说,“整套系统实在是太庞大复杂了,写到现在为止,连 1/4 都没覆盖到,所以上线还是手工回归”,这里反映出的正是从“自动化测试数量”到“手工测试时间”这条线上的时间滞延的效果。在前文中提到过,时间滞延在反馈环路中会造成矫枉过正,这里是它的第二个作用──给人带来挫败感。它会导致某个行为在短期内看不到任何效果,当滞延的时间过长时,会令人失望乃至放弃努力。消除时间滞延可以对系统起到卓有成效的改善。在这个案例中,我们可以通过推动手动测试用例向自动化测试的转化来缩短滞延。

然而,当时间滞延的作用被削弱以后,还有另外的问题等着去解决。下面再来看看这支团队从“写自动化测试”到“不写自动化测试”的变化过程中发生了什么。

在刚开始写自动化测试的时候,团队主要的感受是 QA 少了手工测试的时间,质量多了保障,所以增强环路发挥了作用,每个 story 完成以后,开发人员都会为所对应的场景写几个测试。但当测试数量增加到一定程度,调节环路的反馈力量开始占据主导地位──测试时间变长、维护成本增加。而且测试数量越多,带来的问题就越大,最后便有了第一次的选择:放弃自动化测试。

这正是《第五项修炼》中描述的“成长上限”模型:

增强环路导致成长。成长总会碰到各种限制与瓶颈,然而大多数的成长之所以停止,却不是因为达到了真正的极限。这是由于,增强环路固然产生快速的成长。却常在不知不觉中,触动一个抑制成长的调节环路开始运作,而使成长减缓、停顿,甚或下滑。

……

当改善的速度慢下来,你会更加努力地去改善。但渐渐的,你愈是用力推动你所熟悉的做法,调节环路的反作用愈是强烈,使你的努力愈是徒劳无功。到了最后,最常有的反应是放弃他们原来的目标。

所以,当我们观察到有增强环路与调节环路遭遇的情况出现时,更为有效的解决方案应该到调节环路上寻找。在上面的系统循环图中,“测试环境稳定性”、“开发人员技能”可以限制“测试的开发维护成本”,“硬件数量与质量”可以限制“测试运行时间”,我们可以通过控制这些在调节环路之外起作用的因素,削弱调节环路的影响,让增强环路的成长继续开始。

小结

结构决定行为。增强环路总是产生指数级的上升或衰减;调节环路总是倾向于使整个环路趋于平衡状态;各种环路的相互影响,就会产生“舍本逐末”、“成长上限”或是“饮鸩止渴”等基本模型。

然而不幸的是,参与系统的各个部分,常常见树不见林,只能针对眼中见到的局部信息,做出局部的最佳决策。但每个人的局部最佳决策,并不能构成整个系统的全局最佳决策。因为系统中有反馈、有延迟,因和果在时空上并不紧紧相连,显而易见的解往往无效。

在纷乱芜杂的因果关系中,使用系统思考可以帮助我们理清问题的脉络,认识系统全貌,从而进一步寻找有效的杠杆解──比如案例 2 中的限制调节环路;而不是固囿于局部优化,把环状的因果关系割裂成线段,看不到当前采取的行动会在未来反作用于自身,因此导致各种系统问题的出现。

系统循环图是一个很强大的工具,但一个人的视野总是有限的,用头脑风暴的方式往往可以得到更全面的认知。案例 2 的图形就是小组讨论的结果。只是这种方式需要引导者时时注意控制讨论的边界,不要偏离重心。

本文通过两个实际案例对系统思考的基本概念进行了描述,并讲解了如何使用系统循环图对一个复杂系统进行分析,对这方面知识感兴趣的读者可以通过《系统思考》和《第五项修炼》这两本书进行深入研究,学会用这套工具来指导持续改进的步伐。


感谢张凯峰对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2011 年 8 月 25 日 00:005075
用户头像

发布了 197 篇内容, 共 44.0 次阅读, 收获喜欢 15 次。

关注

评论

发布
暂无评论
发现更多内容

第四周总结

LEAF

架构师训练营第四周作业

养乐多

Android | 资源冲突覆盖的一些思考

哈利迪

android 团队

架构师训练营 -W4-20200701-学习总结

丁亚宁

学习 极客大学架构师训练营 week4

第4周 系统架构:系统架构知识是架构师的常识而不是能力

陆不得

架构师训练营 第四周 学习心得

李君

极客大学架构师训练营

week04总结

uangguan

一个典型的大型互联网应用系统使用了哪些技术方案和手段

张瑞浩

架构 0 期 -week3- 命题作业

陈俊

极客大学架构师训练营

互联网系统应用的技术方案

王麒宇

大型网站架构问题

新世界

【架构师训练营】第4周作业

花生无翼

极客大学架构师训练营

week04作业一

uangguan

架构师训练营 第四周 个人感想

且听且吟

架构师训练营-第四周-命题作业

sljoai

极客大学架构师训练营 第四周作业

week4-典型大型互联网应用系统使用技术方案和手段

暖丶冬

第 4 周 - 学习总结

大海

第四周作业

倪惠华

架构师训练营 week4 - 学习总结

devfan

一周信创舆情观察(6.22~6.28)

统小信uos

大数据 新基建 舆情

大型互联网应用系统技术方案

Thrine

架构师训练营第四周 - 总结

Eric

极客大学架构师训练营

Week4 总结

Coder

极客大学架构师训练营

大型网站技术架构

LEAF

架构 0 期 -week3- 学习总结

陈俊

极客大学架构师训练营

互联网应用系统的技术方案和手段

王鹏飞

架构师训练营 week4

devfan

第四周作业

考尔菲德

架构师训练营-W4-20200701

丁亚宁

极客大学架构师训练营 week4

架构师训练 第四周 作业

李君

极客大学架构师训练营

【荒于嬉】Redis持久化漫谈

luojiahu

redis 持久化

运用系统思考,走上改善之路-InfoQ