开发任务估算，你get到point了吗？
首先要澄清的是这里说的估算指的是工作的复杂程度，或简单的理解成工作量大小；还有一种我们经常提到的是估算feature的用户价值，这个不在本文讨论的范围。
为什么要估算
估算往往都是很花时间的，更要命的是估算总是做不到准确的，那为什么还要做估算？
- 对于用户（或是运营同学）：用户需要一个这样的预期（甚至是承诺），什么时候才能用上这个功能
- 对于管理者：管理者需要这个估算做决策，决策包括调整工作优先级、人员调整、甚至是否砍掉这个功能等
- 对于团队自己：不仅是团队内的合作，还包括团队之间的合作（如联调的时间的确定），都需要基于估算给出
除了上面这三个角色对估算的期望之外，我认为估算还有一个更重要的价值，那就是在估算活动中大家对任务能够趋向达成一致的理解，减少一些被忽略的假设和背景。
正所谓“磨刀不误砍柴工”，在估算上花费的时间是值得的。
估算的对象
一般的情况下我们估算的对象分为3类：
- 特性（feature）
- 用户故事（user story）
- 任务（task）
这个三类对象是有层级关系的：特性可以分解成故事，故事又能分解成任务。
feature往往太大，需要先拆解成story才方便估算；task又太detail，估算的话不仅特别费时，而且团队在对task做估算的时候非常容易在每个task里增加buffer，最后导致整个story的估算大小膨胀不可控。
所以我个人更认同对story的估算。
常用的工具和方法
一般我们常用的敏捷估算方法有扑克估算，T-shirt估算和三角估算法等。
扑克估算
planning poker
上图就是一副比较常见的估算扑克，可以看到扑克上的数字并不是自然顺序的，这是斐波那契数列的变形。
斐波那契数列
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233，377，610，987，1597，2584，4181，6765，10946，17711，28657，46368，···
第0项是0，第1项是第一个1，这个数列从第2项开始，每一项都等于前两项之和。
为什么不使用自然顺序的数字呢？这是因为当一个任务越复杂，我们估计值越大的时候，估算结果的准确性也就越低，这个时候再去纠结它的点数是13还是14已经没有意义了。为了避免没有意义的数字争论和提醒我们这个任务可能太大需要再次拆解，所以才使用了步长越来越大的斐波那契数列。
在实际操作中，一些团队内部会规定超过13的story必须再次拆分。
操作方法
- 先从待估算的列表中选择一个较小的用户故事，讨论确定其故事点数（如1或2），将其作为参考基准故事
- 从列表中随意选取一个故事，主持人朗读完描述之后，大家一起讨论，产品负责人负责回答大家提出的任何问题
- 没有问题之后每一个参与者把该故事与基准故事进行比较，然后选择一张代表其故事点数的扑克牌（不要让其他人看到），在大家都准备好之后同时一起出牌
- 如果大家出的牌都一致（或非常接近），则完成该故事估算，转向下一个故事
- 如果有较大差异，请估算最大和估算最小的进行解释，解释完后大家限时讨论，然后重新开始出牌，直到大家达成一致
- 估算出的故事越多，可用来做基准的参考值就越多，也就越容易估算
- 最终我们就能得到所有用户故事的总工作量
在这种方法下，往往很少有故事超过3轮出牌都达成不了一致；如果遇到了多轮都达成不了一致的故事，那往往说明大家其实是对该故事到底要做什么怎么做还没有达成一致的理解，这就不是估算的问题，而是需求澄清和开发设计的问题。
所以说估算不仅仅是增加可预测性，更重要的是这种不断讨论直到对故事大小达成一致的过程是在帮助我们澄清对需求和设计理解。
T-shirt估算
Tshirt
T-shirt估算就是以T恤大小号码作为单位的估算方式，因为好理解并且选择有限（S、M、L），往往比较容易入手。操作上可以借鉴类似估算扑克的操作步骤。这种方式因为简单，一般在团队刚接触估算的时候可以快速导入，等团队对估算比较熟练的时候这种方式会慢慢显露一些问题：
- 相互之间不能累加，如果完成的时候被问到所有故事的总和，就很难表述（1个S，4个M，3个L？）
- L比M到底大多少？不同的人有不同的默认看法，容易产生冲突
比较适用的场景
个人觉得T-shirt比较适合对feature的大小做估算。
当在一个比较大的项目启动的初期，项目的feature列表和feature的绝大部分user story都澄清了的时候，可以召集各个领域的专家一起使用T-shirt的方法对feature做大小估算。
这样做的好处在于能帮助产品和开发负责人在整个大项目的初期对所有feature有一个完整的把握，尽早发现潜在的风险。
三角估算法
一种比较类似于T-shirt估算的方法，大致思路是两两比较，大的放右边，小的放在左边，类似大小的放下面，直到每一个story都找到自己的位置。
一个在线估算小工具
为了方便使用，我们做了一个在线的扑克估算工具，可以使用手机方便的代替物理扑克牌。支持扑克和T-shirt两种估算方式。
敏捷估算在线工具
一些需要注意的地方
全体组员参与的估算
相对于专家法的估算，在扑克估算的活动中我们更加强调是全体团队一起来参加。全体组员参加能带来一些好处：
- 保证所有人都对每一个story有足够了解，如一些人只关心某几个自己会直接参与的任务而不关心组内其他工作，那么这个team有退化成group的风险。
- 因为每个人的思考角度都不同，集体的思考能更全面，全体参与的讨论能提高大家对story的理解程度和估算的准确性。
- 每个人都需要出牌，并且最高和最低的出牌者需要解释原因，这种方式能促使大家都集中注意力在会议的讨论上，避免有人走神。
用相对值而不是绝对值
估算的单位是一个比较有意思的话题，传统的估算单位一般是小时或是人天，但敏捷估算中我们推荐的是使用故事点（story point）作为单位。
那相对值的故事点到底有什么好处呢？
- 人类天生更擅长相对值的比较，所以相对值的估算会更快
- 小时和人天受限于任务实际执行者的能力水平，在估算时引入这个不可控的变量会让估算活动更加复杂和打不成一致
- 估算本来就不准，所以就更没有必要使用精确的单位
但是是相对值的估算的故事点最终还是不可避免要在日历上进行编排，最好的方式是通过实践统计拿到team的单迭代故事点产出速率范围（velocity），进而据此来估计下迭代合理的交付量和项目整体的交付时间。
如果对task做估算，往往就容易引导到用小时或人天作为单位了，在我过去的经验中经历过很多这样的团队，当然这样也是可以工作的，只要我们把握好几个问题：
- 较长的迭代的估算会议（半天左右？）
- 基于个人能力的估算（往往会有人问这个task到底是谁来做，这样就不可避免在估算的时候要做任务分配了）
- story工时膨胀（每个task为了保证完成都是加自己的buffer，对story估算的话就只会在story上单次加buffer；工期估计的时候加buffer是人的天性）
测试工作的估算
在一般有专门的测试成员的团队中，一般的操作会是开发工作由开发同学做估算，测试工作由测试同学自己估算。这样其实算是把一个story拆成了开发部分和测试部分两个task，然后分别估算。这样做是很常见，但是这种方式其实是暗示让我们在一个迭代中用瀑布的方式做开发。
在目前互联网行业越来越倾向缩编专职测试人员，推崇测试自动化、devops，希望开发人员能加强对自己的产品有更多的质量保证的大环境下，我们可以考虑把开发和测试工作放在一起来估算，让开发同学对测试工作有更全的了解，让测试和开发能更紧密的结合（而不需要传统模式下有明显的提测交接的过程）。
story的大小
story有可能非常小，但是原则上story最大不能超过团队一个迭代的总交付能力，也就是说story必须是在一个迭代里能完成交付的，而不需要跨迭代。如果遇到需要跨迭代才能交付的story，要么是story还没有拆分到位，要么是行业领域特殊性，对这样的团队我们需要定义稍长时间的迭代周期。
燃尽图
有了估算之后，我们就能非常方便的在迭代过程中使用燃尽图的方式做进度跟踪。
当然，如果有对task的估计的话燃尽图的曲线可以画得更详细。
估算点数膨胀
有了估算，管理层就会思考团队的交付速率问题（velocity），一旦团队的速率变成的KPI，估算点数就很可能开始默默的膨胀起来了。
一个基本的原则是不要使用团队自己估算的点数来作为KPI衡量团队的产出，估算的目的不是这个。
不同的观点
对于估算，在看板方法里有不同的看法:
估算需要时间，并且（通常）是错的。
看板更推崇使用历史数据或者具有预测能力的模型构建针对项目产出的概率预测。看板认为预测效率更高、成本更低，结果通常也较传统的估算、计划方法准确得多。
关于看板里的预测，我们以后再谈。
