引言
传统的项目管理方式下，项目估算是项目计划阶段的重头戏，在在对需求分析进行拆分后，把每个模块根据经验计算出所需人天数，平衡三剑客 - 时间，质量和成本后计算出项目所需时间以及人员数，基本由项目库经理带头和技术专家一起进行估算。
在敏捷的框架下，估算进行的更为频繁，在每个迭代开始时进行估算，估算的方式不再是人天而是故事点数，估算的人员也不再是项目经理，而是整个scrum团队。
如何在敏捷框架下进行估算？在估算过程中一般团队会有什么样的困惑？会落入什么样的陷阱？
敏捷项目估算方法
估算标尺
Scrum里根据用户故事的难易程度进行估算，通常会选择如下的度量标尺在进行估算
- 数字（从1到10）
- 衣服尺码（XS, S, M, L, XL, XXL, XXXL）
- 斐波拉契数列（1, 2, 3, 5, 8, 13, 21）
比较常用的是斐波拉契数列， 其中又集中在用1 - 13的数字进行估算，因为有研究表明，人类大脑比较善于处理第一数量级（即各位）的排序，而斐波拉契数列在第一数量级的基础上又把数字进行了跳跃区分，让大脑更容易做决策。虽然1和2很好区分，但是数字越大比如8和9就会变得很难区分，这时候用8和13就可以提高区分度。有人可能会问，要是有的用户故事比13还大怎么办？可以尝试把这个用户故事拆小。要是用户故事不能再拆小或者还没有到需要拆小的时候呢？那么可以用比价大的数字比如20,40,100。13点以上不建议完全按照斐波拉契数列来列举，因为那些数字（21,34,55）确实不好记，既然是较大的待拆用户故事，用整数来标记也无妨。
扑克估算法
在迭代梳理会议或者计划会议上，可以用玩扑克的方式来进行估算，步骤如下
1. 向大家解释1,2,3,5,8,13,20,40,100的意义是什么。
可以选几个数字定义一下对应的用户故事是什么。比较常定义的是1,3,5。
比如：
如果是第一次估算，和团队一起定义出难度标准，如果不是第一次估算，也需要再次审核以前的标准是不是有所变化
2. PO或者用户阅读用户故事，向团队陈述所期望的功能。
在这期间，团队如果又任何疑问都可以提出，由PO或者用户回答陈清
3. 每个人暗自选择一个扑克点数
暂时保密你选择的点数，手中的卡片必须在同一时刻揭晓。这条规定的目的是防止团队成员间决策的相互影响。
4. 最高和最低点数的人陈清他们点数的原因
原因可能多种多样，有可能是对需求的理解不一致，有可能是对点数的标准有误解，还有可能是对实现的方式有不同的方法。无论怎样，都需要进行陈清讨论，有必要的话还需要记录下来各自的原因，这些讨论的内容很有可能在开发过程中非常有用。
5. 在讨论的基础上重复步骤三进行再次估算，直到团队达成基本一致
估算陷阱
只让少数人参加估算
一周的迭代一般需要2个小时的估算会议，有人会说如果每个人都参加会浪费很多时间。所以有的团队会选择让部分人参加，有可能是资深人员，有可能是团队成员轮流着参加。但是这样的结果是，没有参加会议的人会花更多的时间去理解会议上发生了什么，又或者没有参加会议的人有更好的解决方案，但是失去了在估算会议上提出方案的机会。让所有人参加才是明智之举，因为本身估算就是收集所有人意见的过程，来自各个职能团队的专家们是估算的最佳人选。如果听到抱怨说参加估算会议的人太多影响了效率，那就要考虑是否拆分团队，或者用更为有效的组织形式。
估算结果固然重要，估算过程中思维的碰撞对需求的理解才是更重要的目的。
1 点 = 几个人天？
传统的项目管理会有“人天”作为单位来进行项目估算，在scrum中采用故事点数。那么这两者之间有什么换算关系呢？打个比方，从上海距离杭州200公里，开车3个小时。故事点数好比距离计量两地之间有多远，“人天”好比时间计量需要多久，这两种计量方式的换算是基于速度有多快。200公里的距离，开车是3个小时，坐动车是2个小时。同理，一个1000点的项目，资深团队需要60个人天，一个初级团队可能需要180个“人天”。
如果公司里有人执意要在两者之间进行换算，那么建议取消故事点数的概念，直接用“天数”或者“小时”进行估算。
相对估算 vs. 绝对估算
相对估算，即预先设置一个标准，其余的项与这个标准进行比较，得出一个相对而言的结果，例如，如果我们知道A楼高100米，看上去B楼是它的2倍高，我们可以估算B楼高200，C楼高度在A和B中间，可以估算C楼高150米, D楼的高度也在A和B中间，但是与B楼的高度更接近，那么可以估算D楼高180米
绝对估算，是比较精确的估算方式，即通过工具的辅助，估算出A楼高103米，B楼高194米。
为什么我们在进行故事点数估算是选择用相对估算呢？
- 绝对估算方式并不适合软件项目
用绝对估算固然准确，但是却不适合用作软件项目。因为软件项目基本依赖于人脑，人与人之间水平的参差不齐，每个人每天实际用做编码的时间也不尽相同。况且就算用于编码的时间相同，效率也不一样，再加上项目千变万化，很难有好的标尺来进行绝对估算。与其绞尽脑汁进项绝对估算，不如大概估算且多次估算更准确，更能适合千变万化的项目。 - 相对估算易于让团队中不同能力的成员达成共识
不可避免的是，团队中成员的编码水平参差不齐，对需求的理解也是不可胜举。要是用人天来做估算，势必会出现john说3个人天，Bill说1个人天的情况，这样并不能达成共识。而用相对估算就能解决这个问题，比如假设做功能A故事点数是2，John和Bill都觉得比较而言功能B需要比功能A多一倍的工作量，并且跟功能C有交错的地方可能有风险，那么他们达成共识功能B的点数是5。 - 故事点数将估算与具体的时间概念区分开，也把团队成员的感性情绪排除开。
当成员用人天进行估算的时候，心里活动是这样的：一个人天算多少个小时呢？我们每周都有人请假要多估算点；我们还应该招两个人但是也不知道还要多久才能到位可能需要多估算点；我们团队有两个实习生是不是多留点空间？
在如此多的心理暗示下，还能准确的进行估算吗？要是用故事点数就会排除心理暗示，只是纯粹的对完成功能需要多少工作进行估算。
单一标准衡量故事点数
人们容易认为故事点数即是完成一个功能的工作量，但其实这只是故事点数的一个方面，故事点数应该包含的是开发一个功能要做的所有的努力，它受到复杂度，不确定性，风险，工作量等等各方面因素的影响。
- 工作量
单纯从“量”来考虑，比如一个页面有1个输入项，第二个个页面有100个输入项，那么第二个页面的工作量就是第一个页面的一百倍 - 工作复杂程度
除了“量”，还要考虑复杂程度。比如第三个页面也有100个输入项，但是在这个页面有日期选项，有对数字输入正确性的验证等要求，那么在这个页面的故事点数要明显高于第二个页面 - 风险以及不确定因素
如果一个页面还有不确定因素，那么也要适当的增加故事点数，并且做好风险应对措施。 - “完成”的依附工作
团队会制定“Definition Of Done”，比如自动化测试。在进行估算因为这样附加的工作量而增加点数。
拒绝用时间单位估算
故事点数适合对长远的计划进行估算，但是并不适合近在咫尺的任务估算。
试想下在早会时一下两种说法哪一种更好理解呢？
- “我的任务昨天基本完成，今天还需要一个小时结尾”
- “我昨天完成了2个点，我还剩1个故事点要完成”
显然第一种方式更加具体易于理解。故事点数是大概的相对的估算，对于较长时间段内的项目估算很适合，易于达成共识，但是当我们讨论每天的工作时，用时间更接地气。
常用的做法是，对于一个功能用故事点数进行估算，但是具体怎么完成这个功能拆成任务后用小时或者天数进行跟踪。比如，针对招聘网站上的职位进行条件筛选并查找的功能，故事点数是8。然后前端，后端，测试会把这个功能拆分成不同的小任务，由不同的成员负责完成。后端任务需要6个小时完成，前端任务再拆分成两个，由小王和小李各自做4个小时完成。每天早会更新的时候，每人也会针对自己所在的任务进行更新。
估算膨胀
什么是估算膨胀？
同一个功能，在上个月估算的时候是5个点，但是这个月再估算变成了8个点，并不是功能或者解决方案有变化，单纯只是团队成员估算的时候增加了点数。和货币的通货膨胀一个道理。估算膨胀是如何发生的？
团队有来自外部的压力，要求在这个迭代完成更多的故事点数，或者有人通过故事点数来衡量团队的生产率，所以团队成员会有意识的增加故事点数怎么样防止估算膨胀？
设置至少两个标准，并且在估算是提醒团队与标准进行比较后再给出点数。
如果标准设置的时间太久了，或者开始一个全新的模块需要重新设置标准便于团队成员理解比较。
估算结果 = 承诺？
在本文章中已经澄清过，故事点数只是估算有多少工作量，并不能直接作为团队当前迭代完成多少的承诺。
那么，怎样让团队开始承诺，承诺的依据是什么呢？在这之前，先了解下什么是团队速率Velocity。一个相对稳定的团队，在稳定的环境下一个迭代能完成的故事点数即为速率。这是一个比较理想的定义，在实际操作过程中，比较常用平均速率，在排除掉那些占了长假的或者是团队进行大调整的迭代后算出过去5个迭代的平均速率。
有了平均速率，也有有了承诺的依据，当然平均速率只是一个参照，具体还要考虑团队当前迭代实际情况，比如团队成员要请假，要完成的功能对别的团队依赖太大等等。
敏捷项目可以作长计划吗？
项目经理关心产品估算工作量多少需要多少人用多少钱，老板关心产品什么时候能上线，是否赚钱。所以单个迭代的计划并不能回答老板的问题，我们不可避免的要做长计划。由项目经理一拍脑袋想出个日期？还是试试以下两种办法
- 初始会议
在项目一开始，可以安排一个初始会议，在会议上对项目或者项目的独立功能做估算，与迭代计划会议的估算不同，在初始会议上很可能只是对一个史诗级用户故事进行初略估算，估算的单位也要提高一个量级，比如10,20,30,50,80。然后团队再根据团队的速率来计算出完成需要的时间。重要的是项目发起人以及项目负责人可以从开发团队那里直接获得估算结果 - 产品POC
如果这是一个新的团队，或者连团队都没有并没有历史经验应该怎么进行估算呢？建议用最短的时间，比如半个月做一个产品的POC，根据对产品的了解，还有团队成员间的合作情况再进行估算。
最后
估算的目的是为了更好的做计划，商场如战场瞬息万变，一成不变的计划不是好计划，需要时时调整计划。
Estimation is nothing, Estimating is everything. by no one from 艾森豪威尔