一文说通用户故事点数是什么？
第26期：一文说通用户故事点数是什么？
用户故事点数是一种采用相对估算法进行估算的一种工具，一般采用斐波那契数列表征用户故事里说的大小，采用0 1 2 3 5 8 13这样的一些数字来表征用户故事的大小，那么用户故事点说到底是什么？
我们在实现过程当中看到很多人理解的都是错的。为了能够澄清什么是用户故事点数特编写本文，以澄清视听。
01
用户故事点数和绝对工时没有关系
用户故事点数是一种相对估算的单位，它表征了一个用户故事和另一个用户故事之间的开发规模的相对关系，而并不表示它的绝对规模。
用户故事点数和实际的工时没有任何的比例关系。
以镶地砖为例，镶两块地砖的工作量是镶一块地砖的工作量的两倍，这个和是张师傅来镶还是李师傅来镶是没有任何关系的。
在一些开发团队当中，会把用户故事点数和工时进行一个比例设定，这个设定是错的。
这个设定会导致了工作量失去了比例关系，而依赖于个人的生产能力。
同一个功能，不同水平的师傅来干，工时需要的不同，如果绑定这个关系则失去了相对估算的意义。
02
用户故事点数表示了团队的效率提升
每个迭代可以交付的用户故事点数合计表示了团队的速率。
如果按照绝对工时作为度量单位，那么一个人一周只有40小时的工作时间，这是一个无法通过个人努力或者团队努力而改变的客观约束。
那么，在绑定故事点数和绝对工时的前提条件下，就无法表征出团队的持续改进情况。
而采用和绝对工时无关的故事点数是可以表征出来团队的改进情况的。
比如说，一个团队，每周原来可以生产100个故事点数，而经过改进之后，在原来的同样的估算体系下，已经可以每周交付120个故事点数的任务。那么这表示，团队提升了20%。
但是如果采用了故事点数和绝对工时绑定的情况下。
原来一个团队，一周可以交付200个工时（5人x40小时）的任务，现在一周可以交付240个小时的任务，那么反而表明这个团队通过加班来完成任务，实际效率下降。
这是一种错误的估算方式。
所以，采用这种把用户故事点数和绝对工时绑定比例关系的团队，有这么几种原因:
-
不懂什么是用户故事点数
-
对持续改进没有追求
这样的团队，趁早放弃敏捷比较好。
【特殊情况】
如果遇到特殊情况，上述速率公式仍然可以表征团队的实际效率。比如，工程师小张这个迭代休假了，团队从5个人变成4个人，交付的总故事点数从100变成了80。
但是速率没有变化，以两周迭代，每人80小时为例。
速率没有变化
【不同的工程师速率就是不同的】
的确，不同的工程师开发速率是不同的，很多人对此有疑惑。
不同的工程师开发同一个功能效率可能差上几倍乃至几十倍。相对估算是不是表征不了这个特点。
不是的。
假设小张的速率是，每天可以交付8个故事点数，而小李可以交付12个。
那么
可以很客观的反应二者的效率差，也能够表明改进的着力点。
之后小张的速率提升了，那么整个团队就提升了。
03
杂项要不要纳入工时统计
团队除了开发，还有很多杂项，那么统计工时作为分母的时候，要不要把这些杂项纳入工时统计。
和加班一样，所有团队花费的工时都要纳入统计。
同样的，如果遇到节假日，工时缩短也一样处理，这样才知道应该怎么进行改进，比如杂项占用时间太多，那就应该想办法减少杂项所耗费的时间。
