文章

敏捷估算-区分估算和承诺

在许多企业中,把估算和承诺等价看待是普遍现象。开发团队(无论是否是敏捷团队)根据可用的资源和期望交付的功能,做了一个估算,估算得出需要花费7个月。团队向他们的管理者提供了这个估算,管理者又将这些估算传递给他们的副总,副总又将这些告诉客户。在一些情况下,估算在这个过程中被削减了,留给团队的是一个“拔高了的目标”。这里的问题不在于团队的7个月的估算是对还是错。问题的关键是估算被转变成了承诺。 “我们估计这将需要7个月”被转变成了“我们承诺在7个月完成”。估算与承诺都很重要,但它们应该被视为不同的活动。 Read more

估算和计划对最大化交付价值的重要性

由于我对估算和计划是在太感兴趣了,因此每当我看见有人在博客或者消息组里面宣称“估算是在浪费时间!别再做了!”我都会十分留意。有趣的是,这些针对估算和计划的争论从来都不会来自那些我们为他们开发产品或者系统的那些人,因为他们都明白估算和计划的意义(以及错误的估算和计划带来的痛苦)。

 

让我们来仔细想想那个观点。在你的人生当中,有多少件事情是你完全没用做计划的?我估计你会为婚礼做计划,为搬到另外一个城市做计划,为假期出行做计划,或者为任何你事先没有打算做计划的这类事情做计划。

 

假设你打算第一次去意大利旅行。你可能会计划去哪些城市,每个城市要呆多久,预算是多少等等。现在假设你打算第一百次要回去你长大的故乡,你也会进行计划——尽管你计划的内容是决定你不需要做任何计划。

 

计划,是一种考虑将来的行为。有时候,将来是存在着风险以及不确定因素的。在这些情况下,我们需要比对可预知的将来(如第一百次回故乡)做更多的计划。当未来是可预测的时候,我们要做的计划可能只是花费几个毫秒来决定我们并不需要做更深入的计划。

 

当然,一个软件项目远没有那么简单。

 

那么估算呢?我们真的需要估算吗?答案是肯定的。因为估算是计划的前提条件,你不可能在没用做任何估算之前就做计划,就算这些估算是非正式的或者是隐式的。当我在写这篇文章的时候,我还在飞往加州的飞机上。在登机之前,我决定去ATM机取一些现金,因为我估计在稍后我需要一些现金。然后我又估算了一下数额,大概200美金就足够了。在这个例子中,估算所花费的时间还不到一秒钟,我甚至都还没有意识到,它就已经发生了。

 

 

当一位Product Owner 说:“我希望加入这个特性,而不是那个”的时候,他其实已经在为每一项特性所需要的时间做估算了,虽然这是一种隐式的估算(或者叫做猜测好了)。当一位程序员决定在下班之前修复一个BUG,而不是开始做一个新的用户故事的时候,其实他也进行了一次隐式的估算,而他估算的是在到下班之前的这段时间里,他刚好有足够的时间完成这个BUG的修复工作。

 

 

有的团队说:“我们不会进行估算的,我们只会把所有用户故事定义成同样的大小”,但是他们却没有意识到其实他们已经是在进行估算了。在这里,他们所估算的是一个用户故事要和其他用户故事的大小相同。其实,我认为要令所有用户故事大小相同,比要估算在大小一定范围内的大小不一的用户故事更困难。
其实,尽管你没有意识到,但是在不知不觉中你已经进行估算了。那些在博客和消息组里面说估算是浪费时间的人,正是忽略了这种估算的存在。
但是,这种随意的,下意识的估算足够吗?如果团队进行正式的估算会不会更好呢?

 

也许吧,但是并不是所有情况都适用。团队只有在深入调查后需要采取不同的行动的情况下才有必要进一步深入估计,否则就应该适可而止了。当然,如果进一步的计划能够让团队作出更好的决定(对交付日期更有信心,或者更好地为功能排列优先级等等),那么就应该进一步估算及计划。

 

