文章

Scrumcn_scrum

Scrum vs 持续部署

产品开发需要持续性

Scrum的基本思想就是给团队一个安全的和没有变更的环境,让团队可以集中在计划好的开发任务上。一般来说,团队为两周左右的一个Sprint做好计划,然后在Sprint当中不应该被打断,直到当前Sprint结束。这样的流程能够避免了“新的==重要的”的情况发生,能够保证当前的事情能够完成,也能够避免大家认为新的想法就一定比一个月前提出的想法要重要得多的问题。要在产品特性开发上获得成功,就需要稳定的特性优先级。 Read more

项目管理无力 敏捷开发出招

在实际的项目实施中,尽管旁边常常站着解决项目问题的专家,但当项目经理被不自觉地卷入到项目的各种问题中时,项目管理的各种方法也变得苍白无力。此时,敏捷开发往往成为项目经理的制胜法宝。 Read more

成功组建规范敏捷交付团队的 5 大技巧

简介

敏捷宣言(Agile Manifesto)自 2001 年发布以来就定义了敏捷方法的核心精髓。最近,IBM 以 “规范敏捷交付” 之名提出了一组最佳实践,帮助较大型软件开发团队取得与较小型团队在过去 10 年使用敏捷技术所取得的相同成就。这不是说现有的常用敏捷方法是杂乱无章的;事实上,大部分敏捷方法都需要比传统或临时的方法更加规范和严格。但是,并不总是有处理复杂企业环境中的大型敏捷项目的指南。

DAD(规范敏捷交付- Disciplined Agile Delivery,是 IBM 提出的一组实践,旨在帮助较大型软件开发团队像较小型团队一样成功实现敏捷开发) 提供了一个混合框架,将来自各种现有的成熟敏捷方法(比如 Scrum、XP、Crystal、FDD 和 DSDM)的最佳指南结合在一起。尽管这些方法中的每一种都有价值,但每种方法在各个方面都是不完整的,因为从业者通常会将来自不同方法的技术堆叠起来,获得某种相对集中的产物。来自 IBM 的敏捷/精益 IT 首席方法学者 Scott Ambler 收集了来自多种方法的最佳指南,并得到了 DAD 框架。我非常幸运能够与 Scott 合作,并能够在我自己的项目中使用这些实践。

DAD 还为常见的敏捷方法补充了企业指南。例如,DAD 会向团队展示如何将 “积压” 等主流概念带到下一个层次,让它们更适合更大规模的企业环境。它可帮助您与直接开发团队以外的企业权威合作,比如企业架构师或数据库管理员。一些开发人员错误地认为,采用敏捷方法后,您就不再需要处理这些个性特征和准则。事实不是这样的。大部分敏捷团队都必须放眼于团队外部,尤其是在参与其他项目和与组织中的其他权威人员合作时。

基于我个人作为大量敏捷项目的开发人员和团队领导的经验,我提出了以下建议,帮助您思考与敏捷开发原则指导下的项目相关的大型团队管理问题。这些只是在组建拥有 20 或更多位开发人员的敏捷项目团队时要考虑的部分因素,但它们可帮助您朝正确的方向发展。

技巧 1:欢迎通才专家

传统方法倾向于假设一个拥有非常专业人员的团队会为客户带来更出色的产品。事实上,我们发现事实正好相反。在许多情况下,参与项目的人员越专业,他们会越想尝试生成完美的文档、完美的代码和完美的模型。此外,如果团队依靠只拥有自己专长技能的专家,则效率就会降低。例如,如果团队中只有一个人理解数据库,那么不仅该团队的工作会延误,而且将有效的解决方案交到利益相关者手上的整个过程也会延长。

DAD 促进了拥有 “通才专家” 的团队的形成,通才专家也就是具有一项专长,但还对软件开发生命周期中的多个领域拥有基本知识的人。例如,一位分析师可能是需求方面的专家,但还对测试具有基本知识,如果团队测试进度落后了,该分析师可以提供帮助。

在我现在参与的项目中,开发人员除了传统的编码专长外,还花了大量时间来帮助编写部署和持续集成脚本。结果,他们都获得了有关基础架构和配置管理的基本知识。另一个示例:测试人员在传统上主要负责从黑盒角度测试用户界面和软件工作原理。但敏捷领域中的测试人员日渐需要变得更加技术性,考虑开发人员所做的工作。如果他们能够将测试编写为代码,而不仅是从用户界面测试功能,他们会对团队更有用。

技巧 2:更多地专注于协作技能,而不是智囊团

