敏捷软件估算人人适用

我们为什么要进行估算？

我们估计

估算尺度

如何估算

理解速度

估算路线图和预测

估算和日期

#不估算

常见问题解答

不同情况下需要不同的工具。

关于“估算的不可能性”：

把关和对估算数字的了解

测量周期时间

这难道不是估算吗？

想法

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

无一例外，在我开展的每一个咨询项目中，都有一个共同的主题——未能阐明和界定“软件开发工作”的范围，导致组织内部出现广泛而多样的功能障碍。

这是普遍现象，每个人都会遇到，没什么好羞耻的。

弄清楚要做什么、难度如何，以及如何有效地沟通，是完成工作的关键所在。整个职业（项目管理、交付管理）和方法论都围绕着如何做到这一点而存在。

令人惊讶的是，在科技领域，糟糕的估算和失败的项目竟然如此普遍——尤其是在人们如此热衷于敏捷开发、数据驱动开发和衡量指标的情况下。

在本文中，我们将讨论我们为什么要进行估算、估算什么以及你应该如何进行估算，希望能减轻估算过程中可能出现的种种压力和辛苦。

我们为什么要进行估算？

就像你不会在不了解软件项目复杂性的情况下就雇佣水管工来修理浴室一样。估算是人们必须付费才能完成工作时必不可少的环节，而且估算对不同的人来说意义也不尽相同。

对于团队而言，估算是一种工具，它帮助我们了解在不至于精疲力竭的情况下能够完成多少工作。对于高管而言，估算是一种工具，它帮助他们了解自己能够做出哪些合理的承诺。

无论哪种情况，估算的目的都是为了降低或减轻风险，确保我们不做出无法兑现的承诺。更广泛地说，估算就是让我们了解自己能做什么和不能做什么。

估算并非孤立存在——估算结果仅对做出估算的特定人群有效。如果团队构成或其技能发生变化，团队能够完成的工作量和工作类型也会随之改变。

估算的原理是假设在固定的时间段内，同样的人员应该能够完成与之前相同数量、大致相似或已知类型的工作。它基于稳定的团队、知识和经验的综合考量。

估算结果归团队所有；它们是团队的衡量标准。

我们估计

从 2000 年代中期开始，用户故事已成为阐述软件中需要完成的工作的标准方式，它们旨在成为跟踪软件中独立且可部署的变更的工件。

它们应该从用户的角度出发，遵循以下大致标准的格式进行阐述：

作为<用户类型>，

我想要<某种结果>，

因此<这件事很重要的原因>。

在传统的敏捷工作流程中，用户故事通常写在索引卡片上，相关的验收标准则写在卡片背面。当所有验收标准都得到满足时，用户故事就完成了。

随着时间的推移，任务故事的概念越来越受欢迎，任务通常用便利贴贴在故事卡片上。这是一种有效的物理限制，因为故事篇幅有限，便利贴再大就会从卡片上掉下来。

为了进行估算，我们分别评估每项独立工作的复杂度。我们的估算旨在衡量整个团队将整个故事投入生产所需的工作量。

不同团队对于“完成”的含义有不同的看法并不罕见——但随着时间的推移，几乎所有人都同意“投入生产”才是衡量一个故事是否完成的标准。

有些组织可能认为，在实现这一目标之前，他们需要在发布流程自动化方面完成更多工作，但我始终认为，诚实的估计能够反映出与软件发布相关的现有复杂性（如果有的话）。

最终，为了使估算能够准确反映团队的能力，团队执行的任何工作都应该被记录为用户故事并进行估算。

所有产品在投入生产前都必须经过估算。

估算尺度

敏捷项目中的估算采用抽象的度量方法，表示给定团队完成一个用户故事所需的工作量。

过去二十年来，人们提出了各种不同的工作评估标准。

这些都是：

• 时间（通常以半天为单位）
• T恤尺码（XS、S、M、L、XL、XXL）
• XP 的“倍增数字”（1、2、4、8、16、32……）
• 斐波那契数列（1, 2, 3, 5, 8, 13, 21…）
• 修正斐波那契数列（1, 2, 3, 5, 8, 13, 20, 40 和 100）
• 还有一些不值一提。

不同的方法各有优缺点。

时间通常不是一个好的估算标准，因为它既具体又固定。用时间做估算没有回旋余地，也没有协商的余地。如果第一次估算出错，用时间做估算最容易让利益相关者失望。

