00 前言
管理学大师彼得德鲁克曾经说过“你如果无法度量它，就无法管理它” (“It you can't measure it, you can't manage it”)。可见，我们唯有对价值交付过程和成果进行度量，才有可能改善价值交付效率和质量，从而提升团队和组织效能。
与此同时，在业界流传着一句话“你度量什么，就得到什么”。i a
因此，为了促进持续改进和提升组织效能，我们应该采用哪些指标以及如何应用度量指标就显得极其重要。
我们通过本期文章为大家介绍主流的价值流度量指标，包括：精益（Lean）指标、DORA指标、流框架指标、Gartner流指标和软件研发效能度量指标全景图。之后，我们将在下期（VSM每周观点 第6期）探讨应用这些指标的原则、方法和策略。
01 精益（Lean）指标
首先，现有的大部分的价值流指标是源自于精益生产，然后发展演进过来的。精益（Lean）中典型的指标包括：前置时间、周期时间、在制品和增值时间/非增值时间等。
1）前置时间（Lead Time）：全局客户视角，是指从客户提出想法开始到价值实现的时间。价值实现不仅仅是产品/服务的交付，而是要达到客户预期，并产生价值。
2）周期时间（Cycle Time）：局部职能视角，是指一件产品在特定工序/步骤所花费的时间。注意这里强调的是单件的时间，如：完成一个需求的功能测试所花费的时间。
4）在制品（WIP，Work in Process）：也称半成品或进行中工作，是指已经开始但未完成的工作项/需求。如：已完成需求分析待设计、开发中、已开发待测试、测试中、待发布和发布中的需求均为在制品。
5）增值时间（VAT，Value-Added Time）：增值活动所花费的时间。精益将活动类型分为增值活动、必要非增值活动和非必要非增值活动。增值活动是指创造价值的活动，如：开发、测试和部署等。
6）非增值时间（NVAT，Non-Value Added Time）：不创造价值的活动所花费的时间。一类是必要非增值活动，如：招募员工、培训和必要的文档；另一类是非必要非增值活动（即浪费），应最大化的消除，如：缺陷、等待和过度生产等。
02 DORA 指标
其次，是来源于DevOps状态报告的软件交付效能指标，也称为DORA（DevOps Research and Assessments）指标。DevOps状态报告最早是由Nicole Forsgren Velasquez、Gene Kim、Nigel Kersten和Jez Humble四位大咖共同在2014年发布的，之后在过去9年时间里共发布了8次的报告。（除了2020年暂停，其他每年发布一次报告）
图片来源：State of DevOps Report 2014
在8次DevOps状态报告中，作者均采用4个经典指标来度量IT软件交付效能，并通过聚类分析，将组织分为精英、高效能、中等效能和低效能4大类型的组织（在最新的2022状态报告中取消了“精英”这个分类）。
图片
来ctAccelerate State of DevOps Report 2009
如上图所示，这4大指标包括部署频率（Deployment Frequency）、变更前置时间（Lead Time for changes）、服务恢复时间（Mean Time to Recover）和变更失败率（Change Fail Rate）。
03 流框架指标
再次，Tasktop创始人米克·科斯腾（Mik Kersten）在其著作Project to Product中提出了流框架（Flow Framework），流框架最上层即是价值流指标（Value Stream Metrics），包括4个流指标、1个流分布和4个业务结果指标。
图片来源：书籍Project to Product
流指标 Flow Metrics
4个流指标分别是：
1）流时间（Flow Time）：从开始处理到交付给客户的时间。前置时间是从客户提出想法开始算起的，而流时间是从着手处理开始算起的，也就是说在Backlog代表列表中的停留的时间不包含在流时间里。
图片来源：flowframework.org
2）流速度（Flow Velocity）：等同于吞吐量（Throughput），是指在特定时间内完成的工作项数量。
图片来源：flowframework.org
3）流效率（Flow Efficiency）：是指增值活动的时间与流时间的占比（如下图的计算公式）。流效率越低，意味中花费在浪费和等待的时间越多。
图片来源：flowframework.org
4）流负载（Flow Load）：进行或等待中的工作项数量，等同于在制品（WIP）。
图片来源：flowframework.org
流分布（Flow Distribution）
流的分布（Flow Distribution）是指花费在不同工作类型时间的占比。
图片来源：flowframework.org
在软件交付过程中，常见的工作类型主要有4类：
1）功能（Features）：新需求的开发测试工作，带来新的业务价值，一般由客户或业务团队拉动的。
2）缺陷（Defects）：在测试阶段发现或是客户反馈的质量改进需求。
3）风险（Risks）：性能、安全和合规相关的非功能需求。
4）技术债（Debts）：一般指阻碍价值快速交付的技术栈或基础能力，并且随着时间的推移影响越大，“偿还”成本越高，如：软件架构、持续集成和持续交付能力等。
流的分布是一种零和游戏
需要特别注意的是，流的分布是一种零和游戏。也就是说，当你把绝大部分时间精力都花费在新功能开发上时，可能带来缺陷、风险和技术债的急剧上升。缺陷的上升带来的是质量问题和客户满意度的下降；风险问题可能导致组织处于危险的边缘；而技术债的累积会阻碍你快速交付价值的能力。
因此，在组织不同的阶段要合理地平衡流的分布。如在早期发布版本可以重点关注功能需求，随着使用用户的增加要开始关注缺陷和风险，当需要快速迭代时就得关注技术债的影响。
04 Gartner 流指标
然后，于2021年，Gartner发布了文章How Software Engineering Leaders Can Use Value Stream Metrics to Improve Agile Effectiveness，并提出了以技术（Technical）、产品（Product）和业务（Business）为维度的流指标示例。
如上图，Gartner列举了18个流指标（Flow Metric），大部分指标都是比较常见，我们就不在此详细展开介绍。其中有2个指标比较少见，我个人是这样理解的（如有误，欢迎给予指正，在此先谢过）：
1）代码评审搅动（Code Review Churn）：因Code Review而导致的代码变动。
2）工作分布（Work Profile）：等同于流分布（Flow Distribution）指标，是指不同工作类型的占比，如：功能、缺陷、风险和技术债。
05 软件研发效能指标全景图
最后，2022年茹炳晟和张乐2位老师领衔主编的书籍《软件研发效能提升实践》中介绍了3个维度、5个阶段、共计48个指标的研发效能度量指标全景图。
来源：书籍《软件研发效能提升实践》
软件研发效能指标全景图涵盖需求、开发、测试、发布和运营5个阶段，并分别以交付效率、交付质量和交付能力为维度进行度量：
1）交付效率：端到端快速及早交付。
2）交付质量：端到端高质量交付。
3）交付能力：卓越工程能力和持续交付能力。
06 本周推荐阅读
本书Project to Product（中文译本已出版，名为《价值流动：数字化场景下软件研发效能与业务敏捷的关键》）聚焦于传统项目管理模式的误区和问题，强调了以产品为导向的管理模式，同时基于丰富的案例创造性地提出了流框架（Flow Framework），这是一种观察、度量和管理软件交付的新方法。
总结：以上我们介绍了价值流主要的5大类度量指标。那么问题来了，这么多指标我们该如何选择和应用呢？是否有什么通用的原则、方法和策略？不同的团队是否可以使用不同的指标呢？我们将在下一期（VSM每周观点 第6期）跟大家揭晓这些答案，敬请期待！
END
扫码关注公众号