BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

用户故事点数的依据是复杂度还是时间?

| 作者 Vikas Hazrati 关注 0 他的粉丝 ,译者 王瑜珩 关注 0 他的粉丝 发布于 2010年7月9日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

很多敏捷团队将故事点和复杂度点作为同义词来使用,他们相信这比使用“小时”更好,因为这些点数是基于复杂度和相对大小的Mike Cohn则表示,使用故事点来描述特性的开发复杂度是不对的,应该使用工作量。

Mike提到:

我发现太多的团队认为,故事点应该基于用户故事或特性的复杂度,而不是开发所需的工作量。这些团队通常将“故事点”定义为“复杂度点”,这看起来不错,可能还更精确,但却是错误的。故事点与特性的复杂度无关,而与开发特性所花费的工作量有关。

Mike给出了一个有趣的例子,他比较了舔1000枚邮票和做一个简单的脑外科手术。Mike认为,抛开复杂度上显而易见的不同,这两件事应该有相同的故事点数,因为它们需要花费相同的时间。

Scrum Development group上有一个类似的讨论.Adam Sroka提到,为了能够比较稳定的测量velocity,团队需要测量的数据能够接近所耗费的时间。因此,故事应该基于相对工作量,而工作量应与花费的时间有关。

但是,这并不意味着应该以小时为单位进行估算。许多人已经发现以小时为单位的估算是一种浪费,而且也不准确。Mark Levison说到:

估算本身就是浪费。使用小时进行估算则更加浪费,人们花费几个小时去讨论细枝末节,还不如赶快开始工作。虽然使用点数进行估算也是浪费,但为了可以使项目的进度更加易于预测和透明,用户故事应该大致上有相同的大小,再加上一定的差异。对于大多数(成熟或者不成熟的)团队来说,这并不容易,因此他们需要故事点。

Jeff Sutherland也比较了故事点与基于小时的估算。Jeff说:

估算故事点比小时更快速、更好也更经济,高效团队会完全弃用任何以小时为单位的估算,因为他们认为这是一种浪费,只会拖慢他们。

Mark Kilby提出,应该确保那些新接触敏捷的人不会假设故事点=工作量=小时。Mark认为,在决定故事点时,虽然工作量很重要,但还需要充分考虑不确定性。Mike则同意点数和小时之间不存在等价关系

Mike还说

或许我们可说,点数是工作量、风险和不确定性的函数,SP=f(E,R,U)。(如果你愿意,也可以把其中一个称为复杂度,但这不重要。)重要的是,点数是关于工作量的估算。风险、不确定性、复杂度、未知因素以及其他相关的事,仅当他们会影响工作量时才应被包含进去。如果某些事确实很复杂,但却不会影响实现特性所花费的时间,那么复杂性就不应该对估算产生影响-这才是故事点。

因此,故事点应该基于工作量,而工作量应该考虑风险、复杂度、未知因素等等。关键是明白故事点要回答的问题。就像Mike说的:

估算的目的是回答如“什么时候才能完成?”或者“到某天为止我们可以得到多少功能?”这样的问题。如果这确实是真的,那么不管用什么单位、什么途径进行估算,都必须是与时间相关的。

点击查看相关的讨论。

查看英文原文:Do Story Points Relate to Complexity or Time?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

最大的“不确定性”就是人! by 高 翌翔

客户和投资人最关心的的就是“何时可以交付高质量的软件产品”

传统开发过程中,常常会绘制“甘特图”,结果常常是计划赶不上变化,项目一再延期,计划一改再改,
大量的资源浪费在计划的制作和维护上。最终,计划对于实际的项目进度似乎毫无作用!

在敏捷开发中,“计划”变成了“估算”,计划中的“人天、人月”变成了的“故事点”!
在代码中,那些硬编码的整数被称作“幻数”(magic number)——“幻数”会使人抓狂!

当前“故事点”的现状与“幻数”颇有几分相似,因为它让大家开始抓狂了!

就像Mike说的,故事点是工作量、风险和不确定性的函数,SP=f(E,R,U),并且是与时间相关的。
——我完全同意 Mike 的观点,但是 Mike 回避了一个关键问题,即f(E,R,U)如何实现?!
退一步,说,假设 f(E,R,U) 已经实现了,而且 SP 的单位是分钟,多么完美,还有什么问题么?

当然有,问题就出在 (E,R,U) 上,就是输入参数,输入参数会直接影响故事点的计算结果!
而输入参数中必须有与人相关的参数,而个体之间的差异性产生了“不确定性”。

这个不难想象,大师与新人之间的工作效率、代码质量、技术能力可谓天壤之别。
对于同一个故事,先后输入大师、新人,计算出的故事点多数情况下是不同的!

由此导出一个有趣的推论,成员间个人能力相近的团队,计算出的故事点可信度越高,
而成员间个人能力相差悬殊的团队,计算出的故事点可信度偏低!

不过,一系列敏捷实践促使敏捷团队成员间的个人能力差距逐渐缩小!

注意:上面假设 f(E,R,U) 已经实现了,实际情况又如何呢?!

