文章

如何进行优先级排序

敏捷开发里边有很多地方需要多次进行优先级排序,本文将探讨其不同的应用场景,及其关系。

值得注意的一点是,敏捷开发中有无数的“自相似性”,比如估算,每年、每月乃至每天人们都在潜移默化地估计自己的任务;又如计划,也是每年每月每天都有成文或不成文的计划;而发布,也是每个故事自成单元,而又与其他的故事构成每月的交付,进而形成几个月的大版本交付……

由于这些自相似的活动颗粒度不同,一定不要认为只要做一次就可以了,也不要认为用一种方法做就可以了。要就具体活动思考这一活动的目标是什么,以及如何才能更好地达成这一目标。
Read more

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

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

我的建议是,在没有能够试行第一个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

对非功能性需求的估算

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

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

(在这里顺带说一句,如果你对如何用用户故事的形式表达非功能性需求的话可以看这里: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的团队对如何能够最好地跟踪进度有疑惑。一般来说,有几个方法可以选择。有些团队把每个用户故事拆分成以天为单位的任务。但是...

scrumcn1305615765
我经常发现使用Scrum的团队对如何能够最好地跟踪进度有疑惑。一般来说,有几个方法可以选择。有些团队把每个用户故事拆分成刚好一天能够完成的任务。但是我见到不少团队在尝试过这么做以后,发现过程中遇到很多麻烦,因为有些任务需要不到一天,而有很多需要两天甚至以上,所以很难将所有任务都准确地拆分成正好一天能够完成。

有的团队把用户故事拆分成任务以后,花费大量的时间来计算每个任务所占的故事点数。而这个会在计划会议上完成,因此整个会议要持续4到6个小时。在下文中,我们把这种方法叫做“故事点数分配法”。

第三种方法是我最喜欢的一种,我觉得它是最有用的,因为这种方法不需要花费很多时间,这和Scrum中帮助团队避免花费太多时间在获得准确性的其他方面是一致的,例如,在Scrum中使用斐波那契数列或者2次方数列来进行用户故事的估计。

只要有机会,我都会推荐下面这种方法。这种方法的基本技巧就在于,持续地更新每个用户故事的估计所需剩余时间(ETC)。一般来说你可以在每日站会之后更新数据,如果你已经能够掌握时间盒的运用的话,你甚至可以在每日站会当中来更新。总而言之,这种方法的最基本思想就是让团队每天估计并且更新完成某个用户故事所需要的故事点数。

让我们来看看这个例子。假设我们的Sprint长度是两个星期。在计划会议之后,团队承诺完成A到G一共7个用户故事,放在下面的表格里面(图1)。
scrumcn1305615787
图1

 scrumcn1305615845
图2

在完成了星期一下午的工作以后,团队在星期二的早上聚集到一起举行每日站会,然后估计所有在进行中的用户故事所需要的剩余时间。从图2中可以看出,用户故事A和B正在进行中,于是团队根据当前的进展重新估计了这两个用户故事剩余的故事点数。做出估计的依据应该是整个用户故事所剩余的工作量,而不是被拆分的任务。下面是团队重新估计后得出的燃尽图(图3)。
scrumcn1305615878
图3

团队应该每天重新估计每个进行中的用户故事的剩余工作量。图4展示了从开始到完成的过程,图5则是Sprint结束时的燃尽图。

scrumcn1305615896
图4

 scrumcn1305615917
图5

我经常听到其中一个的争论是“但是ETC并不是百分之百准确的”。这是肯定的,没有任何的估计是百分之百准确的。但是,每天重新估计进行中的用户故事的剩余工作量比把故事点从Sprint开始分配到各个任务中,然后每天把剩余的故事点数加起来更加能够让你了解实际剩余的工作量。这是为什么呢?

我们可以用锥型不确定性理论来解释。在项目管理中,锥型不确定性描述了项目过程中不确定性数量了变化过程。在项目刚开始的时候,相对地我们对项目的了解较少,因此估计也会包含比较大的不确定性。随着我们完成了越来越多的开发工作和研究工作,我们对项目的了解也越来越多,不确定因素也会越来越少。(http://en.wikipedia.org/wiki/Cone_of_Uncertainty)

scrumcn1305615947

正如你所想到的那样,锥型不确定性理论对传统的项目管理模型有很强的依赖。尽管如此,它的原理同时也适用于敏捷的项目管理。

还记得“故事点数分配法”(把每个用户故事的点数分配的各个任务当中)吗?我们可以说我们已经有一个不错的误差了,姑且说是+/-25%(1.25/0.75)吧。当然这种方法不会让我们得到百分之百的准确度。当项目进行的时候,为了能够更好地计算剩余的工作量,团队会标记已经完成的任务,然后把在进行中的任务所占的故事点数相加。这么做的问题是,尽管我们现在能够掌握比我们第一次估计的时候更多的信息,但是由于我们没有对用户故事进行重新估计,于是我们的准确度就会卡在+/-25%这个槛上。

如果我们不在一开始就把故事点数分配到各个任务上会发生什么事呢?自然我们就不会把所有剩余的任务所占的故事点数加起来来获得剩余的工作量。我们只能够重新估计每个进行中的故事的剩余工作量。这样我们就可以保证我们重新估计的时候不会还带着+/-25%的误差,而且可以越来越接近锥型的右侧,也就是误差为0的地方,因为我们每次重新估计的时候就会比上一次更加了解项目掌握的信息也会更多。这样做会比单纯维护在计划会议上作出的估计要准确得多。

我推荐各个团队在下一个Sprint中尝试这种方法。如果使用得当的话,你将会很快地留意到持续估计剩余工作量的好处。

原文地址:http://www.scrumalliance.org/articles/356-measuring-sprint-progress

 

实施TDD时的常见问题

如果你刚接触TDD不久,可能一些常见的问题正在困扰着你:

  •  我该容忍多大限度的预先设计?
  •  在写测试的时候,可能必须构建出接口和一些类来让代码编译通过——这一步该跨多大?

Chad Meyers写下了一些他在开始接触TDD实践时碰到的疑惑和问题,它们应该都是比较常见的: Read more

故事点是工作量,而非复杂度

是工作量,而不是复杂度
有个客户问我,“我的团队什么时候才能完成这个项目?”我已经被问过千百次类似的敏捷项目管理问题了。
但却从来没人问过我,“开发这个项目我的团队要费多少工作量去进行思考?”
客户,老板,顾客以及干系人只会关心一个产品要耗时多久,却不会去理会要交付该产品我们得多么殚精竭虑地思考,除非这些必要性的思考会带来时间或成本风险。 Read more

故事点和小时数如何对应?

我经常被问到故事点和小时数的关系。提问者经常期待我像这样回答

“一个故事点=8.3小时”。好吧,事实并非如此(尤其是我用了8.3这个数字)。来,让我们看看敏捷故事点和小时数之间的真正关系吧。

假设因为某些原因你跟踪了一个团队一段时间,来查看他们开发的每个1个故事点的用户故事。如果你把相关数据做成图的话大概会是这个样子: Read more

Sprint中的承诺

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

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