如何理解故事点

下面原文中提到的effort都按照”工作规模“来翻译的,根据经验,我们所有的估算最终目的还是要得到一个对应工作量的估算值,这里翻译成工作规模也是为了与普通意义的工作量做出区分,能让人将故事点理解成故事大小的度量。
如何理解故事点

故事点是一个度量单位,用来表示完成一个产品待办列表条目或者其他工作所需完成的工作规模(effort)的估算值。

我翻译的另一篇文章说明了故事点乱用的一些误区,会更有助于你正确理解和使用故事点,点击跳转

使用故事点估算时我们会给每个产品待办条目估算一个故事点,对于故事点的初始估算并不重要,我们更关注的是相对值。例如一个估算为2个点的故事规模应该是1个点的故事的两倍,应该是3个点的故事规模的2/3。团队甚至可以使用100 200 300,而不是1 2 3 来表示故事点,因为我们更关注的是比例而不是绝对值。

什么是故事点呢?

由于故事点代表开发故事所需的工作规模(effort),因此团队的估算必须包括可能影响工作规模(effort)的所有内容。其中可能包括:工作量、 工作的复杂性、 工作中的风险或不确定性带来的影响。在评估故事点时,请务必考虑全所有这些因素。

译者注:实际操作中可以遵照一个原则”只有当一个因素影响工作量时才将其纳入进来“

下面让我们来看看以上提到的因素如何影响故事点估算。

工作量

如何考虑工作量因素呢?如果有更多事情要做,则估算的工作量应该更大。例如考虑开发两个网页的情况。第一页只有一个字段和要求输入名称的标签,第二页有100个字段,也可以简单地填充一些文本。在实际开发时第二页的开发并不比第一个页更复杂,字段之间没有交互,每个字段只不过是一些普通文本,这两页之间的唯一区别是,第二页有更多的文本标签,需要完成更多是事情,这时候第二个页面所需的工作规模肯定要比第一个大。

风险与不确定性

  1. 产品待办列表条目所包含的风险和不确定性应影响故事点估算。
  2. 如果团队被要求评估产品待办列表条目,而相关干系人并不清楚需要什么(需求不清),这时候这种不确定性应反映在评估中,因为需要完成更多的沟通和试错工作。
  3. 如果为了实现某个功能,而这个功能又涉及更改一些没有自动化测试的旧代码,则这种风险应反映在估算结果中。

复杂度

进行故事点估算时,还应考虑复杂度的因素。回想一下前面的示例,该示例开发的网页包含100个普通的文本字段,它们之间没有交互。现在考虑另一个包含100个字段的网页,但是包括如下一些情况:

  1. 有些是带有日历选择小部件的日期字段。
  2. 一些格式化的文本字段,例如电话号码或社会保险号。
  3. 包括需要进行信用卡号校验和验证的字段,该页面可能还需要字段之间的交互,例如如果用户选择Visa卡,则会显示一个三位数的CVV字段。

    但是,如果用户选择美国运通卡,则会显示一个四位数的CVV字段。

这时候即使此时页面仍然是有100个字段,但是它的实现更加复杂。开发它们将花费更多时间,开发人员犯错误的机率也更大,因此必须充分考虑这些因素来进行估算。

所有以上这种额外的复杂性应反映在所提供的估计中。

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

看上去似乎不可能将三个因素合并为一个数字,并将其作为估算值。不过,这也是有可能的,因为工作规模(effort) 是基准因素。估算人员可以通过考虑完成产品待办列表条目所描述的工作的工作规模(effort)来得到这个最终值。

然后,估算人员会考虑要完成多大规模的工作(effort)来处理产品待办列表条目中包含的风险和不确定性。通常,这是通过考虑问题发生的风险以及如果该风险发生会带来的影响来完成的。

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

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

在完成定义中定义所有内容

故事点估计必须包括产品待办事项列表中定义的所有完成约束定义。例如团队的完成的定义包括创建自动测试以验证故事(这是个好主意),则创建这些测试的工作应包括在故事点估计中。

本文翻译自Mick Cohn的博客

来源:敏捷工坊,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/128443

侵权联系 投诉举报
返回顶部