Joe Schofield在2021年底，发表了最新文章，如何改进scrum的度量与报告。他在上一篇文章《》对于敏捷、敏捷大师们，尤其是敏捷的标准化进程极尽冷嘲热讽。在实践层面，他还是给出很多建设性的意见。
1.如何写故事？
Joe首先就是介绍了如何更好地写故事？其主要思想就是将功能点分析（FPA）与用户故事结合，用“故事”来体现功能需求（事务功能与数据功能），用“验收标准”（AC）来体现非功能需求。这部分我将单独开一篇来介绍。
本文主要讲如何度量，如何做报告。
2.从测量（measure）到度量（metric）
在英语中，measure既是一个名词，代表收集、测量到（例如：数量、重量、价值、尺寸等）的数字；也是一个动词，指的是将收集的数值与标准值、计划值对比。而metric的含义，是对两个测量值进行比较或计算，而产生了有意义的“衍生数据”。我认为也可以称之为指标。
例如：scrum团队会收集：他们的计划工时、实际工时；计划故事点、实际故事点；这些都是测量值（measure）。在此基础上，他们通过对计划工时与实际工时进行比较，产生一个度量值（metric）——两者的偏差情况，即：代价函数。
在我看来，这就是从data（数据）到information（信息）的升华。
在全世界的软件工程领域，比较常见的度量，就是“生产率”以及“交付速率”。
但是，如何应该如何使用这些度量值？
如果就是单纯地比较团队之间的生产率、交付速率，是不利于敏捷的“自组织”，会伤害团队之间、团队与干系人之间的信任。因为这些度量没有考虑以下因素：
产品与服务的目标；
团队人数与专业知识；
物理与技术环境；
跨部门合作的隐形投入；
自组织所特有的团队角色。
在国内，我听到的埋怨主要是——没有考虑功能的复杂度。
这些度量很容使得团队陷入为了数字而数字的尴尬处境。尤其是故事点，本身并不标准，很容易“膨胀变形”。
领导们经常开会，讨论如何让团队A的“生产率”更像团队B，而不是如何消除团队A每天面临的障碍。通常，领导抑制了团队成功所必需的文化变革。
3、团队的测量
首要的问题，还是为什么要测量？
原因一，就是敏捷原则的第12条：团队应该定期反思如何提高成效，并依此调整自身的行为表现。
这种定期的“回顾”，有很多的观察点、测量值，例如：合作技能，跨职能部门发展、沟通、工具知识、注意力分散管理、自我约束、backlog细化和工作流等等。
但是最常见的测量还是：已验收的故事数，故事点数量，计划工期、实际工期。
如上文所述，根据这些测量值，团队可以做一些“启发性”的度量——计划与实际的偏差。这个度量值，可以帮助团队在未来的sprint计划会上，限制故事点的数量。
插一句：这个度量，对于使用“看板”的团队也有帮助，可以量化在制品（WIP）的规模；可以优化“提前期”与“周期”。
原因二，传统的项目管理理论。
即对传统项目管理“铁三角”（进度、成本、范围）的测量。但是这三个测量对于敏捷团队而言，都会造成价值递减。
4、组织的测量
对于组织级而言，传统的项目报告就是将所有正在进行的项目展示在一起：Y轴上逐一排列着项目，X轴显示着项目的进度、成本、质量一些关键指标，每个指标由“红黄绿”三种灯来指示。
绿灯显示项目的指标比较健康，黄灯表示需要警惕，而红灯这是需要格外关注，需要被干预。
组织级的财务管理者普遍有个认知误区：项目的进度没有达到某个里程碑（程度），相应的成本也肯定没有支出那么多。
几十年来，组织一直执着于修复“红灯”，主要的方法就是通过“变更”或“异常报告”。具体的过程：偏差分析、制定纠偏措施、预测新的“铁三角”目标。组织为此会制定繁琐且有“侵入性”的流程，目的就是让高层相信——项目的明天会更好。
但是，由于业务创新驱动的特点，敏捷项目越是到后期，越是会发生需求变更、优先级调整。如果用传统的报告形式，敏捷的项目群肯定是“红灯一片”。
相比较传统的铁三角，敏捷的组织级项目管理应该关注：价值交付、发版（release）、优先级。
这“新三角”应该如何来看？怎么实现？
价值交付。我们去观察自己的组织里，是否存在着一些项目，投入了很多却一直没有产出。正确的做法是，一开始，组织的“种子资金”就是鼓励团队交付早期的价值，然后随着价值交付来投入资金；如果发现没有价值，或者边际效益递减，那么就立刻停止投入。
发版。组织是选择交付的能力？还是控制进度的能力？尽快与频繁的发版可以给组织带来更快更频繁的价值，所以，跟踪发版的规模与速率比调整进度更重要。
优先级。这一点与传统的范围有一些对应关系，我们都知道“范围内”比“范围外”的优先级要高。但是在Scrum中，优先级应该是在每个“梳理”中，由PO来决定的。
梳理（grooming/refinement）是Scrum的变更控制流程，因为要满足不断发展与创新的业务需要，敏捷组织不应该使用传统的、繁重的变更流程。
5、推荐的度量
Joe推荐了几个有洞见的度量。
累计交付价值。PO在写故事的时候，一定要让故事有价值。结合FPA（功能点分析），在这一点上会事半功倍。所以在每一个sprint，以及每一个发版中，就可以度量出包含了多少功能点，也就可以折算出相应的货币金额。
此外的度量：每个版本的缺陷数，交付速率与缺陷的关系，产能与速率的关系。
最后一个度量，就是分析“交付速率”的差异原因，如下图。因为每个sprint的故事点不一样，所以交付速率才有差异。
组织的高层肯定会寻找团队速率波动的原因，如果没有这些专业信息，他们很有可能想到其他原因。甚至在团队之间进行比较，设定标准，寻找适合所有团队的最佳实践。
组织应该认识到每一个团队都有其相对的价值。不应该只考虑故事点的价值(价格)，而忽悠了理解团队。
结论
Scrum的核心是交付价值，所以，传统的项目/组织的度量、分析报告是不适用的。应该将功能点分析结合进来，可以更有效地帮助组织进行敏捷转型。
对于本文，我也进行了反思。项目本身是不区分敏捷与传统的，敏捷只是一种项目管理模式。用瀑布的方式也可以“业务创新驱动”；也要注意交付价值；也可以重新来审视“新三角”。
此外就是，西方软件工程领域存在着严重的官僚主义。而我们中国自古以来就强调“以人为本”，我们能否少走弯路？