围城书评

Dave Nicolette撰写的《软件开发度量》一书探讨了如何使用度量来跟踪和指导软件开发。 它说明了不同的开发方法和过程模型（例如传统的基于瀑布的迭代软件或迭代式敏捷软件开发）如何影响指标的选择和使用。 本书提供了可用于指导工作和管理改进的指标的描述。

本书各章的免费下载可在出版商的“软件开发度量”的书页上找到 。

InfoQ采访了Nicolette，内容涉及度量标准的目的，在软件开发中使用度量，测量速度以跟踪团队改进，度量团队的情绪，防止度量标准被错误使用，以及为敏捷团队和利益相关者推荐的度量标准，这些度量可用于交付值。

InfoQ：是什么让您决定写一本关于软件开发指标的书？

Dave Nicolette ：tl; dr答案：

（1）我认为指标对于尽早发现交付风险绝对必要； （2）我发现度量很无聊。 （3）我观察到，大多数与软件交付有关的人都不知道如何衡量或如何处理他们收集的数据。

对于（1）和（2），我想找到一种简单实用的测量方法，该方法可以尽早进行检测，而不会占用我太多的宝贵时间。 根据（3），我想帮助人们发现在他们自己的工作环境中易于理解和有用的指标。

长答案：

我不能说我何时才意识到这一点，但是在我职业生涯的早期，我注意到在项目之后的项目中，人们在流程的后期对交付问题视而不见，这时可能无法恢复。 他们尝试了各种估计，预测，计划和跟踪工作的方法，但游戏后期仍然出现了令人不愉快的惊喜。

在后来的几年中，当我担任软件交付组织的顾问或教练时，我发现几乎没有人似乎了解如何测量以尽早发现新出现的交付风险以应对它们。 他们仔细地收集了数据，但在交付过程的后期却又一次又一次地盲目了。 今天几乎在我访问的每个组织中都是如此。

我观察到了两种一般的行为模式，这些模式似乎使这个问题更加严重。

首先，许多项目经理爱上一种或多种软件工具。 他们喜欢使用该工具的查询，制图和图形化数据功能，而忽视了所跟踪数据的含义和价值。 它们产生的输出是如此密集地打包了数据，结果是所有的噪声而没有信号。 然后，他们会在过程后期对交付风险视而不见。 我在使用企业风格的项目管理工具的公司中经常看到这种情况，这些工具提供了许多用于配置，查询和制图的选项。

第二，认为度量标准本质上有趣而不是必要的弊端的人们倾向于从数学和统计的角度来研究该主题。 他们喜欢玩数学，并且往往使问题变得比不必要的复杂……尽管他们自己并不认为自己的方法复杂。 并非数学家或统计学家的地道的普通民众发现这种方法令人困惑，他们无法很好地使用它们。 因此，他们对流程后期的交付风险视而不见。

2009年，我在“敏捷​​”会议上发表了有关指标的演讲。 房间又小又热，大约30分钟后，我全新笔记本电脑中的电池就没电了。 我继续使用活动挂图进行讨论。 房间里人满为患，人们站在门口，就在大厅外面。 尽管存在这些问题，当我们的时间到了时，人们不会离开。 他们想要更多。 他们询问了具体情况，等等。 我们必须被赶出房间，为下一次谈话腾出空间。

对于PMI和APLN等用户组，我也有类似的经验。 人们似乎普遍渴望有用，简单，实用的指标。 坦白说，我对我一直认为很枯燥的主题感兴趣的程度令我惊讶。

因此，有一天我认为以书本形式整理其中的某些信息可能会很有用。 既然这本书已经出版了，我们将发现它实际上是多么有用。 这是一本苗条的书，因为编辑们出于对读者的一种服务，将我大部分的自然贪婪消除了。 剩下的只是简单的信息，旨在实用。

InfoQ：您认为指标应达到哪些目的？

Nicolette ：在软件交付方面，我认为有两个衡量标准。

首先，我们需要知道工作是否按照我们的期望或计划进行。 我们越早发现差异，就越有机会适应差异而不会浪费太多时间或金钱。 我称此为“指导”工作。 确切的指导方式取决于组织文化，管理风格，项目驱动因素，手头工作的性质以及其他因素。 但是无论您进行何种操作，都需要客观的数据来知道该采用哪种方式进行操纵。

