作者：Patrick Kua 领导开发团队利用敏捷方法为客户提供有价值的软件，他是《回顾手册：敏捷团队指南》的作者原文：https://martinfowler.com/articles/useOfMetrics.html
管理层都喜欢指标，是基于这样的出发点，“我们需要一个数字来衡量我们的表现。数字会关注人并帮助我们衡量成功。” 虽然本意是好的，但数字管理会不自觉地导致有问题的行为，并最终有损于更广泛的项目和组织目标。指标本质上并不是一件坏事，只是经常不恰当地被使用。这篇文章展示了管理层对指标的传统使用所引起的许多问题，并提供了解决这些功能障碍的替代方法。
告诉我你如何衡量我，我会告诉你我的行为方式。
——埃利亚胡·戈德拉特
从数字管理角度查看指标的组织遵循如下流程：
- 管理层为从事工作的人制定了一个长期（3-6 个月到1年）的目标；
- 指标作为目标——数字的指标使人们特别容易将其用作传达目标的唯一手段。告诉人们一个尺度和一个数字通常比解释一个复杂得多的目标要容易得多。目标通常是一个拍脑门的数字，一些组织甚至花费大量时间来确定该数字应该是多少。
- 指标作为绩效——有了一个既定的数字而不是一个明确的目标，管理人员现在很容易使用相同的衡量标准来跟踪人们朝着目标前进的速度。许多组织将这些数字与个人绩效目标联系起来。
- 指标作为最佳实践——将指标同时用作目标和绩效衡量标准会导致意想不到的副作用——这意味着该指标是实现目标的最佳方法。当一个独立的团体使用数字目标来衡量其他人时，它会对从事工作的人施加更大的压力，以达到既定的数字。由于他们仅根据该指标的绩效进行衡量，因此他们会尽其所能来实现该特定指标。这意味着没有其他方法最适合实现最终目标。
装载具有多种用途的单一指标会导致许多问题，尤其是在处理软件等知识工作时。度量是对一个复杂得多的属性的一种简化，简化复杂性的是以忽视真正的最终目标为代价的，并以次优结果告终。一位测试经理，我们称她为Mary，每周都会与开发主管Dan举行会议。“我们的错误数量如何了？” 她问他们最近的一次迭代。丹回答说：“我们清除了三个优先级为一级的错误，修复了四个优先级为二级的错误并清除了创纪录的十二个优先级为三级的错误。这周还不错吧？”玛丽看着开发负责人，微微摇头，“很遗憾，我们的客户报告了五个一级错误，六个二级错误和十五个三级错误。下周你需要更加努力。” 因错过目标而感到愤怒和不知所措的丹离开了会议，想着让他的团队再工作一个周末。
在这个非常简单的故事中，所选择的指标达到了使会议快速进行的好处：在丹报告他的结果和玛丽回应后，两个人都很快了解了进展。不幸的是，交付有用软件的隐含目标被遗漏了，丹离开会议时提出了一个更可能导致进一步软件问题并拖累软件质量的解决方案。玛丽陈述她的目标的方式给丹施加了压力，要求他减少错误的数量，这似乎是一个值得钦佩的目标。虽然减少错误的数量是一个很好的目标，但它也导致了一个非常被动的解决方案，丹离开会议时想着该要多努力工作。Mary 提出的问题忽视了更广泛的目标，也没有提出关键问题来帮助指导 Dan 和他的团队解决错误存在的根本原因。如果不解决这个根本原因，Dan 和他的团队注定要终身修复错误。Dan 正在经历单循环学习[1]。单循环学习是对同一问题的重复尝试，方法没有变化，也从不质疑目标。如果Dan希望摆脱这种恶性循环，他需要做一些不一样的事情。软件的不当使用使 Dan 偏离了交付有用软件和提高整体软件质量的最终目标。爱因斯坦对精神错乱的定义似乎很适合这里：“一遍又一遍地做同样的事情，却期待不同的结果。”组织喜欢指标，因为它使设定目标更容易，并阻止人们质疑目标背后的目标。这导致管理者对组织效率产生错误的认识。与强大指标相关的强大激励迫使人们只专注于工作的一部分，而忽略了可能使目标更加成功的其他促成因素。组织必须警惕这种积极的破坏性焦点，它会导致人们忽视其他重要因素。
即使是敏捷技术也不能保护团队免受因测量和跟踪错误数字而导致的不良行为的影响。例如，敏捷团队经常使用故事卡[2] 进行开发工作。团队经常在其组织的软件生命周期中将这些小的工作增量可视化。一个典型的流程可能看起来像这样，理想的故事流从左到右移动：管理人员和产品管理人员经常会问这样一个问题：“该功能多久可以完成？” 团队通常选择将其解释为编码完成时，屈服于测试和生产路径是软件过程中微不足道和无关紧要的部分的想法。项目管理则通过提出下述问题进一步强化了这种看法：“我们这周完成了多少个故事？” 而不是更好的问题，“我们有信心向最终用户发布多少故事？” 或者更好的是，“我们向最终用户发布了多少故事？” 再好一些的问题是，“我们的用户从我们最近的版本中发现了多少价值？”团队希望做正确的事情，因此这些问题和指标促使开发人员专注于让故事开发完成。让我们看看过度专注于这个次优目标的后果：Malcolm 是营销代表，他总是对开发人员为他构建的产品非常感兴趣，因此他会尽可能频繁地到访团队。他经常与开发人员 Dan 交谈，询问他的功能何时完成。Dan，不想让马尔科姆失望，他努力专注于完成马尔科姆提出的任何要求，他知道离Malcolm回来询问进展不远了。Dan经常对自己说，“这个功能一定非常重要。” Tim 是团队的最新的测试人员，经常需要与 Dan 等开发人员联系，以了解如何触发新开发的功能。有一天，蒂姆走近丹，“嗨丹！我真的需要你的帮助来了解如何测试你上周完成的这个功能。” 丹，在提供快照的压力下，“你不能自己做任何事情吗？我需要完成这个功能，这样马尔科姆才能摆脱我的支持。” 对丹的回应感到震惊，蒂姆回到他的办公桌前，等待着。他心想：“除非丹帮我，否则我什么也做不了。”每周都会发生这种情况，随着时间的推移，等待测试的故事会越来越多。最终，马尔科姆召集团队开会，关心他两个月前要求的功能在生产中仍然未能看到。令人惊讶的是，丹说他一个多月前就完成了。蒂姆害羞地回答说：“我无法测试那个故事，因为我需要丹的帮助，而他一直忙于其他工作。我不想打断他。”
我们可以从这个故事中学到什么？首先，对 Malcolm 来说重要的是工作流程已经完成。尽管马尔科姆问什么时候可以完成，但他真正想要的是能够在生产中使用它。我们知道蒂姆没有完成任务所需的知识，他的工作以及丹完成更多工作的压力阻止蒂姆获得更多知识。最终的结果是在测试过程中形成了一个恶性循环，一直没有发布，而且 Malcolm 不明白为什么他没有收到他要求的功能。这就是为什么像看板软件开发这样的方法鼓励 明确的正在进行的工作 限制。当瓶颈出现时，这些限制迫使人们帮助他人。这些 WIP 限制有助于克服当人们用错误的个人生产力指标而不是交付的整体价值来衡量时出现的不良行为。《精益软件开发》一书，强调衡量端到端结果的重要性，而不仅仅是过程的一小部分，并提出称之为“优化整体”的原则。优化整体意味着确保使用的指标不会推动次优行为实现交付有用软件的真正目标。鉴于因指标使用不当而出现的不良行为，这是否就意味着它们没有立足之地？度量指标当然有其发挥空间，只是需要一种不同的方法。使用以下指南可引导你更恰当地使用指标：
在传统风格中，管理层决定实现特定目标的最佳措施是什么；然后，管理层根据该措施设定目标；然后，管理层只向从事工作的人阐明这个目标，通常是用数字表示。为监控目标进展而选择的措施与实际目标本身之间的界限很模糊。随着时间的推移，衡量背后的原因消失了。即便是该指标与最终目标不再相关，人们却依然专注于实现指标。度量的一个更合适的用途是确保所选的进度度量（指标），始终与其目的（目标）相关。例如，在软件开发的场景中，您可能会看到如下定义的指标：- 方法必须少于 15 行，一个方法的参数不能超过 4 个，方法圈复杂度不得超过 20。
适当地使用度量标准，每一项措施都应与其最初的目的明确联系起来。当前的跟踪和监控机制必须与其目标解耦，并明确目标以便帮助人们更好地理解指标的意图。存在于更丰富的上下文中的度量将指导人们为实现目标做出更合适、更务实并且更有用的决策。缺乏目的，付出的努力意味着人们想方设法创造性地和系统做游戏，最终将偏离真正的目标。- 我们希望我们的代码不那么复杂并且更容易改变。因此，我们的目标应该是编写具有低圈复杂度（小于 20 行）的短方法（少于 15 行）。我们还应该瞄准少数参数（最多四个），以便方法尽可能保持专注。
将指标与目标明确联系起来，可以让人们更好地挑战其相关性，找到满足需求的其他方法，并帮助人们理解数字背后的意图。如果没有明确的目的，人们可能会想方设法，却无意中违背了隐含的目标。例如，许多技术可能都有助于减少方法长度，但如果不以正确的意图应用则更难阅读，从而增加整体复杂性。软件开发的本质意味着大多数工作是知识工作，因此很难观察。监控活动（他们坐在电脑前的时间）很容易，但很难观察他们产生的价值（满足实际需求的有用软件）。人们越远离代码，他们就越难理解所涉及的复杂性。这意味着，对于离工作最远的人来说，要真正了解监控目标进展的最佳措施，即使不是不可能，也是非常困难的。转向更恰当地使用指标意味着管理层不能孤立地提出措施。他们不能再自欺欺人地认为自己知道监控进度的最佳方法，并停止执行可能与目标最相关也可能毫不相关的措施。相反，管理层负责确保始终保持最终目标，与最了解系统的人合作，提出最有意义的措施来监控进度。管理层对于指标难以抗拒，因为它将组织的复杂性提炼为每个人都能理解的东西，一个数字。很容易看出一个数字比另一个更大或更小，或者一个数字与另一个数字的距离有多远。但是很难看出这个数字是否仍然相关。传统的管理方法喜欢使用这些指标，因为它可以在实现目标时轻松沟通。“只要达到这个数字，我们就会没事的”。当你将一个定性的和高度解释性的问题（想想生产力、质量和可用性）转化为一个数字时，任何数字都是相对的和随意的。5% 和 95% 的代码覆盖率可能存在显著差异，但 94% 和 95% 之间真的存在显著差异吗？选择 95% 作为目标有助于人们了解何时停止，但如果需要付出一个数量级的努力才能获得最后的 1%，这真的值得吗？这只是人们必须在他们自己的组织环境中主观解决的事情。与目标是否实现相比，查看趋势提供了更有趣的信息。确定是否达到目标很容易，难的是，管理人员必须与有技能的人一起来完成观察趋势的工作，看看他们是否朝着期望的方向和是否以足够快的速度前进。趋势为随组织复杂性而来的绩效提供了领先指标。当趋势越来越远离理想状态时，关注数字的差距显然毫无意义。关注趋势很重要，因为它会根据有关实施的任何更改的真实数据提供反馈，并为组织做出更多反应选择。例如，如果团队正在远离理想状态，他们可以问问自己是什么导致他们偏离目标，以及他们可以做些什么。它比简单地在计算出数字之前尽可能多地采取行动要早得多。如果一个团队发现自己趋向于理想状态，他们可以问问自己是什么在帮助他们朝着目标前进，还有什么可以做来加快这个速度。测量团队鼓励人们进行更多的实验，调整一件事并观察它对趋势的影响，任意的绝对数字也会造成无助感，尤其是当实现目标的进展缓慢并且对其他部门或团队控制之外的公司政策的依赖阻碍了更多进展时。趋势有助于将人们的努力集中在朝着正确的方向前进，而不是在看似无法解决的差距之间陷入瘫痪。更恰当地使用指标需要管理层更多地参与报告和记录趋势的变动，因为围绕团队建立生态系统是管理层的责任。这个生态系统包括组织的政策、工作安排或计划的方式以及团队和人员的组织方式。这种生态系统通常对个人付出的努力对趋势的影响要大得多。管理层应该对趋势感兴趣，以观察变化对这个生态系统的影响。适当使用指标会发现趋势比绝对数字更有用。如果没有正确的趋势，任意给出的目标就没有多大意义，当考虑影响趋势的因素以及可以采取哪些措施来影响趋势时，更好的问题会浮现，而不是随意的指出数字与现实之间的差距。Thoughtworks 经常被要求拯救每次更改需要太长时间的软件项目。被认为很小的改变通常需要一个月以上的时间才能真正完成。这些类型的项目具有一个非常共同的特征——代码质量被视为事后考虑项，并且已经产生了大量的技术债务。典型救援项目的代码库充满了大量代码异味。在许多领域（如许多并行继承层次结构）中都弥漫着单一的代码味道的出现频率很高；其他情况，代码味道很大，例如一个过大的方法；最坏的情况，代码异味的出现频率和程度都很大。解决这些问题中的任何一个一开始似乎都是不可能的，因为解决一个问题的努力是压倒性的。始终如一地解决单一代码异味很困难，因为它需要立即停止交付增量业务价值。扭转低质量的趋势是唯一的出路，通过棘轮机制使其成为可能，我的同事 Chris Stevenson 在他的博客文章“使用棘轮机制修复损坏的 Windows ”中提到了这个词。棘轮机制涉及将代码分析工具添加到持续集成的构建中，当某个指标超过某个值时，CI就会失败。团队通常都以这种方式作为开始，将其添加到持续集成构建中，以免进一步朝着错误的方向发展。在交付其他功能和业务价值的同时，逐步解决所选代码异味的问题，一次一小步。在每次小的改进上，团队都会向下修改指标的当前值。似乎是一个无法解决的问题，一次被拆成一小块。棘轮到位以防止向后移动，每一个小的改进都会将趋势推向正确的方向。许多组织使用指标来设定很长一段时间的目标，通常是 3-6 个月，甚至长达一年或更长时间。管理人员制定了这个目标，负责工作的人有责任尽他们所能来实现这个目标。管理层在期末重新审视这一目标，以评估从事工作的人员。在这个系统中，管理层和员工之间的关系，说得好听点，可以描述为对抗性的。员工尽其所能实现目标，而这隐含的想法是管理层没有任何的责任。长时间之后重新审视指标的结果是，未能达到管理层的目标变得越来越不可接受。我听过经理这样说，“你有整整一年的时间来实现你的目标，但你错过了它。” 跟踪期越长，失败的风险和成本就会增加。敏捷方法更喜欢较短的审查时间，因为任何性能差距的成本都较低。一周内没有取得足够的进步远不如一整年没有取得足够的进步重要。每周回顾进展比一年后回顾进展产生更多的选择，仅仅是因为有更多的机会做出反应和改变。在短短的一段时间（例如一周）之后，你还会获得更多关于实际发生的事情而不是计划内容的数据，这应该用于通过使用它来推动变革来影响结果。组织可以从使用较短的跟踪周期中受益，因为它为重新规划创造了更多机会，从而实现了最大价值。我与一个团队合作，该团队每两周将软件发布到生产环境中。该企业喜欢定期发布，因为这样他们几乎可以立即使用该软件。在使用最新版本之后部署的软件时，该企业发现他们拥有足够的功能，几乎可以完成新营销计划所需的一切，而这只是他们最初需求的一小部分。与开发团队编写可能永远不会使用的功能不同，业务选择了剩余故事的一小部分并开始着手下一个计划。适当使用指标可以在较小的周期内跟踪进度，因为它提供了更多关于项目将来可能会在哪里结束的信息。跟踪较小的周期有助于识别趋势，暂停使组织能够更明智地识别影响环境和趋势的速率/方向。跟踪更短的周期还可以实现更多的协作，因为它为管理层提供了更多参与的机会。不是简单地在较大周期结束时评估人们，而是跟踪较小周期提供有关影响趋势的实际情况的更多数据。如果组织能够轻松实现目标，他们就永远不需要指标。组织可以改变方向，可以立即达到目标。不幸的是，这在现实中不会发生，这就是措施存在的原因，实现目标通常需要更长的时间。正确使用指标的第一条准则将实际目标与为监控实现该目标的进度而选择的措施分开。真正的目标必须始终明确。准则#2 和#3，监控趋势并在更短的时间内，这样做是为了帮助组织更快地实现他们的目标。它不是通过本章前面描述的单循环学习来实现的。组织需要的是 Argyris 所说的双循环学习。适当使用指标会促使人们质疑目标，并根据收集的真实数据实施变革以实现目标。因每周修复错误而沮丧的开发人员Dan考虑为什么他要不断修复错误。在过去的三周里，马尔科姆报告了许多关于事情没有按他预期工作的问题。他退后一步思考到底发生了什么，不再关心他总是被问到的错误数量，而是更多地关心他为什么要开始处理这些错误。当丹拿起一个故事时，他经常向马尔科姆提出很多关于它应该如何运作的问题。丹知道马尔科姆还有其它营销活动让他忙碌，也明白马尔科姆不能坐在他旁边回答他的问题。丹在交付某些东西方面承受着巨大的压力，因此他做出了几个假设以确保他可以交付一些东西而不是什么都没有。看着错误，Dan 意识到报告的许多错误都是基于他不断做出的那些小假设。交付某些东西的压力意味着 Dan 从来没有第一次就做出正确的东西。当丹向马尔科姆解释这一点时，他们同意在每个新故事的开头坐下来，以确保丹的所有问题在他开始编码之前都得到解答。他们在第二周尝试这个，并且报告的错误总数减少了。
双循环学习需要更多关于实际情况的数据。较短的周期会产生更多的数据点，从而更容易看到任何趋势。这些趋势提供了对系统当前性能的洞察力，应该用于引发对系统中更深层次潜在力量的思考和问题解决，而不仅仅是跟踪性能测量。实施真正的变革有助于加速组织实现其当前目标。改变人们工作的系统通常比关注个人更努力或更快工作的影响要大得多。在我们的故事中，丹本可以每周花更多时间来尝试修复错误，但是通过调整信息流以及马尔科姆和丹之间的工作关系，他们使系统变得更加有效。项目的事后分析会在项目完成后进行回顾，从中汲取经验教训，希望将其应用于未来的项目或在整个组织中传播。在项目结束时进行事后分析没有机会将这些学习实际应用于项目本身。敏捷回顾的意图有所不同，他们在项目进行中寻求改变，在这种情况下，行动比最终产生的影响更大。这些会议为团队寻找变革机会创造了机会，尽管仍然依赖人员和组织来承诺这些变革。当组织达到其目标时，就该返回用于实现目标的指标了。请记住，如果组织可以立即实现他们的目标，则永远不需要度量指标。定义、跟踪、监控和解释指标需要时间和资源，而这些时间和资源本可以更好地用于实现新的目标。适当的使用指标，组织需要随时放弃不再相关的指标，而不是保留他们习惯收集的所有指标。你可以通过询问人们“为什么我们需要收集这个数字？”来寻找可能过时的指标的一些症状。一个糟糕的回应可能包括：“我们一直都是这样做的”，或者更糟的是，“这是我们的政策。” 这个问题不一定能区分解释不清的目标或过时的指标，因此可能需要多挖掘一些。管理层有责任确保组织的时间不会浪费在收集和维护不必要的指标上。指标在组织和团队中具有目的和地位，它们不能用作思考的替代品。组织也不能认为按数字管理就足以有效地交付软件。组织必须警惕因指标使用不当而出现的不良行为。双循环学习帮助我们理解，在组织学会更合适地使用指标之前，不可能存在关注个人行为的不同。
通过适当使用指标，组织可以将每个指标与每个人都理解的明确目标联系起来。选择用于监控进度的措施必须与目标脱钩，并随着时间的推移挑战每个指标的相关性。使用指标的组织更恰当地理解观察趋势的价值，在更短的时间内进行监控以了解个人、管理和组织的影响。更好的使用还意味着经常检查和调整这些影响，以确保在不断评估适合度的最终目标的背景下趋势加速、减速和逆转。- Esther Derby 的 Gaming Incentives - 反思人们如何操纵情况以最大化他们的激励计划。
- Vanity Metrics vs. Actionable Metrics 作者 Eric Ries - 精益创业布道者，Eric Ries 描述了如何使指标更具可操作性以及为了衡量而衡量的危险。
- 速度是杀死敏捷性的 吉姆海史密斯 - 一篇高度相关的文章，描述了公司如何将速度误用为指标。
- 1：Chris Arygris 和 Donald A. Schön 在他们的著作《组织学习：行动视角理论》中描述了单循环和双循环学习的概念。
玩乐高，学敏捷，【规模化敏捷联合作战沙盘之「乌托邦计划」】，2022年3月5-6日登陆深圳，将“多团队敏捷协同”基因内化在研发流程中，为规模化提升研发效能保驾护航！!🏰⛴
企业组队和个人均可报名参加，一起挑战极客乌托邦
