故事点:衡量scrum中工作总量的度量单位

故事点(story point)是一个度量单位,用于表示全面实现产品待办项或其他工作所需的总体工作量的估计。

故事点是用于表示完全实施产品待办项(product backlog)项目或任何其他工作所需的总体工作量的估计的度量单位。

 

当我们用故事点估计时,我们为每个项目分配一个点值。我们分配的原始值并不重要。重要的是相对价值。分配给2的故事应该是分配给1的故事的两倍。它还应该是故事的三分之二,估计为3个故事点。

 

而不是分配1、2和3,该团队可以分配100,200和300,或者100万,200万和300万。重要的是比率,而不是实际的数字。

 

把什么放入故事点?

 

因为故事点代表了开发「故事」的努力,团队的估计必须包括可能影响工作的所有事情。这可能包括:

  • 要做的工作量

  • 工作的复杂性

  • 这项工作有任何风险或不确定性

在使用故事点进行估算时,请务必考虑这些因素。

 

1、要做的工作量

 

当然,如果还有更多的事情要做,那么对投入的估计应该更大。

 

例如开发两个网页的情况。第一页只有一个字段和一个要求输入名称的标签。

 

第二页有100个字段,也只是填充了一些文字。第二页不再复杂。字段之间没有交互,每个字段只不过是一些文本。第二页没有额外的风险。

 

这两个页面之间的唯一区别是第二页还有更多内容。

 

第二页应该给出更多的故事点。即使有100倍的字段,它可能也不会获得100倍的点数。

 

毕竟,规模经济(随着产量的增加,长期平均总成本下降)可能使第二页的努力量仅为第一页的2或3或10倍。

 

2、风险和不确定性

 

产品积压(product backlog)项目中的风险和不确定性也在影响着对项目的故事点的估计。

 

如果一个团队被要求对一个产品积压项目进行评估,而利益相关者要求的项目不清楚需要什么,那么这种不确定性应该反映在评估中。

 

如果实现某个功能涉及更改一个没有自动化测试的旧的脆弱代码,那么该风险应该反映在估算中。

 

3、复杂

 

在提供故事点估计时也应考虑复杂性。

 

回想一下前面开发一个包含100个简单文本字段但没有相互作用的网页的例子。

 

现在想想另外一个包含100个字段的网页。但有些是日期字段,其中会弹出日历小部件。有些是格式化的文本字段,如电话号码或社会安全号码。其他字段与信用卡号一样进行校验和验证。

此屏幕还需要字段之间的交互。如果用户输入Visa卡,则会显示三位CVV字段。但如果用户输入美国运通卡,则会显示四位CVV字段。

 

尽管此屏幕上仍有100个字段,但这些字段更难实现。它们更复杂。他们会花更多的时间。开发人员犯错的可能性更大,必须备份并纠正错误。

 

这种额外的复杂性应反映在所提供的估算中。

 

考虑所有因素:工作量,风险和不确定性以及复杂性

 

将三个因素组合成一个数字似乎是不可能的,并将其作为估计值提供。

 

但是,这可能是因为努力是一个统一的因素。估算人员会考虑完成产品积压项目描述的工作量所需的工作量。

 

然后,估算人员会考虑在处理产品积压项目中,固有的风险和不确定性时需要付出多少努力。

 

通常这是通过考虑问题发生的风险,以及风险确实发生时的影响来完成的。例如,对于可能发生的耗时风险的估计,将包括更多,而不是轻微和不太可能的风险。

 

估算人员还会考虑要完成的工作的复杂性。复杂的工作需要更多的思考,可能需要更多的试错实验,或许与客户更多的来回,可能需要更长的时间来验证,并且可能需要更多的时间来纠正错误。

 

所有这三个因素必须结合起来。

 

考虑完成定义中的一切

 

故事点估计必须包括将产品积压项目一直完成所涉及的所有内容。如果团队对d完成的定义包括创建自动化测试以验证故事,那么创建这些测试的工作应该包含在故事点的估计中。

 

故事点可能是一个难以掌握的概念。但是,如果可以充分理解这些要点的努力代表的工作量,工作的复杂性以及工作中的其他风险或不确定性,这份影响的努力将是值得的。

作者:Mike Cohn

原文链接:https://www.mountaingoatsoftware.com/blog/what-are-story-points

其他

  • 邮箱:service@rishiqing.com
  • 客服热线:16710862037
  • 服务时间:工作日 9:00-18:30
  • 申请友链
  • 自助检测
Baidu
map