近年来，敏捷社区已多次尝试找出衡量组织转型效果的最佳方式，一些较知名的尝试，包括 Agile Scaling Model 、 Nokia Test 、 ThoughtWorks Agile Assessment 和 Sidky Agile Measurement Index (SAMI) 。最近，敏捷博客世界中又掀起了一场关于如何度量的辩论。
Esther Derby 在最近一篇题为“ 敏捷的度量 ”的博文中，回顾了度量的种类，人们通常在想了解自己的组织转型的进展程度时，求助于这些度量指标。
- 采用敏捷方法的团队数量
- 接受过敏捷方法培训的人数
- 采用敏捷方法的项目数量
- 认证的敏捷教练数量
她指出，这些指标都会让你误入歧途，恰当的度量指标应该是那些能显示出通向敏捷转型所达到的目标的趋势。她的三个建议是：
- 修理缺陷工作量和开发新特性工作量的比率
- 周期时间
- 遗漏到产品中的缺陷
她最后的建议是：
当你考虑度量指标时，应警惕目标值。和目标值比较几乎总会导致失真。意味着人们总会试图达到目标、也许采取的手段与目标背后的初衷完全相反。
Isaac Montgomery 在近期发表在 Rally Software Agile Blog 上的，题为“衡量敏捷投资的影响”的系列文章中，也表达的类似的见解：
敏捷社区对于类似“如何衡量敏捷是否成功”问题的典型回应是通过某种敏捷成熟度评估，比如 Nokia Test。这些工具清晰、易于使用、并可以非常有效地帮助组织评估他们是否遵从了良好的敏捷实践。然而，在单独使用时，会无法实现高层领导的愿望——也失掉了调整敏捷到它本来目标的一个重要的机会。
他建议问题应该是：
如果敏捷的成功等同于业务的成功，那么真正的问题是：“我们如何度量业务成功？”
Isaac 建议采用的指标应属于下面的类别：
- 生产率
- 质量
- 反应速度
- 客户满意度
- 员工满意度
- 可预测性
最后， Gil Zilberfeld 在“ 敏捷转型的真相 ”中有一些简单的建议，当他用敏捷转型的指标与经常被引用的 Standish Group CHAOS 报告对比时：
获取你自己的数据。测量你自己的目标，并确定你的成功。让其他人帮你做（或者完全不做，就这件事来说）是愚蠢的。
你如何衡量组织的敏捷成熟度？你发现什么度量指标最有帮助？
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论