人工度量与自动化协同-QECon案例点评2

先说一句话，关于交付过程的度量，实际上CMMI4中专门有一个MA的，来定义度量哪些内容、数据如何计算，并要求实施QPM,即在项目各阶段中度量各个活动，并用度量结果数据进行项目管理。由于许多公司实施CMMI是为了过级拿到证书，需要项目组成员填写工作日志以及大量的统计数据表单等，给广大的老一辈程序员造成了不同程度的心理伤害。顺便说一句，CMMI已经40岁了，已经超过了互联网35岁的标准了。

论统计项范围之广，内容之全，模型之严谨，在软件行业CMMI无出其右。笔者认为目前各个大厂放出来秀肌肉的那些度量项绝大部分只是换了一个名号，变成了DevOps或者敏捷度量而已。

那新时代的程序员做出来的度量，与前辈相比，到底有何不同呢？本次QECon大会上，来自云集的周同学的演讲主题《云集研发效能数字化转型探索与实践》让人看到了一些新世代的玩法。

这个7步法，类似一个PDCA循环，通过共识达成，设定指标，建立共同的目标，然后通过协同完成交付，并在这个过程中通过度量和可视化随时进行检查纠偏，然后通过效能运营对结果进行复盘，并最终将组织的效能沉淀进了产品进行固化。

这个过程中，笔者最为关注的是演讲者强调的所谓自动化了。包括了协同的自动化和度量数据获取的自动化。

首先是协同的自动化。一次交付过程，涉及到产品、开发、测试、运维等不同的角色。在这个过程当中，通过自动化能够简化自身的交付，让工作更为高效另外一方面，自动化也意味着标准化，在为下游的工作提供便的同时，能够降低人工交接带来的错误风险。这样就促进了流水线上上下游工序之间的协同，让价值流动更加地顺畅。

在度量方面，演讲者通过需求价值流和产研工作流两个流水线之间的协同来实现对于需求价值流的自动化度量数据获取。例如，开发编码的第一个工作项是创建分支，也就意味着(4)开发以启动，于是需求价值流就流动到了“开发编码”阶段。通过类似这样的设计，让整个交付过程各个节点的起止时间，或者是前置时间得到了自动的统计和计算。让开发人员不再有在管理系统中填写工时、推动任务单状态等等负担，减少了工作界面的切换次数,让开发人员能更专注于交付工作自身。当然，另一方面的好处就是这种方式也保证了统计数据的准确性。

在精益生产中，自働化(Jidoka)不仅仅是指生产的自动化，更是指质量内建，流水线能自动检测和分析故障。通过协同和度量的自动化来降低交接和切换的浪费，并促进质量内建，演讲者在设计这些时应该是躬身入局，花了心思的。

这样的DevOps，才更容易成功。