为什么需要基于用户故事的角色指标？

作者 | WILL HAYES 、 PATRICK PLACE —— 卡耐基梅隆大学

我们这些参与过依赖软件系统的大规模开发和收购的人都见过这样的例子:对于任何给定的环境，度量计划都是由必须收集的一系列度量清单定义的。这种方法意味着，为了使项目有效进行并在需要时进行改进，必须制定度量标准。可以是对系统的改进，也可以是对系统被开发的方式，或者被管理的方式做出改进。

这样的列表通常会列出所需的指标，但可能很少甚至直接不说明为什么需要它们。当组织中产生怀疑，人们就会担心："如果我没有良好的表现，我的预算可能会被削减，或组织会收回我的工作。"在这篇博客中，我们讨论了如何将指标重塑为用户故事，从而提高它们的相关性和实用性，同时减轻人们的忧虑。

1、为什么是用户故事？

在许多情况（案例中）下，度量计划助长了一种形式主义，把重点放在了信息的表达上，而不是信息本身。强调产生自上向下的、确定性的图形规范或其他度量计划要求的数据描述(由项目管理强制执行)，会分散参与者对度量计划所揭示并阐明的潜在有用信息的注意力。

例如，事情变成了 "我要完成Excel图表数据的填充"，而不是 "我想要了解事情是怎么进行的"。在单纯填完所有数据后，寻找其他方法来分析数据的意愿似乎也减少了，从不同角度创新地看待数据的机会也可能丧失。对于度量标准所需交付的讨论可能会被过度关注为决策者提供所需的数据，似乎参与讨论的人是在整个决策过程之外的，与决策没有真正的利害关系。

在现实中，随着时间的推移，同一现象的不同属性会有不同的重要程度和意义，这取决于观察它们的人所扮演的角色。尤其是作为一种官僚主义的、流程式打钩的生产方式，限制了从多个角度观察这些属性的能力，甚至限制了寻找不同数据的能力。

度量项目需要更多地参与，并得到参与人员的认同。用户故事是有用的；它们在系统使用者的环境中进行开发，自然地让使用者们讨论。

2、在度量项目中运用用户故事

随着敏捷开发的出现，其中一大进步是用户故事的引入。用户故事不仅定义了系统应该做什么，而且还定义了谁想要一个特定的功能，更重要的是，他们为什么想要这个功能。这个定义通常表示为：

作为一个<角色>，我需要系统<有所执行>，以便<我实现目标>。

其他信息，谁(角色)以及为什么(目标)，为开发人员提供了对所需功能的更深入的洞察。这与度量的类比很明显：我们可以扩展每个指标的定义，以满足那些需要的人，达到他们的预期目的。我们建议指标应该表示为：

作为一个<角色>，我需要<这个度量>，以便<我实现一些目标（例如，为一个决定提供信息）>。

当转换为用户故事时，指标就变成了一种表达方式，使用这个系统的人用它操作，并知道他们的优先级是什么。用户提出指标和需求以后这个用户故事会有不同的实现方法，但是这种基于用户故事的方式还是会让用户参与到解决问题的过程中。

让我们考虑一下这种表达方式的一些优势。

• 每个指标都有其使用者和目的。我们不再因为我们一直这么做，或者只是因为某个权威人士说我们必须这么做而收集这些指标。此外，这也向新成员解释了为什么要收集指标。这在人员流动频繁的组织中尤为重要。

• 在组织中，并非每个角色都需要每个指标。例如，软件开发者可能对测试套件提供的代码覆盖率感兴趣，测试人员和其他质量工程师也是如此。然而，这样的指标通常就不那么吸引项目管理人员，他们更可能关注计划的进展、周期和缺陷计数。

• 它为每个人规定了度量的明确用法，并对指标的预期功能有了更深入的了解。如果指标是以已知的方式使用，那该用法将消除人们在不知道为什么要收集指标时所产生的恐惧。反之亦然，如果指标是以某种未知的方式使用，人们对组织的信任就会被削弱。

• 可以随着时间的推移调整度量计划，因为不同角色的人会寻求不同的信息。特殊情况下，可以用一种富有逻辑、表述清晰的方式来表达对新指标的需求。同样地，他们也可以说某个指标对他们没有帮助，在这种情况下，就可以放弃。

然而，用户故事和我们的度量故事之间有一个关键的区别。前者代表了一个要建立的功能，一旦功能开发完成，故事就可以关闭。后者代表了项目管理中的一项持续进行的活动，只有在确定不再需要该指标时才会关闭。这种差异的后果是，我们不希望度量故事出现在待办事项列表中（尽管启用新的功能需要的数据收集有可能会出现在待办事项列表中），并且度量故事不会出现在燃尽/燃耗图表中。

