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

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

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

 

从估计绝对时间转换到相对估计

恭喜你终于说服团队使用相对估计的用户故事点数来估算工作量,这真的是一个非常大的进步,现在你准备好进入到你们的第一次估算扑克游戏了吗?你该怎么开始呢?哪个是1个点的故事?哪个又是3个点的呢?13个点的呢?这个游戏对你和你的团队来说都是一个全新的开始。

我曾经见过一个简单的设定初始值的方法就是先从你的产品待办列表中找出一个大家同意作为1个点的用户故事。然后,你就可以再挑选一个大概是这个用户故事2倍左右工作量的故事作为2个点的用户故事,接着就是两倍于2个点的用户故事的工作量的作为5个点的用户故事,以此类推。这样做没什么问题,但是你要清晰地意识到你的团队对这个流程还是非常陌生的,同时你又希望尽量地减少歧义和主观性。然而,任何估算本来就是主观的,因此,我在这里推荐一个更加切合实际的方法来帮助团队更好地进行估算。

一个不一样的方法

我们并不能因为我们采用了新的估算方法就把以前的估算方法看作成噩梦然后迅速忘掉。在以前的某些时候,这些方法是可行的。用例、问题、bug、功能特性——无论你管它们叫什么,团队都能够完成,而且团队也有对这些东西的工作量有一定的认识。我的方法是,我们仍然采用老式估算方法的一部份来建立起和新的用户故事点数的对应关系。下面是我的方法的流程:
1) 建立一个用户故事点数和实际时间对应的表格(为了保持表格简洁我把20,40和100点去掉了)。如下图所示:
scrumcn1314947985
当然,你可以根据自己的需要对时间部份进行修改。值得注意的是,随着点数的增加,在时间部分的上限和下限变得更加重要(例如不能是线性的)。这是因为越大的用户故事,包含的不确定性就越多。
2) 以团队为基础,回顾一下(可以回顾文档或者仅凭记忆)以往类似功能特性所需要的时间。需要留意的是,这里所指的时间必须包括了能够把用户故事标记成完成的所有任务的时间,例如开发、评审、设计测试、执行测试、部署等等。
3) 根据我们得到的时间,我们就使用第一步中的表格把第二步中的功能特性作为对应大小的用户故事的参考。例如,以前的XYZ特性现在成为了8个故事点数的用户故事的参考。
4) 然后我们重复这些步骤,直到我们为每个用户故事点数卡片都找到了相应的作为参考的特性为止。

有一点值得注意的是,一旦完成了这个过程以后,一定要把故事点数和时间的对应表格去掉,而使用刚刚找出来的作为参考的特性。这样,我们就可以开始把新的用户故事和作为参考的特性进行比较来进行我们的扑克游戏了。有些人会想,要么我们就继续用上面的对照表格来继续估算吧?但是,这并不是我们想要的。假如我们真的这么做的话,其实我们就是在进行套上了用户故事点数外衣的老式估算而已,而最后我们发现我们这么做纯粹是浪费时间。如果有人问起老式的估算时间方法,你就可以假装失忆然后告诉他你已经忘了,现在你唯一记得的就是要用用户故事之间进行比较,而不是直接去估算时间。唯一的例外就是团队有新成员加入的时候,而他又不熟悉估算扑克的流程,这个时候可以让他先使用故事点数和时间对应的表格进行训练一到两次。

还没结束呢

如果你按照上面的方法进行,我相信你们一定能够很容易地完成第一次估算扑克游戏,然后你们的一个Sprint马上就要开始了。但是,这还没完,仍然有一些东西需要进行调整。

在Scrum中,通常你会每天跟踪完成剩余的任务所需要的总时间(通常这会在燃尽图中反映出来)。但是,我还希望能够统计出完成的用户故事所需要的实际时间,这样,我们就可以比较实际所花的时间和之前按照1)中表格估算的差距。(嗯,也许我应该早就把那个表格给丢掉了,但实际上我总是在我的桌面上放着一份拷贝)

如果用户故事进行得很顺利,但最后发现其实这个应该是一个13个点数的用户故事,而不是8个,那么我们就应该做一些调整,把这个用户故事作为13个点数的故事的参考,这样下一次我们就能够更好地进行估算。我这么做就是为了能够让我们的估算的根基能够更牢固一些。