其次，我们需要知道我们改进交付的尝试是有益还是有害。 在软件领域，人们普遍同意，最好或多或少地不断检查我们的交付过程，并寻找改进的机会。 如果我可以宽泛地使用术语霍桑效应，那就是当人们积极地改变他们的过程时，感觉好像情况正在改善。 实际上，除非我们将实际绩效与改进目标进行比较，否则我们不知道我们的更改是否是改进。

InfoQ：在本书中，您将探讨度量标准在不同开发方法，流程模型和交付模式中的用法。 您能解释为什么这些因素对指标很重要吗？

Nicolette ：这可以回溯到我偏爱务实和简单的指标，这些指标可以满足一个或两个目的-指导和跟踪改进。 许多人尝试应用，认为自己正在应用或者只是错误地应用了一个或另一个软件交付框架。 他们使用针对该框架推荐的指标，但是这些指标可能基于与特定组织无关的假设。 使这个问题更加复杂的是，当人们使用不熟悉的方法时，他们往往不会以完美的技能来应用这些方法。 他们的处事方式可能会使建议的指标变得毫无意义。

因此，重要的是人们剥去闪亮的流行语外层，并查看工作在组织中的实际流动方式。 然后，他们可以衡量实际发生的事情，而不是他们所相信或希望发生的事情。 否则，他们可能希望在此过程的后期对交付风险视而不见。

我提出的用于评估工作流程方式的模型旨在确定在给定组织环境中有意义的因素，以便人们可以衡量现实。 例如，有许多组织称自己为“敏捷”，但实际上是以传统方式进行软件交付工作的。 跟踪诸如“速度”或“运行经过测试的功能”之类的措施对他们没有多大好处，因为会产生有意义数字的活动根本没有发生。

同样，如果产品以“连续beta”形式提供，或者组织使用精益启动方法满足客户需求，则没有预定义的“结束日期”。 这根本不是一个项目。 在这种情况下，“到目前为止已完成的范围百分比”等指标绝对没有意义。

InfoQ：您能否详细说明如何使用“正在运行的功能”等指标来跟踪和管理实现交付目标的进度？

尼科莱特 ：当然。 与大多数指标一样，RTF基于有关组织中工作流程的某些假设。 它假设（1）一种自适应方法，（2）至少在测试环境中逐步交付生产就绪的功能，（3）定期执行代码的自动检查。

通过自适应开发，可能没有预定义的固定范围。 我们会努力争取客户定义的业务功能，直到有足够的功能来支持这些功能为止。 客户决定解决方案何时足够好，他们不希望再花更多的钱来进一步完善。 通过增量交付，我们可以随时使用已完成的功能“上线”。 通过自动检查，我们可以立即知道何时损坏了以前一直在工作的东西。 它使我们有信心随时“上线”。

RTF对于跟踪此类环境中的进度很有用。 它通过显示向客户定义的业务能力的进展来支持自适应开发，而无需预定义100％的计划范围。 它通过显示在任何给定时间有多少功能就绪的生产来支持增量交付。 没有自动检查就没有意义，因为在这种情况下，有关已完成功能的生产准备情况的任何陈述只是一厢情愿的事情。

现在，考虑传统的软件交付过程。 在我们对范围的100％有了明确定义之前，开发还没有开始。 交付可以分阶段或发布，也可以是“大爆炸”风格。 在编写代码之前，无需检查任何内容。 由于这些原因，RTF对传统开发毫无意义，也没有用。

与其他指标一样，RTF在有用时会很有用，而在没用时就不会有用。 您可以对任何度量标准进行相同类型的评估-了解度量标准所基于的假设，并查看这些假设在您的组织中是否成立。 当您执行此操作时，忽略所有流行语并在眼中看到现实是很有帮助的。 现实不会眨眼，但这并不意味着您必须这么做。

InfoQ：大多数敏捷团队都通过测量速度来知道他们可以交付多少。 速度也可以用来衡量团队是否在进步。 你能解释一下吗？

Nicolette ：嗯，速度是另一个取决于某些假设的指标。 它取决于（1）有时间限制的过程模型，以及（2）至少在测试环境中逐步交付生产就绪功能。 在这些假设成立的情况下，Velocity可用于短期计划，也可用于积累燃烧图的经验数据，从而可以暴露新出现的交付风险。 因此，对于以某种方式完成工作的情况，这很有用。

根据我的经验，Velocity太滑了，无法用于跟踪改进。 有三个原因。

首先，团队的改进工作可能包括更改带时间限制的迭代的长度或完全放弃带时间限制的模型。 这些变化中的任何一个都使得将新的Velocity观测值与历史观测值进行比较变得毫无意义。

