敏捷估算之相对估算
在日常的项目管理过程中，我们经常会遇到需要对产品需求进行初步耗时的预判的情况，这个时候我们就需要找团队确定大致的估时，很多时候这不是一件容易的事情，团队给出的时间往往参考性不强，这是大家不愿意认真做估算这件事情么？并不是，更多的时候时大家不知道如何做估算。
针对这种情况，我给大家介绍一种容易上手，又比较省时的估时方法——相对估算。
我们为什么要做估算？
我猜很多人会有这样的疑问，估算到底有什么用，反正都要做，直接动手不是更快？
我们现在推崇的敏捷实践方法中，有一条很重要的实践——迭代周期固定。当团队成员固定，时间又固定的情况下，变量就是需求范围了，在固定的时间内，我们无法完成所有的Product Backlog时，我们需要在这些Product Backlog选取优先级高的需求完成，并制定交付计划，这些优先级往往也是和满足市场，用户或客户的期望紧密关联的。一般计划会包含几个点：什么时候谁完成什么内容已达到什么目标。所谓计划，是在开始时就要做的，那我们如何让能够在动手研发前就确定我们要完成什么内容，这就需要用到估算，事先预测工作耗时，以便实现进度的可预测性，从而来支撑业务的决策。当我们明确了这个计划，我们就对目标有了一个更清晰的认识，团队的每个人都明确我们这一个迭代需要在什么时候交付什么产物。如果没有做估算时，可能就是做到哪算哪了。
一般传统的估算方式是，直接问研发要完成的时间，当研发没有做很详细的需求分析和设计时，他们对多久能够完成是没有概念的，但是不管怎样，他们都会给一个答案，这个答案的准确性可想而知。而且我们在问研发要估时，往往不会一个研发一个研发的问过去，一般都会找SO确定时间，由于个人能力有差异，一个人给的时间不一定适合团队的其他人（如果SO能够按每个人的能力给出相应的时间，就另当别论了）。这种估算方式很可能会导致两个极端情况，由于估时太乐观导致项目延期或者估算太保守导致团队空闲，资源利用率降低。
由于传统估算的弊端很显见，我们就引入了另一种实践——相对估算。
“相对估算”是使用“比较”的原则，通过用户故事（story）之间的大小对比进行估算，估算后的结果没有时间单位。
一般操作步骤是：
Step1：寻找一个参照故事A作为1个故事点（用来度量完成1个story所需工作量的相对单位）。
Step2：迭代的每个story和A做比较，得出这些story需要几个A的工作量，即为几个故事点。
Step3：完成故事A，获得故事A的实际需要的时间，即可推算出完成所有story需要的耗时。
做故事点估算的目的：
- 得出多久能交付产品，每个迭代能够交付多少story的结论
- 统一度量标准，每个迭代可以沉淀以故事点为单位的历史数据，可以进行更客观更准确的分析，甚至可以拉平整个研发中心的度量标准。对制定资源计划也有很重要的参考价值。
- 团队分析user story的需求和澄清
注意：
1、故事点包含内容：
要开展的工作的数量
工作的复杂度
要开展的工作中存在的任何风险或不确定性
2、故事点选择时需要注意避免以较复杂的story作为1个故事点。
我们估算的对象按照颗粒度大小可分为特性（feature），用户故事（story），任务（task）。这个三类对象是有层级关系的： feature可以分解成story ， story又能分解成task 。相对估算一般选择story进行估算。feature往往太大，需要先拆解成story才方便估算；task又太细节，估算的话不仅特别费时，而且团队在对task做估算的时候非常容易在每个task里增加buffer，最后导致整个story的估算大小不可控。
目前比较常见的相对估算方式有扑克估算，T-shirt估算，三角估算法。接下来我为大家一一介绍一下。
扑克估算
将斐波那契数列制成卡片，卡片上的数字代表故事点数，大家在估算时，同时出卡片，卡片数字代表自己认为的这个story的故事点数。当大家都亮完卡片后，可以观察，如果大家的卡片数字相差较大，可以讲解后重新出卡片，直到大家对估时点数达成共识。此时得出的结果即为该story的故事点数。
T-shirt估算
以T-shirt的尺寸为标准对story进行估算，XS代表耗时最少的story，XXXL为耗时最多的story，大家同样可以把T-shirt的尺寸制成卡片，用出卡片的方式进行估算。这种估算比较适合对feature的大小做估算。一般在一个比较大的项目启动的初期，项目的feature列表和feature的绝大部分story都澄清了的时候使用。使用这种方式进行估算，能帮助产品和开发负责人在整个大项目的初期对所有feature有一个完整的把握，尽早发现潜在的风险。
如上图所示，当我们使用T-shirt估算方式对一个项目的成本和收益进行估算时，可以按照上图分析做出合适的决定。
当然，目前没有哪一种估算方式是完美无缺的，相对估算也如此，它也存在一定的问题：
- 团队很难找到一个合适的用户故事做基准；
- 团队更关注于讨论单个用户故事的点数是多少，而不是关注与其它用户故事比较的相对大小；
- 估算所花费的总时间比较长（常常是整个下午，甚至一天）。
我们在选择估算方式时，不求完美，适合团队的就是最好的。