我会跟我的团队说明我记录实际完成的时间并不是要用于绩效考评。团队需要知道我们这么做的原因是出于“检视和应用”的考虑来改进估算而不是想要进行微观管理。

现在你已经知道要怎么做了。如果你觉得这个方法有用,或者你有更好的办法的话请告诉我。

 

作者:Ilan Goldstein
原文地址:http://www.scrumalliance.org/articles/368-transitioning-from-timebased-to-relative-estimation

是有序!不是按优先级排序!

scrumcn1314947432

在过去,Scrum指南里面通常使用优先级来描述产品待办列表,或者写明产品待办列表是根据优先级来排序的。当产品待办列表必须是有序的时候,优先级排序是仅有而且难得的好办法。但最近,新的Scrum指南里面使用了有序(ordered)这个术语,而不是按优先级排序(prioritized)。这反映了很多在Scrum社区中的领导者长期以来的理解。让我们来看看改变的原因。

按优先级排序就是说根据各个项互相之间的重要程度之间的差异来进行排序。其中优先级驱动着两个在列表中的项目的比较。这很容易让人想起使用冒泡排序来进行对产品待办列表的排序:比较最顶端的两项,如果它们的顺序就是错的就交换它们,然后对接下来两项进行比较,然后重复这种操作直到所有项都到达了正确的位置上。排列优先级和排序之间的关系十分紧密。

在给产品代表列表排序时,Scrum团队和Product Owner会按照最大化投资回报率或者价值的目标进行排序。然而,很多人普遍认为投资回报率就是优先级。其实,投资回报率是对待办列表的长期投入和产出的结果,而并非简单地将待办列表中的各项的投资回报率相加。在某种程度上这是正确的,因为待办列表中的一项的投资回报率取决于其在待办列表中的位置。例如,假设有一个用户故事是要在网站的首页上显示一个会跳舞的圣诞老人。这个用户故事能够在十一月底到十二月期间带来一定的回报,但是如果是在七月或者是一月,回报就会大大减少了。当你改变用户故事在待办列表中的位置的时候,实际上你已经改变了它的投资回报率了,因为由于它的位置的改变,其发布的日期也会有所变化。

因此,产品待办列表必须要排序,顺序决定了产品待办列表中的项目的交付次序。团队可以就待办列表中的顺序和Product Owner进行讨论,但是当团队从中拿出用户故事的时候,必须先从最顶端的开始拿。其实,产品待办列表并不能保证其反映的一定就是其中各项的价值或者优先级。你不能因为某一项的投资回报率或者商业价值就直接给定其优先级,你必须要通盘地考虑待办列表中的所有项,才能够使得最终的投资回报率最大。

比如说,你要在热带里建一座房子,你要考虑到每天午后的大雨。你能够预见到一座房子必须有墙、窗户和门,但是屋顶才是你最关心的问题。然后,假如你要给你建造的房子建立一个产品待办列表,这时候很显然屋顶是最需要考虑到的,但是你真的会把建造屋顶放在第一位吗?这个就是要对代表列表进行排序来最大化长期投资回报率的时候了。这个过程需要对产品待办列表中的商业、市场以及工程学依赖关系都有清晰深刻的了解。这很明显是一个比单纯的冒泡排序要复杂得多的过程。

使用“排序”而非“排列优先级”就是为了要让Product Owner知道,他们必须要对用户故事的顺序做决定,而不是只是简单的说“这五个用户故事优先级是1,那三个优先级是2”。
Product Owner必须交付一个已经完成排序的产品待办列表。

当然,你完全可以使用优先级来作为排序的依据,因为“排列优先级”也是其中一种排序的方法。使用“优先级”来排序有可能会导致投资回报率的降低。Jeff Sutherland经常说,如果你的产品待办列表的顺序足够好的话,你甚至可以让你的投资回报率翻倍。当然,有些例外的情况,例如有时候你的团队需要给一些客户做一些固定成本的项目(详情请查阅Change for Free 和 Money for Nothing),这些只是一些特殊的情况,并不是对所有团队和公司都适用。Scrum指南也不提倡这种做法。总而言之,你不应该使用优先级来进行排序。

作者:James O. Coplien