Re: 最大的“不确定性”就是人! by 瑜珩 王

首先,计划并没有”变成”估算,估算仍然是计划的一部分。点数和“人月”,“人天”的区别在与,在一开始你是不知道一个“点”到底要花费多少“人天”。你需要真正去做,然后去测量,然后才能得到一个(相对准确的)答案。而用“人天”,则在估算的时候就已经假设了生产率。


对于story X,A可能估算1人天,B可能估算2人天;而story Y,A可能估算2人天,而B估算4人天。A和B可能因为水平、技能的差异,需要不同的时间来完成相同的任务,但是对于同一个人来说,不同的story之间的相对大小是一致的。不管A来估算还是B来估算,Y都需要2倍于X的时间来完成。因此如果有一个story作为基准,A和B是可以达成一致的。如果用人天来做单位显然不可能。

Re: 最大的“不确定性”就是人! by 瑜珩 王

估算的最大特点是“不准确”,如果非要用什么函数去计算,力求一个准确的、精确的数字,那就是违反了估算的本意,也违反了自然规律。

点数的可信度在于相对大小,2个点的story应该大致需要花费两倍于1个点的story的工作量或时间,这时对于同一个人或者说相同水平的人来说的。看估算是否准确,应该从宏观的角度去看,微观的比较是没有意义的。

Re: 非常感谢您的指教 by 高 翌翔

首先感谢王老师的耐心解释 :)

本人是敏捷开发爱好者,对各种敏捷实践很感兴趣,但从未参与过实际的敏捷团队开发,
表述中难免谬误,还请王老师赐教。

计划”变成了“估算”——确实是个大错误,其实我想表述的本意是“绘制甘特图”被“估算”所取代。
在敏捷开发中,迭代计划发生在每次迭代的起始阶段,是与开发交替进行的。

如您所说,一个“故事点”需要多少时间,需要对实践开发项目进行跟踪、测量后方能得出一个“故事点与相对时间关系的经验参考值”。
而用“人天”,您说“在估算的时候就已经假设了生产率”,对于我所参与过的一些项目,
“生产率”是由项目经理根据以往项目经验臆测出来的,这种臆测虽然没有准确的经验数据作为参考,
但也并非凭空想象出来的,只是估算的误差通常较大!
当然,只要对项目进行持续跟踪地、测量,非敏捷项目同样可以得出一个“生产率经验参考值”。
——无论哪种“经验参考值”,都须从实践中获得!

对于story X,A可能估算1人天,B可能估算2人天;而story Y,A可能估算2人天,而B估算4人天。
——这是王老师给出的例子,并得出“对于同一个人来说,不同的story之间的相对大小是一致的”的推断。
我想这个例子本身就是为了得出您的推断而构造的一个假设。

如您所说“A和B可能因为水平、技能的差异,需要不同的时间来完成相同的任务”,
但不同的 story 对于不同开发人员是否具有一致的相对大小呢?!

不妨把您的假设修改一下:
对于story X,A可能估算1人天,对于 story Y,A可能估算2人天(把关于A的假设调整到了一起)
对于story X,B可能估算2人天,对于 story Y,B估算1人天(改动了,因为恰巧B在前一个项目中实现了类似功能)。
此时,不同的story之间的相对大小不是一致的了,而是针对不同开发人员变成了倒数关系(1/2 和 2)。

我不想抬杠,只是基于假设得出推理难以服人。

其实,如上所述,无论哪种“经验参考值”,都须从实践中获得!
而实践的主体恰恰是“人”,“人”站到了问题的中心,而人的差异性又使得问题的不确定性大大增加了!

Re: 关于估算! by 高 翌翔

估算的最大特点是“不准确”。
——赞同王老师的观点。
估算表示允许误差的存在,但是误差的大小直接关系到估算结果的有效性,
即误差值与有效性成反比,只有误差值在可接受的范围内,估算才是有效的,
否则,估算不如不算,嘿嘿

我想 Mike 的 SP=f(E,R,U) 并不想求得一个准确的数字,
而是想表明:点数受到工作量、风险和不确定性等多种因素的影响,是值得关注的研究点!

点数的可信度在于相对大小。
——完全同意。
有两个问题:
问题1:“故事点与相对时间关系的经验参考值”是否每个项目都要重新测量?
问题2:故事点为 1 点的 Story 是如何识别或定义的?

另,当王老师说--估算的最大特点是“不准确”--这使我联想到“模糊数学”四个字,不过俺没学过。
查了下互动百科的词条,觉得“故事点数的估算”问题应属模糊数学中模糊决策或模糊评判的研究领域,
而模糊数学正处于发展之中。
如果在“故事点数的估算”中引入模糊数学模型,那么对于提高估算的有效性和可操作性上会大有帮助!

Re: 非常感谢您的指教 by Sandy Chu

Arnold Gao说的有道理:)
估算只是个估算,仅此而已.
事实证明,做软件不是工厂生产,估计要准确无误是不可能的.

Re: 非常感谢您的指教 by Chen Archie

