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

很多敏捷团队将故事点和复杂度点作为同义词来使用,他们相信这比使用“小时”更好,因为这些点数是基于复杂度和相对大小的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?

This entry was posted in Agile. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s