原文地址:http://www.scrumalliance.org/articles/367-its-ordered–not-prioritized

Scrum-ban

Scrum-ban是一个Scrum和Kanban的开发模型。Scrum-ban尤其适合于那些维护的项目或者经常会有用户故事变更或程序错误的项目和系统。在这些项目中,Scrum模型中规定时间的sprint显然就不能够满足项目的需求了,但是Scrum中的每日站会和其他一些工程实践还是可能根据团队的情况加以运用。可视化的工作进度和对未完成的并行用户故事和任务的限制都是Kanban的法宝,通过这两样法宝,能够指引团队以最少的时间完成用户故事和修复程序错误以及保证团队每个成员都能持续地投入到工作中。

为了能够清楚地展示工作的每个阶段,在同一个地方工作的团队通常会使用便签纸或者一块大的白板。而分布式团队通常会使用工具软件,如Assembla,ScrumWorks或者安装上GreenHopper的JIRA来帮助团队更好地了解各个用户故事、缺陷和任务所处的状态。

最简单的办法就是把任务或者用户故事划分成以下三类:
 候选
 进行中
 已完成

如果有需要的话,团队可能添加更多的状态,例如,“已定义”,“完成设计”,“完成测试”或者“已交付”等等。划分更细的状态能够帮助团队在遇到瓶颈又不能改变并行任务的最大限制的时候更有效地解决问题。同时,更具体的任务状态划分也能够使团队成员更专注在特定的工作环节上。

对于最大并行未完成工作的数量并没有一个通用的值,每个团队需要根据自身的情况来设定。如果这个值设得太小,有可能会导致很多团队成员有太多的时间在空闲状态;如果这个值设得太大,那么就有可能会在同一时间出现大量的未完成的工作,从而导致每个任务完成的时间大幅上升。这里给出的建议是,每个团队成员同一时间不能进行超过两个任务,另一方面在同一时间所有团队成员不能都有两个任务。

Scrum和Kanban最大的不同就是,Scrum把工作划分成固定长度的周期——sprint中,而Kanban则以持续工作的方式进行。从表示任务状态的表格来看,Scrum会在每个spirnt把表格清空,而Kanban则一直沿用同一个表格。从团队组成来看,Scrum强调的是跨职能团队,团队成员需要是多面手,而Kanban则更强调专职团队。

由于Scrum-ban是新的开发模型,因此并没有太多的参考资料。就目前来看,Kanban至少已经被Microsoft和Corbis采用了。

Scrum还是Kanban?这不是问题

几天前,我就Matthias的关于Scrum强制团队只能在sprint结束之后才能发布,而Kanban则更灵活的帖子发表了看法。

我想知道Scrum和Kanban的不同,我很疑惑为什么有人抱怨Scrum把规则定得太死,不够灵活等等。于是,我参加了David Anderson的Kanban中级课程。

结果,David的课程让我大开眼界。David表示Kanban并不是去改变什么东西,而只是将工作流程可视化和将隐藏的政策公开讨论而已。Kanban通过加入并行任务的限制,使得公司需要进行的改变慢慢地涌现出来。David说Kanban和Scrum的不同就在于,Kanban所引起的改变是自发的,Scrum引起的改变是被动的。革新由于革命。

首先,我要承认的是我真的非常喜欢精益的思想。我对David能够把这种思想融入到软件开发中感到十分敬佩。有趣的是,和我一起上课的人里面有人把我认出来了,而且他们觉得很奇怪,我明明是Scrum的支持者,为什么我会出现在这里呢?

从1994年起,我就开始相信学习精益理论非常有用。当我在2002年知道Scrum以后,我就确信Scrum能够处理精益理论解决的问题。我认为David这种优雅地将精益思想引入到软件开发世界中来的方法是朝着正确的方向迈出了坚实的一大步。

但是,在这课堂中十分困扰我的是居然没有人提及一些在我讲授的课程里经常提及的问题,例如:
 如果大家愿意创建任务版怎么办?
 如果团队成员之间不想合作怎么办?
 如果大家不想坐在一起怎么办?
 如果管理层反对这样的工作方式怎么办?
 我该怎么样创建一个发布计划?
 我该如何计算出项目成本?