聪明的人组建的团队常常无法得到预期的结果。一组聪明的人不一定就会组建成一个优秀的团队。只有在这些人朝一个共同目标协同工作时,才有可能成功。我看到过不想协同工作的非常聪明的人,他们更喜欢独立工作。您的组织中可能有适合这样一个人的职位,但在敏捷开发和交付团队中可能没有。

此外,还有一个事实是,我们无法在每个项目团队中都配备超级明星。我们需要学习如何在具有普通、可预测能力的人中变得富有成效,而不只是明星编程人员。所以,我在组建团队时寻找的是既能良好协作,又展现出竞争力和自信的人。他们谦恭有礼,因为他们认识到事实上他们无法知晓全部内容,他们需要彼此学习一些东西。

技巧 3:为手头的项目组建规模适中的团队

DAD 描述了 3 种不同的团队级别:经典的小型团队、中型团队和大型团队。当然,DAD 主要针对大中型团队而创建。对于可能有多个子项目同时处理共享组件的较大型团队,一定要考虑各队人马与其各自团队领导如何协同工作。一个问题是,经典敏捷理论建议组建小型、自给自足的团队,假设他们应该能够自行实现完整的解决方案。但在我们的队伍不断壮大时,我们需要从团队外引入其他具有专业技能的人。

例如,在我当前的项目中,我们将十几项技术集中起来实现一个非常大的系统。我们明确地应用了 “通才专家” 的原则,但事实上不是团队中的每个人都能够了解所有这 12 种不同的技术的每个细节。所以我们为团队补充了一些基础架构人员,比如 Linux 专家、两个数据库权威人员以及安全性和防火墙专家。

在像这样较大型项目中,当您过渡到生产环境时,您将必须与(举例而言)您的 DevOps 团队或企业现代化团队合作。换句话说,您的系统不会孤立地存在。我当前参与的项目将与一个现有的系统相集成。要移到生产环境的所有要素都会受到严格的变更控制流程的紧密控制,所以我们会定期与团队外部的这些人互动,以让这些要素正常工作。

DAD 还包含在启动项目时执行某种初始规划的指南,这可能对于让不同团队协同工作很有用。对于较重的项目,您需要在要解决的商业问题和要得到的解决方案方面获得初步愿景。这个愿景可能包含业务案例的总体概述、提议的技术架构、风险摘要以及其他的摘要信息,让利益相关者相信该项目真正有用。

技巧 4:理解敏捷领导原则和团队组织,灵活处理手头的项目

小型团队的敏捷方法(比如 Scrum)解决了这样一种事实,在软件开发中,领导阶层的指挥控制方式(经理创建详细的工作细分结构、向团队分配任务,并告诉他们每项任务要花多长时间完成的方式)存在问题。敏捷方法从业者认识到,实际执行工作的人才是制定这些决策的最佳人选。开发人员确定他们的任务,他们执行自己的评估,他们自愿挑选任务,他们自行分担工作量。在本质上,他们就像一个高效运转、自行组建的团队,没有明确定义项目经理职位。相反,该团队指派某个人作为团队领导,帮助推进整个流程。
DAD 使用了产品所有者 的概念,这个概念直接来自于 Scrum;DAD 事实上完全没有更改这个角色。产品所有者负责确定工作范围、优先级并阐明他们需要完成的工作的需求。作为产品所有者,他们拥有解决方案的产品愿景。但是,参与 DAD 实践的人认识到,对于较大型、更复杂的项目,可能必须向团队增加领域专家来协助产品所有者。

DAD 还有另一个类似于产品所有者的角色,称为架构所有者。团队拥有天才开发人员固然很好,但同样重要的是,让某个人 “拥有” 交付解决方案的架构愿景和负责关键技术决策。架构所有者也可以与团队外部的重要权威人员协作,比如企业 DBA 或企业架构师,以确保开发团队所做的决策不会与企业整体的标准和指导原则相冲突。他或她是项目的技术专家,定期与这些利益相关者合作。

作为自己团队的领导,我大量依赖于架构所有者。我目前的情况是,在一个房间里拥有 25 个工作人员。这是一个比经典敏捷项目人数更多的团队,但这是将一个项目升级为 DAD 项目的不错示例。紧挨着我左侧的是架构所有者,所以我总是可以向他咨询问题,比如:
我们是否有合适的人在参与合适的任务?

我们是否减轻了技术风险?
哪些团队成员需要帮助?我们是否为他们安排一个搭档,以便他们在执行任务时可获得帮助?
企业中是否有现有的技术资产或模式可供我们使用?

