敏捷估算
估算是对交付计划产品所需要的成本、进度、投入或者技能进行的预测。对项目的可行性、商业案例和投资回报进行评估非常有必要。虽然在敏捷项目初期可用信息非常少，但可以用ROM（粗略量级估算）来做出决策。
一、敏捷估算基础
1、为什么需要估算？——估算让团队可以了解项目规格，计算ROI和IRR，形成项目执行许可的基础。
2、谁执行估算？——敏捷团队基于产品负责人的投入来估算需求，Scrum Master进行保守估算。
3、估算会议什么时候进行？——整个项目期间进行。在项目逐步完善中更多信息出现，团队定期评估新需求。
4、估算如何创建？——团队使用计划扑克或者亲和估算等技术来确定需求估算。
准确性和精确性
敏捷估算致力于准确性而非精确性，因为实现精确性让估算过程拉长并且昂贵。准确性意味着聚集到一个标准或已知值；精确性是重复性精度；在软件开发中，精确性的建立很困难。
相对尺码
相对尺码是敏捷估算中的重要概念。与测量绝对值不同的是，它通过对比基线来确定需求的大小。相对尺码运用在用故事点估算用户故事时。
价值点
敏捷强调交付价值和成果：
价值点展示一个故事的相对商业价值；
针对故事价值，运用相同的相对尺码技术，将提供对总体交付价值的估算；
这将让产品负责人和商业利益相关者共同参与到将故事或特性价值量化的工作中；
价值点将给估算带来真正的权力（价值）
二、项目规模测量
确定项目规模对于确定它的最终完工日期和资源非常重要。
传统项目管理常用的项目规模测量有：行代码、功能点。
敏捷项目测量用以下表示：故事点、理想时长（又翻译：理想日）。
1、故事点
故事点是描述一个用户故事及其相关努力总体规模的测量单元。
1）故事点：
- 是相对测量；
- 用户故事的故事点互相进行对比；
- 故事点是团队运用计划扑克等估算技术确定的；
- 故事点对一个项目来说是独特的，不能同其他项目相比较。
2）分配故事点需要考虑的：
- 任务规模-故事规则取决于以下因素：复杂性、投入量、风险大小
- 相对价值-故事点是规模的相对测量，绝对值不是很重要。
- 估算-估算运用基准来完成，相对值被运用。
- 选取最小故事估算价值为一个故事点。
- 选取中等规模故事分配5个故事点。
3）故事点估算的步骤
- 用户故事拆分为更小的功能，并确保每个故事具有投资属性。理想情况下，每个故事应该由1个人占用不超过2天的时间完成。
- 确定团队达成共识的故事作为基线，创建它的故事点价值。
- 将所有其他故事卡片同基线故事对比。
- 每次迭代末期，将故事点同故事卡片上记录的校准。
4）故事点之类比估算故事点估算可以通过对比来有效完成。类比估算中需要考虑：
（1）将一个用户故事同其他故事对比基于精确性，如果故事A同故事B类似，他们的估算也将类似。
（2）创建多层面基准
当2到3个不同的规格设定为基准时，一个可能的比较是：故事A比故事B规格大，但是却小于故事C，如果故事C大，故事B小，那么故事A接近于中等规格。 举个例子：我们可以定义喝一小杯热咖啡花费的工作量为参考基准，是 1 个故事点。中杯看起来是小杯的2倍大，所以我们可以估算喝一中杯热咖啡花费的工作量是小杯的两倍，是2个故事点，大杯是小杯的三倍，所以工作量是3个故事点。
2、理想日
1）理想日估算将会回答实施故事所需时间的问题，它需要考虑：
- 正在进行的唯一任务；
- 没有中断；
- 所有需要的信息都可用。
一旦理想日估算达成，经过几天潜在干扰后它将被转化为实际时间。在极限编程中，理想日被称为完美编程日。
2）在理想日估算被转化为实际时间时会遇到很多干扰，以下是影响理想日的因素：
培训、评审、采访、会议、电话、管理评审、邮件、bug修复、生病、示范在正常的工作的8小时内，一个开发人员可能会只花5小时在编程工作上。然而，即使开发时间估算在8小时或1天的工作时间，实际时间也可能接近1天半时间。
三、故事点VS理想日
1、故事点
- 有助于驱动跨职能行为；
- 故事点估算不会衰变；
- 纯规模测量；
- 故事点估算时间很低；
2、理想日
- 同样的团队内理想日有差异；
- 理想日在团队外部容易说明；故事点更加抽象；
- 理想日迫使公司面对浪费时间的活动。
四、估算规模
敏捷评估旨在合理预测估算，不追求精确。以下两种非线性规模常用于估算：非线性规模-斐波那契数列：1，2，3，5，和8，后一个数字是前面两个数字的总和。
非线性规模-翻倍：1，2，4和8，每个数字翻倍得到下一个数字。
1、宽带德尔菲
1）宽带德尔菲技术用来收集关于项目规模的准确估算。宽带德尔菲估计法建立在传统德尔菲技术基础上。具体方法是，在会议中，只讨论估计时可能会遇到的问题，估计本身和所花费的成本不做讨论。会议讨论后让每个人分开，独自准备他们的估计，一定要注意，让每个人做估计时远离群体。接下来召回团队成员，汇集所有的估计，并在图表中画出来，展示价值的分布，但每个估计都不写估计者的名字。然后团队再讨论存在估算差异的情况，并设法达成共识。或者项目经理选择一个估算团队，组织专家，通过一系列会议就估算达成一致。在项目经理收集个人估算后将汇总发送给团队成员，估算匿名完成。如果估算差异很大，另一次迭代（重新估算）进行。缺点是相对常用估算技术例如专家判断、类比估算等，它要求更多精力和协调去进行估算。
2） 宽带德尔菲的步骤：
（1）团队选择：选择负责估算的专家团
（2）启动会议：计划启动会议去说程序和落地规则
（3）个人准备：允许团队成员针对每个任务个人收集初始估算
（4）估算会议：实施一系列迭代步骤组成的估算会议
（5）配置任务：收集个人估算，编译最终清单
（6）任务评审：评审估算程序、最终任务清单和假设的结果。
3） 宽带德尔菲技术之计划扑克计划扑克是宽带德尔菲技术的变化模式，整个团队协同合作估算每个用户故事需要的投入。在计划扑克会议中：
（1）每个团队成员收到有编号的卡片，如果需要数字可以延伸；
（2）产品负责人朗读每个故事卡片并回答团队问题；
（3）每个团队成员评估故事所需投入以及运用相对尺码给故事分配点；
（4）当Scrum Master要求时，每个人必须同时举起写有他们估算的数字卡；
（5）如果这里有差异，团队成员要解释估算偏高或偏低的原因；
（6）讨论后，团队成员重新估算直到达成一致。
2、亲和估算
亲和估算是一种被团队成员用来估算大规模用户故事的技术。当有大量“功能未完项”出现时，进行的快速估算，即为亲和估算。
1）亲和估算的优势：
- 快速简单；
- 决策制定过程透明可见；
- 它创造了一种积极合作的体验而非对抗性。
2）亲和估算的步骤
（1）沉默的相对尺码
- 产品负责人提供产品待办事项
- 故事水平排列在墙上
- 团队成员考虑执行中的努力，对比墙上物品对每样物品进行规模定义
- 团队安静地执行以上步骤，不讨论技术或者特性问题
（2）编辑墙
- 故事卡片的规格在这一步里编辑
- 基于设计讨论和其他团队成员的投入，故事卡片根据相对尺码移动
（3）将物品置于相对尺码栏
- 根据团队决定使用的分栏命名，把相应的规模置于墙上。
（4）产品负责人挑战
一旦团队完成估算，产品负责人可能会不认同某些估算，如果团队决定一个物品必须重新进行规模估算，它可以通过以下：
- 将它置于独立的墙上重新进行规模估算
- 立即同产品负责人决定新规模
（5）储备数据
- 数据被记录和储备，意味着亲和估算流程的结束。
3、T恤尺码估算
一种流行的敏捷相对估算技术：（中码，大码，加大码等）
- 操作简单；
- 介绍团队使用相对估算的好方法；
- 亲和估算非常有效
- 在进行用户故事估算前，每个T恤尺码的基准需要由团队决定。
4、计划扑克牌
计划扑克牌可以在项目早期使用，即在写完用户故事之后。在一个软件项目中，将程序员、分析师、测试人员邀请进来，提供给每个团队成员10张数字牌，这是一组修改过的斐波那契数列（0，1，3，5，8，13，20，40，100），会议展开后，主持人阅读某一个用户故事或一个功能描述，每个估算者可以提出问题，然后每个人选一张卡片，代表对该故事的估算成本。然后所有参与者同时展示自己的卡片。如果有很大的偏差，团队可以同样的用户故事进行另一轮的计划扑克。
五、确定项目规模
项目规模通过添加与用户故事相关的故事点到产品待办事项中来确定。基于敏捷项目的动态特点，新需求会持续地添加到产品待办事项中。因此，项目规模在项目的早期阶段只是一个指示性的指标，需要在整个项目生命周期中不断地被查看。
这些信息将有助于确定：
- 团队规模；
- 团队数量；
- 冲刺持续时间；
- 版本中冲刺数量；
- 目标上限。
估算是否要精准无误，估算有偏差是否要进行修改？我们认为没必要精准，也无需修改有偏差的估算点数。估算是为了辅助我们的工作安排，而不是用来管理员工的绩效表现。为了达到精准的估算而耗费了过多的时间盒精力，这是本末倒置。有的故事卡片会比预计的先完成，有的会耗时更长一些，这些经验的积累都会为团队的下一次估算奠定更好的基础。