其次，随着团队习惯于问题领域，解决方案的技术并一起工作，与在项目开始时相比，可以在更少的时间内交付给定规模的用户案例。 在这种情况下，团队倾向于调整他们对相对规模的不言而喻的共识。 在迭代5中，团队可能会考虑一定数量的工作来代表故事大小3。在迭代15中，团队3的工作量要大于迭代5中的工作。这是自然发生的，不一定是由决策者有意识地做出的决定。球队。 看起来，团队在迭代15中提供的故事点数与迭代5中传递的故事点数相同，而实际上他们的交付性能有所提高。

第三，许多组织尝试应用“敏捷”方法，但他们并不完全“了解”。 管理层通常会设定对Velocity的期望。 有时，管理层甚至要求团队“努力”达到“速度”目标。 速度被设计为对实际输送性能的经验观察。 设置Velocity目标时，我们将完全打破指标。 它变得完全没有意义。 在这种环境下，它对于跟踪改进毫无用处。 不幸的是，这种情况非常普遍。

因此，要使用Velocity跟踪改进情况，某些事情在整个测量期间必须保持正确：（1）迭代长度必须保持不变； （2）相对尺寸必须保持一致； （3）管理人员不得设定速度目标。 所有这些事情在任何时间段内都保持为真的情况很少见。 因此，我不建议使用Velocity进行跟踪改进。 我发现“周期时间”是一种实用的替代方法，它可以提供几乎相同的信息，而不会对过程模型，规模和估算方法或目标设定敏感。

InfoQ：有些方法可以衡量团队的情绪，例如您在书中描述的情绪地震图或幸福指数。 您是否有使用共享这些指标的团队的示例？

Nicolette ：我不确定如何举单个团队为例，但是我可以分享一些普遍的看法。

我已经看到Niko-Niko行事历对新组建的协作团队有用。 在他们进入“风暴”和“规范”阶段（根据Tuckman）的过程中，我观察到，表明每个团队成员的总体情绪有助于人们保持行为的正确性。 例如，如果我不认识乔，并且乔在工作中对我无礼，那么我可能会假设乔是一个无礼的人。 我对Joe的期望将因未来的经历而变色。 但是，如果乔在那天早晨在日历上贴出一张皱着眉头的脸，我会知道他的无礼只是对他生活中与工作无关的事情的React； 没什么大不了的，明天是新的一天。

为什么这么重要？ 因为人们在相处融洽，士气普遍良好时工作表现会更好。 了解每个团队成员的情绪状态可以缓解我们过度React或根据上下文中的小行为做出假设时可能发生的紧张感，尤其是当我们不太了解对方时。 如果出现“乔到底怎么了？”这个问题，我将无法发挥最大的作用。 整日浮在脑海中。 当团队进入表演阶段时，通常会免除Niko-Niko日历。

Niko-Niko日历也可以暴露组织问题。 书中提到的欧米茄狼图案就是一个很好的例子。 当一个团队成员看上去总是消极情绪时，不管另一个团队成员的情绪如何，通常并不意味着该人是一个沮丧的人。 通常，这是系统性组织问题的征兆。 如果我们解雇一个丑陋的人，其他人很快就会担当同样的角色，因为这不是私人的事情。 关于工作环境的某些事情正在引起对此行为的需求。 这是一种安全阀，可以使团队的其他成员正常工作。 真正的纠正措施是更改造成Omega Wolf需求的组织参数。 情绪措施有时会在机械措施无法解决时揭示这种问题。

如果团队成员每天在同一时间更新自己的情绪，则情感地震图可以达到与Niko-Niko相同的目的。 在这种情况下，它与以不同形式显示的Niko-Niko信息相同。 但是到目前为止，在所有情况下，团队都使用情感地震仪作为回顾工具。 他们回想起来时充满了自己的心情。 我的观察结果是，结果往往会受到迭代结果和先行团队成员发布的结果的强烈影响。 如果事情进展顺利，那么人们会记住自己的情绪是积极的。 我倾向于不使用此措施，因为它可能不可靠或会引起误解。

我从客户公司的ScrumMaster那里学习到的健康和幸福指数可以产生有趣的效果。 它用作回顾工具。 有时，团队成员对迭代感到难过是因为它很困难，而不是因为结果很差。 相反也可能发生。 健康和幸福指数将观察到的分娩表现（健康）与感知的表现（幸福）进行比较。 它可以弥合感知与现实之间的鸿沟。

