不论你开发的是哪种类型的软件或你所在公司的规模大小，你都可能需要为某人提供估算。他们也许想知道需要投入多久或者成本是多少。但无论如何，估算是项重要的技能，且对任何规模或任何重要程度的任何软件开发投入来说，估算都是成功的关键。
敏捷团队能利用许多技术来指导他们的投入估算。本文描述的工具包中包含一些方法，用以估算项目及“日常”工作。这些技术严重偏向于敏捷项目，并旨在由对敏捷估算技术已有基本认识的人来使用（即，那些已经参加过敏捷项目管理课程和 / 或参与敏捷项目足够长时间并理解其是如何运作的人们）。
工具包的第一部分说明了一些能帮助团队进行故事点估算的通用工具。其中包括：
- 一些计算项目初始时速度的提示；
- 一些支持规划扑克的工具，这些工具通过提高团队对不同故事的复杂性的认识以实现对规划扑克的支持。
然而，通常甚至在我们开始分析项目之前，就需要对项目进行估算。因此工具包的第二部分，我介绍了一个名为 WAG 生成器的方法来实现这一目的。这个方法并不生成一个详细的估算，但它提供了一个足够精确的推测来比较项目或是决定是否启动一个项目。
本文中讨论的所有技术对我来说都很有帮助，但它们在你所处环境中是否适用或有用要由你自己决定。
敏捷估算技术
敏捷方法论，如 Scrum，通常会推荐使用相对估算。通常，团队用规划扑克来为每个故事分配故事点，然后为了进行项目规划把它们与团队速度进行比较。
规划扑克已经在其他地方讨论过了（包括软件教育“敏捷需求 - 故事”课程），因而在此不会讨论它的细节。不过，我们将讨论：
- 在项目开始前估算速度；及
- 帮助团队更好的理解被估算的故事的工具。
估算团队速度的三种方法
在项目中最精确的估算速度的方法是，进行几个迭代，然后看看平均速度是多少。这种方法让团队找到自己的节奏，然后用其现实世界中的经验对未来的迭代进行预测。然而，那些对项目提供资助的人通常会要求项目团队在可以进行数个迭代之前就给出估算。
如果完全相同的团队已一起合作了一段时间（也许是在类似的项目中，使用同样的工具和技术），那么他们可能会基于之前项目的平均速度给出一个估算。
因此，如果没有一个可以实际观测到的速度可供参考，那么可以退而求其次，估算一个团队的速度。有三种通常能提供帮助的方法来估算团队速度，它们的描述见接下来的三个部分。
1) 在规划扑克完成之后使用传统的方法
规划扑克最大的优点之一是，它清除了包含在解决方案中的假定和约束。规划扑克提供的信息为团队进行估算提供了良好的输入，而不是试图把故事点转换为时间和金钱，估算者简单地用这一信息作为输入，计算项目工期（例如，团队可以使用本文后面描述的 WAG 生成器）。
这也许看起来像是重复劳动，但它或许能为团队在头几个敏捷项目中获得自信。
一旦团队得出整个项目的估算，接着他们就能决定接受这个项目，获得资助并带着启动项目时常有的自信启动这一项目。然后团队将能进行几次迭代，并在获得更多信息后调整他们的估算。一旦完成了这些，团队就能确定并分享他们实际的速度。
2）由迭代长度反向进行估算
第二个估算团队速度的方法是，确定迭代的长度和团队规模，然后决定团队在一个迭代内能完成多少故事。按如下方法进行：
- 决定迭代长度，以及期望的团队规模和组成。
- 把团队聚在一起，选出一些故事样例（并不一定是在早期迭代需要中完成的故事）。
- 一次一个地把各种大小的故事分配至第一次迭代中，让团队决定他们认为自己能在这次迭代内完成多少故事：
- 简单地把故事加入或移出迭代，直到团队感到满意，他们分配了“大约一个迭代的工作”；
- 故事可以分解成任务，再这些任务放入迭代之中。这涉及到估算每个任务所需时间，并把这些时间累加起来，直到消耗光这个迭代中全部的团队时间。
- 一旦得出在一次迭代中能完成多少故事，则每个故事的故事点之和就是估算出的速度。
- 如果你觉得这增加了估算的准确性，那就在更多的迭代中重复这一过程。
3）从一个或多个故事的耗时开始估算
第三种估算团队速度的方式是，计算出交付一个故事点要多久，然后用这一数字计算出在一次迭代内能完成多少故事点。按如下方法进行：
- 选择一个典型的故事。
- 确定完成这一故事所需完成的所有任务，并将其转换为预期的人时。
- 把团队中每个人所花时间加在一起；
- 用理想时间（工作量）而不是持续时间；
- 例如，如果一个故事要花费一名业务分析员 1 小时，一名开发人员 2 小时及一名技术文档撰写人 1 小时，那这就应转化为 4 人时。
- 用故事中的点数除以人时数，算出一个小时内能完成多少故事点。
- 用第三步中算出的数字乘以迭代中包含的小时数，得出在一次迭代内（理想情况下）能完成多少故事点。
- 用第四步中计算出的数字除以 2（或是类似的转换因子），由此把理想时间转换为持续时间。这就是一个故事的预期速度。
- 对更多的故事重复这一过程，对计算结果取平均值。对额外的故事进行估算能提高估算的精确性，但通常在计算了五个故事之后会得到对速度较好的估算——如果你选择一系列不同的故事并从实际出发把它们拆分成任务时尤其如此。
四个协助估算故事的工具
1）关键事物矩阵
“关键事物”（TTM）矩阵是个能用于揭示故事复杂性的简单工具。TTM 由交付一系列故事所需的一组技术组成。所包含的技术列在矩阵的左面，故事列在上面，如下表所示：
TTM 的目的是让团队了解每个故事分别包含何种类型的技术，以此理解故事的复杂性。这一方法的原理是，与那些只包含一或两种类型技术的故事相比，横跨多类技术的故事要更复杂也因此需要更多的估算。
进一步扩展这一想法，开发一些故事所需的努力或许不仅依赖于这些技术——也依赖于各种过程。因此，与其仅列出相关技术，不如我们也选出重要的“关键事物”，比如：
- 复杂性测试（扩展性测试、可用性测试、安全性测试等等）；
- 用户研究；或
- 法律签收。
与其简单地列出一项技术或是一个过程是否涉及其中，不如列出其影响是大是小。例如，我们可以用以下字母代替上图中格子中的“x”，这样可以为估算者提供更详细的信息：
- H = 高复杂性或大工作量；
- M = 中等复杂性或中等工作量；
- L = 低复杂性或小工作量。
由此得出一个稍微复杂些的 TTM，如下所示：
2）系统热点图
热点图显示出一个系统中哪儿会遇到麻烦，哪儿会一帆风顺。
要绘制热点图，任取一个系统模型，把模型中的每个区域用不同的颜色，以此来表明各个区域上工作的难易程度。需要考虑到的事物包括，是否有适当的自动化测试，毫无逻辑性的代码的区域，包含复杂的集成代码的区域，开发者熟知的区域，在涉及系统不同区域间工作时团队感觉复杂的任何区域（并由此评估工作量）。
绘制出热点图后（如下所示），团队能够调整他们对系统中不同区域的估算，以便他们与个别区域的“热度”保持一致。
3）低保真原型
低保真原型只是一张图或是系统的一个简单模型。这些能用于创建新故事或帮助团队进行估算。
术语“低保真”的意思是一个非工作模型，而“高保真”模型是可工作模型。然而，在我的项目中，我们用“低保真”这一术语，仅仅指的是任何没有遵循 UML、线框图标准或任何其它正式规范的图。
画出界面或系统的草图似乎有点过于简单。但当作为一个团队画这幅简单的图时，会惊奇地看到有多少不同的假设浮出水面。因此，每次处理复杂的估算时，我总是让一个团队成员画出下面中的任意一个：
- 用户所见的界面是怎样的；
- 从用户的角度看来过程是如何进行的；
- 系统整合在一起是什么样的。
这通常与获取一个已有系统的界面截图再对变更或更新对界面造成的影响加些评注一样简单。
然而，你也可以创建任何能够帮助人们理解正在处理的功能的草图。例如，可以画一个流程图，把故事附在流程中适当的部分上，以此帮助理解这些故事是如何联系在一起的。或者如下所示，仅仅画出粗略的框图，标明在哪儿显示什么信息，包括下拉列表等等。
4）不确定性的衡量
对我们熟悉的事物进行评估要比对那些我们毫无经验的要容易。虽然这点似乎是显而易见的，但它也常被忽视。
Jim Highsmith 推荐看看他的书“敏捷项目管理”中提到的项目的“探索因子”。本质上他认为，如果随着项目进行我们很可能改变许多需求或者我们正在应用不成熟技术而不是充分理解和充分测试过的技术，那么项目就会更加复杂。
因此，如果一个项目使用了不成熟技术，且随着团队更好的理解问题空间项目很可能涉及需求变更，那么这一项目就拥有高探索因子。
一些团队对故事应用这一方法。 实际上，“热点图”和“关键事物矩阵”技术就是理解探索因子的方法。
通常团队用简单的方法把故事从 1 到 5 分级排列，以此反映出不确定性程度的增加。另一个方法是把故事画在图表上并简单地标明它们之间的相互关系。
当我使用这项技术时，我通常会列入我的估算中的信息。然而，其他运用这项技术的团队记录了评估（故事点或工时）和复杂性评估。两种方法似乎都运行良好。
对于更复杂的项目，我有时会更进一步，讨论若干类别内的探索因子。然后，与热点图相同，团队可以假定那些包括任意类别的高探索因子的故事要比那些不含这些高探索因子的大。
例如，我可以使用下列的一种或多种类别：
- 客户探索因子 - 产品对市场来说有多新颖：
- 这是我们新的核心市场。
- 这是我们已有市场中的新类别或是一个并不是我们强项的细分市场。
- 这是我们已有市场，但并不是用这一产品或服务进入的。
- 这是个我们从未进入的市场。
- 产品探索因子：
- 我们正在增强我们已有的产品或服务。
- 这与我们已有的产品或服务相似。
- 对我们来说是新产品，但我们的竞争对手已经有了这一产品。
- 这是个我们的市场或区域的新产品。
- 这是个还不存在的产品或服务。
- 内部采用探索因子 - 说服人们采用这一功能有多难：
- 新功能与团队已有工作方式的契合程度（1-5）。
- 团队定制新功能的难易程度（1-5）。
- 在如何设计和实现功能上团队有多少话语权（1-5）。
- 把这些数字加起来，排列出采用的可能性。
有时候，讨论一下项目的探索因子或其中一些构成能大大提高团队对项目的理解，并由此让估算更准确。也可能帮助项目干系人和团队理解他们正在进行的项目的内在风险。
在信息不足的情况下估算
WAG 生成器
WAG 生成器（也被称为“wide angle guess”或是“wild a***d guess”工具）不是常见的用法。换句话说，对我来说它工作良好，但没有研究或迹象表明它对其他人也有效。因此你应该对这一工具加以考量，如果看到其中的价值就使用它。
WAG 生成器的目的是为估算者提供一个粗略可用的估算，这估算在缺乏耗时分析时也许足够精确以做出决策了。 我发现通常这种方法在项目初期是必要的，对找出那些增强点值得继续调研哪些应该立刻放弃也是必要的。
这一估算是以日期或美元的方式提供的，为任务在一张表格中选择一个范围而不是给出一个特定的值。
创建生成器
WAG 生成器只是一张包含表示值域的字母的表。
- “A”通常对客户来说足够大了，会让他们在有更详细的估算之前拒绝承诺工作，并因此拒绝资助更进一步的分析；
- “B”分配给那些大约是“A”一半的条目；
- “C”，“D”及后面的字母分配给后续逐级更小的条目；
- 一旦条目到达一个非常细小的水平，就不要添加更多字母了。
使用生成器
一旦 WAG 表创建出来，新的条目就用表中数据进行估算，而不要对其详细的分析。
基于 WAG 估算，客户能够：
- 决定不继续进行；
- 承诺继续进行；
- 对多个条目按优先级排序，而不需要更进一步的分析；或是
- 如有需要，承诺进行进一步分析。
这使得估算者和客户不用投入太多精力就能快速地详查大量的条目。
WAG 生成器的第一个版本用于为来自“一如往常”的团队的小的“增强”请求提供快速粗糙的估算。
与其坐下来分析请求，估算者不如为条目分配宽范围的日期（或成本）。这种估算可以为最初的优先级排序阶段提供足够的精确度，在这一阶段后如有需要，团队可以准备更精确的估算。
级别
预计时间
级别
预计时间
级别
预计时间
A
超过 6 个月
D
2 -4 个星期
G
1 -8 个小时
B
3 -6 个月
E
2 -10 天
H
¼ - 1 个小时
C
4 -12 个星期
F
1 -2 天
I
少于¼小时
注意，也可以用此方法做财务估算代替时间估算。例如，为超过一百万美元的估算分配字母 A，估算在五十万美元至一百万美元之间分配字母 B，以此类推。
项目 WAG
项目 WAG 与增强 WAG 相似，除了它要更复杂一些且定位于整个项目之外。其中的复杂性来自于以下在标准 WAG 中增加的内容：
- 估算中包含一系列更小的估算；
- 估算与传统的“最好情况，最坏情况以及最可能的情况”估算有些相似。然而，这种估算从最悲观的估算开始，然后向后找到一个粗略的猜测。
- 估算明确地参考关键风险。
基于 WAG，项目经理和客户可以决定：
- 继续进行项目；
- 拒绝项目；
- 只对估算中表现出最大风险、最大成本或最大范围的一些组件进行详细分析和估算。
说明项目 WAG 使用方法的最佳途径是通过例子。
项目 WAG 例子
项目经理需要为下面的项目提供估算：
目的：为销售经理们提供一个能自动生成报告的数据跟踪系统。
范围之内
范围之外
前端系统和后端系统的系统变更
在新南威尔士、维多利亚和南澳大利亚的部门上线
向用户交付培训材料
在澳大利亚其他州上线
流程变更作为项目的一部分
步骤 1 - 收集可用数据
项目经理必须先把项目分解成有意义的组件。例如：
- 高层次的任务、里程碑或是交付物；
- 高层次的功能或故事；
- 项目范围。
项目经理决定，为了给出估算，他要基于项目范围和一些关键任务把项目分解成下列相关的组件：
- 管理报告需求的分析；
- 培训材料的交付；
- 前端系统的变更；
- 后端系统的变更；
- 在新南威尔士、维多利亚和南澳大利亚的部门上线
- 为已有系统构建数据接口
步骤 2 - 选择一个分级量表
项目经理创建一个 WAG 生成器。这种情况下，我们的项目经理选择基于以下时间类别进行估算：
级别
预计时间
级别
预计时间
级别
预计时间
A
超过 6 个月
D
2 -4 个星期
G
1 -8 小时
B
3 -6 个月
E
2 -10 天
H
¼ - 1 小时
C
4 -12 个星期
F
1 -2 天
I
少于¼小时
步骤 3 - 向表格中加入组件，并完成 99.5% 信心列
下一步是添加我们要进行估算的组件。下面的表格中显示了已添加的组件。
现在我们来给出第一次估算。项目经理往往声称没有经过项目的分析阶段就无法给出估算。但这并不完全正确。他们的意思是，他们没法给出客户想听到的估算。
这听起来也许有些荒谬，但如果我们允许项目经理如他或她所想的那么悲观的话，那么项目经理总能给出一个百分百有信心做到的估算。例如，我几乎有百分之一百（或者说有 99.9999999%）的信心：
- 10 年内推出一个新的公司内部网；
- 一天内在 Wordpress 上创建个新博客。
因此问题不是我们不确定如何进行估算，而是我们要么需要在估算中加入荒谬的偶然事件，要么承认我们并不是百分百的有信心。
这是我们 WAG 的基础。我们先给出相当有信心（99.5%）完成的估算的最小值。这表示尽管仍有可能我们不能按时交付，但我们几乎可以肯定我们等做到。
在此处，你可以选择为估算加入风险，但这是可选的。
WAG 生成器的首个版本
条目
99.5%
60%
猜测
主要风险
管理需求的分析。
A
在提交前需要锁定范围。
培训材料的交付。
B
培训将依赖于过程变更。
前端系统的变更。
C
后端系统的变更。
A
我们没有见过这个组件——因此会涉及什么我们全无头绪。
在新南威尔士、维多利亚和南澳大利亚的部门上线。
B
构建数据接口。
C
##### 步骤 4 - 分解那些太大以致于无法给出有意义的估算的条目 （分解过大的项目以给出有意义的估算）
第一遍估算时，项目经理识别出一些超过 6 个月的条目。这对估算来说时间过长了。
因此我们把这些条目分解以更好的理清依赖关系、理解任务或是把条目分解到我们能提供某种估算的程度。
WAG 生成器第二个版本
条目
99.5%
60%
猜测
主要风险
管理报告需求范围的讨论。
D
进一步分析具体管理报告的需求。
C
未预见到的报告需求导致范围变更 ——影响预算。
与 CFO 和销售部门负责人确认报告需求。
E
与销售运营团队确认过程变更。
E
缺少确认意味着培训材料无法准备 ——影响进度。
交付培训材料。
D
前端系统变更。
C
数据仓库整合。
B
数据仓库整合不合要求——影响预算和系统设计。
主机系统变更。
C
在新南威尔士、维多利亚和南澳大利亚的部门上线。
B
构建数据接口。
C
##### 步骤 5 - 加入有 60% 信心的估算
我们现在有了一个悲观但并非不可能的估算。但我们还想知道项目将会持续多久，而不是仅仅知道情况可能会有多糟。
我们选择只有 60% 信心做到的区间，而不是选择有 80% 或 90% 信心做到的区间。我不确定我能否科学的解释这种选择，但我相信：
- （在有 80% 信心和有 100% 信心时人们倾向于进入同样的区间。）人们倾向于在 80% 信心列中填入与 100% 信心列相同的值。但我们其实希望能做的比最坏情况要更好一些。
- 如果我们瞄准的是 50% 信心，那么人们会怀疑我们并不是真的在承诺什么；并且
- 选择 60% 信心使我们能抛开恐惧来估算，同时承诺一个我们认为比较可行的数值。
你可以另选一个你认为靠谱的信心等级。
另外，在这一阶段我们在那些 60% 信心做到的依赖以及主要风险中加入更多细节。这些尤其应该添加到任何在 60% 信心和 99.5% 信心估算之间有巨大差异的条目之中。
在我们的例子中，项目经理在表格中加入了 60% 信心列的估算，也添加了风险。他还添加了一个条目（试运行）以减轻他所识别出的解决方案在多个州上线的风险。
WAG 生成器第三个版本
条目
99.5%
60%
猜测
主要风险
管理报告需求范围的讨论。
D
E
进一步分析具体管理报告的需求。
C
E
未预见到的报告需求导致范围变更——影响预算。
与 CFO 和销售部门负责人确认报告需求。
E
F
与销售运营团队确认过程变更。
E
E
缺少确认意味着培训材料无法准备 ——影响进度。
交付培训材料。
D
D
前端系统变更。
C
C
数据仓库整合。
B
C
数据仓库整合不合要求——影响预算和系统设计。
主机系统变更。
C
C
缺少资源导致项目延迟。
在新南威尔士的部门试运行
E
E
在新南威尔士、维多利亚和南澳大利亚的部门上线。
B
C
在培训、系统变更和过程变更中的错误传达或偏差导致负面体验。
为已有系统构建数据接口。
C
C
总体估算
A
##### 步骤 6 - 完成 WAG 生成器
最后一步是在表中其余字段中添加信息，完成生成器：
- 为下面的每一项在表中添加一行，并把它们包含入估算之中：
- 业务案例，项目审批和项目立项；
- 如果想并行工作，投入 10% 在项目管理上；
- 项目部署，交接，运维和结束
- 把 99.5% 列中的最差情况的值加起来，然后依据实际可并行执行的任务进行调整。选一个最能代表项目总历时 / 成本的字母，然后把这个字母放入表的底部；
- 对于每个条目，猜测这个条目要用多少天或多少星期（或要花费多少钱）能够交付。这应该是在 60% 信心列中所示的范围内的一个数；
- 在猜测列中填入上述数字，根据条目的可并行性或偶发性进行调整，得到最终的测试值填入表格的最下方；并且
- 遵循下列方式给出估算：
- 一个乐观的猜测是（猜测列中的总和），但是也有可能需要（99.5% 列的总和）那么多；
- 这一猜测时建立在下列风险和假定（风险列中列出的风险）的影响下；和
- 如果想了解影响这一估算的核心问题，那么他们是（列出最有影响或花费最大的条目）。
WAG 生成器第三个版本
条目
99.5%
60%
猜测
主要风险
管理报告需求范围的讨论。
D
E
4 天
进一步分析具体管理报告的需求。
C
E
5 天
未预见到的报告需求导致范围变更 ——影响预算。
与 CFO 和销售部门负责人确认报告需求。
E
F
2 天
与销售运营团队确认过程变更。
E
E
6 天
缺少确认意味着培训材料无法准备 ——影响进度。
交付培训材料。
D
D
15 天
前端系统变更。
C
C
30 天
数据仓库整合。
B
C
45 天
数据仓库整合不合要求——影响预算和系统设计。
主机系统变更。
C
C
30 天
缺少资源导致项目延迟
在新南威尔士的部门试运行
E
E
5 天
在几个主要州的部门上线。
B
C
40 天
在培训、系统变更和过程变更中的错误传达或偏差导致负面体验。
为已有系统构建数据接口。
C
C
35 天
项目管理 25 天 业务案例和方案
C
D
10 天
交接和结束
C
C
25 天
总体估算
A
277 天
建议终止项目。
项目 WAG 有多精确？
这种估算不是很精确。但对于对比项目，找出对何处进行深入分析最有益，理解项目风险以及做出项目决策来说，这通常足够精确了。
项目 WAG 与故事点或“T 恤”相比有什么不同？
通常的做法是，以“T 恤”开始估算，然后再用故事点的方法。在这方面，WAG 方法的作用与 T 恤号码相似。
T 恤方法让团队坐下来，将他们的故事比作 T 恤的尺寸。换句话说，他们要把故事分解成：
- 超小号；
- 小号；
- 中号；
- 大号；
- 超大号。
这允许团队讨论哪个故事是最有价值的，并将其与所需实现成本最高的故事相比较。他们可能会在对那些价值不大的功能做过多分析之前简化项目。
这是项广受欢迎的技术，很好的用于许多团队之中。但我本身没有用它，因为它没有给出项目将会进行多久，它也缺乏故事点的有利之处并且没有更简单。
那么为什么不能对项目中大的部分直接转入故事点呢。简单的说，可以且能工作良好。你所要做得就是在项目各阶段或主要交付物中应用团队通常应用于故事的同样的方法。
我倾向于在还没有对速度进行估算且只进行过快速粗略估算的项目中应用 WAG 方法。在我完成估算后（假定我们继续进行），我将把项目分解成更小的组件并应用故事点，这除了能提供一个初始的估算之外，还能产生更好的发布规划和变更管理。
结论
我获得的经验越多，就越意识到最佳的估算方法就是，让团队参与进来，分享他们对问题的理解、对解决方案的期望及对解决问题的难度的看法。
在敏捷团队中，这通常反映在规划扑克的使用和关注在功能估算而不是任务估算上。
这篇文章集合了一些我已经在团队中使用的技术：
- 帮助明晰他们正在进行估算的工作中的假设；
- 提供一个能让团队提出更好的估算的讨论框架。
WAG 生成器提供了一条基线，帮助团队及其赞助者决定是否要在一个新想法上进一步投入。其他技术帮助团队更充分地探索他们正在解决的问题。例如，热点图和探索因子技术都能使隐藏的危险或可能变异的地方突显出来，而其他的技术帮助团队开始确定估算。
本文中探讨的技术当然并不是现有最佳实践的一个完整清单，而是在过去对我来说运作良好的技术的集合。我仍然在学习新的技术，如果能收到那些帮的上你和你的团队的技术的信息我将开心至极。
关于作者
James King 是名顾问，他与团队一起工作，帮助团队改进他们的 IT 过程。他也培训团队和团队领导者改进沟通、风险管理和知识管理的方法。
James 也与 Software Education 紧密合作，这家机构提供敏捷技术、测试和商业分析方面的培训。
-
本文是 Agile Techniques 系列文章的一部分。
-
更多敏捷技术请访问: http://www.infoq.com/agile_techniques
-
相关主题文章：
查看英文原文： Estimation Toolkit
感谢崔康对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论