共计 3391 个字符，预计需要花费 9 分钟才能阅读完成。
麻利团队须要选取一些要害指标对生产力、开发流程、产品质量进行度量，从而一直优化开发过程，晋升团队效率。原文: Agile Metrics — What Matters and Why?
麻利曾经在几十年内霸占了软件开发行业，每个技术组织要么是麻利的，要么是在向麻利转型的过程中，能够将它们统称为 ” 麻利组织 ”！传统项目管理指标，如生产力、进度差别、老本差别等，在麻利零碎中岂但没用，而且事实上可能事与愿违。
有很多指标实用于麻利零碎。问题是，哪些指标才是真正重要的？上面将介绍如何抉择一个对大多数环境和组织都有用的麻利度量子集。
为简略起见，咱们将度量规范分为以下三类: 生产率、稳定性和品质，如下所示。
生产力(Productivity)
以下是无关无效利用资源以交付后果的要害指标。
OKR(指标)奉献
重要的一点是如何掂量团队为实现组织或业务单元的战略目标付出了多少致力。例如，在每个 Sprint 中，均匀 60% 的团队能力用于 OKR。现实状况下，50% 或更多的致力应该用于 OKR 或公司战略目标。
价值传递(Value Delivered)
这个指标有助于度量每个 Sprint 交付的价值。在以产品为主导的组织中，优先级公式或矩阵以与开发团队评估工作故事点雷同的形式实现价值评估。例如，WSJF(Weighted Short Job First, 加权短作业优先)优先排序办法依据业务、危险升高、工夫关键性和机会实现来评估价值点。RICE办法估算逾越范畴和影响的价值点。
燃尽图(Burndown)
燃尽图是一种简略的对一组工作所获得停顿进行可视化的办法。X 轴示意工夫盒的工作集，Y 轴示意工夫盒内的增量工夫单位。燃尽图用于监控整个 release、epic 和sprint工作的超时实现状况。强烈推荐 sprint 燃尽图，它有助于在 sprint 期间放弃团队每天的工作进度。
流速(Velocity)
狭义上讲，麻利流速示意每个 sprint 中实现的故事点。这有助于基于故事点估算实现工作主体所需的 sprint 次数。流速有许多变体: 最大流速、均匀流速和最佳流速。最好抉择最佳流速，即依据验收规范，在没有任何未修复缺点的状况下，每个 sprint 交付工作主体的均匀故事点数量。
前置工夫(Lead Time)
前置工夫示意从创立工作项 (Story, Feature 或 Epic) 到实现所破费的工夫。这是一个很好的掂量团队效率的规范。交付工夫越短，团队将想法或未实现的申请转化为可工作软件的效率就越高。
周期时间(Cycle Time)
周期时间示意从工作项 (Story, Feature 或 Epic) 开始到实现所破费的工夫。这是掂量团队开发、测试和公布过程效率的好办法。周期时间越短，团队的开发、测试和公布过程就越高效。
累积流程图(CFD, Cumulative Flow Diagram)
累积流程图提供了从开始到完结的整个启动、开发、测试和公布过程的快照，是一个简略的可视化工具，能够让咱们立刻辨认瓶颈。
净推荐值(Net Promoter Score)
净推荐值是推荐者和诽谤者之间差别的百分比分数。顾客被要求给出一个从 1 到 10 的分数，示意他们向其他人举荐产品的可能性有多大。9 分和 10 分是踊跃者，8 分和 9 分是被动者，6 分及以下是诽谤者。NPS 能够说是所有指标中最重要的，因为客户是决定团队是否交付了任何有价值的货色的最佳利益相关者。
稳定性(Stability)
以下是将帮忙团队确保交付过程 (包含开发、测试和部署) 以稳固、可预测和可继续的形式运行的度量指标。
打算实现比(Planned to Done Ratio)
打算实现比示意在工夫框完结时按计划实现的工作或工作项的百分比，能够让咱们理解团队正确评估工作、解决阻碍、技能差距以及及时交付的能力，指标是超过 80%。亲密关注这一指标将确保在长期内具备更高的可预测性。
在制品(Work In Progress, WIP)
在制品是看板中的要害指标，也能够在 Scrum 中看到它。WIP 是正在解决的工作项的数量，其目标是限度正在进行的工作，以缩小上下文切换，使团队及时解决阻塞。现实状况下，咱们的指标应该是每个 Scrum 团队成员一次实现 1 - 2 个工作。
准时公布率(On-time Release Rate)
这是在公布日期按计划实现公布的百分比，示意团队在按时实现公布方面的可预测性。数字越高，从新布局和重组的需要就越低，而这些会导致团队能力的重大节约。
失败部署(Failed Deployments)
示意在给定工夫范畴内失败的部署数量，波及生产部署和低级环境的部署，是对代码稳定性的度量，并显示开发团队是否在 Sprint 完结时筹备好了潜在的可公布代码，也是对环境稳定性的一种掂量。
团队流动率(Team Turnover Rate)
当波及到稳定性时，这是最重要的指标之一。到职率示意麻利团队成员来到团队和被替换的比率。团队成员流动的老本很高，招聘、晋升技能、团队常识的散失等等都是老本。肯定水平的散失不可避免，但如果超出了行业程度，就应该设法解决。一般来说，科技行业的人员流动率在每年 10% 到 15% 之间。员工散失的三大起因是: 薪酬、职业倒退机会和工作条件。所以你晓得如果人员流动率很高该怎么做了吧。
幸福指数(Happiness Score)
与 CSAT(客户满意度评分, Customer Satisfaction Score)相似，通常以 5 分的规范对团队均匀幸福感进行评分。该考察通常作为 Sprint 回顾的一部分进行，并随着工夫的推移进行跟踪，以监督一个又一个 Sprint 的偏差。幸福指数与到职率间接相干，幸福指数与到职率成反比，幸福指数越高，到职率越低！
品质(Quality)
上面给出了一些要害指标，帮忙团队确保交付的代码具备可承受的品质。
缺点解决工夫(Defect Resolution Time)
缺点解决工夫 (DRT, Defect Resolution Time) 或均匀解决工夫 (MTTR, Mean Time To Resolution) 是开发团队解决缺点所需的均匀工夫，越短越好。均匀 DRT 或 MTTR 通常跟踪所有环境中的缺点。DRT 的 SLA 因组织和团队而异，一般来说，团队应该将最大 DRT 的指标定为要害缺点 1 天，高缺点 1 - 2 天，中等缺点 5 - 7 天，低缺点 10-14 天。MTTR 与客户满意度呈负相关，因而很重要。
代码覆盖率(Code Coverage)
代码覆盖率是单元测试所笼罩的代码行所占的百分比，越高越好，指标是覆盖率超过 80%。能够为每个构建都执行代码覆盖率查看，确保团队不会部署未筹备好的代码。但代码覆盖率并不包含其余类型的测试，因而高代码覆盖率并不一定意味着代码品质高。
测试覆盖率(Test Coverage)
有时，术语 ” 测试覆盖率 ” 与 ” 代码覆盖率 ” 能够调换应用，但并不相同。当代码覆盖率度量编写的代码是否被测试笼罩时，测试覆盖率度量性能需要是否被现有测试用例集所笼罩。指标是 70-80% 的覆盖率。子组件包含需要笼罩、产品笼罩、危险笼罩和边界笼罩。这个度量确保性能满足并且只满足需要。
逃逸缺点(Escaped Defects)
这是在生产部署之后发现的缺点数量，是对软件品质的粗略度量。现实状况下，这个数字应该是零，如果不是零，团队应该从新评估其 QA 和部署流程，将其升高到零。
在开发周期中发现缺点越晚，修复老本就越高。因而，这是麻利团队应该跟踪的要害指标之一。
综合度量
麻利是通过工夫考验的软件交付形式，能够最大限度为客户带来价值。在这个过程中有几十甚至上百个指标，如果咱们认为所有指标都很重要，那就没有一个指标是真正重要的。要害是要抉择适宜团队的外围指标。不用说，如果没有执行的话，想法将毫无价值。是的，说起来容易做起来难。一开始会很艰难，有时很苦楚。但一旦团队成熟并晓得如何保持根本流程并跟踪要害指标，后果就会物超所值。
你好，我是俞凡，在 Motorola 做过研发，当初在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。为了不便大家当前能第一工夫看到文章，请敌人们关注公众号 ”DeepNoMind”，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的反对和能源，激励我继续写下去，和大家独特成长提高！
本文由 mdnice 多平台公布