敏捷估算中的故事点和工期
经常听到有人对于敏捷故事点估算有些纠接，不太清楚故事点估算的意义何在，通过实践和学习后略有心得，所以随笔记下顺便梳理思路。
在谈估算之前，我们先看看工期估算是怎么会事。
在软件开发过程中，工期可以理解为完成所需功能需要的时间，是个绝对值，通常以人天度量。但有两个问题工期无法避免：
- 开发同一个功能的工期可能因人而异（我们无法总是让团队的人总是固定处理他擅长的任务）
- 无法在团队层达成估算一致性，无法用于衡量团队产能（团队的产能不是取决于效率最高的成员，而是取决于效率最低的成员）
再来说说故事点，故事点是什么？
要做的功能有多大，是个相对值，以点数度量。英文表示故事大小是用到了 Size/Scale/effort 之类的词，我不确定中文到底用什么词合适，所以借用学到的词“体量”。或者我们通俗点说这是个啥任务，是包馄饨，包饺子，包包子还是烙大饼？另外，不管谁来做这个功能，它就是这么大，不增不减。它的复杂度是一样的，它的风险是一样的，它的不确定性是一样，要完成这个功能开发不论是谁都要完成这么多工作任务。
故事点不等于工作量，也不等于复杂度，更不等于风险和不确定性，它是一个综合估值，即，故事点估值等于工作量，复杂度因素，风险因素和不确定因素的综合估值。故事点估算是相对概念，所以它能够让不同能力的人，就同一任务的估算达成一致。比如说，做一个登录功能，程序员 A 的用 2 两天完成；程序 B 的用 3 天完成，但这并不影响程序 A 和 B 将登录页面的具体任务拆分并统一评估为 2 点作为基准。那么如果注销功能程序员 A 用时 1 天完成，程序员 B 用时 2 天完成，这也同样不影响两位程序员都认为 注销功能的规模只有登录功能的一半大小，对应的故事点可以是 1 点。所以说故事点的估算可以做到相对稳定和一致。这样一种相对估算一致性在团队中形成，才可以有效的进行团队估算，并过而演化为团队产能。就像是下面两瓶水，我们可能不太确定定两瓶水各有多少，但是我们可以通过相对估算得出，大瓶的容量可能是小瓶容量的 2 倍，那么如果以小瓶为参照，我们就可以说大瓶的容量等于两个小瓶容量，这个 2 倍的小瓶容量就是大瓶容量的一个相对估值。
两瓶水容量各有多少呢？.png
需要注意的是估算的准确性仅限于当前团队。换句话说，一个用户故事的点数仅是基于当前产品其它功能的一个相对大小估算，是当前团队的一个统一估算，仅对当前团队具有参考价值。如果非要在不同团队之间以用户故事点为单位进行统一话，就需要所有团队对估算有一个统一的参考值和统一的估算方法，以确保不同团队的估算不会有太大偏差，但比较难。我们需要单独成篇来分析研究。
为什么要引入故事点来做评估呢
第一，明确团队速率（产能）
工期估算是无法提供产能信息的，我们常到说，某些单位的产能是月产出多少多少，但软件开发的产能却不能说月产能多少多少人天，也没有办法说月开发多少多少功能。因为第一人天是投入不是产出；第二功能有大有小，有简单有复杂不能做位统一的度量单位。所以说度量产能是人天无法做到的，也是功能数无法实现的，除非所有功能大小一致。
当然以故事点来度量产能也只是相对准确。至于如何是稍后说明。
第二，实现团队估算
团队估算有助于团队成员参与需求分析，培养参与感。再则团队估算会刺激团队基于不同角色来剖析产品需求，提前暴露不确定性，避免需求盲点。最重要的是大家在产能方面形成了一个参考基准，一旦团队通过迭代捕捉到了产能，也就可以以产能为切入点，与产品干系人就团队交付效率达成共识，从而避免拍脑袋给日期，又给不准的尴尬局面。
用户对于交付日期的苛刻要求通常源自于对开发团队产能不了解，对于最终交付结果的不确定。
第三，通过稳定的产能，及迭代交付 PSP（潜在可发布产品）增量，可以消除用户顾虑，让用户在不断地交付体验中获得安全感，并能通过提前反馈，优化改进降低产品失败的可能性。举个例子，一个功能，如果我们直接用人天来衡量交付的话，用户第一印象会，这个功能要用 10 天来完成，好久啊；但是如果有故事点来衡量交付的话，用户则会马上意识到，哦，这个功能不小啊，有 10 个故事点。10 天更多体现的是投入，而 10个点则更多体现的是大小，价值。
那么工期估算和故事点估算有什么关系呢？
工期估算和故事点估算其实应该完全分开，其估算的根本目的不同。故事点估算主要为了明确要交付些什么，即不管是团队中什么人来做，什么时间来做，要交付的故事是什么样，体量有多大，所以故事点的估算要相对稳定。
故事点估算通要在迭代计划前完成，即迭代开工前，就要明白告诉团队和用户，每个用户故事规模大概是什么样。工期通常在迭代计划时确定，旨在告诉团队，基于现在的团队现状，我们可以承诺在迭代内完成多少交付。团队现状包括人员配比，成员知识能力，时间要求，工作依赖等。
工期是团队基于本身能力所做出的一种估算，建立在承诺及勇气的基础上。是由团主动做出的估算，所以会更乐于且勇于兑现。这是相较于传统人天估算的一大进步。人天估算由于非团队集体估算，也不是基于团队现状做出的估算，通常会造成团队由于害怕无法按期交付，拼命加缓冲时间，而用户却又坚决不妥协的局面。
分析到这里，我们应该清楚了，故事点估算和工期估算的目的是不同的，方法也是不同的。
- 故事点估算是度量交付价值的；是集体行为。
- 工时估算是执行某项工作的时间，评估工时是根据既定的技能基线来推算某人完成某些工作所需的时间。其重点在于，你应该要了解为什么工时的评估必须以某个技能基线作为校准。所以工时估算是个人行为。
- 最后，敏捷估算（故事点和工时）的最终目的在于团队速度，而不在于个人的速度。
