故事点数是对工时的度量

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

让我举个例子。假设你和我一起观察离一栋建筑物的距离。你认为需要走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

本文转自:leangoo        scrum中文网

原文链接:https://www.leangoo.com/11945.html

时间: 2024-12-08 00:38:03

故事点数是对工时的度量的相关文章

用户故事与敏捷方法阅读笔记二

第8章 估算用户故事 使用故事点 我们用“速率”(velocity)来代表一个团队在一轮迭代中完成(或期望完成)的故事点数.因此,务必保证每次迭代的故事点的度量是一致的. 如果用结对编程呢? 团队用不用结对编程,对故事点估算并没有影响.团队可以采用理想结对日或理想个人日来估算故事点,区别会表现在速率值上. 一些提醒 一个故事(可能是一个史诗故事)分解成一些小故事后,这些小故事估算的总和不需要与开始那个故事或史诗故事的估算相等. 类似地,一个故事分解成一些任务.这些任务估算的总和不需要与故事的估算

《用户故事与敏捷方法》阅读笔记06

第八章 估算用户故事 故事点有一个很好的特性是团队可以定义自己认为合适的故事点,一个团队可能定义一个故事点为一个理想日的工作,也可能定义为一个理想周的工作.故事点有很多意义,所以故事点代表时间的模糊单位. 故事估算应该由整个团队集体来完成.故事估算属于团队集体有两个原因,第一个,还不确定团队中谁负责完成这个故事,第二个,团队决定的估算可能比个人估算更有用.在估算时,作者介绍了他所用的方法迭代的方式进行估算.在初步估算好后,成员进行讨论,然后进行下一轮的讨论,最终达成一致. 三角测量.估算一个故事

用户故事与敏捷开发方法笔记04

因为需要将每个用户故事按重要性分配到相应的迭代过程,所以每个迭代过程的时间就可以根据用户故事大致估算出来,所以要学会估算用户故事所需的时间.估算用户故事可以采用故事点估算的方法,这种方法的优点就是团队可以定义自己认为合适的故事点,可以根据自己团队的情况具体定义,比较灵活.正因为这个原因,有的团队倾向于用理想时间,有的团队则倾向于使用模糊时间.估算的主要目的之一是知道整个项目的工作量,通常将估算量换算成时间,而模糊时间需要考虑项目过程中可能出现的情况,所以采用理想时间更为简单. 进行估算时尽可能整

用leangoo怎么做需求管理及规划?(产品Backlog、用户故事)

传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发.在这样的环境下,需求文档是信息传递的主体,也是一份契约. 然而详细的需求说明书有以下5大弊端: 单向的信息传递,容易出现理解偏差. 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断. 有了详细的文档,我们不会反复讨论它,相互确认. 书面文档不利于团队共享责任,它扮演了证据的角色.Scrum强调团队共享责任,不论是需求人

读《用户故事与敏捷方法》有感(五)

今天,读到了次本书的第三部分--经常讨论的话题,用户故事不是什么,用户故事的优势与不良征兆. 第一,用户故事不是软件需求规格的指南,这种需求规格指南强调的是"系统应该--",而且对于需求规格指南而言,在写下需求之前,每个需求的成本是不可见的.典型的情况是,一个或几个分析师花两三个月时间(通常更长时间)编写出冗长的需求文档.随后把文档交付给程序员.这时程序员告诉分析师(消息会被转告给用户),完成项目要24个月,而不是分析师所希望的6个月.在这种情况下,分析师在编写团队没有时间开发的四分之

关于软件项目工作量估算的若干问题

作者:张克强 软件项目工作量估算从估算依据上看可以分成如下两类: 1,基于规模估算 2,基于工作量估算 基于规模估算的情况下,需要估算软件项目的规模.本文首先来看规模方面的问题. 问题1:如何表达规模? 软件产品或项目的功能规模是涉及软件开发和交易的成本.项目资源投入的预测.项目维护成本的预算.项目质量管理的要求以及产品上市的时间等方面的关键指标.因此,进行软件产品的功能规模测量显得尤其重要. 如何测量软件规模这个问题自软件工程诞生起就一直是这个领域的焦点问题.刚开始,人们很自然的使用代码行数作

精益看板分析:吞吐率

基于PMBoK.Prince2.CMMI等传统项目管理的公司对吞吐率(Throughput) 的了解相对较少.但是,我确信随着精益概念的不断延伸,吞吐率将受到更多的关注. 吞吐率 是指在一段确定的时间内(如周.月.季度)已交付的工作项的数量. 我们所讲的已交付实际上指已经完成并可能已经交付给顾客.即,在这个过程之后收到了钱. 为了理解吞吐率的概念,我们假设在过去的五周中,某个团队在每周分别交付了4.6.4.2.3个故事.对于已经开始但尚未结束的故事不计入其中. 这五周的平均吞吐率约为 (4+6+

回顾会议议程

回顾会议议程 目标 通过总结以往的实践经验来提高团队生产力. 会议准备 邀请与会者:Scrum Master.团队所有成员 .产品负责人(可选) 附属工具:为所有参与者准备的荧光笔.贴纸.白板磁吸.白板和挂纸板 准备一个回顾白板,分三列.第一列和第二列是回顾过去,第三列是展望将来. Good:如果重做同一个sprint,哪些做法可以保持 Could have done better:如果重做同一个sprint,哪些做法需要改变 Improvements:有关将来如何改进的具体想法 会议进程(1-

敏捷和DevOps词汇表

本词汇表是旨在说明敏捷与DevOps中各种术语. 由于敏捷与DevOps存在紧密的联系,在讲述DevOps时需要引用到大量的来自敏捷的词汇,因此本文试图做些整理 词汇名称 对应英文 说明 重构 Refactor 指保持某个对象的外在行为不变,优化其内部结构.代码重构是重构的一种. 代码重构 Code refactor 保持程序代码的外在行为不变,优化代码.在面向对象编程中,典型的是保持类的对外行为不变,优化类的内部结构. 测试驱动开发 Test driven development 利用测试方法