单个故事点和时间是没关系的,最重要的的是第一个放入需求池中的故事,以后每个放入的故事都是以这个为标准,进行相对的评估。
每次迭代计划只是确认本次迭代的速度,即每次迭代完成多少点的故事,并按速度选择本次迭代要完成的故事,也就是说故事点是通过团队速度来和时间扯上关系的,故事点、速度、和迭代时间三者只有速度是可变的,团队通过变更速度来调整项目的进展状态。可见在评估时,故事点和时间没有任何关系,只需要关注故事间相对的规模即可。

Re: 故事点为 1 点的 Story 是如何识别或定义的? by 高 翌翔

由于本人没有敏捷实践的经验,对于“故事点为 1 点的 Story 是如何识别或定义的?”不甚理解,还望赐教!

注:在“关于估算”也提到了此问题。

Re: 关于估算! by 瑜珩 王

问题1:“故事点与相对时间关系的经验参考值”是否每个项目都要重新测量?
问题2:故事点为 1 点的 Story 是如何识别或定义的?

1. 你自己也说了,每个项目的人不同,他们的水平、经验、技能也不同,这本身就带来了很多不确定性和变数。那么上一个项目的系数也就不能作为这个项目的系数。另外,在不同项目中,1点所代表的工作量也是不同的,也没有必要相同。

2.不一定非要找1点的,也可以找3点的。关键是要找一个比较基准,其它story的大小根据这个基准来确定。也可以找几个基准的story。
比较流行的两种点数分布是:1 2 4 8 和 1 2 3 5 8。前一种就是2倍关系,第二种是加和。比如你找一个基准的story,说它是2个点。那么那些比它大一倍的就是4,小一半的就是1。

选择基准时,要找那些比较容易达成一致估算的,大小属于所有story中接近大多数story大小的。如果你的story大小差异比较大,就是story划分的不好了。

Re: 非常感谢您的指教 by 瑜珩 王

不妨把您的假设修改一下:
对于story X,A可能估算1人天,对于 story Y,A可能估算2人天(把关于A的假设调整到了一起)
对于story X,B可能估算2人天,对于 story Y,B估算1人天(改动了,因为恰巧B在前一个项目中实现了类似功能)。
此时,不同的story之间的相对大小不是一致的了,而是针对不同开发人员变成了倒数关系(1/2 和 2)。

---------------------------
估算应该一起估算,达成一致,而不是个人估个人的。即使发生你举的例子中的情况,如果A实现这个功能,为什么不能让B来帮助讲解一下经验呢个?

须理解,不管是开发还是进度,都是团队的,要测量也是宏观测量团队的数据,而不是个人。微观管理或者太计较细节,就会让你偏向“精确“一方,而丢失了估算和计划本身的“不精确”性。

Re: 明白了,真正发挥团队的力量! by 高 翌翔

再次感谢王老师的耐心教导 :)

正如敏捷宣言所说“人和交互重于过程和工具”,团队一起进行估算正体现了这一点。

正是协作与分享促使敏捷团队不断成长,希望有机会我能成为敏捷团队的一员!

Re: 从实践中获取答案! by 高 翌翔

正因为我缺乏相关的敏捷实践,才导致了诸多疑惑。

故事点最终不应基于时间 by Tseng Joseph

我加上“最终”是因为,在缺少scrum经验的团队的第一个sprint容纳的故事点数是需要用实际的时间来估算的。比方说4个故事点一个人天(团队当前的平均水平),据此推算出第一个sprint包含多少故事点为宜。

在以后的迭代中,应该用若干典型的故事所包含的故事点作为相对规模去估算未完成的故事的工作量,而抛弃时间的对应关系。

绑定时间的最大问题是:随着团队对业务熟悉程度、技术能力的进步等因素,团队的速度通常会增加。

如果估算时不考虑速度增加,一个故事点所用的时间不再是2个小时,可能只需要1.5个小时就完成了,这样不同的对应关系会引起混乱;如果考虑到速度增加,仍然把2个小时的时间作为一个故事点来度量,那么速度的提升就变得很不透明,极不利于及时反馈。而及时反馈则是迭代最重要的目标之一。

因此,不如让故事规模固定,但避免与时间对应,而使用“昨日天气”(即上个迭代的实际故事点完成数量)和团队估算的加速度估算本次迭代能完成的故事点数。

Re: 最大的“不确定性”就是人! by 柳 永法

Good,也就是说起点不是时间,就是点,是“故事点”,我不管各位一个故事点要用多久,现在不考虑这个问题。
要考虑的是,大家都知道这只代表一个 基点 故事点,然后所有人的评估,都是用类比来判断的,拿新的故事点跟这个基点对比。

这样一来,是可以解决故事点评估差异较大的问题。

关于一个点要花费多少“人天”,需要在各个Sprint里实践后得出,
Sprint人天/Sprint Story Point ==1个Story Point所用人天==X

下一个Sprint人天是固定的假设为Y,所以下一个Sprint应该解决Y/X个Story Point

然后下个Sprint就选择这么多Story Point

感觉越来越接近真理了

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

14 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT