Scrum敏捷项目管理

用户故事规范化

使用故事点是Scrum团队用来评估用户故事的相对大小的一种技术。如果此技术对单个团队有效,则在涉及多个团队时可能会出现更多问题。在本文中,Paul Raymond解释了为什么在多个Scrum团队合作处理同一用户故事的情况下需要对用户故事进行规范化。

Inflectra Corporation的Paul Raymond, http://www.inflectra.com/

传统的软件开发估算技术是缓慢而持久的练习,因此完全不适合敏捷过程。已经出现了适合敏捷模型的新估算方法,只需最少的精力即可提供“足够”的信息来支持优先级和决策制定。敏捷调整大小最受欢迎的度量单位是Story Point。

用户故事规范化

与故事的小时,天和代码行等传统软件大小单位取自现实世界并因此易于理解不同,故事点是一个抽象的概念,因此需要更长的时间才能习惯。时间,天数和代码行是预先定义的;没有人需要解释一个小时。是的,确实是一个小时可能意味着一个小时,或者仅意味着工程师每小时可工作的时间,考虑到喝咖啡休息时间和其他干扰因素,这可能更像是50分钟,但是重点是,这个概念众所周知。

另一方面,故事点是抽象的,要求团队就一个故事点的定义达成一致,并将所有其他估计值与此相关。最简单的方法是选择一个团队熟知的小故事,并称其为故事点。这个想法的问题在于,它仅在团队中起作用。在有多个团队的情况下,每个团队可能选择不同的故事点参考大小,以使它们的估算与所有其他团队的估算不同。

这有关系吗?嗯,事实并非如此,只要每个团队的运作完全独立于其他团队即可。必须先将故事分配给团队,然后才能进行估算,这只会成为该团队的待办事项。一旦估算,故事就不能简单地分配给另一个团队,因为对于具有不同故事点度量的团队而言,故事的估算没有任何意义。此外,每个团队可能具有不同的速度(团队可以在每次迭代中完成的故事点。)

在一个项目中团队之间可以互换故事的项目中,重要的是要有一个共同的故事点大小。实现此功能称为规范化,在白皮书中进行了描述 敏捷估计简介.

最重要的是,对于只有一个统一团队的项目或团队完全自治的多团队项目,规范化是没有意义的。但是,无论何时要将故事动态分配给团队,还是需要有意义的汇总进度报告,标准化和故事点的最终通用定义都是必不可少的。

关于作者

Paul Raymond是Inflectra公司的成功软件程序经理。他在需求管理系统方面拥有丰富的经验,包括Telelogic的DOORS和Inflectra的SpiraTeam。 Paul帮助多个行业的客户控制了他们的需求,并制定了可行的计划,以便按时按预算交付软件项目。本文最初发表于 http://www.inflectra.com/Ideas/Entry/272.aspx 并经Inflectra许可复制。