学院网站建设管理,做数码后期上数码网站,深圳网架制作,wordpress 代码解析一文说通用户故事点数是什么#xff1f; 第26期#xff1a;一文说通用户故事点数是什么#xff1f;
用户故事点数是一种采用相对估算法进行估算的一种工具#xff0c;一般采用斐波那契数列表征用户故事里说的大小#xff0c;采用0 1 2 3 5 8 13这样的一些数字来表征用户…一文说通用户故事点数是什么 第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
杂项要不要纳入工时统计
团队除了开发还有很多杂项那么统计工时作为分母的时候要不要把这些杂项纳入工时统计。
和加班一样所有团队花费的工时都要纳入统计。
同样的如果遇到节假日工时缩短也一样处理这样才知道应该怎么进行改进比如杂项占用时间太多那就应该想办法减少杂项所耗费的时间。
