文章

scrumcn_userstory

要写封闭式的用户故事

在我们编写用户故事或者拆分用户故事的时候,写封闭式的用户故事至关重要。一个封闭式的用户故事意味着这个故事完成后,用户可以达成一个明确的、有意义的目标。我喜欢打这样的一个比方,完成了一个用户故事,用户应该可以停下来休息一会儿,喝杯咖啡了。

下面给一个不是封闭式的用户故事的示例: Read more

交流,而不是监督

我从不是一位事必躬亲的管理者,要不是因为使用敏捷和Scrum。若不是我总是太忙了,以至于无法花费我的时间在监督别人,在我的职业生涯的早期,我就可以转型成一位事必躬亲的管理者。但是,在我避免监督团队或人们的同时,我从来没有不情愿与他们沟通。最近通过阅读一篇关于从小处着眼的重要性来提醒自己记住这个。 Read more

良好的团队结构指导原则

以下是一套用于思考如何设计一个合理的团队结构的指导原则。每一个指导原则,以向现有团队或者拟议的团队提出一个问题的形式出现,并且这些问题需要迭代地询问。询问现有团队或拟议团队每一个问题后,根据答案改变团队结构;当团队结构改变后,重新再询问,直到对于每一个问题,你都可以回答“是”。
这个结构是否可以突出优势,弥补不足,并帮助团队成员提升积极性? Read more

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

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

重新取样是基于我们相信我们在未来观察到的数据会和以前观察到的数据相似的原理的。在下面我们要观察的例子中,我们假定一个团队在将来的速率应该和过去的速率是相近的。我们可以把重新取样想象成将所有我们收集过的老数据全部都放到一个袋子里面。如果我们过去的速率是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

看看团队的故事点数如何从1到8保持一致

最近关于如何利用用户故事的相对大小进行估算的话题,已经在很多评论以及这个博客的留言中多次出现过了,那么我们就这个话题来讨论一下吧。下面的图表显示了一个公司的相关数据:
scrumcn1319134105

每一列的数据和每一对柱状图都显示了来自下方表格中对应的用户故事点数的数据。第一组数据是关于1个故事点数的用户故事的,第二组是关于2个故事点数的用户故事,如此类推。在第一组数据中我们发现,这家公司中完成一个1个故事点数的用户故事所需要的时间的中位数是21个小时。最短所需时间是6小时而最长所需时间是36小时,在上图中分别用绿色和蓝色表示,而中位数则由红色曲线表示。

让我们来看看2个故事点数的用户故事。从图中我们可以看到,中位数是52个小时,最短和最长的时间分别是31和73个小时。如果我们假设1个故事点数的用户故事的估算是准确的,那么我们应该预期2个故事点数的用户故事所需时间的中位数应该是42个小时而不是52小时。反过来推断,那么1个故事点数的用户故事所需时间的中位数应该是26个小时。在绝大多数情况下,估计都不是完美的。无论是从哪边开始推断都有所偏差,因为2个用户故事的中位数并不是正好是两倍的关系。

但是我再看看3个故事点数的用户故事。根据推算,对应的中位数应该是1个故事点数用户故事的3倍,也就是说应该是63小时,从图中可以看出实际是64,已经非常接近。

同理,5个和8个故事点数的用户故事的中位数应该分别是105小时和166小时,而他们的实际值是100小时和111小时。但是,等等,我们必须要对这两种用户故事进行一些调整。如果你使用的是我推荐的方法的话,你就会将这些数字看成是一个个水桶。8个故事点数实际上对应的是从6到8的用户故事。所以,如果你认为一个用户故事是6个故事点数的话,你不能把它放到5个点数的那一项里面,而是要放到8个点数的一项。

这就意味着,5个故事点数的用户故事实际上是对应4个和5个点数的用户故事。如果我们假设这两个大小的用户故事的数量是相等的,那么实际的平均故事点数应该是4.5。于是4.5×21=94.5个小时,在实际值101小时的5%的误差以内,还算不错。

由于图表中8个故事点数对应的是6,7,8三种大小的用户故事,我们可以推断平均故事点数是7。于是,中位数应该是7×21=147小时。然而,实际值却是111小时。所以,这个团队在进行8个故事点数的用户故事的时候肯定会比计划中有所偏差。

(在这里我想说点题外话。与其简单地推断21个小时就是1个故事点数所对应的时间,然后在后续的计算中使用,使用Excel进行线性回顾分析会是更好的办法。你可以观察复判定系数r-squared来检验得出的值是否合理。在这里我并不想深入探讨这些数学问题。但是我相信,这些数据一直到8个故事点数都会比较准确。)

我鼓励你在你的公司收集类似的数据,但是你必须小心。因为你要收集的是每个用户故事的实际时间,所以很有可能你的团队会比平常感觉到更多的需要在估计时间内完成的压力。然后,他们也许就会给自己预留更加充裕的时间。要是这样的情况发生的话,最终将影响到数据的准确性,违背了收集数据的初衷。所以,让团队看看类似上面的图表,然后向他们说明这是为了帮助他们。举个例子,上面图表中的团队可能会意识到他们也许将本来应该是5个故事点数的用户故事误当作8个故事点数了。(从数据上来分析,也许他们的估算是对的,只不过是当中包含了比较多的6个故事点数的用户故事而已。)

很多团队会发现他们对故事点数从1到8的用户故事的估算还是比较准确的,就像上面图表中的团队一样。使用这种方法一段时间以后,加上一些练习和校正,几乎任何团队都可以对13个故事点数及以下的用户故事进行较为准确的估算。至于超过了13个故事点数的用户故事,使用这种方法的时候必须非常小心,或者只能够用来回答一些比较粗略的问题,如:“这个项目的周期大概是几个月还是要一年?”

如果你收集了你的团队的相关数据,并且愿意和我分享的话,我将会十分感激。你可以把数据通过邮件方式发送到mike@mountaingoatsoftware.com。我一直在做这些数据的研究工作,因此如果我能够有更多数据会更好。

作者:Mike Cohn

原文地址:http://blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

 

scrumcn602120522

在Sprint中间改变目标

我曾经应聘过一个SCRUM Master的职位,面试官问我这样一个问题:“在一个Sprint进行中,如果用户想改变某个正在这个Sprint中实现的User Story,你觉得应不应该改变它?”SCRUM的规定在我脑海中明明白白的印着:“在Sprint里不许改变任何任务,团队在第一天承诺一系列工作,然后期望它们在整个Sprint保持不变。” Read more

在合适的时间点进行估算

虽然产品Backlog的估算很重要,但是并不是所有的团队都需要做估算。那些做估算的团队更需要了解的是为什么要做估算,而不仅仅是如何去做估算。我们估算产品Backlog主要有两个原因:

首先,估算产品backlog条目帮助PO对产品backlog进行排序。 Read more

敏捷的成功率是瀑布式的三倍

根据2011年Standish Group的CHAOS 报告,敏捷项目的成功率是非敏捷项目的3倍。

在这份报告中提到:“敏捷流程是一种通用性的,可以用于挽救将要失败的软件开发项目的补救措施。使用敏捷流程开发的软件应用程序的成功率是使用传统瀑布式开发的三倍,而且所花费的时间和成本也要比瀑布式低得多。” Read more