节省显示器同时提升持续集成问题修复及时性的“流水线问题责任聚焦”实验

作为企业IT部门某个开发团队负责人的你，从书上和大佬那里得知，软件开发团队，如果采用持续集成实践，那么就能降低软件开发过程中的返工。

于是你按照书中和大佬所说的，在团队工位显眼位置，摆放了一个大显示器，并接上持续集成流水线。

你喊团队中所有的5位开发人员来开会，告诉他们，一旦流水线运行出现问题，比如编译打包错误或自动化测试运行失败，显示器就会显示告警的红色/黄色画面。团队中无论谁看到了红色/黄色告警，第一时间就要放下手中工作，及时修复流水线。团队中的其他人，也要配合这位同事的修复工作。

开发人员都答应了。

但很快你就发现，你所辛辛苦苦搭建的流水线健康显示屏，其实就是一个摆设。团队开发人员根本就不关注。即使显示屏变红/黄好几天，也无人修复。

这个问题该如何破？

你读了阿伦森的《社会心理学》，其中的“责任稀释假说“给了你很大的启发。即目睹紧急情况的人越多， 他们中任何一个人干预的可能性就越小。

你觉得工位边上的持续集成流水线健康状况显示器，其实就再现了一个***责任稀释的场景***。看到红色/黄色告警的开发人员，都会觉得其他开发人员已经看到并处理了，于是不再采取行动。

你从书中了解到，在1968年，两位社会心理学家用实验模拟了一个人命关天的紧急情况。实验结果发现，当受试者面临要出人命的紧急情况，并意识到周围有4个旁观者时，只有31%的概率会去施救。若旁观者下降为2人，施救的概率上升到62%。当周围没有旁观者，施救的概率会达到85%（如图）。

图：当周围没有旁观者，受试者施救的概率会达到85%

我在“吾真本说混沌工程”知乎专栏的文章“做软件的人不被他人忽悠的唯一方法”里，说只有自己动手做有对照组的科学实验，才能避免被忽悠。

为了避免被忽悠，你觉得可以设计一个实验，来找到提升自己团队流水线问题修复及时性的方法。

该如何设计这个实验？

我在下面帮你列出这个实验的6个步骤和具体实施方法。你可以根据团队具体情况，做适当的调整。如果遇到问题，欢迎在评论区留言，与我交流。

1 基于观察

放置在工位附近显眼位置的持续集成流水线健康显示屏，就是一个摆设。团队中的5位开发人员平时根本就不关注。即使显示屏变红/黄好几天了，也无人修复。

2 问出问题

是什么阻碍了开发人员，让他们即使看到了显示屏的红色/黄色告警，也不及时修复流水线问题？

3 形成可验证的解释性假说

根据“责任稀释假说“，目睹流水线红色/黄色告警的开发人员越多， 他们中任何一个人修复流水线问题的可能性就越小。

4 基于假说做出预测

如果将工位附近的流水线健康显示屏撤掉，并要求每位开发人员，在向流水线合并代码后，需要通过自己的电脑显示器，观察流水线健康状态。直到状态变为健康的绿色，才算合并成功。若其间发现红色/黄色告警，因为只有她/他一人在场，周围没有旁观者，那么她/他主动修复流水线所发现的问题的概率会达到最大。

5 设计并执行有对照组的实验检验预测

你需要设法吸引IT部门负责人对这个实验感兴趣，并获得她/他的支持，比如帮助你找到另一个同样有5人左右开发人员的开发团队作为***对照组***，并获得那个开发团队负责人的支持。而你所在的团队，可以作为***实验组***。

由IT部门负责人和实验组与对照组这两个开发团队负责人，三人成立实验小组。

为了让实验结果不会因为实验组和对照组两个开发团队的开发人员，因相互攀比而有损数据的准确性，该实验***从始至终秘密进行***。即实验的事情，只有实验小组的那三人知道。若其他人问起实验过程中一些事情的缘由，比如为何撤销显示屏，可以编一个理由，比如其他团队临时借用。总之不要透露正在开展的实验和实验意图。

在实验开始前，两个开发团队的负责人，需要各自准备好流水线健康状况观测工具。比如能通过工具，观测出流水线何时出问题变红/黄，何时修复好变绿。可以设置一个及时修复的时长范围。比如流水线每次从变红/黄到变绿之间，没有超过4小时，算及时修复。否则，就不算。

对照组在工位显眼位置，摆放一个大显示器，并接上持续集成流水线。对照组团队负责人在实验开始前一天，召集所有开发人员，告诉他们一旦流水线运行出现问题，显示器显示告警的红色/黄色画面，团队中无论谁看到了红色/黄色告警，第一时间就要放下手中工作，及时修复流水线。团队中的其他人，也要配合这位同事的修复工作。

实验组则悄悄撤销工位附近的流水线健康显示屏。实验组团队负责人，就是你，在实验开始前一天，召集所有开发人员，要求他们在向流水线合并代码后，需要通过自己的电脑显示器，而不是工位附近的流水线健康显示屏，观察流水线健康状态。只有健康状况变为绿色，才算合并成功。若发现红色/黄色告警，就需要立即修复。其他开发人员在修复期间，需要积极配合。

设置一个开展实验时间段，比如6周。两个团队同时开展实验，并同时采集数据。

每2周作为一个迭代。实验小组在迭代末就开一次碰头会，分析和对比这2周采集的观测数据，即这2周流水线问题及时修复的百分比。

6 根据实验结果可回到第3步不断迭代优化假说/预测/实验过程

到第6周结束，总结和对比这3个迭代实验组和对照组流水线问题及时修复百分比。根据实验数据，看看是否支持第4步的预测，并决定是否回到第3步，改进假说、预测或实验过程。

如果在实验过程中遇到问题，欢迎在评论区留言，与我交流。

如果觉得本文对你有帮助，欢迎点赞，点击在读，并转发给其他经常受流水线问题修复不及时之害的小伙伴。你觉得提升流水线问题修复及时性，还有什么其他好办法？你还希望我聊有关做软件的其他什么新话题？欢迎在评论区留言。我会仔细阅读每一条留言。期待听到你的声音。

企业生意蒸蒸日上，软件系统稳定运行。你所阅读的文章，来自**“吾真本说混沌工程”**知乎专栏。