编程任务估算的艺术

Adriana Lopez龙腾世纪 2 （ Dragon Age ）开发总监

II

我们为何来到这里 ?

个人估算的改进

问题

是否曾有人要求你为某项任务提供一份估算… 最后却被证明错得离谱 (>2x)?

结果你经历了什么后果？

后果是什么？

游戏质量差 与其他团体的协作差 在你的上司或同事面前，你的可信度受

损

哦，又要加班 接二连三地加班

综述 基本概念

何谓估算？ 为何估算有难度？

如何使估算变得更简单？

问题？

何谓估算 ?

估算…

是对一项任务工作量或其复杂程度的预测。

应该反映出固有的不确定性： “我想这任务将花 3 到 8 天。”

应该由实际从事该工作的人员来提供。

估算…

具有准确度与精确度两个方面。

准确的估算 —— 实际值在估算范围内。 避免范围太大（范围太大的估算没有价值）。

精确的估算——范围很小。 避免那些没有数据支持的容易产生误导的所谓精

确。

估算…

让项目能对其资源进行计划与组织。 准确且精确的估算使得项目

能按时、按预定方式完成。

为何估算有难度？

低估与高估 研究表明，编程人员通常会低估完成一项任务所需的工

作量。

不完整的要求 在项目进行中过早提出。

在大家还不不知“它”是什么之前，就估算“它”要花多长时间。

用户不清楚自己想要什么。 我看到“它”时就知道。

我们没有问恰当的问题。 要记得同时征询到功能性及非功能性要求。

区分不完整要求与不稳定要求

不确定性圆锥体是项目管理的术语，用于描述项目各阶段的不确定性水平

由 Steve McConnell 推广普及的一个术语。

估算

可变

性

项目生命期

个人估算做法

提供低估算的压力 管理层需要达到某个目标。 来自同伴的压力。

记住： 更低的估算 != 更好的程序员 避免“即兴的”估算

个人估算做法 被省略的活动

编程活动 非编程活动

没有理由的乐观 支持某估算的理由未以数据为依据。 “我们现在更聪明了” “不可能那么糟”

个人估算做法 主观性 / 偏见

获得某特定结果的愿望（有意识或无意识的）

不熟悉的问题领域 缺乏经验。

缺乏历史数据 将你的估算建立在以往绩效的基础上。

项目混乱

区分目标与估算 确认一下，是要求你进行切合实际的估算，还是要求你达

到某个目标。

不要提供“即兴的”估算 “即兴的”估算可能变成目标 /承诺。

学会对要求进行协商。

How do we make it easier?

规划你卷入了什么样的情形 ?

你卷入了什么样的情形 ?

• 项目组长关心的是，要完成议定的工作范围，全部工作量是多少。

• 总工作量是个别任务的总和，并且基于你所认为的该项工作的复杂性 /规模

• 采用估算技巧来解答这个问题。

技巧 1 ：设定一根基线

复杂性估算 : XP ( 经验分 ) 复杂性分 头痛之事 啤酒

允许范围： 1,2,3,5,8,13,20… 实际工作是以实际时间（例如 :小时）进行衡量的。

基于时间的估算 :工作小时数理想天数

技巧 2: 协作 减少个人偏见。 如果没有协作：

该估算将取决于问到谁，什么时候问。不要想当然地认为最可靠的估算来自于那些最能说的人。

哎，伙计，这得花多长时间 ?

52 Zzz

z

技巧 3: 三角系 将新工作与以往的工作相比较。 .需要历史数据。 要前后一致！

~ 10,000 XP

A – 2 XP

B – 3 XP

C – 1 XP

技巧 4: 分解 将大的任务（用户故事）细分成具

有以下特点的小的任务（用户故事）： 你更熟知的 只需花短短数天时间

规划

运用这些技巧来达成一个受以下方面影响最小的估算： 被省略的活动 无理由的乐观 主观性 偏见 不熟悉的问题领域

规划

要记得记录下你的估算！ 要得到先前任务的数据，你必须着手开始将

估算写下来。

在执行期间，将其作为帮助你监控及改进自身绩效的一个工具。

执行80% 的时间花在 20% 的工作上

记录下实际花费的时间

处理许多个人估算问题的最有效方法。 关键是要有一项明确、不含糊的任务。 明确的任务让你能够区分缺陷与变化。

你的时间都花在何处？ 练习：在下一个用户故事（ user-

story ）或任务中，请试着跟踪你的时间使用情况。观察一下你把时间都花在了何处。

回顾我是如何做的 ?

我是如何做的 ?

问以下问题：

你工作有多快？ 你的估算与实际结果有多接近？ 我是否忘了对有利于下次任务估算的某事

项作出预测？

对结果进行分析

有用的计算

速度 你工作有多快？

相对误差大小 (MRE) 你的估算与实际结果有多接近？

例子 – Part 3a, 速度

速度是指单位时间完成的工作量 分数 : 7 XP / 3 个日历日 = 2.3 XP / 日 工作量 : 9.5 小时 / 3 个日历日= 3.2 小时 /日

日期 任务 原始估算 日历日总数 总速度

4/7/2008 A 3 XP 5

4/8/2008 B 2 XP 2

4/9/2008 C 5 XP 8 0.66 XP /日

例子 – Part 3b, 相对误差大小（ MRE ） MRE 等于 ABS ( 实际 – 预期 ) / 实际

ABS (9.5 – 7) / 9.5 = 0.26

任务 最佳 预期 最差 实际 MRE

A 1

B 5

C 10

D 5 7 10 9.5 26%

更新未来预算 不要为了得到一个更好的结果数据，而在任务

结束时，对原始预算进行篡改。

估算会随时间而变化，对之要有预期。 随着项目的进展，要求将被喜欢或全盘改变。

记住“不确定性圆锥体”

总结

提高估算的准确性与精确性，是我们每个人的责任。

警惕不良个体估算做法 运用协作技巧 收集并分析数据 运用分析来改进未来估算

总结

找到一种适合自己的方法。

（要确保该方法仍适用于你的项目）。

¿问题 ?

“对于由非定量方法得出、并且由管理人员基本凭直觉认可的估算，很难对其进行有力、可信的辩护。”

Fred Brooks

参考

由 Construx Software 提供的 10x软件工程学（ Software Engineering ） 课程 (http://www.construx.com)

Steve McConnell 所著的《软件估算》（ Software Estimation ）

Mountain Goat Software (http://www.mountaingoatsoftware.com/)