我见过有些人没有成功连续完成3个Sprint,经常找不到Product Owner,或者团队经常被打扰的问题无法解决。然后,这些人就说Scrum没有办法解决这些问题,Kanban才是更好的解决方案。恕我不客气地说一句,就在Kanban倒在无数无法解决的问题前的时候,Scrum的支持者们已经给这些问题提供了解决方案。

今天,Scrum的实践者们已经懂得了如何:
 管理大型项目
 解决大型团队的问题
 解决团队之间的依赖关系
 使用Scrum构建大型架构的框架
 在项目开始之前计算项目成本
 快速有效地进行估算
 还有很多很多
在David的一本书中解释的著名的“泳道”模式,是为了管理大型企业的模式。这个模式是我2004年在德国WEB.DE的时候为4个Scrum团队发明的。直到今天,我还在用这种模式来管理180人的团队。从2005年起,我在我的所有课程中都会解释这种模式。

但是,无论是Scrum,还是Kanban,还是ASD,还是Crystal都无法解决下面的这个问题:人们害怕改变,尽管他们已经看到问题所在。很多人,包括Scrum Master,都需要一个领路人来让他们变得更好。

使用Kanban,Crystal或者ASD的人都必须说服他们的团队或者管理层他们建议的方法是真正能够带来改进的。Ken Schwaber总是说:“行动才是最好的证明。”我必须承认的是,我也不大明白,David能够让人相信使用他推荐的方法,而不是单纯他们自己本身的能力能够解决问题。

我认为David就是一个天才,一个天生的领导者。我承认以他提倡的方式开展一个新项目会比使用Scrum看起来更加简单。Kanban可能在某些环境中更加有效,当然我们也可以在实施Scrum的时候使用Kanban中的某些方法。

其实,Scrum,Kanban,Crystal和ASD在核心上是非常类似的:找出障碍和问题的来源,然后有针对性的行动。

我的建议是按照你认为能够符合你当前情况的方式进行。你可以先使用Kanban然后在其中应用一些Scrum的内容,或者先使用Scrum然后在其中应用一些Kanban的内容。例如,为任务定义Service Levels是解决分组工作的很好的办法,或者让循环周期可见度更高。这些都是对Scrum很有用的补充。

我所关心的是,我们想要改变我们公司成员的工作方式。我们想要给他们授权,我们想要让他们高兴和给他们最好的,因为他们热爱他们所做的事情。

然而,更常见的是,在很多Scrum团队中,有的人默默离开,有的人行为根本不像成年人,有的人只愿意被动地接受别人指派的任务。正是这些人,通常会在我的课程里面问类似“我们真的有必要分割任务吗?如果我们不能完成所有用户故事怎么办?如果一个用户故事本应该是8个故事点而被估成5个点怎么办?”的问题。

我认识很多Scrum实施顾问经常会把他们的客户引导这些问题上面来,因为他们只懂得回答这些问题,或者更不幸的是,他们害怕使他们的客户面对更加麻烦的流程问题。这些顾问败坏了Scrum的名声,因为他们不敢向他们的客户提出一些有可能让他们感到不自在的问题。于是,为了保住他们的客户,他们选择了沉默。

当然,有时候我们会损失一些客户。因为客户对我们呈现出来的真相感到恐惧。我们并不迷信Scrum,我们只是做我们认为对的事。我们是很务实的!我们坚持真相和让事情更透明。那是因为Scrum虽然简单,但是却很难用好。

作者:Boris Gloger

原文地址:http://www.agileweboperations.com/scrum-or-kanban-it-does-not-matter

对非功能性需求的估算

几个星期前,我曾经答应某人在博客上发表关于估算非功能性需求的独特挑战的文章。

首先,我们应该知道所谓非功能性需求是指对整个系统状态的一种需求,而不是系统的某个特定功能。非功能性需求通常包括性能,准确性,可维护性,互通性以及便携性等等。

(在这里顺带说一句,如果你对如何用用户故事的形式表达非功能性需求的话可以看这里:http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories。)

估算非功能性需求的挑战是它包含两项成本。第一个是初始维护成本。第二个是持续维护成本。