作为团队领导,尤其是在像这样的大型团队中,我很难详细地了解每个开发人员是如何工作的。所以我选择架构所有者作为我的搭档,帮助提高团队效率。
从另一方面讲,架构所有者也很重要。架构是项目风险的一个巨大的潜在来源,因为存在超越项目边界的依赖关系,比如生产环境、业务需求、遗留数据、旧有系统等。架构所有者确定要在早期迭代中实现哪些工作项,以尽可能早地减轻这些风险。这种 DAD 实践称为 “风险价值生命周期”,它不同于其他仅依靠商业价值来确定工作优先级的敏捷方法。架构所有者帮助团队理解关键技术风险,以及必须捕获和满足哪些需求才能减轻这些风险,在项目后期,修复这些风险可能非常困难且成本极高。

技巧 5:提防自行组建的团队,尤其是如果团队缺乏经验

自行组建的团队是一个非常美妙的敏捷概念。团队成员最了解如何自定义他们的流程,以保持最高效率。他们可以协作,是因为已学会了如何协同工作。例如,Hal 知道他是否可向 Julie 发送电子邮件,或者他是否需要面对面地讨论以提高效率。在理想情况下,团队拥有他们履行构建所需软件任务所必备的技能。在实践中,自行组建的团队非常适合技术牢固、透彻理解软件开发最佳实践且对敏捷方法有一定了解的人。

对于较新的或更年轻的团队,可能不具备这些条件。他们可能不理解如何针对架构或需求建模解决方案。或者更基本来讲,他们可能不熟悉敏捷方法,不理解不同的实践。

因此,在自行组建团队时,您需要考虑技能和经验成分。技能和经验的缺乏可能导致混乱且散漫的团队环境。还有一种个性特征成分。一些团队成员不习惯于决定他们应该执行哪些任务或按何种顺序执行。一些人可能实际上更喜欢采用更加传统的方式。如果您是团队领导,您必须对这些态度和习惯产生警觉,理解某个人何时需要诱导或引导他们的日常活动。

此处传达的基本信息是,自行组建的团队可以运转,但团队领导让团队自行管理的程度取决于团队的成熟度和能力。优秀的团队领导不会简单地相信团队,全权委托权威专家来完成他们想要的任何事情。相反,优秀的团队领导应该了解团队的进展,密切关注以确保他们朝正确的方向发展。

最后的思考

主流的敏捷理论在向客户交付具有较高商业价值软件方面奠定了牢固的基础,但它可能有点理想化。它并不总是代表 Scott Ambler 和我每天在较大型项目中的经历。我们的目标不是推翻前人的成果,重新发明敏捷方法,因为如果正确实现敏捷方法,那么这些成果是很有用的。我们只是尝试填补所存在的一些空白。

毋庸置疑,对于 DAD,我们没有打算规范化。例如,尽管我们更喜欢在工作项列表中通过用户案例来表示需求,但如果您希望应用用例场景,完全没问题。DAD 是一个框架。您应该选择其中最适合您的敏捷项目需求的技术。

结束语

DAD 可帮助大型软件开发团队成功实现敏捷开发项目。DAD 将来自各种现有的成熟敏捷方法结合到一个框架中,为常见的敏捷方法补充了企业指南。因此,它可帮助具有超过 20 人团队的组织充分利用敏捷开发方法。当组建 DAD 团队时,请记住以下这些技巧:欢迎通才专家,专注于协作技能,为您的项目组建规模适中的团队,理解敏捷团队原则和团队组织,但保持灵活并提防自行组建的团队。

原文来自:http://www.ibm.com/developerworks/cn/rational/agile/forming-dad-teams/

使用特性团队(Feature Team)

敏捷团队更有利于关注价值交付,对这一主题产生了相反的矢量。实际上对于敏捷团队的组织,几乎普遍接受的方式是围绕特性的。如下图所示。
scrumcn1352366254

特性团队方式的优点也非常明显:团队可以形成对实际领域和系统使用方式的专业知识,而且通常可以加速任何特性的价值交付。这种方式的开销更少,因为在对特性的实现中,多支团队不必来回传递待办事项条目。而且在团队之间的相互依赖少很多,计划工作与执行也更简练。

与核心技能对应于技术栈中某一层形成对比的是,特性团队的核心能力对应于某个特性(或特性集)。团队的待办事项被简化了,在任何时间只有一到两个特性,这样必然可以促进高增值特性的快速交付!

也有一些其他作者支持以特性为焦点的方式。例如Highsmith写道:

基于特性的交付意味着工程团队将构建最终产品的特性。

当然,这并不是说团队本身必然是“按特性组织”的,因为所有工程团队到了最后都是为最终产品构建特性,虽然他所说的可能含有某种合理推断。其他人—包括Larman和Vodde,更直接(而且坚决)地提倡特性团队作为组织敏捷团队的最佳方式,他们指出:

