开发者学堂课程【研发效能提升和敏捷实施36计：设定北极星指标——数据驱动效能改进】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/615/detail/9377
设定北极星指标——数据驱动效能改进
内容介绍
一、上节课程回顾
二、度量反馈和持续改进
三、总结
四、在Teambition上设置和查看研发效能度量指标
一、上节课程回顾
1. 束水攻沙：限制在制品数量，加速价值流动
通过控制在制品的数量，加速价值的流动，提高响应力
2. 湖水岩石：暴露问题，促进改进
3. 站会6+1：关注和处理阻碍价值流动的问题
4. 建立节奏：月规划，周排期，日站会
包括输入类节奏如需求的规划，排期，输出类节奏，如产品的发布等
二、度量反馈和持续改进
通过度量来反馈问题，从中产生洞察，落实改进行动。度量反馈也是为了改进服务。
角度分析：
好的度量是什么（What’s Good Metrics）-研发 效能度量体系（R&D EfficiencyMetrics）-小能改进的愿景目标（Vision Metrics）-改进是系统工程（System improvement）
没有度量的管理，就是“盲人骑瞎马 夜半临深渊”
度量在管理的角度中，是一个非常重要的概念
问题：好的度量是什么？
答：度量需要回答一个本质问题，讲述一个完整的故事
如果将度量比作一棵树，那么回答问题的根本就是回答本质问题，当阐述这些问题的时候，就需要用相应度量来解决这些本质问题。度量包含其中获取到的信息，信息是从最根本的数据中挖掘出来的。数据提供最根本的信息，信息汇聚起来就形成了度量，度量最终回答本质问题。
在研发过程中会产生很多数据，给数据赋予很多的意义，它就变成了信息，信息本身不是度量，只有带着目的去回答本质问题，从问题出发提供出有意义的完整的信息，才能被称之为度量。
度量需要回答本质的问题，并且为回答这个问题讲述一个完整的故事。度量需要赋予数据意义，否则它就不是度量。
问题：
12L 9L 此数据没有任何意义
某品牌汽车，每百公里95号汽油油耗：城市道路为12L，高速路为9L。 提供相应的信息，赋予数据意义
选择一辆汽车，需要比较各种汽车的燃料效率，同时需要考虑其他的信息，譬如价格。
哪一种汽车最适合你？
度量需要去回答一个问题，比如此题中的度量是为了选择哪款合适的汽车，这是一个根本问题。所以选择的度量就是选择一辆汽车需要比较各种各样的信息指标，聚合在一起可以完整的回答此问题，这就是一个度量。
研发效能度量体系
持续快速、高质量地交付价值的能力：
需求响应能力、持续发布能力、交付吞吐率、交付过程质量、交付质量五类指标都提供了完整的信息。
1.需求响应能力：
（1）交付周期：从确认用户的需求，到需求上线的时长：这反应了团队（含业务、开发和运营等职能）对客户问题和业务机会的响应速度
（2）开发周期：对需求进行澄清理解之后，可开发状态，到需求可发布上线的时长：这反应了技术团队的响应速率
软件的交付过程：
需求从需求池中已选择，进行分析，然后就绪，再进行开发，测试，验收三个步骤，最后到发布是一个完整的价值流。是需求端到端研发发布的过程。在这个过程中我们的目的是保证需求从需求池中选择出来，能够顺畅快速并且高质量的发布出去，这是度量需要回答的问题。
从需求中选择，确定要不要做，到一个需求发布出去后，这样一个完整的时间长度被称作需求交付周期。决定做此需求，到需求已经发布经理的时间被称之为交付周期。这个数据对于用户来讲，是非常有价值的，因为针对用户来说，一个需求会选择到什么时候可以使用到这样的需求，反应了响应能力。
从就绪到待发布的阶段被称之为需求开发周期。就绪是指对开发就绪，待发布指开发已经做好了一切工作，如果需要发布，就可以进行发布操作，这反应了开发对外响应能力。
最终关注的是需求交付周期，对于某些团队来说，由于种种限制，需要有审计的周期，如果不能持续的发布，就需要进入开发周期。需求交付周期和需求开发周期很大程度反应了一个团队对外的响应能力。
问题：为什么是到待发布，而不是已发布的时间
答：因为发布是根据业务进行决定的。
将需求的交付周期和需求的开发周期合并起来，就是需求的响应能力
需求响应能力示例图：
此图中的每一个点都代表一个需求的发布。横轴代表具体的日期，纵轴代表具体需求从已选择到发布花费的时间，表示发布周期。需求点越低越好，代表从承诺到交付的时间短。
图中的点前半部分基本上会出现一个45度的斜角，这里表示排进一批需求，越迟开始就越迟交付。
控制线：85%的需求周期时间小于该值
橙色的线代表控制线，控制线是过程统计中经常使用的线，此处控制线表示有85%的需求是在控制线以下的，意义是有85%的需求能够在13天之内完成交付，反应了外部响应能力。
问：为什么不使用平均值，而使用控制线
答：因为有的异常数据，很有可能会影响整体的需求。使用控制线会更加科学。
期望的散点分布：
1.纵向上向下集中—响应能力及其可预测性提升；
2.散点密度提高—提升交付速率；
3.横向上更均匀分布—持续交付。
需求点越向下集中就表示，周期时间越稳定，对外成果越可靠，可预知性越高。需求点在横轴均匀分布，意味着可以进行持续发布。需求点的密度和数目表示发布的需求的数量。
实例图：
解读：
1.需求批量选择进入，越迟开始的越迟结束
2.前期交付能力比较强，尤其6月底7月初交付较多
3.后续交付水平乏力（周期时间长、数量少）
1.需求持续进入，持续交付
2.前期需求交付能力强，中间有缓下来，后期交付量很多
3.后续从交付能力很强（速度快、数量多），都集中在两周以内
从两图中反映出B产品的需求点更加向下集中，B产品的需求点也更加密集，但是从均匀分布的角度来观察，A产品和B产品都不均匀。
2.持续发布能力：
工程能力能否做到持续发布的能力
（1）集成发布时长：从代码提交，到功能上线的时长：体现了团队发布的基本能力，如果时间开销很大，就不合适发版频率
代码提交到上线中间的过程可能会经历，代码检查、验证、构建，以及部署上线等方面
（2）发布频率：单位时间内，有效的发布次数：团队对外响应的速度不会大于其交付频率，发布频率约束团队对外响应和价值的流动速度
只有发布频率很强，才可以做到频繁的发布，这也体现了团队的工程能力，但是有时候发布频率是根据业务进行决定，而不是工程能力。发布频率足够好，也反应了团队具备这种优秀的工程能力
持续发布能力体现了工程的能力，持续发布能力是需求响应能力重要的保障，最后体现在外部，用户能够感知到的部分是交付周期，交付周期是外部最核心的重要指标。
3.交付吞吐率：
（1）单位时间交付需求数：整个团队在单位时间内交付的需求数目：强调整个团队需求交付吞吐率的历史对比，反应交付效率的趋势和问题
交付吞吐率只作为一个参考指标，不建议在团队之间进行比较。对于同一个团队可以比较前后变化的趋势，如果需求本身较小，从统计的意义上，有一个反应的能力。
交付吞吐率是不作为团队横向比较的数据，更多作为团队中纵向的比较，比如相对上一个周期是否有提高等
4.交付过程质量：
（1）创建/关闭缺值分布：开发过程中，缺陷发现和修复的时间分布：希望能够持续地发现开发过程中的缺陷，并能及时修复掉
（2）缺陷库存：开发过程中，库存总量及趋势：在整个开发过程中，缺陷的总量控制在一个比较低的水平，收敛，保障持续交付。
相对于交付质量，更多的会强调交付过程的质量
缺陷的库存关乎到所花费的成本是多少，而创建和关闭缺陷的趋势分布能够反映出是否在可供范围内
缺陷趋势图实例：
图中橙色的曲线反应的是存量缺陷数目，红色的部分向上表示新建缺陷的数目，绿色部分向下表示解决缺陷的数目。横坐标代表日期。
图中反映出从1号到20号之间没有任何缺陷。粉色部分从第一个月的1号到下一个月的3号代表第一个迭代结束。
前期的时候没有发现缺陷的原因是因为还没有进行产品的测试。集中设计、编码引入缺陷，但并未即时发现它们
在后期的时候缺陷集中爆发，导致无法进行产品的发布
在缺陷解决完毕以后，才能进行发布
右边绿色部分是改进研发模式之后的第二个迭代：
在减少批量之后，可以进行持续的集成，而且还可以在此阶段进行测试和及时的发现问题并解决，让整个过程处于基本可发布的状态。进入了持续开发，持续测试，持续可交付的状态。
总体上将左边粉红色部分的小瀑布的模式转变成了右边绿色部分的持续交付的模式
小瀑布模式：集中发现和解决问题
持续交付模式：内建质量，即时发现并移除缺陷
持续交付模式比小瀑布模式更具优势，它具有更好的开发方式和开发质量
示例2：
A产品缺陷累积流及趋势图：
B产品缺陷累积流及趋势图：
累积流图中绿色的区域代表已经修改和关闭的缺陷，而红色的区域代表的是现阶段还没有关闭的缺陷（新增的缺陷）。
从A、B产品的累积流图的比较中可以观察出，A产品相较于B产品是处于一个比较低的水位，A产品的红色区域始终是一个狭窄的状态。
缺陷趋势图中红色的区域表示缺陷发现的数目，绿色的区域表示缺陷修改的数目。从图中可以观察出，A产品在持续的发现缺陷并持续的修改，相较于B产品，它处于一个较低的水位。而B产品中新增的缺陷的数目较大，导致无法进行持续发布。
从此角度中可以了解到，团队是处于一个瀑布式的开发方式还是持续交付的开发方式。
5.交付质量：
（1）单位时间线上缺陷：单位时间的故障（线上缺陷）数：越少越好，尤其关注那些对业务造成重大影响的故障，有非常明确的定级
（2）线上问题解决时长：线上问题，从发现到解决的时长：越短越好，线上问题得到解决的时长，也直接决定了故障的定级
根本问题：提高研发效能
持续快速、高质量地交付价值的能力分为三类：
流动效率：包含需求响应能力和持续发布能力
用户价值在系统中的流动速度。如：用户需求从提出到交付的时长（越短越好）；或者是过程中等待时间的占比（越小越好）
资源效率：包含交付吞吐率
各环节的资源利用率和产出情况。如：资源的忙阈程度、使用率、代码产出和测试执行速度等。
质量保障：包含交付过程质量和交付质量
交付过程中和交付的质量。如：缺陷和故障数，及其分布情况和解决时长等。
包含了线上的需求或者故障
总体示例：
左上角的图反应的是交付周期，每一个蓝色的点代表一个需求，黑色的折线表示在每个月中的统计周期，它的85%的控制线的需求。6月的时候控制线为7天，7月份的时候为24天，到了8月和9月份已经变成56天。缺陷的不断累积，交付的时间也越来越长和困难。可以从图中得知团队的响应能力很弱。图中需求点颜色较淡和稀疏，也可以反映出吞吐率较低的情况。
右上角的累积流图反应很平缓，所以它的交付周期也很长，吞吐率较低。
效能改进的愿景目标
早期愿景目标：2-1-3
2Weeks（需求的交付周期为两周）：需求交付周期：从想法提出并确认，到上线的时间
方法：整个组织各职能和部门的协调一直和紧密协作
1Week（需求的开发周期为一周）：需求开发周期：从需求设计完成到上线的时间
方法：需求的拆分和管理，开发团队的分工协作模式，外部依赖的管理，持续集成和持续测试实践
30Min（测试验证时长是三十分钟）：测试验证时长：在集成过程中，对变更的测试验证时长
方法：自动测试、自动部署等能力的提升
业务团队愿景目标：2-1-1
2Weeks（需求的交付周期为两周）：需求交付周期：从想法提出并确认，到上线的时间
方法：整个组织各职能和部门的协调一直和紧密协作
1Week（需求的开发周期为一周）：需求开发周期：从需求设计完成到上线的时间
方法：需求的拆分和管理，开发团队的分工协作模式，外部依赖的管理，持续集成和持续测试实践
1Hour（变更集成发布时长为一个小时）：变更集成发布时长：代码完成后，从提交集成到上线的时间
包含代码的扫描、构建、验证部署等操作
方法：需要持续交付流水线，产品架构体系和自动测试、自动部署等能力的提升
愿景并不代表已经做到的，但是是一个改进的方向。对于不同的团队，也可以使用不同的指标。
专有云团队目标：1-1-1
1Month（需求的交付周期为一个月）：需求交付周期：从想法提出并确认，到上线的时间
方法：整个组织各职能和部门的协调一直和紧密协作
1Week（需求的开发周期为一个周）：需求开发周期：从需求设计完成到上线的时间
方法：需求的拆分和管理，开发团队的分工协作模式，外部依赖的管理，持续集成和持续测试实践
1Day（变更集成发布时长为一天）：变更集成发布时长：代码完成后，从提交集成到上线的时间
方法：需要持续交付流水线，产品架构体系和自动测试、自动部署等能力的提升，及落地实施能力
专有云和公有云的交付方式不同，对应的所部署的生产环境不同
寻找改进的机会
愿景目标是给出的需要达到的目标状态，我们需要了解现状，然后寻找改进的机会，并且将问题识别出来，分析根因进行改进是非常重要的
改进的机会：识别问题，分析根因，实施改进
改进是系统工程
持续改进机制：
外部质量，如故障、告警、通过缺陷、舆情反映了交付质量是如何的，同样可以根据交付效率，如响应响应能力和交付周期来反应情况如何，同时还有一些过程的指标，如行为、制品质量、能力等，组织好度量的数据，可以看到完整的现状，通过分析，然后去识别问题找出根因，然后回去落实到具体的改进行动中如在环境或者工具、流程、代码和设计、测试守护、员工技能等等问题。改进行动落实完毕后要看效果，效果就体现在交付的效率以及交付的质量等，最终形成封闭的闭环。
外部质量：包含故障、告警、缺陷、舆情。分组、分类、归因、引入点、控制点等
交付效率：包含响应能力、吞吐率等
过程指标：
（1）行为：包含提交频率、集成大小、分支数、合并冲突数、Review时长、测试执行率等
（2）制品质量：包含代码复杂度、解耦数、静态扫描、单侧覆盖率、测试通过率、内部缺陷等
（3）能力：包含变更集成时长、测试自动化率、缺陷修复时长、回滚率、发布时长等
改进行动：包含环境/工具、流程、代码/设计、测试守护、员工技能等
总体流程：
1.看现状：组织核心数据，建立度量体系
2.找问题：识别问题，分析根因
3.做改进：定义和落实改进行动
4.建闭环：观察改进效果，形成封闭环
总体示意：
1. 业务规划及探索实践：
（1）业务规划
（2）规划执行和反馈
（3）低成本有效探索
2.需求管理实践：
（1）目标管理
（2）需求组织和排期
（3）需求分析和澄清
3.协作管理实践：
（1）协作和交付方式
（2）关键活动以及节奏
（3）反馈和持续改进
4.持续交付实践：
（1）测试守护
（2）环境及基础设施
（3）持续集成及部署
（4）安全、运维
5.设计代码实践：
（1）代码实践
（2）代码资产评价和管理
（3）领域驱动设计及微服务
6.研发效能：
（1）流动效率（响应能力）
（2）资源效率（吞吐率）
（3）质量保障
顺畅高质量交付
7.组织效能：
（1）利润
（2）用户增长
（3）客户满意度和口碑
（4）运营效率
……
研发效能最终来源于各方面的实践，如需求管理实践、协作管理实践、持续交付实践、设计代码实践。业务规划及探索实践为组织效能服务。
三、总结
1.度量是改进的基础，度量要为回答一个根本问题讲述完整的故事。
2.研发效能度量要回答的根本问题是：持续快速、高质量地交付价值的能力
3.研发效能度量分别从流动效率、资源效率和质量三个方面，回答组织持续快速交付价值的能力这一问题，讲述了完整的故事
4.流动效率是撬动系统改进、提升研发效能的关键。2-1-1愿景目标以流动效率为核心，知名了研发效能改进的方向
5.研发效能最终为组织效能服务，而它的提升源自协作、需求以及技术的那个方面的实践的落地
思考：
你们在实际工作中，是如何度量团队的研发效能？
你觉得在选中的度量指标中，哪个最有效？
四、在Teambition上设置和查看研发效能度量指标
实:1：
三条业务线：交付速度变快，质量状况变好
此团队当时所定的目标为1-1-1，也就是需求交付周期为一个月，需求开发周期为一周，以及发布时长为一天
从图中可以反映出需求开发周期都提升到30%以上，第二个团队对需求开发周期的提升并不明显，就从39%提升到了40%，橙色部分表示需求开发周期大于3周的时间，此项有所提升。经过一段时间以后三个团队的需求开发周期都有一定程度的缩短。还反映出3个团队的需求交付周期都上升到70%以上，也是一个明显的提升。关于缺陷第一个团队，缺陷发现的时间趋于合理，缺陷库存明显下降；第二个团队缺陷发现的时间分布趋于合理，缺陷库存还需要下降，虽然库存下降但是下降得不够明显。
实例2：
某团队的需求响应周期：
左图中的柱形代表需求交付的个数，图中反映出在2019年6月此团队交付了62个需求，蓝色部分的需求交付周期是小于一周的，绿色的需求交付周期是小于2周，橙色部分的需求是交付在2-4周，红色部分的需求交付周期是4周以上的
右图代表需求开发周期，图中反映出此团队在2019年6月在一周之内有50个需求的开发周期
反应出此团队的吞吐量在逐步下降，而交付时长再加长
分析：
首先打开Teambition，选择统计功能项，点击右上角新建报表，其中包含自定义报表项；项目概览项包含了概览报表和任务状态按停留时间分布项；任务分布项包含了任务按执行分布，任务按优先级分布，期间截止任务完成情况项；按执行者查看任务进展项包含了期间提交工时的任务，期间完成的任务，期间截止任务分成员完成情况，期间逾期的任务项；效能分析项包含交付周期报表项；迭代分析项包含迭代走势图，迭代Burnup图，迭代分析，团队速度项；缺陷分析项包含了缺陷变化趋势，缺陷累计趋势，缺陷按迭代分布等等项；还有一部分测试案例的图表可以进行创建。
分析交付周期趋势图：
点击页面中的此图进入分析
汇总方式设置为按任务数汇总，周期设置设置为需求，已选择，已发布最后点击确认。
图中橙色的部分代表在2019年9月2日中有一个需求的交付周期是2到4周，在2019年9月16日中有两个需求进行发布，一个是在一周之内，一个是一到两周之内所发布。
下方图表中可以看到需求明细，还可以直接点击进入查看详情：
开发周期趋势图 ：
开发周期与交付周期的不同是周期设置中的设置为需求，就绪（待开发），待发布
可以通过图看到团队交付趋势的情况，还可以显示出吞吐率的趋势
缺陷变化趋势：
图中红色部分代表当前创建缺陷的数量，绿色部分代表当天解决缺陷的数量，黄色曲线代表缺陷的库存。可以从此图判断出团队为持续交付模式还是瀑布模式。如果为持续交付模式的话，缺陷的创建和分布会趋于合理，同时缺陷的库存会较低。
任务状态停留时间分布:
红色部分代表需求已经停留了14天以上，需要去分析为什么停留在14天以上
概览报表：
可以从中看到任务的总数，已完成或未完成的任务数等任务详细情况