3、目标和需求

使用目标为度量程序提供信息的想法远非新鲜事。Goal/Question/Metric (GQM)这种方法在20世纪80年代中期就被记录下来，并且一直盛行。在适当的计划之后，第一次会议通常是一个正式的头脑风暴。在这个研讨会上，明确了度量计划的目标。这些目标通常是高层次的，但同时也可以被视为一种约束，因为所有随后派生的问题和指标都必须与原始目标相关联。相比之下，将指标作为用户故事，而目标是故事的一部分，这样组织中所有级别的人员都可以表达自己的需求。如果度量计划的目标清单是一个必要的工具，那么关联分析，加上单个故事，就可以用来表示高层次目标。

当遇到紧急的度量需求时，可能很难在一个严格自上向下的框架中满足他们，该框架最终将所有问题和指标映射到一个目标网络中，并追溯到组织目的的最高抽象。虽然与部门、企业和细分市场的雄心之间的逻辑联系是合理的，但记录它们的努力有时会使本地决策者的注意力集中在一个绩效模型上，而这只占很小的一部分。与其坚持映射到分支、部门和公司级别目标声明相匹配的的潜在学术实践，不如使用用户故事来指定数据、决策和需要它们的角色，这有助于缩短指标的验证和实现周期。

同样，对个人角色的关注有助于激励收集和使用指标工作的所有权。这些角色的需求是在一个更大的绩效框架内运行的，可以在不同的抽象级别(在组织中，在产品架构中，在特定产品线的时间轴上)理解该框架。然而，一直忠实于对这些更大抽象概念并不是对指定指标的合法性进行论证的主要来源。我们在实践中观察到，认为指标是“我们必须收集以安抚其他人”的观点是最大挑战之一。通常，其他角色在某种程度上超出收集并报告指标人员的控制范围。

通过用户故事中指定的基于人物的指标，可以更直接地验证完成工作所需的角色和决策的合法性。目标、问题和指标之间的映射不再是判断指标是否正确的主要基础。简单来说，这些指标必须为决策者服务。许多人认为GQM范式是为了实现结果而设计的，因为目标和问题肯定来自于反映在角色和他们所做的决定中的相同动机。然而实际上，当外部推动者组织一个研讨会时，自上而下的关注通常是结果合法性的主要依据，建立一套衡量标准所遵循的步骤通常从自上而下的角度进行优化。

4、警告、注意事项和潜在的陷阱

我们已经通过一些项目实现了本文中所描述的基于角色的用户故事，并根据我们的经验在此提供了一些注意事项:

• 并非所有在用户故事中确定的信息需求都能轻易或有利地转化为可收集的度量。“我需要x来实现y”的模板，在实践中往往会从人们那里引出大量的一般性问题，例如："谁知道我需要的这个东西？"这样的问题不容易被转换为一个指标。为了使引出用户故事的工作可控且有用，项目应该严格关注指标，这样就不会因为不相关需求的表达而使工作被淹没。一个能够熟练识别真正重要的、可以用量化指标来表达需求的推动者在这里会很有帮助。

• 不是每个角色、信息需求和决定的组合都能产生有用的东西。如果没有强有力的引导，用户故事的生成可能会成为一种理论上的练习，徘徊在没有人关心的领域。

• 在时间和资源有限的环境中，要让人们自己面对问题可能是一件很有挑战性的事情。我们看到人们抵制生成用户故事的工作，因为他们担心这样做会增加他们已经很艰巨的工作量。同样的，他们也担心没有时间做额外但必须的工作。我们相信，将角色作为用户故事的一部分，可以使人们更容易表达他们真正关心的指标，而不是整个项目。如果事实证明他们选择的指标没有用，那么基于学习经验调整工作的敏捷思维应该会帮助他们克服承认第一次迭代失败的障碍，并尝试新的指标来满足他们的需求。

5、为什么需要指标

我们目前正在一些政府项目中使用基于角色的指标和用户故事，到目前为止，反馈都是积极的。其中一位参与者在使用这种方法时评价道："我们经常忘记指标为什么需要"。此外，与典型的GQM会议不同（可能会让参与者筋疲力尽），引出用户故事可以在短时间内开完会，积聚小组的力量，并在大家疲惫前散去。

迄今为止，我们的经验是，把指标写成用户故事是一种非常有效的方式，它帮助收集项目各成员的指标需求，以形成整个项目。同样的，它也加强了一个大型项目中不同部门之间的沟通，从而促进了优质想法的快速传播。有趣的是，我们有一个同事，当看到另一个人消费的指标的人和原因时，说“我也想要。”

更多精彩内容和视频，请关注同名微信公众号。