度量避坑指南，合理选择指标（上） | IDCF

本文主要是介绍度量避坑指南，合理选择指标（上） | IDCF，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：Patrick Kua  领导开发团队利用敏捷方法为客户提供有价值的软件，他是《回顾手册：敏捷团队指南》的作者

译者：冬哥

原文：https://martinfowler.com/articles/useOfMetrics.html

管理层都喜欢指标，是基于这样的出发点，“我们需要一个数字来衡量我们的表现。数字会关注人并帮助我们衡量成功。” 虽然本意是好的，但数字管理会不自觉地导致有问题的行为，并最终有损于更广泛的项目和组织目标。指标本质上并不是一件坏事，只是经常不恰当地被使用。这篇文章展示了管理层对指标的传统使用所引起的许多问题，并提供了解决这些功能障碍的替代方法。

告诉我你如何衡量我，我会告诉你我的行为方式。

——埃利亚胡·戈德拉特

一、我们使用指标的方式有什么问题？

从数字管理角度查看指标的组织遵循如下流程：

• 管理层提出目标并制定措施；

• 管理层为从事工作的人制定了一个长期（3-6 个月到1年）的目标；

• 管理层只传达目标（根据商定的指标）；

• 从事工作的人尽其所能达到目标人数。

这一过程鼓励出于以下目的对指标进行装载：

• 指标作为目标——数字的指标使人们特别容易将其用作传达目标的唯一手段。告诉人们一个尺度和一个数字通常比解释一个复杂得多的目标要容易得多。目标通常是一个拍脑门的数字，一些组织甚至花费大量时间来确定该数字应该是多少。

• 指标作为绩效——有了一个既定的数字而不是一个明确的目标，管理人员现在很容易使用相同的衡量标准来跟踪人们朝着目标前进的速度。许多组织将这些数字与个人绩效目标联系起来。

• 指标作为最佳实践——将指标同时用作目标和绩效衡量标准会导致意想不到的副作用——这意味着该指标是实现目标的最佳方法。当一个独立的团体使用数字目标来衡量其他人时，它会对从事工作的人施加更大的压力，以达到既定的数字。由于他们仅根据该指标的绩效进行衡量，因此他们会尽其所能来实现该特定指标。这意味着没有其他方法最适合实现最终目标。

装载具有多种用途的单一指标会导致许多问题，尤其是在处理软件等知识工作时。度量是对一个复杂得多的属性的一种简化，简化复杂性的是以忽视真正的最终目标为代价的，并以次优结果告终。

让我们看一个例子：

一位测试经理，我们称她为Mary，每周都会与开发主管Dan举行会议。“我们的错误数量如何了？” 她问他们最近的一次迭代。丹回答说：“我们清除了三个优先级为一级的错误，修复了四个优先级为二级的错误并清除了创纪录的十二个优先级为三级的错误。这周还不错吧？”

玛丽看着开发负责人，微微摇头，“很遗憾，我们的客户报告了五个一级错误，六个二级错误和十五个三级错误。下周你需要更加努力。” 因错过目标而感到愤怒和不知所措的丹离开了会议，想着让他的团队再工作一个周末。

在这个非常简单的故事中，所选择的指标达到了使会议快速进行的好处：在丹报告他的结果和玛丽回应后，两个人都很快了解了进展。不幸的是，交付有用软件的隐含目标被遗漏了，丹离开会议时提出了一个更可能导致进一步软件问题并拖累软件质量的解决方案。

玛丽陈述她的目标的方式给丹施加了压力，要求他减少错误的数量，这似乎是一个值得钦佩的目标。虽然减少错误的数量是一个很好的目标，但它也导致了一个非常被动的解决方案，丹离开会议时想着该要多努力工作。Mary 提出的问题忽视了更广泛的目标，也没有提出关键问题来帮助指导 Dan 和他的团队解决错误存在的根本原因。如果不解决这个根本原因，Dan 和他的团队注定要终身修复错误。

