文章

对速率重新取样来模拟项目

我通常只会在我使用过一个技巧若干年并发现这个技巧确实在几个不同情形下都适用后才会将这个技巧告诉大家。而今天,在本文中我要介绍的正式这样一种技巧。这是一种统计学的方法,叫做“重新取样”,我一直喜欢用这种方法来对未来的速率进行预测。

重新取样是基于我们相信我们在未来观察到的数据会和以前观察到的数据相似的原理的。在下面我们要观察的例子中,我们假定一个团队在将来的速率应该和过去的速率是相近的。我们可以把重新取样想象成将所有我们收集过的老数据全部都放到一个袋子里面。如果我们过去的速率是18,17,18,19,22和20,然后相信我们把这些数字都分别写在纸条上,然后放入袋子中。需要留意的是,在这个袋子中将会有两个上面写着18的纸条,因为我们有两次的速率都是18。

接下来要预测未来的速率了,我们要做的就是从袋子中拿出一张纸条。第一张被抽出的纸条上面的数字就是我们预测第一个sprint的速率。然后我们要预测第二个sprint的速率,我们要做的就是再从袋子里抽出一张纸条而已,但是在这之前,我们必须要将第一次抽出的纸条先放回到袋子中。这种方法叫做“resampling with replacement”。因为团队在任何给定的sprint都有可能再次达到以前的任意一个速率。

假设我们要预测一个团队在未来十个sprint能够完成的任务量。我们就会重新取样十次。每次我们都从袋子里抽出一张纸条,然后放回去,直到抽完十次。最后我们把十次抽到的数字加起来,于是我们就得到了这个团队在接下来十个sprint有可能完成的工作量。

当然,我们完全有可能十次都抽中数值最大的22,也有可能都抽到17。但是,实际上这两种情况出现的概率极低,最多每几千或者几百次才出现一次,所以基本上可以忽略不计。

由于我们不可能手工来做几千次的取样,这个时候我们就需要电脑来帮助我们了。这样我们就可以从大量的数据中看到实际的结果了。假设我们要启动一个10个sprint的项目。如果我们能够知道以下这些东西将会对我们有很大帮助:

  •  10个sprint能够完成的工作量的平均值是多少?
  •      团队完成200个故事点数的工作量需要的时间是多少?