让我们来看看下面这个例子来说明这两个成本。假设一个团队正在开发一个新产品,而且对该产品有性能方面的需求。在第一个Sprint中,团队可能会考虑到性能的问题,但是由于还没有足够的代码,他们并没有办法去做性能测试。在几个Sprint以后,比如说Sprint 5,团队觉得已经有足够的代码,并且决定从这个Sprint开始做性能测试。

还记得我们提到过的初始维护成本吗?在这个例子中,就是指团队在Sprint 5开始做的性能测试的工作。虽然,性能测试比不会比大多数的其他用户故事多花很多时间。于是,团队在估算的时候给性能测试预留了几个用户故事点数或者理想人日。

接下来,我继续看这个例子。假设团队真的在Sprint 5中进行了性能测试,并且根据测试的结果进行了调优。在第六个Sprint的时候,团队还需要继续增加新功能,这就是刚刚提到的第二个成本—持续维护成本。一旦团队在项目开始中开始关注非功能性的需求(就像例子中的团队在Sprint 5中做的那样),他们就必须在项目中接下来的日子里一直维护下去。我把这项成本看作是一种税。性能测试(或者说持续维护非功能性需求)给团队带来了额外的负担(也就是税)。而且这种负担或者说税必须一直的持续下去。

有些时候,团队和Product Owner会确定每个Sprint都需要承担这种税。在这个例子中,就意味着每次他们要添加一个功能,他们都必须要给新功能甚至是整个系统做性能测试。有时候,团队和PO可能会同意每隔几个Sprint才承担一次。毕竟,有时候团队会说新加入的功能并不会给系统的性能带来什么影响,而且我们并不会在这个Sprint后发布。我们可以把每个月的进行性能测试想象成销售税或在VAT。把每隔几个月进行一次测试的想象成季度税,例如在美国的独立承包商所付的税。

我们到底应该如何估算非功能性需求呢?答案很简单,把上面提到的两项成本分开估算。像估算其他用户故事或者待办事列表项目一样估算初始维护成本。团队和Product Owner需要一起估计什么时候开始进行测试,因为在第五个Sprint开始做性能测试和在第二十开始做是不同的。然后,团队和Product Owner要协商持续维护的频率,是每个Sprint都要做还是每N个Sprint做一次?然后团队可以估算需要的工作量,然后分配相应的时间。比如说,团队和Product Owner决定每4个Sprint做一次性能测试,团队估算出每4个Sprint大概需要6个用户故事点来做性能测试。也就是说,大约每个Sprint要1.5个故事点。如果团队的速率是30的话,1.5个故事点可以看作成是5%的税。当然,对于第一次团队的估算可能不大准确。不过值得庆幸的是,团队在几个Sprint之后可以清楚的知道他们在性能测试上具体花了多少时间,然后根据统计来修改他们对持续维护成本的估算。

原文地址:http://blog.mountaingoatsoftware.com/estimating-non-functional-requirements

 

作者:Mike Cohn

重新思考 Sprint 长度

我们的项目是在一个分布式的环境下展开的——开发团队和产品管理处在不同的地理位置。当我们第一次进入到这个项目的时候时,我们要做的是帮助一个已经存在了数年的随机开发项目,没有固定的迭代和发布计划,建立离岸的开发中心。它的业务并不复杂,但是代码质量低下,再有就是它的知识持有人不在场出现(或者远程操作)令项目启动比我们以及项目干系人所预期的要难得多。
我们用最开始的三到四个月时间学习代码库(通过修复漏洞和增加新的功能)。最后,我们已经清楚了要如何来做我们的项目。 我们知道我们想试一个敏捷方法,在许多讨论论辩之后,我们决定试 Scrum (这里的来龙去脉,Scrum之前是如何被介绍的,那么本来应该怎么介绍它,它是如何最终改变了公司运作的方式是我们另外一篇或者两篇文章的主题——也许是下次)。
 Scrum起航
