古板先生是个很有秩序的人，家里的东西样样摆放整齐，一丝不苟。
有一天，古先生想要买双皮鞋，于是，他先拿尺子量了自己的脚，然后记下数字，穿上外套去鞋店。
到了鞋店才发现，自己忘记带记下数字的纸条了。于是古先生急急忙忙往家跑，去取那张纸条。店员连忙招呼他：先生，我可以直接量您的脚啊！
古板先生为了买到合适的鞋，自己选取了一个量化的指标，在真正遇到需要解决问题的时候反而回去寻找当时制定的指标对应的数据，而不是实时的去度量这个数据，这也是企业中在制定KPI时经常遇到的问题，不够实时。
目前大部分企业都在做敏捷研发和Devops的转型，阿里，腾讯，京东等企业都各自出了关于自己的研发效能模型。敏捷研发和Devops转型的最终目的都是鼓励增量更改和更快发布，同时提高研发的质量和客户满意度。为了更好的衡量研发效能的改变结果，我们需要衡量什么样的DevOps指标能更好的来体现研发效能的提升。
SDLC各个阶段的角度
从SDLC的角度出发，度量标准可以深入了解DevOps流水线的各个阶段（从设计到开发到部署）所发生的事情。 指标是客观的衡量标准。 它们加强了对DevOps至关重要的反馈循环。 收集指标并通过仪表板或记分卡显示它们应该是自动化的。 将这些指标映射到业务需求非常重要。
从阶段上我们可用划分为以下的阶段：
- 开发
- 测试
- 部署
- 发布
- 运维
从上图可用看出，各项活动的消耗时间和吞吐量会是衡量的重要指标之一。这是从SDLC的阶段维度来划分研发效能。
部署方面的角度
特别是从部署的角度来看Devops的KPI指标的话，比较推荐以下的12个指标模型：
- 部署速度：流水线部署的速度。
- 部署频率：生产中部署的频率。
- 部署失败：生产环境中有多少次部署失败。
- 变更前置时间：开发完成一个功能到其在生产环境中部署成功之间的平均时间。
- 变更容量：生产中每个部署中提供的新用户故事总数和新代码行。
- 平均检测时间：生产环境中从部署到出现第一次故障之间的平均时间。
- 平均故障间隔时间：生产环境中的平均故障间隔时间。
- 平均恢复时间：生产环境系统崩溃和恢复之间的平均时间。
- 变更失败率：变更与生产中断之间的比例。
- 效率：开发时间和等待时间之间的比例，这两个指标与开发功能的时间和等待直到将其部署到生产中的时间比例。
- 性能：显示生产中应用程序的可用性，响应时间和资源利用率。
- 流水线的适用性：了解采用流水线上的每一个指标的定义，将有助于很快搭建新的流水线。
业务价值金字塔的角度
Gartner在2018年正式发布了一个Devops指标相关的金字塔，如上图，从上面可以看出，服务层面也是从质量和效率两个方面来衡量的IT交付服务，但在客户价值的角度更多的添加了前置时间、发布的版本、响应时间、客户满意度等许多和客户相关的指标。
国内的许多大企业也对应的推出了自己的研发效能体系指标，比较经典的是阿里以何老师为主力输出的五组研发效能指标：
可以看出这五组研发效能指标比较明确和清晰的定义了持续快速交付的多个聚焦点，在组织级的整体改进中若有如此清晰的定义，对于团队中的目标对齐，力量聚焦都很有益处。（业界里腾讯的TAPD，京东的互联网企业也出了类似的研发效能体系，总体感觉来说还是阿里的比较符合持续快速交付的特色）。
如何利用这些指标和模型来有效提高企业中的研发效能体系会是下一个需要持续研究的课题。欢迎有兴趣的小伙伴一起来讨论。