Dan 正在经历单循环学习[1]。单循环学习是对同一问题的重复尝试，方法没有变化，也从不质疑目标。如果Dan希望摆脱这种恶性循环，他需要做一些不一样的事情。软件的不当使用使 Dan 偏离了交付有用软件和提高整体软件质量的最终目标。爱因斯坦对精神错乱的定义似乎很适合这里：“一遍又一遍地做同样的事情，却期待不同的结果。”

二、小心你度量的东西 

组织喜欢指标，因为它使设定目标更容易，并阻止人们质疑目标背后的目标。这导致管理者对组织效率产生错误的认识。与强大指标相关的强大激励迫使人们只专注于工作的一部分，而忽略了可能使目标更加成功的其他促成因素。组织必须警惕这种积极的破坏性焦点，它会导致人们忽视其他重要因素。

即使是敏捷技术也不能保护团队免受因测量和跟踪错误数字而导致的不良行为的影响。例如，敏捷团队经常使用故事卡[2] 进行开发工作。团队经常在其组织的软件生命周期中将这些小的工作增量可视化。

一个典型的流程可能看起来像这样，理想的故事流从左到右移动：

 （图 1：故事墙示例）

 

 

管理人员和产品管理人员经常会问这样一个问题：“该功能多久可以完成？” 团队通常选择将其解释为编码完成时，屈服于测试和生产路径是软件过程中微不足道和无关紧要的部分的想法。项目管理则通过提出下述问题进一步强化了这种看法：“我们这周完成了多少个故事？” 而不是更好的问题，“我们有信心向最终用户发布多少故事？” 或者更好的是，“我们向最终用户发布了多少故事？” 再好一些的问题是，“我们的用户从我们最近的版本中发现了多少价值？”

团队希望做正确的事情，因此这些问题和指标促使开发人员专注于让故事开发完成。让我们看看过度专注于这个次优目标的后果：

Malcolm 是营销代表，他总是对开发人员为他构建的产品非常感兴趣，因此他会尽可能频繁地到访团队。他经常与开发人员 Dan 交谈，询问他的功能何时完成。Dan，不想让马尔科姆失望，他努力专注于完成马尔科姆提出的任何要求，他知道离Malcolm回来询问进展不远了。Dan经常对自己说，“这个功能一定非常重要。” Tim 是团队的最新的测试人员，经常需要与 Dan 等开发人员联系，以了解如何触发新开发的功能。

有一天，蒂姆走近丹，“嗨丹！我真的需要你的帮助来了解如何测试你上周完成的这个功能。” 丹，在提供快照的压力下，“你不能自己做任何事情吗？我需要完成这个功能，这样马尔科姆才能摆脱我的支持。” 对丹的回应感到震惊，蒂姆回到他的办公桌前，等待着。他心想：“除非丹帮我，否则我什么也做不了。”

每周都会发生这种情况，随着时间的推移，等待测试的故事会越来越多。最终，马尔科姆召集团队开会，关心他两个月前要求的功能在生产中仍然未能看到。令人惊讶的是，丹说他一个多月前就完成了。蒂姆害羞地回答说：“我无法测试那个故事，因为我需要丹的帮助，而他一直忙于其他工作。我不想打断他。”

我们可以从这个故事中学到什么？首先，对 Malcolm 来说重要的是工作流程已经完成。尽管马尔科姆问什么时候可以完成，但他真正想要的是能够在生产中使用它。我们知道蒂姆没有完成任务所需的知识，他的工作以及丹完成更多工作的压力阻止蒂姆获得更多知识。最终的结果是在测试过程中形成了一个恶性循环，一直没有发布，而且 Malcolm 不明白为什么他没有收到他要求的功能。

这就是为什么像看板软件开发这样的方法鼓励 明确的正在进行的工作 限制。当瓶颈出现时，这些限制迫使人们帮助他人。这些 WIP 限制有助于克服当人们用错误的个人生产力指标而不是交付的整体价值来衡量时出现的不良行为。

《精益软件开发》一书，强调衡量端到端结果的重要性，而不仅仅是过程的一小部分，并提出称之为“优化整体”的原则。优化整体意味着确保使用的指标不会推动次优行为实现交付有用软件的真正目标。（未完待续......）

 

 

这篇关于度量避坑指南，合理选择指标（上） | IDCF的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---