Mic*_*bon 6 agile scrum estimation time-estimation
我习惯于以Joel Spolsky建议的方式思考时间估计 - 如果预定项目需要超过16小时,则应将其划分为较小的任务.现在,我正在我的团队中实施Scrum以及基于Story Points的估算.在我看来,一个故事点的好单位将是理想的工时,而不是人日.如果我用了几天,我的大多数问题都会估计为1/2或1.
你有什么想法,为什么在Scrum文献中最常提到使用理想的人日？
Pas*_*ent 10
在我看来,一个故事点的好单位将是理想的工时,而不是人日.
这句话听起来真的很奇怪,而且不是真的.你在哪里读到故事点和理想的人日之间存在关联？理想的人日可能是在Scrum的早期使用,但对我来说,故事点(SP)是另一回事......
故事点是量化与由多个任务组成的特定产品待办事项(PBI)相关的相对努力的一种方式.一些团队使用数字大小(即1到10的等级)来估计PBI的"大小",其他人使用T恤大小(XS,S,M,L,XL,XXL,XXXL),有些使用斐波那契序列(1,2,3,5,8,13,21,34等).顺便说一下,你注意到SP是无单位的吗？
如果我用了几天,我的大多数问题都会估计为1/2或1.
所以呢？这只意味着你有小PBI,这不是一件坏事(至少不是最重要的).但是不要忘记在Scrum中理论上有两个级别的估算:产品Backlog级别,以点为单位,以及Sprint Backlog级别,以小时为单位.正如我在前一段中所提到的,PBI由任务组成,在Sprint计划会议的第二部分中它们应分成任务.然后以小时为单位估算任务,此处适用16h规则:任务不应超过16小时.如果确实如此,那就太大了,应该分成更小的任务(因为我们在评估大事时太糟糕了).
你有什么想法,为什么在Scrum文献中最常提到使用理想的人日？
无论如何,这已经过时了.事情可能会在未来发生变化,但目前的共识是以无单位估算.点与任何时间单位完全去相关,这是为了避免与现实世界单位进行任何映射,工作量应该用速度来衡量(团队在一次迭代中可以达到的点数).