敏捷估算

敏捷估算

更好的理解敏捷估算

敏捷开发小权 发表了文章 • 0 个评论 • 67 次浏览 • 2016-12-25 19:19 • 来自相关话题

形象的体现了故事点估算:




 
可以参考一个真人实例:http://www.uml.org.cn/SoftWare ... 4.asp
形象的体现了故事点估算:
scrum-gusuan.png

 
可以参考一个真人实例:http://www.uml.org.cn/SoftWare ... 4.asp

故事点数是对工时的度量

敏捷开发小权 发表了文章 • 1 个评论 • 73 次浏览 • 2016-12-23 21:36 • 来自相关话题

尽管我尽了最大努力来澄清,但是仍然流传这样一种说法:故事点数是对复杂度的度量。这种说法是完全错误的。真相是,除非复杂度已经对完成用户故事的工作量造成影响,否则其复杂度并不重要。

让我举个例子。假设你和我一起观察离一栋建筑物的距离。你认为需要走5分钟,而我因为正拄着拐杖所以需要走10分钟。

你和我不能在花费时间上达成一致。对你来说走5分钟是对的,而对我来说走10分钟也是对的。如果采用分钟、小时、天等时间单位进行估算,问题就会比较棘手——由于我们处于不同的生产率水平,这会导致我们无法在估算上达成一致。

然而,我们能够对建筑物距离是“1个单位时间远”达成一致。当我们都认为估算结果是1单位时,你是认为会走5分钟而我是认为会走10分钟——但是这并不是什么问题。我们已经得到一个能够达成一致的估算结果。

假设,然后你又指着另外一栋建筑物说,“到那栋建筑物的距离是两倍,它是2。”你认为对你来说是走10分钟而我认为对我来说需要拄着拐杖走20分钟——但我们都同意有两倍距离远。

尽管生产率(步行速度)不同,但我们仍然能够对估算结果2达成一致。这就是故事点数的要点。

如果我们只估算复杂度又会怎么样呢?走到第一栋建筑物和走到第二栋建筑物的复杂度是一样的。我们把走到任何一栋建筑物的复杂度都估算成同样的值——称为1。这样做究竟会有什么好处呢?没有任何好处,对吗?我们不会直接估算复杂度——我们只会估算某某事项会花费多长时间,复杂度只是可能对估算结果造成影响而已。

继续刚才的例子,假设我们指向第三栋建筑物。它在物理上的距离同到第一栋建筑物一样(估算值是1),因此我们可能也会估算成1.

除非,在到达第三栋建筑前,我们需要走过一个高悬在灼热熔岩之上的极其狭窄的通道——这个通道只有一只脚宽或者是其它你认为狭窄但可以通过的宽度。

我认为我们能够能对此达成一致:走到这样一栋建筑物是更复杂的,因为就算在物理上与走到第一栋建筑物的距离相同,也需要更多的注意力和平衡感才能到达。往这样一栋建筑走,我们都会走的更慢——因此我们可能会把这项工作估算成3或者4——因为我们认为会花费到第一栋建筑物的3倍或者4倍的时间。

我们估算的仍然是工作量——复杂度只是部分而非全部。

如果我们只估算复杂度,我不知道该把那条窄路估算多少数值。我真的不知道——该如何估算复杂度?我唯一能够量化复杂度的方式,就是它会对其他事物造成多大影响。

在采用故事点数,我们估算的是完成一件事情的工作量(时间)——工作量的大小可能受风险、不确定性或者复杂度影响。因此让我竭尽全力说明的是:故事点数是对工作量而非复杂度的估算值。


本文译者:李洁(Jerry Li) ,CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

原文作者:Mike Cohn 查看全部
尽管我尽了最大努力来澄清,但是仍然流传这样一种说法:故事点数是对复杂度的度量。这种说法是完全错误的。真相是,除非复杂度已经对完成用户故事的工作量造成影响,否则其复杂度并不重要。

让我举个例子。假设你和我一起观察离一栋建筑物的距离。你认为需要走5分钟,而我因为正拄着拐杖所以需要走10分钟。

你和我不能在花费时间上达成一致。对你来说走5分钟是对的,而对我来说走10分钟也是对的。如果采用分钟、小时、天等时间单位进行估算,问题就会比较棘手——由于我们处于不同的生产率水平,这会导致我们无法在估算上达成一致。

然而,我们能够对建筑物距离是“1个单位时间远”达成一致。当我们都认为估算结果是1单位时,你是认为会走5分钟而我是认为会走10分钟——但是这并不是什么问题。我们已经得到一个能够达成一致的估算结果。

