Scrum 学习篇 -- Backlog之浅析 （二）

3.  除了优先级外，还有一个设置也是非常重要的，就是对于每个任务，你需要做工作量预估，预估什么呢，预估该任务开发完成所需的时间和人力等，敏捷里把这个预估叫做Story Point，故事点。

故事点这个概念现在争议很多，究竟以怎么样的方式来预估工作量呢？

（1） 有人说用小时，但是我们知道能力强的人跟能力弱的人所用的小时数必然是两样的，所以通过小时来得到故事点并且进而得到Velocity数据是不正确的。

（2） 也有人说按照困难度，但是困难度只能比较每个迭代中完成功能的困难程度，而无法去预判开发的速率趋势。

（3） 也有人说，与其花时间讨论这些，还不如直接分任务做了，这样才敏捷了。那么这样真的是敏捷吗？这样当然不是敏捷了，敏捷还需要一定的预判与分析，不然就不是敏捷，而叫做无序了。

 

那究竟何种方式能正确的呢？我是觉得还是按照各个公司的实际情况，比如，

（1）你们公司团队。而如果你们团队水平比较均衡，就可以时间，因为水平差不多，对于任何一个功能完成的时间是差不多的。

（2）当然，如果你们公司水平相差比较多，这个时候就可以用困难度了，就像跳水比赛一样，有很多标准的困难度。

 

假设我们现在已经选好了适合我们的方式，那怎么才能正确地得到这个故事点数的数值呢？

既然这个是估值，那我们就需要评估，谁来参与评估呢？答案是有直接负责这些功能的团队来负责估值，在估值中水平高的人和水平低的人需要进行一些讨论，在确定这个功能的数值。

 

而对于已经讨论产生的数值，开发人员就得承诺在讨论出来的时间内完成，因为既然是自己讨论出来的，当然能够按时完成，不然就太没面子了，而Backlog恰恰通过这个故事点估值来让大家产生按时按量完成的动力，所以很多时间自愿加班就变得很正常。

 

当然自愿加班是对估值的一种损害，所以下一次的估值需要对这种损害进行修复，也就是需要对之后的估值多更加仔细的考虑。

 

通过这种估值以及其不断修复而得到速率分析与预判是相对比较正确的。

（未完待续）