以T 恤尺码进行估算通常对长期预测和路线图规划很有用，其目的只是为了了解一项工作的相对规模。

XP（极限编程）最初建议将数字翻倍作为其抽象估算尺度，以反映工作规模越大就越复杂，而且工作很容易变得过大的事实。

后来，有人提出用斐波那契数列来更准确地表达同样的概念，但它是一条指数增长的曲线，用来描述复杂性的不断增加。出于实际考虑（没人想无休止地争论应该选择哪个巨大的数字），这个数列后来被修改，最终以 20、40 和 100 为上限。

大多数进行估算的团队最终都会使用修正斐波那契数列，因为它既能体现未知数不断增加的复杂性，又易于记忆，而且明确表示它不是时间的度量。

如何估算

在计划会议中，所有参与该项目的团队成员会聚集在一起，共同阅读为他们编写的用户故事。这些用户故事通常由产品经理或产品负责人进行优先级排序，但估算并不一定需要优先级排序。

团队会就每个故事进行2-3分钟的简短讨论，彼此分享背景信息。在讨论过程中，大家可以记录完成这项工作所需的任务类型，分享自己对故事的特殊了解，或提供任何补充背景信息。

一般来说，列出所涉及的活动类型是一个好主意——“一些前端工作，可能是一个新的 API，一些配置，一些新的部署脚本，一些 UI 设计”，以此来突出隐藏的复杂性。

这是因为故事涉及的环节越多，它就会变得越复杂。

在这次简短讨论结束时，至关重要的是，团队成员应该同时使用计划扑克牌或者像玩石头剪刀布游戏一样举起所需数量的手指，来估计故事的复杂程度。

该团队同时进行估算，以防止锚定效应造成的认知偏差，即谁先给出数字，就会“定下基调”，无论是有意识的还是无意识的。

然后，将估算结果记录在故事卡上，大家继续进行下一步。

整个团队对每张卡片进行估算至关重要，而且这些估算应涵盖整个团队所需的全部工作量。

估算中一个常见的错误是，人们只估算自己负责的特定职能的工作量（前端和后端估算、开发和测试估算、设计和开发估算，这些都是同样糟糕的反模式）。这样做的问题在于，它阻碍了所有团队成员对项目复杂性的共同理解，有时甚至会导致人们陷入另一种反模式：各自为自己的团队职能进行估算。

团队作为一个整体进行估算，以提高团队的凝聚力，分享对工作复杂性的理解，最重要的是，用整个团队的思维模式取代单个贡献者的思维模式。

估算过程中经常会出现一些值得指出的冲突点。

球队对最终确定的比分可以有分歧。

这种情况会经常发生——假设你使用修正斐波那契数列进行估算，团队中一半人认为这个故事值 5 分，而另一半人则认为它值 8 分。你可以通过始终采用较高的估算值来解决这种冲突。

负责团队提高效率的产品负责人常常会对这种做法有所抵触，但事实很简单——少承诺多交付总是比反其道而行之，让人失望要容易得多。

如果团队高估了某些工作量，他们仍然有足够的资源来安排后续工作。但如果较高的估计值是正确的，而最终选择了较低的数字，则会危及团队之外可能承诺的工作。

团队在计划扑克中表达的故事点范围太广。

另一种常见情况是团队成员对评分标准给出了截然不同的答案。例如，某个团队成员可能认为某项工作只值 1 分，而其他所有成员的平均评分却是 5 分。

你们可以通过简短的讨论来解决这个冲突——或许那位团队成员知道一些之前讨论中没有提到的事情。在这个阶段，可以通过协商来讨论和修改估算结果。

团队认为这个故事的价值无法估量，或者说它太大了。

如果团队认为故事不够详细，无法估算为可执行的工作量，他们可能会以故事太大而无法估算为由提出异议。

当这种情况发生时，团队应该要么在计划阶段集体将用户故事分解成可以估算的较小用户故事，要么将用户故事推迟到另一次会议中进行估算。

如果用户故事经常难以评估、不够清晰或缺乏足够的细节，建议每隔一天安排一次45分钟的细化会议。在会议中，团队可以共同完善和编写用户故事，直到待办事项清单变得更加易于理解和处理。团队应根据自身对待办事项清单中现有工作的接受程度，决定需要进行多少次这样的会议。

对于那些因难以着手而屡遭拒绝的棘手故事，撰写一篇“挑战稿”（spike）或许是个明智之举。挑战稿是指在限定时间内完成的故事，其成果是收集更多信息和研究资料，并用于完善和修改那些被认为过于复杂或难以着手的故事。