特性团队是一种长期、跨职能的团队,能够一个接一个地完成一些端到端的顾客特性。其优点包括提高价值产量、方便知识学习、简化计划、降低浪费….

Larman和Vodde还认为应该“避免构件团队”。不管怎样,他们也指出了采取特性团队方式的若干难题,包括需要更宽泛的技能和产品知识、对代码的同时访问、共享设计职责、以及在实现复用和基础设施工作中的困难,而且还有围绕边界的组织对齐造成某些团队成员错位的可能性。

有时候界限是模糊的

即便有着这样的建议,我们也必须承认特性和构件都是抽象概念,它们的界限并不明确,一个人设计的特性可能是另一人的构件。而且有时候,单一特性最好被实现为独立的、面向服务的构件。

举例来说,TradeStation Securities构建一个在线交易系统,其中“记录”是一个关键的交易者功能,由少量集中的敏捷团队一起在“记录”功能上工作。表面上看起来这是特性团队的一个良好示例,因为记录是该系统的主要特性。

在开发新的在线交易功能时,如“外币兑换交易”(Forex),必须添加新的记录功能。然而驱动这一新记录功能的是一些主要构件,如流化数据、账户管理、与外汇交易市场的交换接口。是应该把新特性的价值流描述为“通过专门的记录功能完成与外汇交易市场的所有交易”吗?如果是,很明显应该产生垂直特性流,而且可能要重新组织团队,从各构件团队吸纳某些成员并针对外汇交易市场的交易创建新的垂直特性团队。或者是否把新特性描述为“Forex交易”加“Forex绘图”?这种情况下的绘图团队是否已经有了适当的组织?这种记录功能是特性集还是构件呢?或者是二者?对这种状况起个什么名字真的重要吗?

即使认为其称谓是可以明确的,特性团队总是最佳选择吗?Keith Black(TradeStation Technologies的副总裁)写道:

在线交易要求在许多不同层次上有着相当深度的专业技能和行业知识,我们没有办法对来自所有构件领域的成员合理地形成特性团队。

因此,在我们向敏捷转型中,我们首先是围绕构件团队进行组织,在成熟之后,我们现在针对特殊情况组建特性团队。虽然特性团队在推动一个计划直到完成中是出色的,但是某些情况下它们就不合理。例如,有二十支特性团队而且他们都依赖某个公共构件,比如一个时间关键型的联机事务处理引擎,让20支不同的团队都参与到这一关键构件是不明智的。相反,可以选择使其中的变更由单一团队控制,由该团队代理20支团队的需要,并通过对具体特性作出修改确保其他团队不危及他们不了解的区域。

向特性团队倾斜

鉴于每种方式的优点与缺点,答案并非一直都那么明显。但是考虑到敏捷对直接价值交付的焦点,可以向特性团队适当倾斜。正如Mike Cottmeyer指出的:

我倾向于从特性团队开始,只在必须的情况下才转向构件…但这种决定是基于特定状况的。

为了做出这种决定,将必须分析你们的技术多样性…你们系统设计的如何…使用什么工具来管理代码基…你们团队的规模与技能…团队是如何定位以及分布在哪里…还包括你们的基础设施自动化的品质。

必须认真研究要把特性团队分解到什么程度…到了某种规模特性团队会瓦解。伸缩到这样的程度是我们必须现在处理的吗,还是可以等待?

在混合型的开发和受限于服务品质协议的bug修正团队中使用敏捷

如今在大多数的软件开发组织中,没有专门的维护工程(SE)团队来关注已发布产品的维护和支持。工程(研发)团队除了完成产品的功能开发外,要花费同样的时间来完成维护任务。然而,支持服务品质协议(SLAs)的维护支付的客户通常都很严格,所以比起研发,维护工程经常有更高的优先权。然后遵循scrum的工程团队由于维护工程问题的大量涌入以及对于迅速解决问题的需求,他们无法成功地递交承诺的功能。在功能开发和修改bug中挣扎反作用于团队士气和工作积极度。
以下基于scrum的选择是由小组成员提出建议来克服在这些情况下发生的问题的。 Read more

敏捷绩效评估

每年我们都痴迷于为团队成员评级。回顾软件开发领域,好像已经有近50年历史,有一些我们可以肯定的是:软件是由团队来创建的,而不是个人的。此外,每个人都需要积极主动的合作来生产有质量的软件,这意味着团队中的每个人来承担集体所有制,并且相互帮助。因为他的主旨并不是成为一名英雄,而是创建一个超高质量和可预测的最终产品。 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

看看团队的故事点数如何从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