估算|速度(Velocity)不背这个锅( 二 ) |天数|点数|

2. 基于理想人天的估算
理想人天的估算需要基于这样的假设：

所估算的故事是唯一要做的工作
所有需要的东西在故事开始前都会准备好
故事开发过程中不会被打断。

在不考虑其他因素的情况下，这种理想人天的估算是类似于故事点的估算方法，同样是一种相对大小的估算。
理想时间跟耗用时间是不同的。比如一场NBA比赛的理想时间为12分钟一小节，但是实际比赛耗用时间需要比这个时间长很多，因为中间有暂停、死球等时间。理想人天的估算是基于理想时间的，在软件开发过程中会有多个因素导致实际耗用时间跟理想时间会有很大的不同，比如开会、讨论等。

理想人天的估算方法很容易让人根据一个故事所需完成的任务多少去估算，而不是从这个故事跟其他故事的相对大小角度去考虑；不同人估算的理想人天也会有不同，导致估算可能会不太准确。这在估算的时候是需要特别注意的。
在团队不熟悉故事点估算方法的初期，理想人天的估算方法更容易开始；理想人天的估算对于团队外部人员更容易解释清楚，也更方便预测速度。
哪种方法更好
从前面的介绍可以看到，两种估算方法各有利弊，都是对于用户故事大小的相对度量，不能跟实际完成天数关联起来。通常，更推荐使用故事点的估算方法，根据团队自身情况也可以选择采用理想人天。
03. 什么情况需要重估前面提到的误解里对于用户故事没有在预定的天数内完成考虑给故事涨点，也就是重估，这种以进度来驱动重估的做法是不对的。没有在估算天数内做完可能有两个方面的原因：1. 估算不准确，低估了；2. 被其他工作所打断，或者团队技术原因导致进度较慢...

发现估算不准确的情况可能需要调整，但不能是因为做不完赶不上进度而调整。当所有用户故事的相对大小是准确的时候，不需要重估；只有当其中一个或多个用户故事的相对大小不准确的时候，需要调整该部分用户故事的点数大小。
我们来举例解释这个问题：
1. 不需要重估的情况
假设一个团队有4个复杂度相当的用户故事，原本估算均为3 ，预计能够在一个迭代完成的。在第一个迭代结束后，只完成了其中的两个用户故事，也就是完成了6个点，团队感觉这两个用户故事比预估的要大，想调整为原来点数的两倍，由6变成12；由于四个用户故事的大小相当，剩下的两个用户故事也需要调整为原来的两倍，剩下的工作量也变成了12 ，同样的可能还需要一个迭代才能完成。这样的重估就没有意义。
因此，如果只是发现用户故事实际耗费时间比原来预测的要多，但是故事的相对大小并没有问题的时候，不需要重估，而是要去回顾和分析耗费时间长的原因，并采取相应的措施去改进。
2. 需要重估的情况

假设团队由A、B、C、D四个用户故事，刚开始给每个故事的估点均为3 。在开发故事A的过程中发现A比原来估算的值要大，需要调整为5才合适，另一个类似的故事B也是一样，需要调整为5；但是C和D跟它们不一样，估算值应该是准确的，还可以保持为3 。这种情况下对A和B的重估是有价值的，因为相对大小发生了变化。

本文插图

04. 速度的作用速度是对团队的进度生产率的度量，可以通过计算团队在一次迭代中完成的用户故事所分配的故事点数的总和来得到。比如，完成5个3个点的用户故事，速度是15；如果完成了2个5个点的用户故事，速度是10 。关于“完成”的定义不能只是到“开发完成” ，而应该是“交付完成” ，开发完成不能说明什么，可能后续测试还不能过关、有很多缺陷需要修复等情况。