（十五）什么是敏捷估算？

估算

估算是对交付计划产品所需的成本、进度、投入或者技能进行的预测。对项目的可行性、商业案例的投资回报进行评估非常有必要。

虽然在敏捷项目初期可用信息非常少，但可以用ROM（初略级估算）来做出决策。

敏捷估算基础：

为什么需要估算？

估算可以让项目团队了解项目规格，计算ROI和IRR，形成项目执行许可的基础。

谁执行估算？

敏捷团队基于产品负责人的投入来估算需求，Scrum Master进行保守估算。

估算会议什么时候执行？

整个项目期间进行。在项目逐渐完善中更多信息出现，团队定期评估新需求。

准确性和精确性

敏捷估算致力于确定性而非精确性，因为实现精确性让估算过程拉长并且非常昂贵。

准确性意味着聚集到一个标准或已知值。

精确性是重复性精度；

在软件开发中，精确性的建立很困难。

项目规模测量

确定项目规模对于确定他的最终完工日期和资源非常重要。

传统项目管理常用的项目规模测量有：行代码，功能点。

敏捷项目测量用以下表示：故事点、理想时长（又翻译：理想日）。

1.相对尺码

相对尺码是敏捷估算的重要概念。

与测量绝对值不同的是，它通过对比基线来确定需求的大小。

相对尺寸运用在用故事点估算用户故事时。

2.故事点

故事点是描述一个用户故事及其相关努力总体规模的测量单元。

1）故事点：

①是相对测量；

②用户故事的故事点互相进行对比；

③故事点石团队运用计划扑克等估算技术确定的；

④故事点对一个项目来说是独特的，不能同其它项目比较。

2）分配故事点需要考虑的：

①任务规模 -故事规则取决于以下因素：复杂性、投入量、风险大小；

②相对价值-故事点是规模的相对测量，绝对值不是很重要；

③估算-估算运用基准来完成，相对值被运用；

④选取最小故事估算价值为一个故事点；

⑤选取中等规模故事分配5个故事点；

3）故事点估算的步骤：

①用户故事拆分成更小的功能，并确保每个故事具有投资属性。理想情况下，每个故事应该由一个人占用不超过2天的时间完成；

②确定团队达成共识的故事作为基线，创建他的故事点价值；

③将所有其它故事卡片同基线故事对比；

④每次迭代末期，将故事点同故事卡片上记录的进行校准。

4）故事点之类比估算

故事点估算可以通过对比来有效完成。类比估算中需要考虑：

①将一个用户故事同其他故事对比；

基于精确性，如果故事A同故事B类似，他们估算也将类似；

②创建多层面基准

当2到3个不同的规格设定为基准时，一个可能的比较是：故事A比故事B规格大，但是却小于故事C，如果故事C大，故事B小，那么故事A接近于中等规格；

举个例子：我们可以定义喝一小杯热咖啡花费的工作量为参考基准，是一个故事点。中杯看起来是小杯的2倍大，所以我们可以估算喝一中杯热咖啡花费的工作量是小杯的两倍，是2个故事点，大杯是小杯的3倍，所以工作量是3个故事点。

3.价值点

敏捷强调交附价值和成果：

价值点展示一个故事的相对商业价值；针对故事价值，运用形同的尺码技术，将提供对整体交付价值的估算；这将让产品负责人和商业利益相关者共同参与到将故事或特性价值量化的工作中；价值点将给虎算带来真正的权利（价值）。

4.理想日

①理想日估算将会回答实施故事所需时间的问题，它需要思考：

1）正在进行的唯一任务；

2）没有中断；

3）所有需要的信息都有用；

一旦理想日估算达成，经过几天潜在干扰后它将转化为实际时间。在极限编程中，理想日被称为完美编程日。

②在理想日估算被转化为实际时间时会遇到很多干扰，以下是影响理想日的因素：培训、评审、采访、会议、电话、管理评审、邮件、bug修复、生病、示范。

在正常工作的8小时内，一个开发人员可能会花5小时在编程工作上。然而即使开发时间估算在8小时或1天的工作时间，实际时间也可能接近1.5天时间。

故事点VS理想日

故事点-

①有助于驱动跨职能行为；

②故事点估算不会衰变；

③纯规模测试；

④故事点估算时间很低；

理想日-

①同样的团队内理想日有差异；

②理想日在团队外部容易说明；故事点更加抽象；

③理想日迫使公司面对浪费时间的活动。

5.估算规模

敏捷评估旨在合理预测估算，不追求精确。一下两种非线性规模常用于估算：

非线性规模-斐波那锲数列：1，2，3，5和8，后面一个数字是前面两个数字的综合。非线性规模-翻倍：1，2，4和8，每个数字翻倍得到下一个数字。

6.宽带德尔菲