假设,然后你又指着另外一栋建筑物说,“到那栋建筑物的距离是两倍,它是2。”你认为对你来说是走10分钟而我认为对我来说需要拄着拐杖走20分钟——但我们都同意有两倍距离远。

尽管生产率(步行速度)不同,但我们仍然能够对估算结果2达成一致。这就是故事点数的要点。

如果我们只估算复杂度又会怎么样呢?走到第一栋建筑物和走到第二栋建筑物的复杂度是一样的。我们把走到任何一栋建筑物的复杂度都估算成同样的值——称为1。这样做究竟会有什么好处呢?没有任何好处,对吗?我们不会直接估算复杂度——我们只会估算某某事项会花费多长时间,复杂度只是可能对估算结果造成影响而已。

继续刚才的例子,假设我们指向第三栋建筑物。它在物理上的距离同到第一栋建筑物一样(估算值是1),因此我们可能也会估算成1.

除非,在到达第三栋建筑前,我们需要走过一个高悬在灼热熔岩之上的极其狭窄的通道——这个通道只有一只脚宽或者是其它你认为狭窄但可以通过的宽度。

我认为我们能够能对此达成一致:走到这样一栋建筑物是更复杂的,因为就算在物理上与走到第一栋建筑物的距离相同,也需要更多的注意力和平衡感才能到达。往这样一栋建筑走,我们都会走的更慢——因此我们可能会把这项工作估算成3或者4——因为我们认为会花费到第一栋建筑物的3倍或者4倍的时间。

我们估算的仍然是工作量——复杂度只是部分而非全部。

如果我们只估算复杂度,我不知道该把那条窄路估算多少数值。我真的不知道——该如何估算复杂度?我唯一能够量化复杂度的方式,就是它会对其他事物造成多大影响。

在采用故事点数,我们估算的是完成一件事情的工作量(时间)——工作量的大小可能受风险、不确定性或者复杂度影响。因此让我竭尽全力说明的是:故事点数是对工作量而非复杂度的估算值。


本文译者:李洁(Jerry Li) ,CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

原文作者:Mike Cohn

更好的理解敏捷估算

敏捷开发小权 发表了文章 • 0 个评论 • 67 次浏览 • 2016-12-25 19:19 • 来自相关话题

形象的体现了故事点估算:




 
可以参考一个真人实例:http://www.uml.org.cn/SoftWare ... 4.asp
形象的体现了故事点估算:
scrum-gusuan.png

 
可以参考一个真人实例:http://www.uml.org.cn/SoftWare ... 4.asp

更好的理解敏捷估算

敏捷开发小权 发表了文章 • 0 个评论 • 67 次浏览 • 2016-12-25 19:19 • 来自相关话题

形象的体现了故事点估算:




 
可以参考一个真人实例:http://www.uml.org.cn/SoftWare ... 4.asp
形象的体现了故事点估算:
scrum-gusuan.png

 
可以参考一个真人实例:http://www.uml.org.cn/SoftWare ... 4.asp

故事点数是对工时的度量

敏捷开发小权 发表了文章 • 1 个评论 • 73 次浏览 • 2016-12-23 21:36 • 来自相关话题

尽管我尽了最大努力来澄清,但是仍然流传这样一种说法:故事点数是对复杂度的度量。这种说法是完全错误的。真相是,除非复杂度已经对完成用户故事的工作量造成影响,否则其复杂度并不重要。

让我举个例子。假设你和我一起观察离一栋建筑物的距离。你认为需要走5分钟,而我因为正拄着拐杖所以需要走10分钟。

你和我不能在花费时间上达成一致。对你来说走5分钟是对的,而对我来说走10分钟也是对的。如果采用分钟、小时、天等时间单位进行估算,问题就会比较棘手——由于我们处于不同的生产率水平,这会导致我们无法在估算上达成一致。

然而,我们能够对建筑物距离是“1个单位时间远”达成一致。当我们都认为估算结果是1单位时,你是认为会走5分钟而我是认为会走10分钟——但是这并不是什么问题。我们已经得到一个能够达成一致的估算结果。

假设,然后你又指着另外一栋建筑物说,“到那栋建筑物的距离是两倍,它是2。”你认为对你来说是走10分钟而我认为对我来说需要拄着拐杖走20分钟——但我们都同意有两倍距离远。

尽管生产率(步行速度)不同,但我们仍然能够对估算结果2达成一致。这就是故事点数的要点。