举个例子,我们最近在给一个网站添加对我们的敏捷估算和计划的eLearning功能的支持。我没有询问负责这个功能的程序员完成该功能所需要的时间,但是我仍然能够有一个大致的概念知道需要多久能够完成。因为我和他已经在一起工作很久了,我对他的工作效率非常清楚。进一步地追问并不会为这个项目带来任何改变。

 

 

从上述可见,估算和计划是必须的。因为它们可以(而且应该)是轻量级的。如果进一步的估算不能让你做出更好的决定,那么你目前的计划就是足够了的。

敏捷规划和估算的12条指导原则

1.让整个小组参与。

特定活动的主要职责可能会落在某个人或者某个分组身上,例如确定需求的优先级主要是产品所有者的职责。但是,在最求可能具有高价值的项目时,要让整个小组 参与进来并做出承诺。例如,我们可以在一条建议中看到这一点,这条建议就是虽然可能很明显只有1~2个特定的小组成员会处理正在估计的故事或任务,但整个 小组做出的估计才是最好的。小组成员分担的职责越多,小组可以共享的成功也就越多。

2.在不同层次上进行规划。(产品Backlog->Spring Backlog->任务->每日计划)

不要错误地认为发布计划会让迭代计划没有用,反过来也一样。发布计划、迭代计划和每日计划分别以不同的精度覆盖了不同的时间范围,而且各有其特定的用途。

3.使用不同度量单位,让对规模和持续时间的估计保持独立。(规模和工作量的关系,故事点)

让对规模和持续时间的估计保持清晰区别的最佳方法是使用不会造成混淆的独立度量单位。使用故事点来估计规模,再使用速度把规模转换到持续时间是完成这一工作的好办法。

4.用功能或者日期来体现不确定性。

没有哪个计划是必然发生的。要确定您制定的任何发布计划中都包含对不确定性的体现。如果新功能的量是固定的,就把不确定性表示为一个日期范围(“我们会在 第三季度完成”或者“我们会在7~10次迭代中完成”)。如果日期是固定的,就需要表示在要交付的确切功能上的不确定性(“我们将在12月31日完成,产 品至少会包含这些新功能,最多可能只会再包含那些新功能”)。不确定性较大的时候,就使用较大的单位(例如迭代、月,季后是季度)。

5.经常重规划。(滚动计划)

利用每次新迭代开始的时候评估当前发布的关联度。如果发布计划是根据过时的信息或现在被证实为错误的假设制定,就更新它。使用重规划的机会来保证项目总是瞄准着向公司交付最大的价值。

6.跟踪进度并沟通。

有许多利益相关者会对项目的进度很敢兴趣。通过经常发布有关小组进展的简单而易于理解的指示器来让他们了解进度。耗散图和其它让人一眼就能看明白的项目进度指示器是最好的。

7.承认学习的重要性。

由于项目既是向产品增加新能力,也是产生新的知识,所以必须更新计划来包含这些新知识。随着我们更多地了解客户的需要,会把新功能增加到项目中。随着我们更多地了解我们使用的技术或我们合作的情况,会调整对进度率的期望和希望采用的方法。

8.规划具有适当规模的功能。(故事点的粒度问题,短周期迭代)

在不久的将来(接下来几次迭代中)就要增加的功能应该分解成相对较小的用户故事–通常就是需要1~2天,最多不超过10天的事项。我们最善于估计规模处于 一个数量级内的工作。让用户故事都处于这一范围内,可以让我们在估计和规划中付出的工作量和得到的准确度达到最佳的组合。它还可以提供足够小的用户故事, 让大多数小组合一在一次迭代中完成。当然,在较长时间的项目中,使用小用户故事会很费事。为了平衡这个影响,如果您要建立的发布计划覆盖的时间范围超过了 未来的 2~3个月,也许可以编写一些更大型的故事(称为史诗)或者使用主题,来对时间更遥远的工作进行估计,从而避免过于提前把大故事分解成小故事。

