敏捷方法有几个度量标准，可以显示软件开发的操作方面. E.g., 一些揭示了过程效率, 发展的速度, 完成某一特定功能所需的时间, 等.
然而, 在正确的语境中, 这些操作指标讲述了一个故事，揭示了交付的实际业务价值. 在这篇文章中，我们的目标是揭示敏捷指标，帮助你从信息过渡到洞察.
数据驱动的响应能力
从工作开始(不仅仅是任务创建，而是在一个真实的故事点上工作)到工作交付之间的时间被认为是周期时间或流程内时间. 而这个指标的平均值告诉您实现特定功能的速度, 它没有说任何关于在要求的时间框架内交付的确定性.
一年的开发价值是这样的:
来源:内部数据
x轴实际上是一整年的时间除以月份. y轴显示了sprint两周内每个交付工作输出的天数. 尽管存在异常值，但大约85%的工作是在10到20天内交付的.
这个数据点有助于回答客户的问题, “该功能能在12天内交付吗?”. 看看这张图表, 我们确信我们可以在20天内交付所要求的功能.
这里需要注意的一个关键点是上下文. 这种数据驱动的响应性假设我们与一个同样熟练的团队一起工作, 有足够的领域知识, 他们大部分时间都在做类似的项目.
交付的可预测性
吞吐量和冲刺速度是基本的度量标准. Sprint Velocity是在一个确定的时期内，在一个Sprint中完成的故事点的平均值. 吞吐量是一段时间内完成的故事点的数量. 例如，在上面的图表中，平均吞吐量是每个sprint 16个工作单位.
吞吐量指标还提供了对团队生产力的大量洞察，并可用于评估需要推出的工作和执行该工作所需的技能之间的团队一致性和匹配.
冲刺速度对于详细的冲刺计划来说是一个很好的度量. 然而, 吞吐量有利于制定高层管理目标，这些目标影响重要的公司绩效指标. 仅仅看吞吐量数字并不能告诉我们什么. 然而, 看看产品待办事项列表, 可以很容易地找到特定功能所需的工作单元，然后将它们除以吞吐量. 结果数字会让产品所有者知道交付特定功能所需的时间线.
由此产生的时间线为特定时间段内特定特性的交付提供了相当好的可预测性.
价值交付
敏捷方法的基石之一是交付给客户的价值. 与发布相关的净启动子评分(NPS), 能否帮助产品所有者微调他们对市场的理解.
净推荐人得分是根据一个简单的问题计算出来的——“你有多大可能向别人推荐这个产品。?得分为9分和10分的受访者被称为促销员. 得分为7分和8分的人被归类为被动语态，而得分为6分或6分以下的人被归类为诽谤者. 然后通过从启动子中减去诽谤者来计算NPS. 被动语态对整体数量有贡献，因此把发起者和诋毁者都拉了下来.
NPS可以帮助产品所有者了解功能推出的时间是否符合市场趋势，从而帮助他们的客户. 这个反馈, 反过来, Better帮助产品待办事项列表梳理和优先级特性发布，使之与客户的需求更加同步.
情境数据到洞察力
借用看板世界, 一个累积的流程图很能说明问题——与我们在这里讨论的早期指标相结合. 让我们考虑以下累积流程图:
图片来源: MicroTool
在图的待办事项部分, 任意两个给定日期之间的直线斜率表示工作到达的速度. 与此同时，“完成”部分中直线的斜率定义了工作的离开率. 在任何给定的点上，这两个速率之间的偏差决定了对发布时间表的信心.
在更长的一段时间内取平均值很简单. 然而，平均水平可能并不能反映正确的情况. 所有的数字都应该结合实际情况. 例如，有些月份可能有异常多的bug需要修复. 这一修复是以其他被搁置的工作为代价的. 或者，有一项功能是c级高管迫切要求的. 这种急件工作也会以常规的交付工作为代价.
结论
敏捷方法定义了大量的度量标准. 然而, 大多数敏捷指标在单独读取时显示单个信息, 告诉我们的很少. 在其他信息的环境中，这些度量显示了有价值的见解. 他们在交付的业务价值方面描绘了正确的图景.
这篇文章旨在让你思考产品开发过程如何量化商业价值. 我们很乐意在下面的评论中听到你的想法.