我已经看到了团队回顾性的情绪低落，经过健康与幸福运动后，他们意识到他们毕竟已经完成了一些非常出色的事情。 他们对迭代感到不快，因为他们一直都在研究困难问题的杂草上。

我还看到团队进入了回顾性的感觉，就像他们是宇宙的主人一样，只是发现他们交付的工作由于一个或另一个原因是不完整的-由于从不依赖第三者，他们从未集成过代码派对; 他们的用户故事实际上只是伪装成用户故事的任务，没有任何有价值的东西流向客户。 度量标准可以帮助团队学习专注于重要的事情，并认识到他们在做出与一天中的困难而非工作成果相关的假设时。

InfoQ：您能详细说明如何误用指标吗？ 有什么可以防止的事情吗？

Nicolette ：很难知道从哪里开始。 我认为，至少有1/3的书讨论了指标使用中的反模式。 这本书的灵感是观察到人们倾向于测量错误的事物，或者以错误的方式度量正确的事物。 度量标准的错误使用是规则，不是例外。

将指标视为工具。 为了从工具中获取价值，您需要做两件事：首先，为任务选择合适的工具。 其次，正确使用工具。 如果我需要打螺丝，锤子将是错误的工具。 如果我选择螺丝刀，但是用手柄敲击螺丝头，则说明我拥有正确的工具，但使用不正确。

相同的经验法则适用于指标。 例如，考虑速度。 很多时候，团队告诉我他们正在跟踪Velocity，因为管理层告诉他们“使用敏捷”，而“敏捷”则表示“跟踪Velocity”。 （FWIW，我尚未在宣言中找到。）但是，它们并没有在每次迭代中提供可能可交付的解决方案增量。 他们甚至没有开发端到端功能。 他们实际上没有速度。 他们正在计数并绘制图表，但这不是速度。 砰砰砰。 他们无法使用该指标来预测任何事情，除非我们可以预测，他们将在流程后期对交付风险视而不见。

我也看到了Velocity以相反的方式被滥用。 团队将传统项目中的工作分块并假装运行“迭代”，他们经常使用Velocity作为“迄今为止完成范围的百分比”的代理。 这根本不是Velocity，它只是跟踪任务完成情况。 管理层期望在每次迭代中都要完成一定数量的工作，以便保持进度。 团队只是简单地计算数字以避免麻烦。 这导致了可预见的结果：他们在过程后期对交付风险视而不见。

可能有数十个（如果不是数百个）类似的示例，涉及您想要命名的任何度量。 普遍的原因是人们试图衡量未真正发生的事情，因为他们认为这些事情应该发生。

InfoQ：对于敏捷团队可以用来传递价值的建议，您是否有具体的建议？

尼科莱特 ：简短的回答是“不”。 我对“敏捷团队”一词并不感到疯狂。 我认为“敏捷”是一门思想流派，它为自适应软件开发提供了许多很棒的想法。 但是，可以在不提及“敏捷”的情况下进行适应性开发，并且可以通过其他思想流派（例如精益思维和系统思维）来指导有效的“敏捷”发展。 “敏捷”方法可以并且经常应用于传统项目。 许多标记为“敏捷”的团队也离这很远。 从某种意义上来说，它是一个神奇的词。 我喜欢哈利·波特，但是，你知道。

实际上，我在书中试图指出的一点是，人们应该抛开流行语，并研究工作在组织中的实际流动方式。 这是选择适当指标的基础，而不是当前恰巧起作用的魔术字。 明年将出现一组新的魔术词，但软件仍将是软件。

InfoQ：对于敏捷团队的经理和其他利益相关者来说，这是一个类似的问题，他们可以使用相同的度量标准还是不同的度量标准？

Nicolette ：出于指导目的，软件交付团队的所有直接利益相关者的利益都是相同的。 因此，我的回答是“是”，他们可以查看相同的数字并查看相同的信息，并在具有共同理解的情况下讨论纠正措施。 正如问题所指出的，这不仅限于“敏捷团队”。 它适用于所有软件交付团队。

当涉及与改进相关的指标时，我倾向于不建议与团队外部的任何人共享这些数字。 在大多数组织中，管理层极有可能使用此类度量来给团队造成痛苦（即使是出于最好的意图）。 团队最好使用跟踪改进的指标来告知他们自己的改进工作。 一旦他们实现了以某种度量进行跟踪的性能改进目标，就无需继续跟踪该度量。

在出版商的网站上购买图书时，使用代码“ sdmiq40”可获得40％的折扣。

翻译自: https://www.infoq.com/articles/software-development-metrics/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

围城书评