01. 那些对速度（Velocity）的误解
误解1 – 点数跟天数对应？
用户故事的估点跟天数对应，1个点的故事对应2天的工作量；
统计每个用户故事所耗费的天数，如果点数对应的天数到了，先标记为“开发完成”，第二天Desk check就不用增加天数了；
为了赶进度，由结对改为不结对，原来结对的两人并行做不同的task，天数还是按照结对的情况来统计…
问题：
- 虽然按照故事点来估算，但是每个点都跟天数对应起来，而且不是理想人天，是实际耗费人天；
- 把这种估算当做一种承诺，要求故事需要在点数对应的天数内完成；
- 用户故事的只是关注开发完成。
到底该如何估算？点数又该如何使用呢？
误解2 – 做不完了给用户故事涨点？
如果用户故事没有在预定的天数内完成，需要涨点，那么得先说服客户；
列出涨点原因并且跟客户解释不是一件容易的事情，团队有时候宁愿加班加点按照原来的估点完成也不要去跟客户解释…
或者，为了避免以后涨点的各种麻烦，在估算的时候多估一些点，导致估点不准确…
问题：
- 开发团队的估算不应该受到外部因素的影响；
- 虚估点导致的估算不准确失去了估算原本的价值和意义。
估算的意义是什么？什么时候需要调整点数进行重估？
误解3 – 速度驱动一切？
周报里的速度保持稳定，每周每对pair在2个点上下；
性能调优，客户觉得目前看不到价值不给点，所以团队就不做了；
技术改进，同样的，客户看不到价值不给点，就不做了；或者团队实在无法忍受想要改进，那就从别的功能用户故事里多估算一些点来留时间给做技术改进；
目前组内开发速度不够，用户故事都做不完了，生产环境的support能给别的组就给别的组做吧，那个太耽误开发进度了！
问题：
- 一切围绕速度，如果比较顺利，满足了速度要求，团队可能就放松了，不一定会做更多的特性开发；如果不顺利，速度赶不上，那就可能面临着加班或者愁着怎么能给故事涨点以增加速度；
- 不再是业务价值驱动，不会正常的从价值的角度去考虑工作的优先级，速度被严重的误用。
速度有什么用？又该如何利用呢？
带着这些误解中引发的疑问，我们一起来探讨一下。
02. 两种估算方法
1. 基于故事点的估算
故事点是纯粹对用户故事大小的相对度量，不应该跟任何的天数或者工作量等关联。
用户故事本身的大小属性不会发生变化，基于故事点的估算不会过期，不会受到团队技术能力和业务领域熟悉度的影响而发生变化。比如，一个点数为3的用户故事，它的复杂度相对于那个点数为1的基准故事来说不会发生变化，不管谁、也不管用什么技术来开发这个用户故事。
故事点的大小是指团队所有角色工作加一起的统一估算数值，需要多个角色一起合作讨论才能得出这个估算，因此，故事点的估算方法有利于帮助团队实现跨功能合作的行为。特别注意，不应该按照开发的点数、测试的点数去估算用户故事的大小，需要结合一起给出一个唯一的数值。
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。关于“完成”的定义不能只是到“开发完成”，而应该是“交付完成”，开发完成不能说明什么，可能后续测试还不能过关、有很多缺陷需要修复等情况。
速度可以修正计划的误差。估算把对工作量的估算和对工作时长的估算完全隔离开来，将必须完成的所有用户故事的点数总和除以迭代的速度，可以推算出迭代的次数，也就是项目持续时间。我们通过一个例子来看速度如何修正误差：
假设团队估算出项目中包含了200个故事点的工作，一开始认为可以在每次迭代中完成25点，也就是将用8次迭代来完成工作。但是，在项目开始以后，团队发现速度只能达到20点。这样，不用对任何工作进行重估，就可以正确的认识到项目需要10次迭代，而不是8次。
速度不会是稳定不变的。根据团队对技术和业务领域知识的熟悉程度，速度可能会增加；而随着团队人员调整，有新人加入以后，速度可能会下降。在故事点估算准确的情况下，速度正好是反映团队状态的一个参数。不应该为了保持速度的不变去调整估算的结果，而应该根据速度的变化来观察和分析团队的健康程度。
05. 估算与计划
估算是为了更好的做计划，通过估算推算出的持续时间是一种可能性，而不是对交付时限的一种承诺。估算的是用户故事固有的属性，其大小不应该受到交付时长的干扰。老马在文章《WaterfallProcess》里讲到敏捷开发里的计划应该是适应性的，而预测性的、承诺性的计划不属于真正的敏捷。我们需要认真做好估算，尽量的准确，利用速度并根据团队状态和其他项目因素来适时地调整、修正计划。
客户都会希望更短的时间交付更多的功能，但是不要让客户只把目光关注到进度上，要引导客户更多的关注交付的业务价值。因此，在考虑任务的优先级的时候，需要以价值为导向，而不是进度为导向。比如，重构等技术改进、性能调优、生产环境的支持，这些可能比新的特性开发带来的价值更大、有着更高的优先级。
06. 小结
- 不管是故事点还是理想人天的估算方法，估算的都是用户故事的相对大小，跟实际完成时间没有直接关系。
- 不能因为用户故事没有在预期的时间内完成而进行重估，只有相对大小发生变化的时候需要重估。
- 估算是为了更好的计划，不能把估算当做一种承诺；速度是可变化的，可以用来修正计划的误差。
- 始终要以价值为导向，更多的关注质量而不仅仅是进度，计划应该是可适应性的。
07. 参考文献
- 《敏捷软件开发实践：估算与计划》，作者：Mike Cohn，译者：金明
- 《点之殇》，作者：冉冉，https://insights.thoughtworks.cn/story-point/
- 《WaterfallProcess》，作者：Martin Fowler，https://martinfowler.com/bliki/WaterfallProcess.html