如果你发现自己在编写原型，请务必在原型中明确阐述并编写验收标准，说明这项工作的确切预期结果。

计划和估算工作通常始于繁琐的细节和复杂的情况，但通过频繁的改进会议和轻松的估算讨论，随着团队凝聚力的增强，它应该会变得更加可预测和简单。

对于新组建的团队来说，估算和计划往往需要几次迭代才能趋于稳定，因为团队成员会慢慢地更深入地了解团队中发生的各种工作。

理解速度

速度是指迭代过程中完成的故事点数的滚动平均值。

团队速度是一个平均值，代表团队在当前配置下的工作效率。如果团队构成发生变化（例如人数、技能分布、假期安排等），团队速度也会相应变化。

在计划制定过程中，我们会使用速度指标来了解团队在平均迭代周期内实际能够完成多少工作。需要注意的是，速度指标并非需要超越的目标，而是一个抽象的数字，代表团队可持续的工作节奏。

速度是针对团队的，是一个不可比较的指标。

即使是同一组织内的两支团队，即使报告的速度数据相同，其背后的含义也必然不同。虽然人们常常会试图根据速度指标来建立团队基准或进行比较，但这并非同类比较，由此得出的任何统计数据都将是不准确的。

Velocity 旨在用于以下场景：

• 了解团队在每次迭代中能够完成多少工作。
• 通过刻意降低速度来规划假期和应对疾病。
• 了解团队的可预测性——不稳定的速度是故事创作规范不良或环境不可预测的关键指标。

团队的目标是保持稳定的开发速度，因为稳定的开发速度意味着团队可以承诺何时交付用户故事。

估算路线图和预测

在制定公司路线图、季度审查或其他长期愿景活动等长期规划工作中，通常需要进行估算。

了解估算就像霰弹枪一样很有帮助——近距离非常精准，但随着计划或日程安排的距离增加，精准度就会降低。因此，详细的估算在远距离就毫无用处了。

这常常导致希望与投资者、公众或其他部门沟通的商业领袖与乐于接受高层规划活动不确定性的技术人员之间产生紧张关系。

路线图和其他高层次的估算流程是企业表达其意图和愿望的完全有效的方法，但它们不是，也不可能是时间表。

我们可以使用高层次估算来辅助这些流程，但需要注意以下几点。首先，高层次估算必须使用不同的估算尺度。这一点至关重要，可以确保不会出现混淆和混淆的情况。

其次* ， *高层估算过程应该而且将会缺乏实施细节，因此最终得到的项目往往被粗略地归类为容易、中等、大或特大。

这种对复杂度的大致概念对于企业来说至关重要，它能帮助企业了解工作量级，而不是精确估算交付日期。一旦确定了大致规模，就需要进一步工作，以制定更实用、更以团队为中心的估算。

除了详细的路线图预测之外，还有一种替代方法（我保证我不是在开玩笑），那就是计数。

通常，路线图内容庞大，包含众多主题和工作内容，这时只需简单地统计一下项目数量，然后诚实地问自己一个问题：“如果你们公司所有人都在参与这个路线图的制定，你们每天能完成一项吗？”如果答案是否定的，那就重复这个问题两天、三天，直到你算出你认为的“倍增因子”是多少。

通常情况下，这个数字足以准确了解路线图可能需要多长时间，再加上对路线图项目进行一些简单的“小/中/大”估算。

估算和日期

如果估算值是日期，那它们就会被称为日期，而不是估算值。

估算的目的是帮助团队了解其可持续的进度和速度。
利用估算结果反向推算日期是一种危险（尽管有时可行）的非科学做法。

团队与其试图将故事点转换回日期，不如专注于提供稳定的开发速度和发布窗口。

一个节奏稳定的团队应该能够通过结合他们的估算、能力以及工作优先级排序的迭代的预期结束时间来预测某个功能最早应该交付的时间点。

最早可以开始施工的日期应该是那天。

#不估算

“但我从推特上看到有人说估算从来都不靠谱！所有时髦的人都在谈论#拒绝估算！”

随着时间的推移，健康稳定的团队会将用户故事精简成结构统一、易于管理的小块。当这些团队推进工作时，他们常常发现对用户故事的估算总是千篇一律，导致出现“所有故事都是 5 分！”或“所有故事都是 3 分！”的情况。

