开发者学堂课程【阿里巴巴研发效能提升实践系列公开课：研发效能的度量】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/608/detail/8869
研发效能的度量
目录
一、主要内容
二、研发效能度量体系
三、研发效能的改进愿景
四、研发效能度量与产品交付和创新
五、总结
一、主要内容
本节会分三个部分
(1)第一节：研发效能度量体系，会涉及一个体系来衡量研发效能；
(2)第二节：研发效能改进的愿景；
(3)第三节：研发效能度量与产品的交互和创新，探究其所处位置。
二、研发效能度量体系
1.什么是一个好的度量
这是一个挺难回答的问题。在产品开发中从来不缺乏数据，有各种数据如开发者的行为数据，从一个需求的角度，看到需求的交付数据，从软件的角度，可以看到各种软件的数据（比如软件的质量，软件的复杂度，软件的耦合等）但是数据本身不是度量，如何去使用它、用它去解决什么问题才是真正的核心。一个好的度量必须是一个完整的体系，作为一个完整的体系，好的度量首先的根本是要回答一个根本的问题，并为回答这个根本的问题而讲述一个完整的故事。但是这个问题的意义不大，因为刚才所研发效能的定义的时候，已经提出了这个问题，就是研发效能的定义，即持续、快速、交互价值的能力。研发效能度量要回答的问题就是这样的能力如何、关于持续快速交付价值的能力达到了什么状态。如何为回答这个问题讲述一个完整的故事呢？这是一个完整的体系，它包含五个部分：持续发布能力、需求响应周期、交付吞吐率、交付过程质量、交付质量。接下来逐一解释以便看到背后的逻辑，它是如何作为一个系统来回答这个根本问题的。
2.持续发布能力。
(1)持续发布能力：
①发版频率
②发布前置时间
(2)发布频率：单位时间内的有效发布次数
(3)发布前置时间：
从代码提交到功能上线花费的时间，也称变更前置时间
体现了团队发布的基本能力。如果时间开销很大，就不合适加大发版频率。
3.需求响应周期
需求响应周期分为：
（1）交付周期时间
（2）开发周期时间
交付周期时间：从确认用户提出的需求，到需求上线的平均时长。
反映团队（包含业务、开发、运营等职能）对客户问题或业务机会的响应速度。
开发周期时间：从开发团队理解了需求开始，到需求可以上线的平均时长。
反映技术团队的响应速度
先简单介绍一下这个看板：里面每一个蓝色的卡片是一个需求。可以看到这个需求要经历从左到右各个阶段，比如选择、设计、带评审、待开发、开发设计、开发中、待测试，直到发布上线。这是从左到右，每个需求要依次挪动，经过各个阶段直至上线。这是一个需求的基本流程。
思考：哪里算是开发周期，哪里算是交付周期呢？
开发周期在上图中就是从待开发开始，到待发布结束；而交付周期是从选择开始到发布结束。
为什么是从选择开始，而不是用户提出来立马去开始计算这个时间？
因为假设是在互联网的世界里，机会和要解决的问题总是无穷多的，但是一旦选择了解决这些问题，也就暂时放弃了解决其他问题的机会，希望尽快的把它交付，所以从选择一个需求开始到发布结束。开发周期已经讲解了，是待开发，也就是开发已经理解可以去开发，到待发布，也就是可以发布。如果业务需要，立马就可以发布结束。这是两个时间点，也就是刚才讲的第二点，看周期时间。
4.交付吞吐率
交付吞吐率：单位时间交付用户需求数量
强调单个团队的需求吞吐率的前后对比，统计上反映交付效率的趋势和问题。
5.交付过程的质量
交付过程的质量：
（1）缺陷创建和修复时间分布
（2）缺陷库存
过程中缺陷分布：并发过程中缺陷的发现和修复时间分布
希望缺陷能够持续和及时地被发现，并且在发现后尽快修复。
缺陷库存：开发过程中缺陷的库存情况及趋势
希望在整个开发过程中控制缺陷库存量，让产品始终处于接近可发布状态，奠定持续交付的基础。
讲解：
前面的三组指标，有流动效率和资源效率，后面的指标是关于质量的。质量非常重要，其实它的重要不仅仅体现在对用户的感知，也体现为过程的质量。因为过程质量关系到可持续性，如果过程中代码都很差，效率的可持续性就很差，而且最终也会影响效率。当然也需要关注交付的结果质量，先看交付的过程质量。过程质量会关注两种指标：第1个指标是缺陷创建和修复的时间分布，这个有点抽象，稍后看具体的例子；第2个是关注缺陷库存，关于缺陷分布就是它想反映的是缺陷是什么时间发布的，什么时间发现的，以及发现后是什么时间修复的。什么时间发现的，显然是越早越好，希望它持续的去发现。就写了一个代码，立马就能发现它的缺陷，希望能够持续及时的发现，并且发现后尽快的修复。从这个描述上面人人是定性的，稍后看具体的例子的时候，会把它转化为定量的指标。还有一个缺陷库存这是定量的，也就是开发过程中缺陷的库存的情况和趋势，库存就是当前时刻所存在的缺陷的个数。从目标上来说，显然希望在整个开发过程中控制这个缺陷的一个存量。来看一个具体的例子：
这是一个当时来自云零售团队的一个例子，对这个数据操作了加工。这个图称为缺陷趋势图，是一个度量。它的横坐标是是日期，可以看到它的这两个月，从1号到这边的30号又从1号到31号，这个粉红色的和粉绿色的两个部分是它的两个迭代。
先解释一下这个图的意义：横坐标是日期，红色的条是在这一天所发现的缺陷的数量，或者说新增的缺陷的数量；绿色的条是在这一天解决的缺陷的数量；橙色的曲线是缺陷的库存。因为对原始数据已稍作加工，把原始的库存的历史存量清零，然后就看新增的缺陷的库存。
来看这个团队，它是每个月一个迭代。第1个月的迭代里面，从1号到20号始终没有发现缺陷，这是因为写的代码并没有集成，每个独立的职能团队在设计、写代码时没有及时的集成，所以它集中设计的编码引入缺陷。就比如在现场讲的时候，会写缺陷、写bug，但是它们并没有及时的发现和解决这些bug。到21、22号准备集成，发现一些问题，23、24号发现更多的问题，之后就开始开始解决这些问题。到30号应该发布的时候，缺陷存量恰好是最大的，甚至还有些缺陷没有被发现，显然这个迭代延期了。如果是周末加班，去解决这些缺陷就会造成延迟批量的集成，然后集中的测试和移除缺陷，解决完这些缺陷才可以上线。在上图中可以看到，如果下个月3号上线，可能还有一些缺陷遗留在系统中，就写着want fix。所以在这里面无论如何时做不到持续发布的，因为何时发布是依赖于缺陷什么时间被移除。来看下一个迭代，团队改变了它的开发模式，它把需求变得更小，每一个需求可能若干人协作去做这个需求立即开始集成，并且移交给测试，之后及时的去移除这些问题。可以看到这幅图里面三维缺陷是持续发现并且被持续移除的，前面所看到的是小瀑布模式。下面减小了批量持续的集成，及时的测试和发现问题，发现问题以后及时的移除发现的缺陷。但在这里面所看到的缺陷的库存其实始终处于一个低位，但是不排除到最后的时候，29、30号的时候，仍然有一个小的波峰。这个小的波峰可能是因为一些大的需求在这个时候交付的。但无论如何它会持续交付创造的条件，上图反映的是一个过程质量。之所以要关注过程质量，是因为过程质量直接关系到交付模式、关系到团队的协作模式、关系到效率是否可以持续、甚至关系到最后交付的质量，因为在第1种模式下最后半个小时在赶工，更容易采取一些并不干净的修复方式，往往会对系统的真正的长期质量带来损害，所以关注过程质量是非常重要的。关注的效率，可持续性，以及长期的质量。图中绿色的部分是一个持续交付的模式，这正是为了提高资源效率和流动效率希望达到的一个模式，把它称为内建质量。所谓内建质量就是在整个开发过程中保证质量，而不是依赖于最后的阶段，或者仅仅是依赖于最后的测试，让内建质量及时发现并移出缺陷，做到可以持续的交付。
6.交付质量
交付质量：
（1）单位时间问题数目
（2）线上问题解决时长
线上问题数：单位时间的故障（线上问题）数
越少越好，尤其是造成较大影响的高级别故障。
问题解决时长：线上问题，从发现到解决的平均时长
越短越好，尤其是造成较大影响的高级别故障。
讲解：
交付质量就是线上问题的数目，不管是用户发现的还是自己发现的，单位时间里面它的数量越少越好，尤其是造成较大影响的高级别的缺陷，这个就被称为故障；还有问题的解决市场就是对外响应的市场越多越好，尤其是造成较大影响的高级别的故障。
7.总结
在一开始就讲了好的度量要为回答一个根本问题讲述一个完整的故事，这个根本的问题就是持续快速交付价值的能力。这个完整的故事就是从持续发布能力、需求响应周期、消耗吞吐率、交付过程质量、交付质量这5个方面去讲述的。它们分别代表流动效率，就是对用户的响应，就是持续发布能力和需求响应周期；资源效率，也就是交付吞吐率，资源效率反映的是各个环节，真正的产出的情况；质量包含过程的质量和交付的质量，甚至于为了提升研发效能，往往注重一开始要更加关注过程质量，向过程质量要效力，也向过程质量要交付质量。这样一个度量体系，是希望它是一个完整的而且是面向结果的一个研发效能的度量体系。
三、研发效能的改进愿景
研发效能的改进愿景究竟怎样？过去一年来与不同的部门去协作，去试用了这样的度量体系，各部门一开始提出了自己的改进愿景，最后把它们总结成了一个新的一个指标体系，叫做211指标体系。称之为愿景肯定是比较难的，愿景是要去实现的，也只有个别的团队能够实现，能够去做到。这个愿景最早是在天猫新零售，后来在闲鱼，在中间的中台部门等地方，不断去实施总结出来的。
211愿景就是两周的客户周期，从想法提出到确认上线的时间要两周：一周的开发周期，就是从需求设计完成开发理解了这个需求到可上线的时间；一小时的发布前置时间，也就是写完代码到上线所要花费的时间。
首先从客户周期来看，它是最难的，因为它涉及到各个部门、各个职能开发、测试，还有前面的业务产品以及后面的运维，它的一些紧密的协调和协作才能达到两周的客户周期。如果达到这个效果说明配合就非常好，因为这个不仅仅是各个职能，也有可能各自的依赖；又比如做一个新的项目，可能涉及到钉钉和淘宝的协作，它才能打通导购端用钉钉，客户端用淘宝的这样一个链路。客户两周的客户周期尤其对于复杂项目并不容易，接下来一周的开发周期比两周的客户周期涉及到的环节少，它涉及到需求的拆分和管理。
开发团队是分工协作模式，比如各个职能各自为政，各自有各自的目标，互相又不对齐，那么会造成相互的等待，无法做到一周的开发周期，还有外部依赖的管理。最近有尝试和共享所谓的内部开源模式，就如何能够降低这种依赖能让大家更好的或者和共享更好的去协作，也是为了解决这个问题，加速开发周期。还有持续集成和持续测试的实践，比如在这里就会涉及到环境的管理问题，如果环境不稳定可能会造成开发被block。还有一小时的发布前置时间，这个过程也会非常依赖，有很多问题要去解决，需要持续的交互流水线的构建，需要产品架构体系。例如微服务、微服务体系的的改造，让部署、开发能够更加的更加灵活。例如自动化测试、自动化部署能力，自动化测试一定是有效的，它也和刚才讲解的环境也相关。这一系列能力的提升才能带来这些指标的达成，这些指标的达成直接反映了协调能力、协作、技术能力。
这些指标很难，但是对它满意的其实也正是它不容易达到。要去实现这些指标，就会发现需要改进组织的各个方方面面，而一旦改进了，达成了这些目标，其实组织中的问题也会被解决，最终达到的效力响应质量的同步提升。所以211是一个愿景，作为一个愿景，可能对于不同的团队有不同的阶段。例如最近的中间建部门部分团队，过去的发布前置时间为三四天，现在它也211先。它先把时间从三四天降到一天，注意最后的1不是一小时而是一天。但它也做了一个限定：这个一天不是指24小时，是指从早上开始到下班前结束能够完成一次发布。这并不容易，包含回归测试，还包括把环境管理的更好，这已经是巨大的进步了，至少对于那种通宵发布的情况就变少了。那么它也愿意更加频繁的去发布，这是一个愿景，有的团队已经做到，这也值得去挑战。至于是否要去改变它，则根据自身情况去改变。因为产品的特征可能不同，比如在阿里云的IOT或者460，可能两周的发布就不太合适，所以可以根据情况去调整。
讲了这条度量体系和目标以后，其实Aone的度量体系的设计也是依据于这样的一套背后的方法学、这样的一套理念去设计的。并不是它的体验就足够好，但也可以尝试去使用，在使用的过程中它可以直接联系Aone的产品和开发团队来共同的去改进。比如需求开发周期、交付周期以及缺陷趋势图、还有之后会介绍的需求累积流图。下方的需求累积流图它会非常系统全面地反映包括这样的指标，而且更可解读，下节课会有个单独的课程来解读Aone里面的度量图表和度量数据。
四、研发效能度量与产品交付和创新
研发效能的度量体系，就是为了回答持续交互能力怎么样这个问题给出的一个体系，并且提出了211的指标，以流动效率为核心。其实211都是关于流动效率的，它是改进的抓手，在下一讲具体的实践的时候还会进一步解释为什么它能够成为改进的抓手，不管是流动效率还是资源效率，它都可以通过这些东西来改进，但是本节课讲的第3部分是研发效能度量和产品交付和创新的改进的是什么样的关系。
已经提出的研发效能的度量，它度量的是持续快速交付价值的能力。它从流动效率，资源效率和质量三个方面来衡量，但是研发效能并不是最终的指标，它是一套指标，最终的目标还是应该服务于组织的。例如利润、用户的增长、客户满意度、口碑、运营效率等，但是这些研发效能的确是与它紧密相关的，至少提供了足够的支撑。例如流动效率是关系到客户的满意度，就是对客户的响应。也关系到把握市场机会的能力，关系到用户和增长等，质量和资源效率也是同样的。
这些研发效能来源于各类实践的提升，例如协作和管理实践，这是下一讲要重点去讲的，这个团队如何协作来提高流动效率，资源效率和质量，它的协作时间应该是什么；也会关系到需求的管理实践，例如为了做到开发周期一周，必须要把需求更合理的拆分，并且要更好的去分析它，减少返工。包括提高质量也是一样的，下一讲会讲到以终为始，也就是在开发开始之前就要知道需求，知道需求应该做成什么样子知道，它的终态是什么样子，这是需求管理时间。例如持续交付时间，这个是偏工程的，这里面包含分支策略是什么样子的测试，有效的测试手部体系应该如何去构建，是关于自动化的，也包含手工测试。持续集成和持续部署的流水线；环境和基础设施的监控等；环境的稳定性、监控和安全等，这是提供一些工程保障的。最后离不开的是设计和代码的实践，例如有核的架构，但这里会讲微服务，领域驱动设计和微服务代码实践。例如测试开发UT或者是重构这些，只有这些实践的落地，才能带来研发效能的提升。当然研发效能也不是全部实践，这些实践是保证顺畅的交付，快速的交付，还有交付引用的东西，需要强调的是如何保证交付有害的东西是一个很困难的事情。一开始会有些设想，这些东西是有用的，但这些设想并不永远甚至很多时候都只是一个假设。那么如何快速的反馈，不断的调整，不断的去验证，这是产品的探索和创新的实践，这里面包含只能一开始去设计，做成一个初始的假设，这个初次假设本身要有它的逻辑性和合理性。即使它逻辑上可能是合理的，仍需不断的去探索，去验证、去调整。这些实践，这个可能是5个部分的实践，这是后面关于实践部分要分别展开去讨论的问题，所以这一部分对它的研发效能在整个组织效能或者研发这个实践中的位置，在研发效能它的度量不同的改进提供了一个确定的方向，设定了目标和愿景，也能够衡量事实上提升的一个结果，是它大概的定位。
五、总结
1. 度量是研发效能改进的基础，度量要为回答一个根本问题讲述完整的故事。
2. 研发效能度量要回答的根本问题是：组织持续快速交付价值的能力怎样?
3. 研发效能度量分别从流动效率、资源效率和质量三个方面为组织持续快速交付价值的能力这一问题，讲述了完整的故事。
4. 流动效率是撬动系统改进、提升研发效能的关键。2-1-1愿景以流动效率为核心，指明了研发效能改进的方向。
5. 研发效能最终为组织效能服务，而它的提升源自协作、需求以及技术等的落地。
讲解：
第1点：首先度量是研发效能改变的基础，一开始就引用了彼得德鲁克的话，如果不能衡量它就无法改进它。但度量要为回答一个根本问题讲述完整的故事，回答的根本问题就是组织、持续、快速消除它的能力如何。
第2点：研发效能分别从流动效率、资源效率、质量三个方面回答了为组织这个效能的度量这一问题，讲出了完整的故事。
第3点：流动效能是撬动系统改进提升研发下来效能的关键，这一部分会在下一讲更深入的讲解在实践中是如何做的。
第4点：211愿景是以流动效率为核心的，指明了研发效能改进的方向。
第5点：研发效能最终是为组织效能服务的，但它的提升是要落实到协作、需求、技术、创新等方面的实践的。
以上就是本次课时的内容。