其实要回答这些问题,使用重新取样和模拟的方法是最直接的了。接下来让我们来看看怎么做吧。你可以根据这个速率重新取样电子表格(http://blog.mountaingoatsoftware.com/wp-content/uploads/ResamplingVelocity.xls)来进行。在下图中,B3单元格到B28单元格显示的是历史速率。

scrumcn1320381250

由于我们的项目需要10个sprint,单元格D3到E12显示的是sprint 1到10重新采样后的速率。

agilescrumcn1320381274

重新采样速率实际上就是从单元格B3到B28中随机抽取速率而已。这样的任务可以使用下面这条公式来完成:
=SMALL($B$3:$B$28,INT(COUNT($B$3:$B$28)*RAND())+1)
这个公式首先产生一个1到26之间的随机数,然后用SMALL方法从列表中选出一项。(SMALL方法是从一个列表中选中最小的一项,在这个例子中我们也可以使用LARGE,目的只是为了要从B3到B28中随机抽取一个速率而已。)

因为我们对E3到E12使用了RAN()函数,所以每次你在表格中改变任何单元格的时候,E3到E12中的数值都会变化一次。这个正是我们想要的结果。

E3到E12模拟了10个sprint的速率。然而,我们想要的是模拟100次,200次甚至是1000次项目的数据(每次都是10个sprint)。要达到这样的目的,我们必须做一些额外的工作,因为我们将要使用大家在Excel中不大熟悉的Data Table。在我们的表格中,Data Table的范围是G3到H202,下图显示的是其中一部分。

scrumcnagile

G列显示的是sprint的序号,H列显示的是10个sprint速率的总和,也就是说每个单元格就代表了这个例子中一次项目。从途中可以看出,第一次项目10个sprint总共可以完成的故事点数是230点。在下一行中,团队得到了高得多的速率264。在数据表格中,我重复了这样的操作200次,当然你也可以根据自己的情况来增加或者减少。

本文结尾有建立Data Table的概述。想要详细介绍请参阅Excel帮助文档。

现在我们有200个次项目的数据了,于是我们就可以回答之前提出的问题了。“这个团队在10个sprint中一个可以完成多少工作量呢?”单元格E17和E18显示出200次模拟项目的可以完成的平均工作量,以及其标准差。

scrumcn1320381462

在这个例子中,重新取样的平均值是240点,标准差是12。于是我们可以推测团队可以完成大概240个故事点数的工作量。我们都知道有95%的可能性团队能完成2个标准差范围内的任务,也就是说95%的可能团队可以完成216到264个故事点数的任务。

如果我的老板需要我保证的话,我会说:“我可以保证完成216个故事点数。”当然,从技术角度分析,我知道数学方法并不能支持我的承诺,因为还有2.5%的可能我们会只能完成少于216个点数的任务。尽管如此,包括我参加过的很多很好的团队在内,人们总是希望能够多做一点,而不是只承诺216个点数,于是,我们还是决定210点以防止那2.5%的概率发生。

另一个通过这种模拟项目可以解决的问题是,当你的老板对你说:“我们要在接下来10个sprint以内完成250个故事点数的工作。”你可以通过重新采样的方法来看看完成这么多的工作有多大可能,也可以知道有多大可能性可以超过老板,客户和用户的预期。下图中的表格正是显示了这个自动完成的功能。

scrumcnagile1320381491

在L20单元格中输入期望的数值,表格会自动计算在模拟中达到或者超过这个数值的次数填入L21中,然后把得出的机率填入L22单元格中。在这个例子中,如果老板想要在10个sprint中完成250个点数的工作,我们可以回复说“我们会尽力,但是历史数据表明我们只有20%的机会完成这么多的工作。”

希望这种重新取样的技巧能对你有所帮助。使用这种技巧还可以完成很多估算。我会在以后的文章中做介绍。

你可以在http://blog.mountaingoatsoftware.com/wp-content/uploads/ResamplingVelocity.xls下载上面这些例子。

如何创建Data Table

要创建Data Table,首先要在H2(也就是你想要显示模拟结果的单元格)填入你需要用来计算每次模拟结果的方程。在这里,由于我想要知道10个sprint的速率总和,于是我输入:=SUM($E$3:$E$12)

接下来,在G列中填入数字1到200。然后假设你要做200次模拟,选中G2到G202单元格。现在我们开始创建Data Table。在我手上的Excel – Mac 2011中,选中Data->What If->Data Tables。然后你会看到一个弹出对话框询问需要的取值范围。然后用鼠标选中G2单元格。关闭对话框,你就会看到200行的模拟数据了。

作者:Mike Cohn

原文地址:http://blog.mountaingoatsoftware.com/simulating-a-project-by-resampling-velocity

根据待办列表中的一项估计整个列表

在本文中我想讨论一下最近经常被提及,几乎每个月都要被问到的一个问题。这个问题就是我们如何能够在没有可参考的历史数据的情况下,估算完成整个产品待办列表中所有项目所需要的时间。

我的建议是,在没有能够试行第一个Sprint之前,不要轻易给出答案。但是,我们总是要应对各种特殊情况的。在我们无法试行一个Sprint的情况下,可以举行一到多次的承诺驱动的(commitment-driven)的Sprint计划会议,然后根据这些数据来预计可能的速率。

当然,有的人总是喜欢使用小时,而不是速率,他们希望能够估计出完成产品待办列表所需的小时数,从而估算出整个项目周期(然而通过速率反而能够更直接的估算项目周期)。但是,既然这是一个普遍问题,我就希望能够解决它。

下面是经过我简化和提炼的实际问题:

我们没有历史的速率数据。我们有一个包含300个用户故事的产品待办列表。所有的用户故事都已经完成估算了,大多数都在3到13个故事点数左右。下面的方法合理吗?
1. 随机选择40个用户故事。
2. 把这些用户故事都分割成任务,然后对人物进行估算。
3. 然后可以得出每个用户故事的平均小时数。

例如,假设我们随机选择了40个用户故事,总共有150个用户故事点数,然后通过估算,完成这40个用户故事总共需要600小时。那么我们就可以得出每个用户故事点数大概是4个小时了吗?

嗯,是的,但是这种方法有下面两个问题:

1. 千万要记住故事点数和小时数并不是对等的关系,不能相互转换。我们不能够像上面的例子那样说1个故事点数就等于4小时。1个故事点数大约等于4个小时加上标准差,假设是45分钟。这就是说,在68%的情况下,1个故事点数等于3个小时15分钟到4个小时45分钟,在98%的情况下,1个故事点数等于2个半小时到5个半小时,也就是2个标准差。
2. 以上的方法假设1个故事点数的用户故事和13个点的用户故事是按照相对估算的。也就是说,如果1个故事点数为1的用户故事如果需要4个小时,那么一个13点的用户故事就需要13X4=52个小时。由于各种原因,这种推断并不成立。根据我收集的很多团队的数据表明,正如我们所预期的一样,团队并不是完美的。

那么我们怎么样才可以解决这些问题呢?第一个简单的解决方案就是,我们计算出每种大小的用户故事所需要的平均小时数,而不是把所有大小的用户故事合起来一起计算。例如,在上面的例子里40个用户故事总共是150个故事点数和600小时,然后得出每个点数等于4小时的结论。但是,如果我们把所有故事点数为1的用户故事来做计算,我们有可能会发现1个故事点数等于3.2个小时。同样的道理,我们可能发现2个故事点数的用户故事可能是1个故事点数等于4.3个小时,而用3个故事点数计算的时候,1个故事点数等于4.1个小时。

然后,我们就可以将平均小时数和对应的用户故事个数相乘得出每种大小的用户故事所需要的总时间。如下表所示:

 

 故事点数  每个用户故事对应小时数   用户故事个数   总时间
 1   3.2   5   16.0
 2  8.6  8  68.8
 3   12.3   7  86.1

我们首先要注意的是,在上表中的第二列是每个用户故事对应的小时数而不是每个故事点数对应的小时数。一个故事点数为2的用户故事每个故事点数等于4.3小时,所以一个这种大小的用户故事总共需要8.6小时。

 

这个表格告诉我们,故事点数为1的用户故事一共有5个,每个需要3.2小时。最后把最后一列的总时间相加就是170.9个小时。

在这里需要注意的是,这种方法会包含所有在分割任务和估算时间中的缺点。由于通常团队会无法一次过确认所有任务,所以这种方法只能估算出能够在会议上找出的任务所需要的总时间。因此,这种估算方法将需要后续的调整工作。我将会在后续的文章中讨论对这种简单方法的改进方案。

作者:Mike Cohn

原文地址:http://blog.mountaingoatsoftware.com/estimating-a-full-backlog-based-on-a-sample

巧妙使用“故事点”进行敏捷估算

克强在“敏捷中国”讨论组中引发对敏捷的估算的讨论(“Scrum sprint plan中规模估算的做法调查”,“关于story point的单位”)。我想分享一下我自己对敏捷估算方法的理解以及对于“故事点”的认识。

在敏捷开发中,团队通过两种方法对迭代做计划。
  • 基于承诺”Commitment”。做法很简单:
    • Product Owner从Product Backlog中取下一个用户故事(按照优先级),对这个用户故事进行解释,
    • 团队对用户故事进行讨论,明确需要解决的问题,
    • 整个团队确定是否能够在下一个迭代周期中完成这个故事,
      • 如果团队没有信心完成该故事,计划会议结束,或者把这个用户故事进一步划分成更小的用户故事重复第一步。
      • 如果团队有信心完成该任务,重复第一步。
  • 基于速率”Velocity”
    • 确定Product Backlog中用户故事的规模(用“故事点”)
    • 确定团队迭代的开发速度(“昨天的天气”)
    • 从Product Backlog中取出相应量的用户故事。
基于速率的估算中,需要确定一个“故事点”,也就是确定一个速度的单位。而在敏捷计划与估算计中,这个“故事点”是没有单位的。为什么?首先来看一下传统的规模估算的方法(标准日、代码行数)的问题。
  • 绝对估算 vs. 相对估算
    传统的方式是通过计算出一个绝对值(有单位,比如多少人天,多少代码行)。然后,做出计划。很大的问题是,人天生不擅长做绝对估算,人们更擅长做相对估算,更容易在相对估算值上达成共识。举一个简单例子,估算从上海市人民广场到徐家汇的距离,如果使用公里或者米等绝对单位,多个估算者很难达成共识,往往陷入没有必要的讨论和争吵。而如果用相对距离,比如从人民广场到徐家汇的距离相当于两倍的从人民广场到火车站的距离,人们就很容易、很快达成共识。因此对一个需求点来说,关注于相对大小也更容易使整个团队在估算值上达成共识。
  • 关注规模(而不是将不同维度的概念混淆)
    比较合理的估算方法是,首先估算整个规模,然后有一定的历史数据,知道速度,从而可以做出计划,推算出时间。比如我们看书,一共三百页,一天看十页,很容易就算出是三十天。如果使用理想日(时间维度),其实就是把这个过程搞反了,从时间维度反过来推算规模。同时使用“故事点”可以综合考虑一些其他因素包括复杂度、不确定性等,基于故事点的规模估算是在综合考虑各种因素之后的综合估算。而用代码行数很难对复杂度、不确定性等作出估算
  • 忽略个人能力的不同
    不同人的理想日和代码行数估算是不同的,是根据每个人的能力和认识的不同而不同的。但是使用关注“相对大小”的“故事点”就可以解决这个问题。同样举距离的例子,每个人的能力是不同的(有人步行、有人跑步、有人公车、有人地铁、有人开法拉利),但是所有人得出的相对规模值还是一样的。因此使用相对规模估算就可以不需要考虑这种个人能力因素。
  • 不可相加
    传统估算方式的一个很大的问题是,估算不能相加。每个人的理想日是不一样的,这样成员甲的估算(理想日)就不能和成员乙的估算(理想日)相加。基于这种相加结果的计划肯定是不准确的。在敏捷开发中,需要整个团队一起对任务进行估算,因此需要一个能够达成团队共识的标准 – 也就是“故事点”。
因此,为什么“故事点”没有单位?
  • 首先,故事点是一个相对量,相对值是没有单位的;小学乘法:被乘数 × 倍数 = 积。故事点估算值就是这个倍数。
  • 其次每个团队的单位“故事点”是不同的,很难也不需要统一。
最后,其实敏捷的计划估算与传统的计划估算很大的不同是对计划的态度。在敏捷开发中,计划估算只是一个对未来的预测,因为是一个预测,所以总是有不确定性。敏捷开发计划承认这种不确定性,因此对计划估算的态度应该是不断根据新的发现,对计划进行不断的调整,但是不需要过于关注预测的准确性(我们的工作是为客户开发有用的软件,而不是提供可靠的计划。如果公司以预测的准确性来衡量员工的绩效,那其实大家也该考虑换一个地方了,这又是一种局部优化)。

关于作者:

爱迪德高级软件经理,InfoQ中文站特约编辑。他是亚洲第一位也是目前唯一一位认证Scrum教练(Certified Scrum Coach)Daniel具有多年的敏捷项目(Scrum & XP)实践经验以及丰富的带队经验。

Daniel20061月创建了Irdeto上海研发团队,并将ScrumXP成功引入了团队。目前该团队主要负责数百万美金级别的大型付费媒体计费及客户关系管理系统的开发及维护,四年中成功发布产品的两个新版本。系统现在在美洲、欧洲以及亚洲的许多国家运行。

Daniel一直致力于将海外的敏捷思想、理论及方法以及实践介绍到国内,帮助国内的软件团队高效并有趣地工作,真正为客户创造价值。作为敏捷社区的活跃分子,Daniel通过博客、InfoQ以及讨论组等宣传敏捷。Daniel经常受邀到各个会议中针对敏捷话题进行演讲,他是敏捷中国2009的讲师,并受邀QCon北京2010以及在CSDN举办的软件开发2.0大会2009等中作关于敏捷的演讲。

Dianelblog: http://www.cnblogs.com/tengzy/

Sprint中的承诺

承诺(commitement)是Scrum所强调的核心价值观之一。也是执行Scrum时的关键概念。

有人认为,在缺少开明管理的情况下,团队的承诺将只是一种大的、自我强加的指挥棒,在每次团队未满足目标时敲打他们。还有人认为团队会走各种捷径来履行承诺,可能在必要时降低质量。 Read more