你还在做事后度量报告么？
你的敏捷过程度量改进，起作用了么？
如何在这里寻找到突破？
今天和大家谈谈如何突破敏捷过程度量瓶颈，实践有效度量改进？
在开启探讨和实践之前，为了避免只见枝叶不见林，先给大家看一张简版软件研发全过程框架图。
解释下这张图：
1）软件研发实践分三块：产品管理、开发过程、度量改进；
2）各模块之间需相辅相成、和谐互通，才能真正发挥作用；
3）各个模块要结实际情况，制定和落地敏捷实践方法。例如若你的产品还没有跨越鸿沟，也许不适合搬用传统Scrum，试试定制下Kanban等；
4）各个模块主要实践者不尽相同，要学会从关注过程本身，转向关注实践过程的主要人员。如上图标注的不同人员；
5）度量改进贯穿过程，持续优化实践。
篇幅有限，今天就探讨度量改进这块。
度量出了问题？是的。
为了满足组织级或项目级不同度量需求，我们习惯定义不同维度的度量；组织专门的度量小组，每到月底或季末，就得开启一轮数据大战。。。
虽然高大上的度量分析报告在公司各级展现研发管理能力，或试图挖掘改进机会；甚至尽管数据显示在改进。但开发团队或多或少并没有那么高的参与度和认同感。
问题出在哪里？ 其实这里面的问题很多元，我们还在实践中不停探索和验证。篇幅有限，今天先谈度量相关的问题。
其实，我们启用的大部分度量，并没对改进本身有效。
先不绕太多，谈到有效，首先看看什么是有效度量？这是个很有意思的问题，引用下图：
上图来自某国外同行分享的有效度量应具备的四个特点。
●Honest诚实可信的：数据经过处理，非实时的原始数据，缺乏可信度。
●Simple简单易用的：复杂的度量定义，在团队内是无法持久的内耗挣扎。
●Actionable可采取行动的：不能采取行动的度量，就算光鲜也是形同虚设。
●Comparable可比较的：不能比较的度量，无法延续持续改进的意义。
我很认可这些有效度量的定语，简单务实。
翻翻我们曾经定义的各种度量，却找不到几个符合的。来反思下：我们过于追求华丽报告，却忽视了度量真正的目的是实践改进而不是事后报告。
于是，进一步问：该如何去改进和落地？
确定有效度量的目标，百度采用最简单的度量组合：
1） 累计流图（Cumulative Flow Diagram - CFD）
2） 控制图（Control Chart）
累计流图足具视觉效果，而控制图兼备数据化精准定位，堪称左右脑的完美结合。
是不是已经用过这些度量了？来说说这些年“被玩坏”的控制图。
控制图曾无数次出现在各种度量分析报告里，但却未能发挥其真正作用。
为什么这么说？我总结几条：
1） 数据经过多道数据处理
2） 因为用法麻烦，一般都是过程改进专家自己用
3） 仅粗略显示了月度或季度揉和后表现
其实，它已不具备：
●简单易用的
●诚实可信的
●可采取行动的
控制图很有用，要如何改变现状，让其真正发挥有效性？
我们结合百度需求管理工具icafe，设计实现了能实时、自动化显示最小颗粒度的过程执行（卡片级）控制图。
百度工具控制图长什么样？（图解由百度王一男整理提供）
●控制图中每一个蓝色的点表示一个卡片（任务项）。鼠标移上去可显示卡片信息和链接
●X轴表示卡片流转出选定的状态的时刻。许多团队会选定“开发中”+“测试中”两个状态来看控制图。其实在iCafe中你可以选定空间中的任何状态来生成控制图。
●Y轴表示选定的状态下卡片停留的时长。你可以任意选择一个或多个状态，例如“开发中”、“待测试”、“测试中”等。效率越高的团队用越少的时间完成工作。换句话说，Y轴的值越小越好。
●紫色直线是图中所有卡片在选定的状态上花费时间（即周期时间）的平均值。这个值越小越好。
●绿色曲线是周期时间的移动平均线，如果团队效率越来越高，这条线会越来越向下。
●蓝色的阴影是各点与其移动平均值的标准差。越稳定的团队，蓝色阴影与移动平均线间的距离越窄，团队的未来工作越可以准确预测。这可以给团队更多的信心迎接未来的工作。
来总结下自动化控制图都做了什么？
●根据你的数据条件，实时生成控制图；
●实时计算出过程绩效能力：整体平均、移动平均（算法有效避开异常影响）、50分位值、波动范围；
●自动识别出异常点和趋势情况，辅助团队分析这些异常点和趋势，稳定和提高过程执行能力。
那么
简单配置，再也不用加班熬夜收集和处理原始数据！
原始数据，再也不用怀疑度量数据可信度！
自动计算，也不用利用Excel去计算控制范围、Mean等各种参数！
实时度量，更重要的是可以配置进行中任务状态进行度量，不用等到事后度量！
再来看看CFD
来看看CFD图，形象化工具（图解由百度王一男整理提供）
●纵坐标方向表示卡片（任务项）的累计数量。
●横坐标方向是时间线。
●曲线表示的是在时间维度上每个特定状态的工作项累计数量趋势。
●鼠标移到上去显示当前时刻各状态 WIP、平均Lead Time以及平均Cycle Time
CFD图在项目组使用过程中，团队会本能去盯曲线斜率情况、两条线间隔距离情况及等待浪费情况，配合工具给到的预估数值，能直观查看到一些问题或风险。
CFD有很多直观、有用的分析实践。这里举2个实际项目例子：
Case1：1. 需求范围在增加 2. 5月中旬后等待测试（黄色）和等待上线（紫色）的有所增加 3.交付属匀速交付（Kanban模式）
Case2：1.范围在增加，需求和开发gap一直较大 2. 交付属阶段性交付（Scrum模式）
还想看么？那就赶紧实践起来。。。等你的案例分享~
CFD图和控制图结合分析定位，很容易定位问题所在。
例如通过CFD查看到某些状态趋势进展缓慢，再通过控制图计算任务项相关周期数据。找到异常点和趋势，然后分析消除。
总结下，以上和大家分享了：
1） 软件开发的整体框架
2） 有效度量的定义和目前度量改进的问题
3） 列举CFD和控制图实践，谈谈百度在有效度量方面的改进和实践
当然，软件过程改进不仅仅在度量方面，高效软件研发实践的路还很长，我们一直在反思、实践和验证的路上，期待下一次再和你分享。（本资讯于2016-06-13首次发布）