9.确定功能优先级。(计划安排之基本,规模和优先级)

按照让项目总价值最高的顺序来处理功能。确定优先级时除了考虑功能的价值和成本,还要考虑它能带来的学习效果以及开发它能够减少的风险。可以在早期消除一 个显著的风险的可能性,往往就足以保证先开发某个功能的合理性。与之相似,如果开发特定的功能可以让小组获得大量有关产品或他们开发它的工作的知识,也应 该考虑尽早开发这个功能。

10.把估计和计划建立在事实上

只要有可能,就把您的估计和计划建立在现实的基础上。确实,有些时候在某些公司中会需要在没有什么事实根据的情况下对类似速度之类的事做出估计。但是,只 要有可能,就应该根据事实的测量值建立估计和计划。这同样适于一个功能完成了多少的问题。很容易知道一个功能完成了0%的时候(我们还没有开始处理它), 也相当容易知道我们已经完成了100%的时候(产品所有者的所有满意条件测试都通过了)。在这两者之间就很难度量了–这项任务完成了50%还是 60%?由于这个问题太困难,最好还是坚持您所知道的:0%或100%。

11.保留一些松弛度。(项目进度和人员缓冲)

尤其是在规划一次迭代的时候,不要规划用掉所有小组成员100%。就像公路达到100%容量的时候完全停滞一样,如果将所有人的时间都规划成满负荷工作,开发小组的进度也会减慢。

12.通过前瞻规划协调做个小组。

在涉及多个开发小组测项目中,应该通过滚动前瞻规划来协调他们的工作。通过前瞻和把特定功能分配到即将来到的特定迭代,可以规划和调节小组间的依赖。

原文:http://blog.d8in.com/posts/618.html

敏捷开发中对进度的把握