我们刚刚开始的时候,我们选择用四周的sprint。我们的产品backlog方面,我们使用per-feature需求文档,我们称这个为feature specs。每一个feature的规格说明通常是一本三到五页的文档,里面包括特征描述,主要工作流以及截图。我们的特征规格是由产品经理远程制作的。
这些文件在一定程度上是有作用的。尽管这样, 时常需要收集下一个sprint所必需的一定量的规格让产品负责人很累。他和产品经理经常拼命去找时间来写规格。甚至有的时候,哪怕他们已经写下了这些规格,这种情况经常时有发生,他们所提供的信息不足以让开发人员来做出合理的估计。
团队觉得Sprints长度没有问题,但是管理团队认为他们需要更可视化的结果。 同时,我们想是否更短的sprint会帮助我们的团队专注,同时优化绩效。我们计划切换到尽可能最短的期限:仅仅一周。如果不成功的话,我们随时可以切换回来。
我们的部分改变带来了积极的结果。比方说,股东每周能收到更可视化的结果。尽管如此,但实际上是弊远大于利。第一,开发团队需要每周 deliver,他们开始感觉有压力。第二,要在一周时间以内提供有价值的功能有的时候是很有难度的。最后,启动和终结一个sprint的成本感觉很高,不管是团队时间方面的投入还是情感上的投入。

前面路还远,我们还不能休息
一周的sprints的结果很不如人意,我们决定还是返回到四周的sprints。
同我们之前所经历的很仓促的每周发布相比,接下来的一个月将会感觉很轻松。 因为我们开始调整进程到我们理想的样子(我们期望达到现实)我们努力开始提前收集规格,给项目人员和测试人员提供更多详细的说明。事情会有所改善的。尽管这样,当我们认真仔细地看我们的sprint 活动,我们意识到我们实际上在做的是三周 sprints加上一周最后未完成的sprint任务缓冲,而非四周sprint。这可真不是我们期望“我们的 Scrum”的样子。

喂! 我看到陆地了
自这个项目被外包至今已经超过一年了。事情得到了改善,但还没有达到我们期待的效果。在那时,我们对要求管理过程做了一个根本的改变:我们用轻量的用户故事 (受Mike Cohn的 《应用用户故事》的启发) 取代了我们的中级重量的规格说明书。
如我们希望的一样,用户故事在开发和产品经理之间的沟通得以提高。同时他们帮助团队增加了对于业务需要的理解。所以,公司内部的的信任和沟通得以提高。这个相应地提高了产品质量(产品质量的提高也得益于更细致的用户故事使得计划更加优化 ,增加的单元测试量以及增加的测试团队规模)。
达到先前所说的条件之后,我们计划试试更短的sprints。 以下的是我们要抓住的“野兔”,他们是曾被认为只要改变长度就能解决的。(对于野兔爱好者,这可真是乐事一桩,有些小动物还在野地里跳得欢呢。)
• 提高团队绩效。 团队已经有一种在sprint进展中丢失关注的倾向。为了阻止这种状况的发生,他们在第二周之后简单地开了另一个sprint计划会议,为了能找出目前的状态(尽管我们一直更新燃尽图),以及通过重新分配任务来纠正他们的计划。这不是一个理想的情形。
• 从产品管理团队(用户代理)得到更早的反馈,从而从产品真正的用户那里得到反馈。通常在sprints结束的时候,用户故事被用来评审。在三到四周时间里开发的大量的用户故事增加了管理的工作难度,他们会很难确定项目质量,以及为下一sprint计划bug fixing或者变更。
• 让公司做更频繁的发布。公司的正式计划是季度发布,但是我们希望有更加频繁的发布可能。
• 消除计划难度。做每月sprints,产品负责人需要提前四周进行计划,由于时常变化的商业优先级,有的时候有点困难,同时,这对于开发团队来说,也有困难——相当多的故事我们需要考虑,这样计划需要很长时间,同时经历也被耗费。
• 更快地学习。我们需要等待至少四周时间才能看到任何我们开发过程中的变化所产生的效果。而且我们经常希望在单一的sprint里做了那么多的改变以至于我们不可能专注于所有的事情。我们在sprint回顾中所确定的问题在后来的一些过程中又一而再再而三地出现。
还远远没有完成
截至目前为止,团队已经完成了三个双周sprints。在这个时间里,完成以下任务(或者抓住以下野兔):
• 提高团队表现。团队开始更加专注,这点他们自己也非常喜欢。现在他们还能够记住大部分sprint的用户故事,这让他们彼此之间沟通他们的状态更加轻松容易。但是他们中的有些人说,如果用户故事的难度提高或者内部复杂性增加,他们就不能够这么好的完成sprints 。
• 及早得到反馈。这点已经得到产品经理的确认:他们能够得到客户的更早反馈,得到开发人员的估计,以及更早地更新计划,继而缩小整个反馈环节。
• 降低计划难度。这一点所有受影响的人都可以看到。对于Alexey来说 (一们ScrumMaster),这样的计划是最难的:要考虑太多的故事,要大力好太漫长的会议。现在计划就像每日站会一样轻松简单了。
• 更快地学习。过去的六周里,我们已经开了三次回顾会议(如果我们进行每月sprint话,我们最多只能开两次),这个非常富有成效,并且易于操作。 参加的人员要列出所有的障碍也不匆忙,因为我们知道两周之后我们可以再来回顾一次。
截止目前为止,下面的目标还没有达到:
• 让公司做更多的发布。这依旧是下一个或两个季度的目标。.尽管上个月的质量有所提高,但依旧还没有不能够在还没有做一两个特殊sprints漏洞修复的情况下就可以直接发布软件。
所有这些积极的改变是因为我们切换成两周sprint带来的吗?不。缩短sprint 长度本身,产生了积极效果,但是倘若没有其他必须的改变,这些积极效果也是达不到了,比如增强团队的积极性和职业道德,提高和增加产品管理和开发人员之间的沟通 (在介绍产品故事方面)以及提高内部产品质量。
我们应该在一开始就做两周sprints 吗?我们不这么认为。我们还是认为要不是有这些良好的先决条件(信任,用户故事,良好质量,等等),我们就已经失败了。慢慢地开始,解决这些先决条件因素,我们慢慢的能够发布越来越快,然后很自然地调整sprint长度。毕竟,是要先学会走路,再学着跑。
原文地址:http://www.scrumalliance.org/articles/10-rethinking-sprint-length

