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

不管是故事点还是理想人天的估算方法，估算的都是用户故事的相对大小，跟实际完成时间没有直接关系。估算是为了更好的计划，不能把估算当做一种承诺；速度是可变化的，可以用来修正计划的误差。
01. 那些对速度的误解

本文插图

误解1 - 点数跟天数对应？ 用户故事的估点跟天数对应， 1个点的故事对应2天的工作量；
统计每个用户故事所耗费的天数，如果点数对应的天数到了，先标记为“开发完成” ，第二天Desk check就不用增加天数了；
为了赶进度，由结对改为不结对，原来结对的两人并行做不同的task ，天数还是按照结对的情况来统计...
问题：

虽然按照故事点来估算，但是每个点都跟天数对应起来，而且不是理想人天，是实际耗费人天；
把这种估算当做一种承诺，要求故事需要在点数对应的天数内完成；
用户故事的只是关注开发完成。

到底该如何估算？点数又该如何使用呢？
误解2 - 做不完了给用户故事涨点？ 如果用户故事没有在预定的天数内完成，需要涨点，那么得先说服客户；

列出涨点原因并且跟客户解释不是一件容易的事情，团队有时候宁愿加班加点按照原来的估点完成也不要去跟客户解释...
或者，为了避免以后涨点的各种麻烦，在估算的时候多估一些点，导致估点不准确...
问题：

开发团队的估算不应该受到外部因素的影响；
虚估点导致的估算不准确失去了估算原本的价值和意义。

估算的意义是什么？什么时候需要调整点数进行重估？
误解3 - 速度驱动一切？ 周报里的速度保持稳定，每周每对pair在2个点上下；
性能调优，客户觉得目前看不到价值不给点，所以团队就不做了；
技术改进，同样的，客户看不到价值不给点，就不做了；或者团队实在无法忍受想要改进，那就从别的功能用户故事里多估算一些点来留时间给做技术改进；
目前组内开发速度不够，用户故事都做不完了，生产环境的support能给别的组就给别的组做吧，那个太耽误开发进度了！
问题：

一切围绕速度，如果比较顺利，满足了速度要求，团队可能就放松了，不一定会做更多的特性开发；如果不顺利，速度赶不上，那就可能面临着加班或者愁着怎么能给故事涨点以增加速度；
不再是业务价值驱动，不会正常的从价值的角度去考虑工作的优先级，速度被严重的误用。

速度有什么用？又该如何利用呢？
带着这些误解中引发的疑问，我们一起来探讨一下。
02. 两种估算方法

本文插图

1. 基于故事点的估算
故事点是纯粹对用户故事大小的相对度量，不应该跟任何的天数或者工作量等关联。
用户故事本身的大小属性不会发生变化，基于故事点的估算不会过期，不会受到团队技术能力和业务领域熟悉度的影响而发生变化。比如，一个点数为3的用户故事，它的复杂度相对于那个点数为1的基准故事来说不会发生变化，不管谁、也不管用什么技术来开发这个用户故事。

故事点的大小是指团队所有角色工作加一起的统一估算数值，需要多个角色一起合作讨论才能得出这个估算，因此，故事点的估算方法有利于帮助团队实现跨功能合作的行为。特别注意，不应该按照开发的点数、测试的点数去估算用户故事的大小，需要结合一起给出一个唯一的数值。