①宽带德尔菲技术用于手机关于项目规模的准确估算。宽带德尔菲估计法建立在传统德尔菲技术基础上。具体方法是，在会议中，只讨论估计时可能会遇到的问题，估计本身和所花费的成本不做讨论。会议讨论后让每个人分开，独立准备他们的估计，一定要注意，让每个人做估计时远离群体。接下来召回团队成员，汇集所有的估计，并在图表中画出来，展示价值的分布，但每个估计都不写估计者的名字。然后团队再讨论存在估计差异的情况，并设法达成共识。

或者项目经理选择一个估算团队，组织专家，通过一系列会议就估算达成一致。

在项目经理收集个人估算后将汇总发送给团队成员，估算匿名完成。

如果估算差异很大，另一次迭代（重新估算）进行。

缺点是相对常用估算技术例如专家判断、类比估算等，它要求更多精力和协调去进行估算。

②宽带德尔菲的步骤：

1）团队选择：选择负责估算的专家团

2）启动会议：计划启动会议去说程序和落地规则

3）个人准备：允许团队成员针对每个任务个人手机初始估算

4）估算会议：实施一系列迭代步骤组成的估算会议

5）配置任务：收集个人估算，编译最终清单

6）任务评审：评审估算程序、最终任务清单和假设的结果

③宽带德尔菲技术之计划扑克

计划扑克是宽带德尔菲技术的变化模式，整个团队协同合作估算每个用户故事需要的投入，在计划扑克会议中：

1）每个团队成员收到有编号的卡片，如果需要数字可以延伸；

2）产品负责人拉朗读每个故事卡片并回答团队问题；

3）每个团队成员评估故事所需投入以及运用相对尺码给故事分配点；

4）当Scrum Master要求时，每个人必须同时举起鞋油他们估算的数字卡；

5）如果这里有差异，团队成员要解释估算偏高或偏低的原因；

6）讨论后，团队成员重新估算直到达成一致；

7.亲和估算

亲和估算是一种被团队成员用来估算大规模用户故事的技术。当有大量功能未完项出现时，进行快速估算，即为亲和估算。

①亲和估算的优势：

1）快速简单；

2）决策制定过程透明可见；

3）它创造了一种积极合作的体验而非对抗性。

②亲和估算的步骤

1）沉默的相对尺码

1.1产品负责人提供产品待办事项

1.2故事水平排列在墙上

1.3团队成员考虑执行中的努力，对比墙上物品对每样物品进行规模定义

1.4团队安静地执行以上步骤，不讨论技术或者特性问题；

2）编辑墙

2.1故事卡片的规格在这一步里编辑

2.2基于设计讨论和其它团队成员的投入，故事卡片根据相对尺码移动

3）将物品置于相对尺码栏

根据团队决定使用的分栏命名，把相应的规模置于墙上。

4）产品负责人挑战

一旦团队完成估算，产品负责人可能会不认同某些估算，如果团队决定一个物品必须重新进行规模估算，它可以通过以下：

4.1将它置于独立的墙上重新进行规模估算

4.2立即通产品负责人决定新规模

5）储备数据

数据被记录和储备，意味着亲和估算流程的结束。

8.T恤尺码估算

一种流行的敏捷相对估算技术：（中码，大码，加大码等）

* 操作简单；

*介绍团队使用相对估算的好方法；

*亲和估算非常有效；

*在进行用户故事估算前，每个T恤尺码的基准需要由团队决定。

9.计划扑克牌

计划扑克牌可以在项目早期使用，即在写完用户故事之后，在一个软件项目中，将程序员、分析师、测试人员邀请进来，提供给每个团队成员10张数字牌，这是一组修改过的菲波那切数列（0，1，3，5，8，13，20，40，100），会议开展后，主持人阅读某一个用户故事或一个功能描述，每个估算者可以提出问题，然后每个人选一张卡片，代表对该故事的估算成本。然后所有参与者同时展示自己的卡片，如果有很大的偏差，团队可以同样的用户故事进行另一轮的计划扑克。

10.确定项目规模

项目规模通过添加与用户故事相关的故事点到产品待办事项中来确定。基于敏捷项目的动态特点，新需求会持续的添加到产品待办事项中。因此项目规模在项目早期阶段只是一个指示性的指标，需要在整个项目生命周期中不断被查看。这些信息有助于确定：

（1）团队规模

（2）团队数量

（3）冲刺持续时间

（4）版本中冲刺数量

（5）目标上限

估算是否要精确无误，估算有偏差是否要进行修改？不必要精准，也无需修改有偏差的估算点数。估算是为了辅助我们工作安排，而不是用来管理员工绩效表现。为了达到精确的估算而耗费了过多的时间盒精力，这是本末倒置。有的故事卡片会比预计的先完成，有的会耗时更长一些，这些经验的积累都会为团队的下一次估算奠定更好的基础。