使用velocity来分配资源时间

时间:2013-10-17 19:22:16

标签: agile velocity scrum sprint

关注速度:如何根据速度在下一个Sprint中为具有各种技能的团队分配时间?

团队拥有不同级别的开发人员以及在前端和后端开发方面更熟练的人员。

不同的Sprint对每组有不同的拉力。

对我来说,简单地说'团队'每个Sprint完成100分,然后为Sprint分配10分后端工作和90分前端工作似乎没有意义,实际上它是速度为90分的后端人员和速度为10分的前端人员。

我无法想象答案只是忽视人们的优势。我应该按子队划分速度吗?

3 个答案:

答案 0 :(得分:0)

Velocity是一项团队测量,在不同团队之间进行比较时,这些数字通常毫无意义。如果你把它分解到一个单独的水平会发生同样的事情:一个人的速度不能与另一个人的速度相比。这个概念仅在将项目的一个sprint与另一个sprint进行比较时才有用,因此在项目中间更改测量指标可能会导致您误解结果。

您是否在尝试确定个人的工作效率?您可以衡量其他方式,例如询问其他团队成员是否觉得这个人做得很好,在团队工作中减轻他们的负担等等。

答案 1 :(得分:0)

  

如何根据速度在下一个Sprint中为具有各种技能的团队分配时间?

整个团队就故事的故事点数应达成共识。由于同一个团队将在项目期间确定这些故事点,因此团队的速度应该随着他们的冲刺越来越准确。

是的,一些开发人员会比其他开发人员慢,但如果团队保持不变,那么速度计算将变得更加准确,让您可以对何时传递故事做出合理的估计。

通过子团队分割速度无法帮助您估计何时传递故事,整个团队的速度是关键因素。

  

团队拥有不同级别的开发人员以及在前端和后端开发方面更熟练的人员。

Scrum团队应该由开发人员(开发人员是开发团队中的开发人员,例如软件工程师,测试人员,业务分析人员)组成,他们是推广专家;每个团队成员都应该能够进行后端和前端开发,以及测试,实际上是传递故事所需的一切。是的,在实践中,一些团队成员将拥有专家前端经验(例如),但随着冲刺的进展,应该进行知识共享,以便所有团队成员都能够开发解决方案(例如,通过结对编程,指导,文档( !))。

一个优秀的Scrum大师将鼓励这种知识共享,你可能会发现一些前端开发人员是优秀的后端开发人员,反之亦然!

正是这种概念让开发人员摆脱了公司挣扎的孤岛环境,但这对成功的敏捷/ Scrum团队至关重要。

答案 2 :(得分:0)

scrum团队的规模通常为7或8.如果有专家,2-3可以做后端工作,他们正在燃烧90个故事点。然后风险和对它们的过分依赖。最好分享知识,以便scrum团队中的每个人都了解后端和前端。在最初的阶段,你可以将25-30%的时间放在一边作为加速并提交较少的故事点说60.最后当团队加速时,速度是有道理的。速度总是意味着无论个人专业知识如何,Scrum团队都可以完成多少任务。

但是如果你想保持后端和前端专业知识的不同,可以组建2个独立的scrum团队。然后速度才有意义