项目经理被问到最多的问题就是,“这个项目什么时候才能完成?”
被问的时候,可能项目才定下来,仅仅知道大概的功能模块,非功能性需求还模糊不清,甚至团队成员都没到位。但是上级、销售、客户急切地要知道,这个项目什么时候才能完成?
被问的时候,也可能项目已临近结束,或者说临近当初计划的交付日期。然而待完成的功能还有一堆,测试出来的bug有一大堆,客户又提出了新的需求,团队正有人要离职 …。但是上级、销售、客户非常急切地要知道,这个项目到底什么时候才能完成?
这还不算糟糕。更头疼的问题是:“再有三周,项目应该完成了吧?”
因为后者根本不是问题,而是命令。项目经理必须要能够合理解释为什么三周不能够完成项目;或者说明在三周内,能够完成什么。
我们都用过MS Project, 但是那上面的漂亮表格对这样的困境毫无帮助。相反,正是Project 中的甘特图和日程表,埋下了陷阱。因为,在Project 中无法预估需要多少工作日才能完成模糊不清的需求,也无法体现实际情况发生变化后对进度的影响。
当我们讨论进度的时候,其实包含了两个未知的变量。第一是完成需求所要的工作量,包括需求定义、开发内容边界;第二是团队的工作能力,包括成员的行业知识专业技能,成员之间、成员和外部的沟通能力,等等。
关键就在于,这两项都是变量。如果任务是搬一千块砖头,每分钟每人能搬10块,那么结果是显而易见的。
在敏捷开发中,采用相对估算和迭代求精的方法来处理项目进度的问题。
首先是工作量。用估算代码行数或者界面元素的方式,就像论斤卖书一样,只适用于粗制滥造的软件生产过程。用户需要的并不是代码或者按钮,而是可靠易用的功能。
在敏捷方式中,先由用户和设计人员粗略估计各个功能模块的相对规模和难度,给出一定的分值。分值不代表具体人月,起相对比较的作用。例如有查询、显示、修改三个模块,如果实现显示模块的工作量是10分,那么查询模块可能是15分,而修改为20分。
下一步,选择一个工作量估分最低的模块,例如这里是显示模块,然后进一步考量其工作量。例如要准备数据库、设计界面、执行查询,显示内容等等。假设这轮估算得出此模块需要10人天,从而得出单位分值对应的人天为1;那么,整个项目就需要45人天。
这个估算建立在对项目的初步了解上,主要依赖项目经理的经验。有偏差?没关系。接下来通过迭代来求精。先来实现显示模块,如果事实上花费了12人天,那么根据比例关系,剩余内容的估算大约就是42人天。
当然,比例关系也不是一成不变的。随着模块的逐个完成,项目经理对项目的认识也在加深,他可以再调整剩余模块的相对分值。
在实际操作中,项目经理首先按照优先级排列功能模块。然后把高优先级的模块尽可能地细分,再选择分值最小的模块开始开发。统计总工作量时,按比 例累加其他模块的工作量,并加一定的调整系数,因为模块的复杂度不是线性增长的。每次迭代开发完成后,逐步降低调整系数。通常4~5次迭代后,可以将调整 系数归零。
在上面的例子中,第一次估算的初步结果是45人天,因为完全是凭经验,因此要给较大的调整系数,比如说0.4,因此给出的估算工作量区间为[45*0.6,45*1.4],即27到63人天之间。为保险起见,项目经理上报的工作量为70人天。
第二次估算,剩余内容的初步估算为42,调整系数下降为0.3,因此给出估算区间为30到50人天之间。依此类推,通过不断迭代,对剩余工作量的估算将越来越精确。
这样估算的好处在哪里?
首先,工作量变量的很大一部分因素,存在于非功能需求,例如界面的美观程度。而同 一项目的不同模块之间,非功能需求往往是一致的,相对估算法过滤了这一层复杂度。团队能力这一变量因素也是如此。当然,随着项目的进展,成员的开发能力应 该有一定的上升,但随着加班出差等因素,投入程度也可能下降,因而会相互抵消。总之在周期6个月以内的项目中,很少出现团队工作能力戏剧性变化的情形。因此相对估算也过滤了这个复杂度。
其次,迭代求精的方式让项目经理对估算时间更有把握。最初出现偏差是必然的,但只要团队稳定,没有大的需求变动,估算范围将迅速收缩。这比一次性报数更准确。
它的额外好处是,敏捷开发是遵循优先级的,即使对剩余时间(即低优先级模块的开发时间)的估算不十分准确,影响也不是非常大。
对比一下甘特图方式,在开发初期就要把各个模块的开发时间估算出来以统计总量,这就是瀑布开发的模式。
进度问题的另一方面,是项目经理如何了解团队以及每个开发人员的开发速度。当任务分配之后,项目经理如何做到心中有数,估算任务实际完成时间。
敏捷开发过程中,由开发人员自己来估算完成该任务所需要的时间。当然,每个人的能力不同;每个人的心态也不同,有的人保守,有的人乐观。没关系,还是靠迭代来逐步求精。
在每天的例会上,开发人员被要求对当前任务的剩余开发时间做重估。不同于Project 统计每人每天在任务中花费了多少时间,敏捷方式只关心这项任务还需要多少时间去完成,直到归零,然后再来统计实际的工作时间。
为什么?因为统计开发过程中的花费时间是毫无意义的。这和搬砖头不同,也许昨天用了8个小时没有一点进展,今天一旦想通了就事半功倍。我们真正关心的,就是到底还需要多少时间来完成任务,而不是已经花费掉不可恢复的时间成本。
在每天例会中,项目经理需要注意时间曲线保持水平的成员,他是不是遇到瓶颈了,是 否需求帮助?也要留意时间曲线下降幅度过大的成员,他发现了什么好的办法,有没有低估需求?这样,项目经理会更面向结果,只要按计划保证质量完成任务就 行,成员到底花了多少时间是个人的事。传统做法记录每个人每天的工作内容,第一是因繁琐而失真。其次,一旦上级发现某人工作时间不够(即便他完成了任 务),忍不住会派新任务,从而造成越干活越多,反过来打击程序员的积极性。
敏捷估算的关键之处,是把成员能力这个变量的估算,交给最合适的人去做,即程序员本人。然后通过比较历次迭代时的预估和实际时间,给出校正系 数,以避免程序员过于保守或过于乐观。这肯定不是绝对准确的,但效果往往比项目经理自己拍脑袋估算,然后强行指定deadline 要好得多。
在敏捷开发中,做计划比计划本身更重要。项目经理需要时刻向前考虑,考虑各种动态因素,而不是死报着计划本身。在进度估算的时候,项目经理应该在不同阶段,根据实际情况,给出合乎情理的回答。

 

