关于CI仪表盘的反思

KJCH项目是一个100多个实施人员的大型全流程敏捷项目，项目分为四个开发实施队伍，每队20-30人，相对于敏捷开发中提倡的分组规模来说，每个开发队伍的规模明显过大了，不过，关于分组和规模不是本文讨论的重点。

由于开发人员规模较大，部门特意安排我针对本项目进行一次敏捷辅导，经过与项目十天的相处，发现整体项目进展和实施人员的工作氛围都很不错。过程中也发现了一些问题，并与项目经理、ScrumMaster和Product Owner以及技术骨干们进行了问题的分析和应对。涉及百人的大型敏捷项目，必然有很多有趣的事情发生，其中关于CI物理仪表盘的事情也给我自身带来不少反思和学习的机会。

CI物理仪表盘是部门的一项敏捷实践，通过在每一个产品开发Team的工作区域摆放物理的显示器，显示本产品的持续集成信息，来促进团队养成时刻关注持续集成情况的工作意识。

物理仪表盘显示的信息包括：

• Sonar检查的问题数
• 单元测试成功率
• 单元测试覆盖率
• 构建是否通过（通过为绿色，不通过会变红）

特别是针对最后一条“构建是否通过”的信息，仪表盘变红的规则有：

• 构建不成功，会变红
• 有单元测试又不通过，会变红
• 单元测试覆盖率相对于最高点下降超过1%，会变红

KJCH项目一期的时候只有二三十人，本迭代开始之前，由于项目需要，实施人数暴涨到一百人，人员的急速扩张，加上项目交付进度的压力，必然带来的是质量的下降。这一结论，通常都是通过简单的直觉和经验就可以得出的（注意：是通常！）。我在项目人员扩张之初就预言：该产品的单元测试覆盖率将会很快从54.3%下降到40%甚至30%。因为，我一直以来都认同一个观点：单元测试覆盖率是产品内建质量的一个非常直接的体现指标。

在我初到项目开发团队的时候，产品的单元测试覆盖率就已经变成52%左右了，虽然这已经是一个非常不错的成绩，并且开发团队也的确付出了很大的努力，但是，已经超出了部门制定的“单元测试覆盖率下降不超过1%”的要求，所以CI物理仪表盘长期保持红色状态。我所在的这一段时间里，持续的在关注SVN上的代码情况，发现开发人员的代码提交习惯还是非常好的，每天每个时间段都有不少的提交。同时，我也跟踪了CI仪表盘提示的错误信息，有的时候，仪表盘变红是由于有单元测试不通过，有的时候是由于单元测试覆盖率下降超过了1%。但是，由于开发团队的确已经无力将单元测试覆盖率提升到曾经的最高点54.3%，单元测试下降超过1%已经成为团队的既定事实，短时间内根本无法改变，而在现有的规则下，CI物理仪表盘必定会长期处于变红的状态。

这样的一种现象显然是不对的，但是，一开始，我并没有真正的意识到具体是哪里不对，以及应该如何应对。

直到我突然想到了一句话“CI物理仪表盘最重要的作用是信号灯的作用！”显然，现在的物理仪表盘已经没有信号灯的作用了。这好像就是问题的症结所在。

对于团队已经经过努力仍然无力改变的现状，我们应该承认它，并将其作为既定事实。并以此作为基础进行改进，而不是视而不见，任性管理，仍然以超越团队承受能力的标准去要求。那么我们现在首先要承认的事实就是：产品的单元测试覆盖率下降已经超过了1%，并且在现有的交付压力和工作情况下很难提升回去。

既然承认了事实，为了发挥CI物理仪表盘的信号灯作用，就要根据事实调整规则。根据当前单元测试覆盖率现状，我们改变仪表盘变红的最后一条规则为：单元测试覆盖率相对于最高点下降超过4%，会变红。

将GAP从1%，调整到了4%。这样基本上和团队的实际情况匹配了。