经验主义—基于已知信息做决定

经验主义是一种基于已知信息做决定的一种行为。Scrum是一种以经验为依据的流程,有些时候被称作“可能的艺术”,实际上说的就是我们要利用好我们手头上掌握的所有信息尽力做到最好。

一个PO根据当前所有已知的信息进行版本发布计划。他会列出目标和特性,以及团队交付这些特性的能力,还有可能的成本和交付日期。这样看来,PO的职责就是根据团队的能力评估可能达到的目标,然后做出最好的决定以达成目标。由于技术、市场、需求以及人力等各个方面的权衡,有时候无法在合理的成本范围内达到目标;有时候虽然达成了目标,但是和PO原来的计划有所偏差。这就是经验主义的实践。

Scrum中的团队其实也在干同样的事情。团队和PO举行会议,对PO觉得接下来最重要的事情进行评估。一旦完成以后,团队就可以朝着PO希望的方向进发。团队会根据在接下来这个Sprint中他们能够完成最大工作量对产品待办列表中的条目进行挑选。由于团队的人力成本和Sprint的长度是固定的,所以唯一可变的就是从产品待办列表中选择的条目的数量。这些条目就是版本发布目标的所有条目的子集。

在Sprint计划会议中,当团队从产品待办列表中选择条目的时候,他们承诺在当前的Sprint中完成这些条目。“承诺”的定义是:通过许诺或担保的形式进行约束或担负义务;诺言;承担自己的诺言;许诺做某件事。诺言、许诺做某件事,这就符合了我对“承诺”这个词的理解。

然而,很多Scrum团队误把承诺当作成一种“保证”。这其实是从瀑布时代遗留下来的,因为那个时候估计就等于合约。直到现在,这种概念仍然残留于很多PO和开发人员的脑海里。我发现很多团队都觉得他们不惜一切也要完成他们的承诺。而通常这么做的代价会是牺牲质量。

我在想,我们是不是应该把“承诺”说成“预测”会更好一些呢?因为这可能会引导大家认为我们就是在预报天气一样,用现有已知的所有信息尽可能地做好预测。这种实践在气象学和我们所了解事物的中已经被证实可行了。因为这种实践并不保证什么,而是根据我们所了解的信息来做最好的抉择。我们发现在销售行业中,预测同样被运用。也许,这能够帮助我们说明在Scrum中,“承诺”就是利用我们现有的一切尽力做到最好。

原文地址:http://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-decisions-based-on-what-is/

 

作者:Ken Schwaber