来源:软件开发网

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

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

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

使用估算扑克做工作量的估算

微信扫一扫,立刻免费使用微信版估算扑克

Scrum中文网微信号:Scrum_CN

scrumcnweixin

使用估算扑克来做工作量估算是最有效,也是非常有趣的一种估算方式。估算扑克由一组类似斐波纳契数列的数字组成,这些数字包括:0,0.5,1,2,3,5,8,20,40,?,∞, 每幅扑克有四组这样的数字,可供4个人使用。

估算扑克的使用方法:

1.每个团队成员拿到一组卡片,包括0,0.5,1,2,3,5,8,13,20,40,?,∞,共计12张。
2. 产品负责人或者一名团队成员扮演阅读者的角色,他负责阅读需要估算产品Backlog的条目,并且询问大家是否有疑问。
3. 团队讨论这个条目。
4. 当团队理解了这个条目之后,每个团队成员按照自己的想法给出估算结果,并且选择对应的扑克出牌,估算结果不能告诉其他人,出牌时数字朝下扣在桌面上。
5. 所有人都出牌之后,阅读者向大家确认是否都已经确定估算结果,确认后,数”1,2,3″,大家同时展示估算结果。
6.团队评估不同的估算结果.我们是否想法一致?我们是否存在分歧?有没有什么是我没有考虑到的?团队共同讨论估算的差异,最终达成一致。
7. 回到第二步,开始估算下一个条目。

 为什么要使用估算扑克来做估算

有人可能会问,在传统的做法中,我们一般是让一个专家或者项目经理来做估算,给出结果,然后团队照做就可以了,多个人都参与估算不是浪费时间吗?
使用估算扑克来做估算基于两个结论,
第一:团队的智慧要高于某一个人的智慧。
第二:真正参与工作的人做出的估计要高于其他人做出的估计。
估算扑克有效还有如下几个方面的原因:
1. 传统估算通常是一个人在思考,而使用估算扑克估算时,鼓励跨职能团队的多个团队成员参与估算,团队成员可以从不同的视角来思考和分析问题,估算的过程中考虑的更加全面、估算也更加准确。
2. 在估算的过程中,团队对估算的结果进行讨论和评判,在一个高度透明的环境下,估算的结果更加真实和客观。这样也避免了很多时候过于武断,或是拍脑袋做出的决定。
3. 估算的过程也是一个知识分享和学习的过程,对某一个条目不清楚的成员通过其他成员的阐述会增加对该条目涉及到的要点的认识。

如何获取估算扑克?

估算扑克由于需求量很小,所以目前市场上是买不到的。 您有以下几种方式可以获取:
1. 选择专业的扑克定制厂商定制,一般是5000到10000副起印。
2. 联系Scrum中文网购买,每幅扑克30元,联系方式: info@scrumcn.com.邮件标题注明购买估算扑克,邮件中请提供您的所在单位、邮寄地址、购买数量、联系人姓名及手机,以方便我们与您联系。
3. 获取电子可打印版本,自己裁剪,URL: http://www.scrumcn.com//down/html/index.php?29.html  。
4.扫描Scrum中文网微信(文章开头),立刻免费微信版估算扑克,T-shirt Size估算。

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

克强在“敏捷中国”讨论组中引发对敏捷的估算的讨论(“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/