这个调整之后，CI物理仪表盘发挥信号灯作用的基础就具备了。但是，如何让信号灯发挥作用？最重要的就是让大家接受这个信号灯，并且看到信号之后能够及时采取切实有效的应对措施。具体的做法就是启用那条说说很容易，做到很难的规则“物理仪表盘变红不下班！”

“制定一条规则很简单，成功启用一条规则，并让其被大家接受和执行就并非易事了。”

为了让这条规则可以被有效的接受和执行。

首先，需要针对性的培训和宣讲。对开发人员进行关于单元测试的意义、编写原则和实际编码过程中的技巧的培训和宣讲，还有，作为推动者要发动Team中的技术骨干进行一些更为务实的技能培训。这期间一共开展了四次培训，我一次，其他三名技术骨干各一次。每一次时间并不长，一般在半个小时到一个小时之间。

其次，要扫清规则启用的障碍。将GAP从1%，调整到了4%之后，我发现CI仪表盘还是红的，并且红了一整天，这说明可能存在两个方面的问题，第一、Team还没有建立起将CI仪表盘作为集成信号灯的意识；第二、代码中存在容易导致仪表盘变红的顽固因素。针对第一点，我将四个Team的ScrumMaster叫到一起进行了简单的宣讲，这个地方有点做的不到位的是时间仓促，很多东西没有讲透，讲的有点“简单直接”，好在我们的ScrumMaster都有很好的敏捷素养。针对第二点，就是找到代码中的“顽疾”，发动技术骨干挖除之。总之，在推行新的规则“物理仪表盘变红不下班！”之前，要先能够保证规则的确可以被遵守，并且遵守的成本和门槛不要太高。这一步扫清规则启用障碍很重要，一般情况下，对于新规则的启用有两种类型的障碍：意识障碍和执行障碍。

再次，吹风试用新规则。已经是我和团队一起工作的最后一天，第二天我就要离开团队了。当天下午，在和四位ScrumMaster“简单的宣讲”之后，我就和大家说了我们要做到“物理仪表盘变红不下班！”。当然，只是嘴说的，我其实对于Team是否真能够做到并没有什么信心！因为，大家已经是8-10-7的工作方式了，就是早上八点半上班、晚上10点下班，每周7天，其实，到时候，就是真的到10点下班时间了大家没有搞定，仪表盘还是红的，难道真的让大家通宵不成？不过，当天下午仪表盘已经是绿色的了，并且做了那么多的铺垫工作，还是决定冲一把。很有戏剧性的是，当天的晚上九点半左右，仪表盘真的又红了，又红了，红了，了！！！！这是个好事儿，也是个坏事儿。我当时就大声的说了一句话：大家停止所有手中的工作，我们的第一要务是让仪表盘变绿了，然后我们就可以下班了。经过一段“惊心动魄”的问题查找，终于在10点20分找到了问题，并成功解决了。找到问题，并解决之后，大家真的很开心，感觉困意都没有了。这一天是2017年8月22日。

最后，正式启用新规则。经过前一天晚上的一次现场的演练，我相信大家已经具备了执行“物理仪表盘变红不下班！”的新规则的一切条件。我们的ScrumMaster开始正式的执行新的代码开发纪律！

我回京后的几天也一直在持续的关注开发Team的情况，感觉新规则和大家相处的还算融洽。

最后，有一点小惊喜！仅仅过了一个星期，开发Team竟然把单元测试覆盖率提升回来了。我也不知道到底发生了什么！不过真的太牛了。

总结来说，CI系统也好，CI仪表盘也好，最容易的一步是从物理上搭建起来，最难的一步是在Team的心里搭建起来。而这个“走心”的过程，很难，也很有意思，回头看起来也很有讲究，而一旦Team走心之后，往往神奇的事情就发生了。甚至会颠覆一些“通常”为我们理所当然就接受的认知，比如：“人员的急速扩张，加上项目交付进度的压力，必然带来的是质量的下降。”