如果我们只估算复杂度又会怎么样呢?走到第一栋建筑物和走到第二栋建筑物的复杂度是一样的。我们把走到任何一栋建筑物的复杂度都估算成同样的值——称为1。这样做究竟会有什么好处呢?没有任何好处,对吗?我们不会直接估算复杂度——我们只会估算某某事项会花费多长时间,复杂度只是可能对估算结果造成影响而已。

继续刚才的例子,假设我们指向第三栋建筑物。它在物理上的距离同到第一栋建筑物一样(估算值是1),因此我们可能也会估算成1.

除非,在到达第三栋建筑前,我们需要走过一个高悬在灼热熔岩之上的极其狭窄的通道——这个通道只有一只脚宽或者是其它你认为狭窄但可以通过的宽度。

我认为我们能够能对此达成一致:走到这样一栋建筑物是更复杂的,因为就算在物理上与走到第一栋建筑物的距离相同,也需要更多的注意力和平衡感才能到达。往这样一栋建筑走,我们都会走的更慢——因此我们可能会把这项工作估算成3或者4——因为我们认为会花费到第一栋建筑物的3倍或者4倍的时间。

我们估算的仍然是工作量——复杂度只是部分而非全部。

如果我们只估算复杂度,我不知道该把那条窄路估算多少数值。我真的不知道——该如何估算复杂度?我唯一能够量化复杂度的方式,就是它会对其他事物造成多大影响。

在采用故事点数,我们估算的是完成一件事情的工作量(时间)——工作量的大小可能受风险、不确定性或者复杂度影响。因此让我竭尽全力说明的是:故事点数是对工作量而非复杂度的估算值。


本文译者:李洁(Jerry Li) ,CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

原文作者:Mike Cohn 查看全部
尽管我尽了最大努力来澄清,但是仍然流传这样一种说法:故事点数是对复杂度的度量。这种说法是完全错误的。真相是,除非复杂度已经对完成用户故事的工作量造成影响,否则其复杂度并不重要。

让我举个例子。假设你和我一起观察离一栋建筑物的距离。你认为需要走5分钟,而我因为正拄着拐杖所以需要走10分钟。

你和我不能在花费时间上达成一致。对你来说走5分钟是对的,而对我来说走10分钟也是对的。如果采用分钟、小时、天等时间单位进行估算,问题就会比较棘手——由于我们处于不同的生产率水平,这会导致我们无法在估算上达成一致。

然而,我们能够对建筑物距离是“1个单位时间远”达成一致。当我们都认为估算结果是1单位时,你是认为会走5分钟而我是认为会走10分钟——但是这并不是什么问题。我们已经得到一个能够达成一致的估算结果。

假设,然后你又指着另外一栋建筑物说,“到那栋建筑物的距离是两倍,它是2。”你认为对你来说是走10分钟而我认为对我来说需要拄着拐杖走20分钟——但我们都同意有两倍距离远。

尽管生产率(步行速度)不同,但我们仍然能够对估算结果2达成一致。这就是故事点数的要点。

如果我们只估算复杂度又会怎么样呢?走到第一栋建筑物和走到第二栋建筑物的复杂度是一样的。我们把走到任何一栋建筑物的复杂度都估算成同样的值——称为1。这样做究竟会有什么好处呢?没有任何好处,对吗?我们不会直接估算复杂度——我们只会估算某某事项会花费多长时间,复杂度只是可能对估算结果造成影响而已。

继续刚才的例子,假设我们指向第三栋建筑物。它在物理上的距离同到第一栋建筑物一样(估算值是1),因此我们可能也会估算成1.

除非,在到达第三栋建筑前,我们需要走过一个高悬在灼热熔岩之上的极其狭窄的通道——这个通道只有一只脚宽或者是其它你认为狭窄但可以通过的宽度。

我认为我们能够能对此达成一致:走到这样一栋建筑物是更复杂的,因为就算在物理上与走到第一栋建筑物的距离相同,也需要更多的注意力和平衡感才能到达。往这样一栋建筑走,我们都会走的更慢——因此我们可能会把这项工作估算成3或者4——因为我们认为会花费到第一栋建筑物的3倍或者4倍的时间。

我们估算的仍然是工作量——复杂度只是部分而非全部。

如果我们只估算复杂度,我不知道该把那条窄路估算多少数值。我真的不知道——该如何估算复杂度?我唯一能够量化复杂度的方式,就是它会对其他事物造成多大影响。

在采用故事点数,我们估算的是完成一件事情的工作量(时间)——工作量的大小可能受风险、不确定性或者复杂度影响。因此让我竭尽全力说明的是:故事点数是对工作量而非复杂度的估算值。


本文译者:李洁(Jerry Li) ,CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

原文作者:Mike Cohn