文章

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

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

 

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

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

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: https://www.scrumcn.com//down/html/index.php?29.html  。
4.扫描Scrum中文网微信(文章开头),立刻免费微信版估算扑克,T-shirt Size估算。

Scrum中的工作量估算

当我们提起工作量估算的时候,我们会碰到同样的问题,我们如何来做估算?有什么方法可以遵循呢?如何估算才更准确?我对某个功能做了估算,但它超出了预计的开发时间,为什么?

Scrum团队已经做了很严肃的承诺去完成开发工作(可以交付的产品),必须要深思熟虑才可能成功。成功的工作里昂估算的几个步骤:

估算每个团队成员有多少时间可以在Sprint中被使用:

估算每一个团队成员在当前的Sprint中有多少时间可以被使用时Sprint计划会议的一个非常非常重要的部分。需要注意的是如果一个开发人员估算一个任务8小时可以完成,这个并不等于他一天可以做完。事实上,没有人会做在座位上一动不动,工作8个小时,参加会议的时间,午饭时间,意外的打断,看email, 接听电话等等都要考虑进去。

刚刚开始实践Scrum的人经常会问“是否需要预留一些时间来做bug修改?”。我当然不会准备两个Sprint,一个用来做产品backlog的开发,一个做bug修改。bug修改的时间应该是每天例行的时间,也就是说这是我们每天例行工作的一部分,扣除这些例行的时间,剩下的才是你可以承诺给Sprint的时间。1. 估算每个成员有多少时间花在和Sprint相关的工作上。

Sprint可用的工作时间= 平均日工作时间 – 其他活动.
平均日工作时间 = e.g. 8 hours
其他活动: = e.g. 4 hours
Emails and Phone : 1 Hrs
午饭: 1 Hrs
读Blogs/bbs : 0.5 Hrs
Bug fixes : 1.5 hrs
Sprint可用的工作时间= 4 hours

为产品Backlog中的每个项目估算工作量: 

有完成过类似工作经验的人来做相关的估算会更好一些,有历史数据可供参考。最好是让相关的有类似工作经验的人参与进来做适当的估算。经过几个Sprint之后,团队成员就会找准自己的位置,知道自己可完成多少工作。这也会使估算更为准确一些。

2. 所有的团队成员都要参与工作量估算的游戏。

3. 从Product Backlog中挑出排列好优先级的项目,要能够完全理解它,知道应该做什么,有哪些依赖、复杂度,风险等。如果需要的话让Product Owner做相关的澄清。
4. 细化理解后的项目为2-16 h/m工作量的小任务。

5. 为每个小的任务估算时间.

关于工作量估算的一些注意点:
1.一旦已经承诺要递交的Sprint的工作任务,团队成员不应该在受到外界的干扰,比如指派新的工作任务,或改变工作任务等。

2. 余下的工作将被移动到下个Sprint中。
3. 为了达到目标,团队必须是自我组织,并且团队成员之间是透明的。

团队冲突管理

团队协作由人组成, 有人的地方就有争执. 值得说明的是,冲突不全是坏事,它能暴露组织中存在的问题,促进问题的公开讨论,增强企业活力,刺激良性竞争.从某种意义上讲,冲突是企业创新的重要源泉.在大多数情况下, 一起工作的人都足够成熟, 会按制自己, 他们试图在一起和平工作, 并且一般来说会努力,愉快, 高效地完成项目. 在两个或更多的成员对同一个主题极为感兴趣的情况下, 最容易出现争执. 例如项目的两个开发人员都坚持用不同的方法开发应用软件,因则争论不休. 一般说来, 两方都是好员工, 只是都强烈地主张采用各自的工作方法. Read more

持续交付对大型产品管用吗?

最近我有幸听了Martin Fowler关于“持续集成与持续交付”的演讲,Martin分享了很棒的见解–如何通过尽早交付和持续反馈来帮助团队使客户满意?

在过去5年的一大半时间里,我都在帮助大型产品公司的团队向敏捷转型。这段经历使我一直很困惑,我们给客户的建议是否真的可行? Read more