这对于可预测性来说非常棒，因为这些一致的数字真正代表的是一种共同的思维模式和一种已知的可持续节奏。

现在，由于估算有意地是抽象的，并且有意地由团队自己的内部衡量标准来衡量，如果所有事情都是 5，所有故事的大小都相同，并且它们总是 5，那么，好吧，所有事情也很容易变成 1。

当所有物体的大小都相同时，估算的目标就达到了。

因此，你可能会听到一些来自高效、长期稳定团队的人们主张不要进行估算，因为他们已经走到了这一步，并且可能已经建立了内部机制来应对团队能力的变化。

与此相反，没有共同心智模型和对平均故事规模的连贯内在概念的团队，绝对需要估算来帮助他们达到可预测性和安全的状态。

指望团队在没有提供工具（例如估算）来衡量进度的情况下，神奇地形成对故事规模和能力的共同理解是不现实的。

当你的团队达到一种舒适的和谐状态时，你就知道什么时候可以减少估算了。

常见问题解答

感觉过去十五年里，我一直在以各种形式谈论估算和计划，人们也对这个话题有很多疑问。以下是一些最常见的问题。

我们是否应该对任务和子任务进行估算？

你要估算团队必须完成的所有工作，才能开展一些工作。

数字工具缺乏物理约束（你不可能把大量的子任务贴在索引卡上！），这无疑助长了一种反模式，即子任务的爆炸式增长。

通常情况下，人们会将子任务作为规范，而不是努力将过于庞大而难以理解的故事拆分和细化。

我始终认为所有任务都应该以笔记的形式记录在故事卡片上，而不是可以随意移动、重新分配或自行阻塞的元素。它们要么是故事不可或缺的一部分，要么就不是。

总之，如果是工作，你必须指出来。

我们如何估算技术任务？

这个问题经常被问到——答案有两种。

任何一个：

• 技术任务是面向用户的故事工作的一部分，而它的“估算”只是这项工作的一部分。
• 你要明确描述一个技术用户角色，该用户对系统有需求，“技术任务”就是一个满足该用户需求的用户故事。

无论哪种情况，你都要像评估其他故事一样评估故事，根据整个团队在生产环境中完成该变更的复杂性来评估故事。

我们应该对漏洞进行评估吗？

只有当漏洞出现在生产环境中时，它们才算是漏洞——在此之前，它们只是未完成的工作。

开发过程中发现并修复任何错误所需的工作量是估算项目需求的一部分，测试人员在构建过程中所做的观察也只是工作的一部分。

一旦 bug 进入生产环境？嗯，修复它就变成了另一个任务，应该像其他任何任务一样进行估算，这些任务也会像其他任何工作一样计入你的开发速度。

我们是否应该分别估算前端和后端任务？

不。估算应涵盖整个团队的工作量、沟通成本和交付时间。任何团队成员完成的工作都应计入团队估算中。

为什么峰值是有时间限制的，而不是有方向性的？

观察得很仔细！峰值是这个过程中的一个异常现象，因为它们具有时间限制。

这些测试项目之所以有时间限制，是因为它们不会产生部署到生产环境的工作成果，而是提供更多信息。在测试阶段，应该将执行这些测试项目的人员视为暂时退出迭代，并且相应地减少迭代中的工作量。

过度依赖尖峰测试是一种反模式——尖峰测试的目的是帮助你分解繁重的工作，而不是将分析工作向下推给团队。

如果在一个迭代周期结束时我们还没有完成某个用户故事，我们是否应该在下一个迭代周期开始时重新估算它？

其实差别不大，你可以把故事留在看板上，减少后续工作直到全部完成，或者重新评估故事的“剩余工作量”。

我不喜欢在故事开发过程中重新评估进度，而且鉴于什么都不做反而更省事，我建议什么都不做，让速度是滚动平均值这一事实来处理报告中的任何差异。

不同情况下需要不同的工具。

估算和计划可能是敏捷方法中讨论最多的两个方面。

好消息是，通过练习、完善故事以及越来越多地以团队而非个人的方式运作，你的估算和计划能力会得到提高。

当你努力达到一定的协调一致程度，以至于估算变得不那么有用时，重要的是要记住，在不同的成熟阶段，团队需要不同的东西，这完全没问题。

估算的目的是帮助你增强预测能力。如果估算方法无法帮助你实现目标，不要害怕改变它。

虽然我们无法预测未来，但我们可以通过练习来提高对未来的估计能力。