对于估点这个事情，我一直以为是一件理所当然，大家都理解的事情，也没有去深究它。但最近经历的种种推翻了这种“我以为”，想了想，以5W1H的方式来阐述估点再合适不过了。

WHAT-什么是估点

估点是敏捷软件开发中的一个实践或者环节，是指对一个Epic/故事卡/开发任务进行的规模估计，我们通常以故事点来作为规模的度量单位。本篇博客主要是讲项目交付过程中故事卡的估点。

WHY-为什么要估点

在软件开发过程中，我们常常会被问到以下这些问题：你们计划什么时候上线？开发完这个功能你们需要多少人力、多少时间？这个迭代你们要做哪些故事卡？这些问题实质上是项目规划问题，他和我们的开发速度以及功能（故事）规模紧密相关。这也是为什么我们需要估点的理由。

WHO-哪些人应该参加估点

理想情况

在敏捷开发中，一个需求从产生到发布上线，会经历需求分析、开发实现、测试等多个阶段，对一个故事的估点包括与之相关的所有工作的规模。如上文提到，估点主要用于规划，故估点一般是项目启动初期或迭代启动前，在估点的时候我们并没有确定这个故事卡是由谁来开发、测试等。综上两点，估点需要团队内的所有参与故事点分析、开发、测试的人参加。

实际项目

以我为数不多的几年工作经验，经历和所见的多个项目为例，估点的时候都是估计开发的工作量，所以是所有开发参加，外加一个主持人，大多是BA，因为要澄清故事卡内容，QA可视情况参加。

WHERE-在哪儿进行估点

这个W存粹是为了凑5W，估点也是一个会议，和一般会议一样，线上、线下都可以。

WHNE-什么时候估点

结合估点的原因，我们不难得出，估点需要在一个新的迭代开始前，因为有了估点，有了迭代开发速度，我们才能得出一个迭代能开发哪些故事卡，才能安排迭代内容。在我经历的项目中，估点的时间和形式都所有差异。
1.迭代中间专门组织估点会议
当BA和TL把一个需求方案分析完成后，会专门组织一次估点会议。这样的优点就是当我们分析完一个需求的时候，我们就可以很快的知道它的规模，然后把它放入backlog，在安排迭代内容的时候就很容易了。缺点就是估点时间不固定，很容易打断开发的工作时间。
2.在迭代后期组织大家估点
基于第一点的改进，在迭代中后期集中一次澄清最近的需求，组织一次估点。这个项目的背景是，项目进入平稳期，没有太多技术挑战的需求。这样的优点是尽量减少打扰大家的次数，缺点是一次会议时间会比较长，而且估点太滞后，如果出现争议点，修改时间就很紧张，BA的压力会比较大。
4.在迭代启动会议的时候估点
这个项目的背景是每次release的内容基本固定，人力比较充足，迭代内容比较确定，不需要提前根据故事卡规模安排迭代内容。所以在迭代启动会议的时候，BA先澄清故事卡，然后开发同学估点。这样估出来的点的目的是监测开发速率，帮助识别进度风险，对提前安排迭代内容没有太多意义。
5.团队核心成员估计后再由全体成员估计
在迭代开始前，组织团队核心开发，比如TL、经验丰富的开发先估一轮点，以此作为迭代安排的依据。在迭代启动会议上，再由郑哥团队一起估点，再调整迭代内容。一般来讲，这次的估点和第一次的估点差异不会太大，之所以要让大家再估一次，就是要让每个人都发表自己的看法。

以上可见，估点的时间点是根据项目的不同而不同的，需要结合项目的实际情况而定，只要满足各方的需求即可。

HOW-怎么估点

以上，估点的准备工作做好了，现在正式开始进入估点会议。
1.第一步：定义估点方法
通常有两种估点方法，故事点估点法和理想日估点法。

故事点估点法估计的是一个故事的复杂度，先找一个较小的故事卡作为标准故事卡，将其规模定义为1个故事点，之后的故事卡估点以它为参照，估计为2、3、5…最后出来的故事卡的规模，应该是2个故事点的故事卡的规模比1个故事点的故事卡大，比3个故事点的小。由此可见，故事点的大小是相对的。那么问题来了，这么估出来的故事点怎么应用到迭代安排中？怎么知道我该排多少故事点到迭代中？这就需要结合迭代速度（一个迭代完成的故事点数）来计算了，对于迭代速度的计算，可以是参考项目以前的，可以根据经验猜测，也可以以第一个迭代作为试验来估算。

理想日估计法是我们常用的。即每个人估算这个故事卡需要多少个理想人天（没有任何其他事情干扰的情况下）可以做完。这样可以直接省略故事点转换成人天的步骤，大家也更容易理解。但是这样的故事点容易过期，随着项目的变化以及团队成员对业务的熟悉程度，一个理想人天能做的事情是随之变化的。

2.第二步：约定估点尺度
通常我们使用斐波拉切数列来进行估点，即1、2、3、5、8、13…理由如下：
（1）估点只是对故事卡的大致估计，往往故事点越大说越不准确，越大的故事卡我们估计的点数越大，斐波拉切数列越往后间隔越大正好契合这一特点。
（2）如果点数越大间隔不越大的话，就会出现同一故事卡不同的人估计出5、6、7、8个点的情况，大家的争议也比较大。但其实结合第1点来看，这种1个点的争议价值并不大。所以约定使用斐波拉切数列可以减少这样不必要的争议。
3.第三步：差异处理
如果对同一个故事卡大家的估点不一致，这时需要让他们说出自己估点的理由，因为每个人的视角是不一样的，看到的东西也不一样，澄清之后再次估点。如果这样几轮下来仍不一样，可以视情况按取大的处理或者少数服从多数。

标签：你学,迭代,故事,项目,估点,估计,开发
来源： https://blog.csdn.net/qunyaoaiziji/article/details/117624084