搜索
关闭此搜索框。

什么是Scrum?

Scrum知识库全面介绍了Scrum的理念、角色、流程、工具使用等各方面的核心知识,旨在帮助您快速全面地了解和学习Scrum的知识体系。

Scrum是一个用于开发和维护复杂产品的框架

Scrum是一个用于开发和维护复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint backlog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目,但它适用于任何复杂的或是创新性的项目。

Scrum流程图
Scrum流程图

 

Scrum框架包括3个角色、3个工件、5个事件、5个价值观

 

3个角色

  1. 产品负责人(Product Owner)
  2. Scrum Master
  3. 开发人员(Developers)

 

3个工件

  1. 产品Backlog(Product Backlog)
  2. Sprint Backlog
  3. 产品增量(Increment)

 

5个事件

  1. Sprint(Sprint本身是一个事件,包括了如下4个事件)
  2. Sprint计划会(Sprint Planning)
  3. 每日站会(Daily Scrum)
  4. Sprint评审会(Sprint Review)
  5. Sprint回顾会(Sprint Retrospective)

 

5个价值观

  1. 承诺 – 愿意对目标做出承诺
  2. 专注 – 把你的心思和能力都用到你承诺的工作上去
  3. 开放 – Scrum 把项目中的一切开放给每个人看
  4. 尊重 – 每个人都有他独特的背景和经验
  5. 勇气 – 有勇气做出承诺,履行承诺,接受别人的尊重

 

Scrum理论基础

Scrum以经验性过程控制理论(经验主义)做为理论基础的过程。经验主义主张知识源于经验,以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下:

第一:透明性(Transparency)

透明度是指,在软件开发过程的各个环节保持高度的可见性,影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面,而且必须理解他们看到的内容。也就是说,当某个人在检验一个过程,并确信某一个任务已经完成时,这个完成必须等同于他们对完成的定义。

第二:检验(Inspection)

开发过程中的各方面必须做到足够频繁地检验,确保能够及时发现过程中的重大偏差。在确定检验频率时,需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度,那么就会出现问题。幸运的是,软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

第三:适应(Adaptation)

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准,并且最终产品是不合格的,那么便需要对过程或是材料进行调整。调整工作必须尽快实施,以减少进一步的偏差。

Scrum中通过三个活动进行检验和适应:每日例会检验Sprint目标的进展,做出调整,从而优化次日的工作价值;Sprint评审和计划会议检验发布目标的进展,做出调整,从而优化下一个Sprint的工作价值;Sprint回顾会议是用来回顾已经完成的Sprint,并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意,并且工作更快乐。

 

Scrum术语

Scrum: Scrum无对应中文翻译

Agile: 敏捷

Lean: 精益

Iterative:迭代式的

Iteration:迭代

Agile Manifesto: 敏捷宣言

Empirical: 经验性的

Empirical Process:经验性过程

Transparency: 透明性

Inspect and Adapt: 检视与调整

Sprint:原意为冲刺,Scrum中的Sprint无对应中文翻译,指一个迭代

Sprint Goal:Sprint目标

Product Owner :产品负责人,简称PO

Scrum Master :简称SM,一般不翻译

Developers :开发人员(Scrum团队中除了PO和SM之外的所有人)

Scrum Team:Scrum团队,含PO、SM和开发人员

Scrum Roles:Scrum角色,指PO、SM和开发人员

Emergent :涌现的

Product Backlog:产品待办列表,指需求清单

Sprint Backlog:Sprint待办列表,指Sprint任务清单

Sprint Burn-down Chart:Sprint燃尽图,团队用于做Sprint内的进展跟踪

Release Burn-down Chart:  发布燃尽图,产品负责人做发布进展跟踪

Sprint Planning: Sprint计划会

Daily Scrum:每日站会

Sprint Review:Sprint评审会

Sprint Retrospective: Sprint回顾会

Product Backlog Refinement: 产品待办列表梳理

Product Backlog Item: 产品待办清单条目,简称PBI

User Story: 用户故事,指一条需求

Story Point:衡量用户故事的工作量大小的计量单位

Velocity: 团队速度

Sprint Task: 实现一条需求需要做的一个技术任务

Definition of Done: DoD,完成的定义

Stakeholders: 干系人

Backlog: 待办列表

Artifact :工件

Estimation :估算

Collaboration: 协作

Scaling Scrum:大规模Scrum

 

Scrum起源

Scrum的原始含义

Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。争球双方各有8个队员参与,各方出3名前锋队员,并肩各站成一横排,面对面躬身互相顶肩,中间形成一条通道,其他前锋队员分别站在后面,后排队员用肩顶住前锋队员的臀部,组成3、2、3或3、4、1阵形。然后,由犯规队的对方队员在对阵一侧1码外,用双手低手将球抛入通道,不得有利于本队。当球抛入通道时,前排的3对前锋队员互相抗挤,争相踢球给本方前卫或后卫队员,前卫和后卫队员必须等候前锋将球踢回后,方可移动。

英式橄榄球争球现场

 

1986 Scrum这个词汇首次应用于产品开发

1986年,竹内弘高和野中郁次郎在New New Product Development Game文章首次提到将Scrum应用与产品开发,他们指出:

传统的“接力式”的开发模式已经不能满足快速灵活的市场需求,而整体或“橄榄球式”的方法——团队作为一个整体前进,在团队的内部传球并保持前进,这也许可以更好的满足当前激烈的市场竞争。

 

 1993年Jeff Sutherland首次将Scrum用于软件开发

敏捷思想深受日本工业界最佳实践的影响,尤其是丰田和本田公司推行的精益原则,以及竹内弘高和 野中郁次郎开发的知识管理策略。受到以上思想的影响,以及对世界范围内软件项目的研究,Jeff Sutherland在 1993年首次在Easel公司定义了用于了软件开发行业的Scrum流程,并开始实施。

1995年Jeff Sutherland和Ken Schwaber规范化了Scrum框架,并在OOPSLA 95上公开发布。

2001年 敏捷宣言及原则发布、敏捷联盟成立,Scrum是其中一种敏捷方法。

2001年,Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》。

2002年Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。

 

 

经验性过程

软件开发是一个复杂的活动, 在软件产品开发的过程中不仅存在着需求的不确定性,也存在着技术的不确定性,再加上参与软件开发的主体通常是由多人组成的软件开发团队,加上人的因素,就让整个软件开发的活动变得非常复杂。如下图所示,软件开发活动通常处在下图的很复杂的区域。

projectcomplex

 

为了管理软件开发的活动,我们会引入过程控制来管理它。过程控制通常有两种方式,第一种方式是预定义的过程,第二种方式是经验性过程。

我们所熟知的是预定义的过程,它通常是使用已知的方法解决已知的问题。制造业的生产线就是典型的预定义过程,例如生产饼干、啤酒、汽车的生产线等。预定义的过程的特点是给予固定的输入,得到固定的输出,过程可重复。它的优势在于可以大规模批量生产。预定义过程的缺点在于一旦过程定义出现错误,或产品设计上存在瑕疵,会造成比较大的损失。

beerline

 

如果我们期望解决的问题比较复杂,并且存在着较大的不确定性的时候,我们需要使用经验性过程。经验性过程的特点是过程是不能够完全预先定义好,结果是不可预知的,生产过程是不可重复的。比如研究一项新技术,下一盘棋,踢一场球赛,在过程运行当中,我们需要通过不断的获得真实的反馈,然后进行适应和调整,使得过程能够产出我们需要的结果。

“在过程运行机制相当简单易懂的情况下,典型的做法是采用预定义的建模方式。如果过程复杂程度超出预定义方式的能力范围,便应用经验性方式。”

                                                              ——B.A.Ogunnaike and W.H.Ray

《过程动态学、建模与控制》

软件产品的研发通常存在多很多的不确定性,并且生产的过程非常的复杂,所以更适合使用经验性过程来管理。

Scrum以经验性过程控制理论做为理论基础的过程。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

 

Scrum过程框架的基石包括如下三个方面

 

第一:透明性(Transparency)

透明度是指,在软件开发过程的各个环节保持高度的可见性,影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面,而且必须理解他们看到的内容。也就是说,当某个人在检验一个过程,并确信某一个任务已经完成时,这个完成必须等同于他们对完成的定义。

 

第二:检验(Inspection)

开发过程中的各方面必须做到足够频繁地检验,确保能够及时发现过程中的重大偏差。在确定检验频率时,需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度,那么就会出现问题。幸运的是,软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

 

第三:适应(Adaptation)

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准,并且最终产品是不合格的,那么便需要对过程或是材料进行调整。调整工作必须尽快实施,以减少进一步的偏差。

Scrum中通过三个活动进行检验和适应:每日站会检验Sprint目标的进展,做出调整,从而优化次日的工作价值;Sprint评审和计划会议检验发布目标的进展,做出调整,从而优化下一个Sprint的工作价值;Sprint回顾会议是用来回顾已经完成的Sprint,并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意,并且工作更快乐。

 

Scrum团队的三个角色

Scrum团队

Scrum 的基本单位是小团队,称为 Scrum TeamScrum团队)。 Scrum 团队由一名 Scrum Master,一名 Product Owner 和 Developers 组成。在 Scrum 团队中,没有子团队或层次结构。Scrum 团队是具有凝聚 力的专业团体,一次专注于一个目标,即 Product Goal。

Scrum 团队是跨职能的(cross-functional),这意味着团队成员具有在每个 Sprint 中创造价值而所需的全部技能。他们也是自管理的,这意味着他们在团队内部决定谁做什么、何时做以及如何做。

Scrum 团队规模足够小以保持灵活,同时足够大以便可以在一个 Sprint 中完成重要的工作,通常只有 10 人或更少。总的来说,我们发现较小的团队沟通更好,效率更高。如果 Scrum 团队变得太大,则应考虑将他们重组为多个具有凝聚力的 Scrum 团队,每个团队都专注于同一产品。因此,他们应该共享相同的 Product Goal、Product Backlog 和 Product Owner。

Scrum 团队负责所有与产品相关的活动,包括与干系人的协作、验证、维护、运营、实验、 研究和开发,以及可能需要进行的其他任何活动。组织组建并授权 Scrum团队自行管理他们自己的工作。以可持续的速度在 Sprint 中工作可以提高 Scrum 团队的专注度和一致性。

整个 Scrum 团队都有责任在每个 Sprint 中创建有价值的、有用的 Increment(增量)。 Scrum 在 Scrum 团队中定义了三种特定的职责:Developers、Product Owner 和 Scrum Master。

 

Scrum角色之:Developers

Developers(开发人员)不仅仅是负责开发软件的成员,这里指的是 Scrum 团队中致力于创建每个 Sprint 可用 Increment(增量) 的任何方面的人员。

Developers 所需的特定技能通常很广泛,并且会随着工作领域的不同而变化。但是, Developers 始终要负责: 

  • 为 Sprint 创建计划,即 Sprint Backlog; 
  • 通过遵循 Definition of Done 来注入质量; 
  • 每天根据 Sprint Goal 调整计划; 
  • 作为专业人士对彼此负责。 

 

Scrum角色之:Product Owner

Product Owner(产品负责人)负责将 Scrum 团队的工作所产生的产品价值最大化。 如何做到这一点可能在组织、Scrum团队 和个体之间存在很大差异。 Product Owner 还负责对 Product Backlog 进行有效管理,包括:

  • 开发并明确地沟通 Product Goal ; 
  • 创建并清晰地沟通 Product Backlog 条目(items);
  • 对 Product Backlog 条目进行排序;
  • 确保 Product Backlog 是透明的、可见的和可理解的。 

 

Product Owner 可以自己做上述工作,或者也可以将职责委托他人。 然而无论如何, Product Owner 是负最终责任的人。

为保证 Product Owner 取得成功,整个组织必须尊重他们的决定。这些决定在 Product Backlog 的内容和顺序中可见,并在 Sprint Review 时透过可检视的 Increment 予以体现。 

Product Owner 是一个人,而不是一个委员会。在 Product Backlog 中,Product Owner 可以代表许多干系人的期望要求。那些想要改变 Product Backlog 的人可以尝试去说服 Product Owner 来做到这一点。

 

Scrum角色之:Scrum Master

Scrum Master 负责按照 Scrum 指南的游戏规则来建立 Scrum。他们通过帮助 Scrum 团队 和组织内的每个人理解 Scrum 理论和实践来做到这一点。

Scrum Master 对 Scrum 团队的效能负责。他们通过让 Scrum 团队在 Scrum 框架内改进其实践来做到这一点。 

Scrum Masters 是真正的领导者,服务于 Scrum 团队和作为更大范围的组织。

 

Scrum Master 服务于 Scrum 团队

Scrum Master 以多种方式服务于 Scrum团队 ,包括:

  • 作为教练在自管理和跨职能方面辅导 Scrum 团队成员; 
  • 帮助 Scrum Team 专注于创建符合 Definition of Done 的高价值 Increment; 
  • 促使移除 Scrum Team 工作进展中的障碍;
  • 确保所有 Scrum 事件都发生并且是积极的、富有成效的,并且在时间盒(timebox)内完成。

 

Scrum Master 服务于 Product Owner 

Scrum Master 以多种方式服务于 Product Owner,包括: 

  • 帮助找到有效定义 Product Goal 和管理 Product Backlog 的技巧; 
  • 帮助 Scrum Team 理解为何需要清晰且简明的 Product Backlog 条目; 
  • 帮助建立针对复杂环境的基于经验主义的产品规划(empirical product planning);
  • 当需要或被要求时,引导干系人协作。

 

Scrum Master 服务于组织

Scrum Master 以多种方式服务于组织,包括: 

  • 带领、培训和作为教练辅导组织采纳 Scrum; 
  • 在组织范围内规划并建议 Scrum 的实施; 
  • 帮助员工和干系人理解并实施针对复杂工作的经验主义方法(empirical approach); 
  • 消除干系人和 Scrum 团队之间的隔阂。

 

Scrum的三个工件

Scrum 工件

Scrum 的工件代表工作或价值。它们旨在最大限度地提高关键信息的透明度。因此,为适应而检视它们的每个人对工件都有相同的基础。 

每个工件都包含一个承诺,以确保它提供可增强透明度并聚焦于可度量进展的信息:

  • 对于 Product Backlog 而言,它是 Product Goal。 
  • 对于 Sprint Backlog 而言,它是 Sprint Goal 。 
  • 对于 Increment 而言,它是 Definition of Done。

 

这些承诺的存在是为了强化经验主义和 Scrum Team 及其利益攸关者的 Scrum 价值观。 

 

工件一:Product Backlog – 产品待办事项列表

Product Backlog 是一份涌现的和有序的清单,它列出了改进产品所需的内容。它是 Scrum Team 所 承担工作的唯一来源。

能够被 Scrum 团队在一个 Sprint 中完成(Done)的 Product Backlog 条目被认为准备就绪,在 Sprint Planning 事件中可供选择。它们通常在精化活动后获得这种透明度。Product Backlog 精化是 将 Product Backlog 条目分解并进一步定义为更小更精确的行为。这是一项持续进行的活动,为 Product Backlog 条目增添细节,例如描述、优先顺序和规模。这些属性通常随工作领域而变化。

将要做这项工作的 Developers 负责使其适当的大小。Product Owner 可以通过帮助 Developers 理解和权衡取舍来影响他们。

承诺: Product Goal

Product Goal 描述了产品的未来状态,可以作为 Scrum 团队制定计划的目标。Product Goal 在 Product Backlog 中。Product Backlog 的其余部分涌现,用来定义“做什么”将实现 Product Goal。 

产品是传递价值的载体。它具有明确的边界、已知的干系人和定义明确的用户或客户。产品可以是一种服务、实体产品或其他更抽象的东西。

Product Goal 是 Scrum 团队的长期目标。他们必须先实现(或放弃)一个目标,然后再开始下一 个目标。

 

工件二:Sprint Backlog

Sprint Backlog 由 Sprint Goal (为什么做)、为 Sprint 选择的 Product Backlog 条目(做什么)以及交付 Increment 的可执行计划(如何做)组成。

Sprint Backlog 是 Developers 为其制定的计划。它是 Developers 在 Sprint 期间为实现 Sprint Goal 而计划完成的工作,是一个高度可视且实时的工作画面。因此,随着学到更多,Sprint Backlog 在整个 Sprint 期间会进行更新。它应该有足够的细节,以便他们可以在 Daily Scrum 中检视其进展。

承诺:Sprint Goal

Sprint Goal 是 Sprint 的单个目标。尽管 Sprint Goal 是 Developers 的承诺,但它为实现该目标所需的确切工作方面提供了灵活性。 Sprint Goal 还创造了连贯性和专注点,鼓励 Scrum 团队一起工作而不是分开独自行动。 

Sprint Goal 在 Sprint Planning 事件中确定,然后添加到 Sprint Backlog 中。当 Developers 在 Sprint 期间工作时,他们将 Sprint Goal 铭记在心。如果需要做的工作与预期的不同,他们将与 Product Owner 协作,在不影响 Sprint Goal 的情况下,协商本次 Sprint Backlog 的范围。

 

通过燃尽图(Burn-down Chart)跟进进展

 

Sprint燃尽图(Sprint Burn-down Chart)

Sprint Burndown Chart 显示了Sprint中累积剩余的工作量,它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量,X轴代表的是Sprint的工作日。

burndownChart

在Sprint开始的时候,Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成,但没有完成的任务的工作量是累积工作量,团队会根据进展情况每天更新累积工作量,如果在Sprint结束时,累积工作量降低到0,Sprint就成功结束。

由于在Sprint的刚开始的时候,增加的任务工作量可能大于完成的任务工作量,所以燃尽图有可能略微呈上升趋势。

 

发布燃尽图(Release Burn-down Chart)

在Scrum项目中,团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期,以Sprint为单位, Y轴代表的是剩余工作量,通常以用户故事点、理想人天或者team-days为单位。

 

工件三:产品增量(Product Increment)

一个 Increment 是迈向 Product Goal 的一块坚实垫脚石。每个 Increment 都是之前所有的 Increment 累加起来的,并经过彻底地验证,以确保整合在一起的所有 Increment 都能工作。为了提供价值,Increment 必须是可用的。 

在一个 Sprint 中可以创建多个 Increment。 Increment 的总和在 Sprint Review 中展示,从而支持经验主义。 但是,Increment 可以在 Sprint 结束之前交付给干系人。Sprint Review 决不应该被视为发布价值的关口。 

一项工作除非符合 Definition of Done ,否则不能将其视为 Increment 的一部分。

承诺: Definition of Done 

Definition of Done (完成的定义)是当 Increment 符合产品所需的质量度量标准时对其状态的正式描述。

当一个 Product Backlog 条目符合 Definition of Done 时,就会产生一个 Increment。 

Definition of Done 通过使每一个人对作为 Increment 的一部分、什么样的工作算是已完成的工作有一个共同的理解来创建透明。如果一个 Product Backlog 条目不符合 Definition of Done,那么它就不能发布,甚至不能在 Sprint Review 中展示它。相反,它返回到 Product Backlog 中以供将来考虑。

如果 Increment 的 Definition of Done 是组织标准的一部分,那么所有 Scrum 团队都必须以此为最低标准来遵守。如果它不是组织标准的一部分,那么 Scrum 团队必须制定适合于该产品的 Definition of Done。

 

Scrum的五个事件

Sprint 是所有其他事件的容器。Scrum 中的每个事件都是检视和适应 Scrum 工件的正式机会。这些事件都是为实现所需的透明度而特别设计的。未能按规定运作任何事件将导致失去检视和适应的 机会。Scrum 使用事件来创造规律性,并以此最小化对 Scrum 中未定义的会议的需要。 最理想的是,所有事件都在同一时间同一地点举行,以便减少复杂性。

事件一:Sprint

Sprint 是 Scrum 的核心,在这里创意(idea)转化为价值。

它们是固定时长的事件,为期一个月或更短,以保持一致性。前一个 Sprint 结束后,下一个新的 Sprint 紧接着立即开始。

实现 Product Goal 所需的所有工作,包括 Sprint Planning、Daily Scrum、Sprint Review 和 Sprint Retrospective,都发生在 Sprint 内。

在 Sprint 期间: 

  • 不能做出危及 Sprint Goal 的改变; 
  • 不能降低质量; 
  • Product Backlog 按需进行精化(refined)
  • 随着学到更多,可以与 Product Owner 就范围加以澄清和重新协商。 

 

Sprint 通过确保至少每个日历月一次对达成 Product Goal 的进展进行检视和适应,来实现可预测性。当 Sprint 的长度拉得太长时,Sprint Goal 可能会失效,复杂性可能会上升,同时风险可能会增加。可以使用较短的 Sprint 来产生更多的学习周期,并将成本与工作投入(effort)的风险限制在更短的一段时间内。每个 Sprint 都可以视为一个短期的项目。

存在各种各样的实践来预测进展,例如,燃尽图(burn-downs)、燃起图(burn-ups)或累积流图(cumulative flows)。尽管被证明是有用的,然而这些实践并不能用来取代经验主义的重要性。在复杂的环境中,未来将要发生什么是未知的。只有已经发生的事情才能用来做前瞻性的决策。

如果 Sprint Goal 已过时,那么就可以取消 Sprint。只有 Product Owner 有取消 Sprint 的权力。

 

事件二:Sprint Planning

Sprint Planning 通过安排在 Sprint 中要做的工作来启动 Sprint。最终的计划是由整个 Scrum 团队协作创建的。

Product Owner 要确保与会者准备好讨论最重要的 Product Backlog 条目 ,以及它们如何映射到 Product Goal 。Scrum 团队还可以邀请其他人参加 Sprint Planning 以提供建议。 

Sprint Planning 处理以下话题: 

话题一:为什么这次 Sprint 有价值?

Product Owner 提议产品如何在当前的 Sprint 中增加其价值和效用。然后,整个 Scrum 团队将共同制定一个 Sprint Goal ,用以沟通当前 Sprint 对干系人有价值的原因。必须在 Sprint Planning 结束之前最终确定 Sprint Goal 。

话题二:这次 Sprint 能完成(Done)什么? 

通过与 Product Owner 讨论, Developers 从 Product Backlog 中选择一些条目,放入当前 Sprint 中。 Scrum 团队可以在此过程中精化这些 Product Backlog 条目,从而增加理解和信心。

选择在 Sprint 中可以完成多少任务可能会有挑战。 但是,Developers 对他们以往的表现,他们在即将到来的 Sprint 内的产能以及对他们的 Definition of Done 了解得越多,他们对 Sprint 预测就越有信心。 

话题三:如何完成所选的工作? 

对于每个选定的 Product Backlog 条目,Developers 都会规划必要的工作,以便创建符合 Definition of Done 的 Increment。这通常是通过将 Product Backlog 条目分解为一天或更短的较小条目来完成的。Developers 自行决定如何完成这一工作。没有人告诉他们如何将 Product Backlog 条目转化为价值的 Increment。

Sprint Goal 、这次 Sprint 所选出的 Product Backlog 条目加上如何交付它们的计划称之为 Sprint Backlog。

Sprint Planning 是有时间盒限定的,以一个月的 Sprint 来说最多为 8 个小时。对于更短的 Sprint, Sprint Planning 所需时间通常会更短。

 

事件三:Daily Scrum

Daily Scrum 的目的是检视达成 Sprint Goal 的进展,并根据需要调整适应 Sprint Backlog,以调整即将进行的计划工作。

Daily Scrum 是一个属于 Scrum 团队的 Developers 的 15 分钟的事件。为了降低复杂性,它在 Sprint 的每个工作日都在同一时间同一地点举行。如果 Product Owner 或 Scrum Master 正在积极处理 Sprint Backlog 条目,那么他们将作为 Developers 参与其中。

Developers 可以选择他们想要的任何举行 Daily Scrum 的结构和技术,只要他们专注于实现 Sprint Goal 的进展,并为下一工作日的工作制定可行的计划即可。这可以创建专注点并改进自管理。

Daily Scrum 改善沟通,发现障碍,促进快速决策,从而消除其他会议的需要。

Daily Scrum 并不是唯一一次允许 Developers 调整计划的时间。他们可以在一天中任何时间碰面,详细讨论如何调整适应或重新规划 Sprint 的剩余工作。

 

事件四:Sprint Review

Sprint Review (Sprint 评审会)的目的是检视 Sprint 的成果并确定未来的适应性。Scrum 团队向关键干系人展示他们的工作结果,并讨论 Product Goal 的进展情况。

在 Sprint Review 期间,Scrum 团队和干系人将评审在这次 Sprint 中完成了什么,以及环境发生了什么变化。基于这些信息,与会者可以就下一步的工作进行协作。Product Backlog 也可能会进行调整以适应新的机会。Sprint Review 是一个工作会议,Scrum 团队应避免将其仅限于展示。

Sprint Review 是 Sprint 的倒数第二个事件,Sprint Review 是有时间盒限定的,以一个月的 Sprint 来说,最多为 4 个小时。 对于更短的 Sprint,Sprint Review 通常所需的时间更短。

 

事件五:Sprint Retrospective

Sprint Retrospective(Sprint回顾会)的目的是规划提高质量和效能的方法。 

Scrum 团队检视最近 Sprint 中有关个体、交互、过程、工具和他们的 Definition of Done 的情况如何。被检查的元素通常随工作领域而变化。识别使他们误入歧途的假设,并探究其起源。Scrum 团队讨论在 Sprint 期间哪些进展顺利,遭遇到哪些问题以及这些问题是如何解决(或未解决)的。 

Scrum 团队识别出最有用的改变以提高其效能。最有影响力的改进将尽快得到执行。甚至可以将它们添加到下一个 Sprint 的 Sprint Backlog 中。

Sprint Retrospective 结束 Sprint。它是有时间盒限定的,以一个月的 Sprint 来说,最多为 3 个小时。对于更短的 Sprint,Sprint Retrospective 通常所需的时间更短。

 

Scrum的五个价值观

Scrum 的成功应用取决于人们变得更加精通践行并内化 5 项价值观: 

承诺, 专注, 开放, 尊重和勇气 

  1. 承诺 – 愿意对目标做出承诺
  2. 专注 – 把你的心思和能力都用到你承诺的工作上去
  3. 开放 – Scrum 把项目中的一切开放给每个人看
  4. 尊重 – 每个人都有他独特的背景和经验
  5. 勇气 – 有勇气做出承诺,履行承诺,接受别人的尊重

 

Scrum 团队致力于达成其目标并且相互支持。他们的主要关注点是 Sprint 的工作,以便尽可能地向着这些目标获取最好的进展。Scrum 团队及其干系人对工作和挑战持开放态度。Scrum 团队成员相互尊重,彼此是有能力和独立的人,并因此受到与他们一起工作的人的尊重。Scrum 团队成员有勇气做正确的事并处理那些棘手的问题。

这些价值观为 Scrum 团队的工作、行动和行为指引方向。做出的决定、采取的步骤以及使用 Scrum 的方式应强化这些价值观,而不是削弱或破坏它们。Scrum 团队成员通过 Scrum 事件和工件来学习和探索这些价值观。当 Scrum 团队和与他们一起工作的人们体现这些价值观时,基于经验主义的 Scrum 的三个支柱:透明、检视和适应,就成为现实,并在每个人之间构建信任。

Scrum的四大支柱Scrum4pillar

 

迭代开发

在Scrum的开发模式下,我们将开发周期分成多个1-4周的迭代,每个迭代都交付一些增量的可工作的功能。迭代的长度是固定的,如果我们选择了1周的迭代,那么保持它的长度不要发生变化,在整个产品开发周期内每个迭代都是1周的长度。这里需要强调的是在每个迭代必须产出可工作的增量功能,而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。

 

增量交付

增量是一个 Sprint 及以前所有 Sprint 中完成的所有产品代办事项列表条目的总和。 在 Sprint 的结尾,新的增量必须“完成”,这意味着它必须可用并且达到了 Scrum 团队 “完成”的定义的标准。无论产品负责人是否决定真正发布它,增量必须可用。增量是从用户的角度来描述的,它意味着从用户的角度可工作。

 

自组织团队

Scrum团队是一个自组织的团队,传统的命令与控制式的团队只有执行任务的权利,而自组织团队有权进行设计、计划和执行任务,自组织团队还需要自己监督和管理他们的工程过程和进度,自组织团队自己决定团队内如何开展工作,决定谁来做什么,即分工协作的方式。

 

高优先级的需求驱动

在Scrum中,我们使用Product Backlog来管理需求,Product Backlog是一个需求的清单,Product Backlog中的需求是渐进明细的,Backlog当中的条目必须按照商业价值的高低排序。Scrum团队在开发需求的时候,从Backlog最上层的高优先级的需求开始开发。在Scrum中,只要有足够1-2个Sprint开发的细化了的高优先级的需求,我们就可以启动Sprint了,而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求。

 

Scrum团队

在传统的工作方式下,开发团队会有很多不同的角色,比如项目经理、产品经理、架构师、设计师、用户体验设计师,程序员,测试人员,DBA等等。但是,在Scrum的工作方式下,总共只有三个角色, 这三个角色分别是产品负责人(PO),Scrum Master和开发人员。

我们通常可以以划龙舟的团队角色来类比Scrum的角色,划龙舟通常有舵手、鼓手、划桨团队三个角色。Scrum中的PO就是舵手的角色,他对产品的方向负责,对产品的Why和What负责,对产品的愿景,产品包括哪些主要的特性负责。Scrum中的Scrum Master鼓手的角色,他帮助团队保持高昂的士气,并进行良好的协作,他是一个Scrum的专家,团队的教练,团队的服务式领导。Scrum中的开发人员,对应到龙舟赛的划桨团队,团队必须协调一致,作为一个整体前进,在这样的环境下单打独斗,各自为政没有任何胜算。

Scrum的开发人员对实现Sprint目标需要做的所有事情负责,包括技术方案和决策,团队分工(谁做什么),执行Sprint开发任务等,而且作为自组织的团队,他们也对他们的工作进度的跟踪和管理负责。Scrum开发人员的主要职责包括如下五个方面:

  • 执行Sprint
  • 梳理产品Backlog
  • 做Sprint计划
  • 每天跟进工作进展,并对他们的工作做检查和调整
  • 每个迭代对产品和团队的工作过程做检查和调整

 

Scrum团队有如下10方面的特征

  • 自组织
  • 多元化、跨职能的完整团队
  • 团队成员符合T型技能,即一专多长
  • 持续改进
  • 最大限度的沟通
  • 透明沟通
  • 2个披萨的团队大小(5-9人)
  • 专注、投入
  • 按照可持续的节奏工作
  • 团队长期存在,人员稳定

自组织团队

 

什么是自组织团队?

自组织团队是敏捷软件开发的基本观念 。敏捷宣言的原则中提到 :“最好的架构、需求和设计出于自组织团队 ”。自组织团队也叫做自管理团队、或者被授权的团队。团队被授权自己管理他们的工作过程和进度、并且团队决定如何完成工作。

 

自组织团队和经理领导的团队的区别

对于经理领导的团队来说,团队成员被分配任务,团队成员只有执行任务的权利。

对于经理领导的团队来说,管理者除了要确定目标、方向,团队的上下文(组织结构、团队结构、团队组成),还需要监督和管理团队的过程和进度,分配任务即确定谁做什么。这种团队的管理方式,更多的是命令与控制,以及微观管理。

 

对于自组织团队来说,他们拥有如下权利

  • 团队决定谁做什么,即任务的分配
  • 团队决定如何做,如何实现目标,即团队做技术决策
  • 团队需要在确保目标的前提下制定团队内的行为准则
  • 团队有义务保持过程的透明性
  • 团队监督和管理他们的过程和进度

 

在自组织团队的环境下,管理层关注在如下几个方面

  • 确定团队目标和愿景
  • 确定团队上下文,组织结构、团队结构、团队组成
  • 提供环境和支持(安全感、良好的团队空间、氛围,技能辅导等)
  • 授权团队
  • 训练协作

 

对于自组织团队的普遍误解

  • 误解1:团队自己决定目标是什么 ; 纠正:管理层决定团队目标
  • 误解2:团队自己决定谁进入团队; 纠正:管理层决定团队上下文
  • 误解3:团队自己设计团队结构; 纠正:管理层决定团队上下文
  • 误解4:自组织团队不需要管理者; 纠正:管理者从微观管理转向目标驱动、授权团队的管理方式
  • 误解5:自组织团队需要员工更加主动; 纠正:自组织让团队更加主动,每个人都不喜欢被命令和控制,每个人期望有成就感、期望被认可
  • 误解6:自组织团队想干什么就干什么; 纠正:管理层决定团队目标,团队决定如何实现目标

一个自组织的团队通常由不同职能专业、思考方式和行为模式的成员组成,也就是说它是跨职能的团队。

 

自组织的团队不是与生俱来的,打造一个团队需要一个过程,打造一个组织团队也是一样。打造自组织团队,首先要让团队需要完全自主; 其次,有了自主,管理者需要引导团队持续改进,帮助团队持续地挑战更高的目标;第三,给团队提供环境和支持,引导团队往正确地方向迈进。

 

特性团队

如果我们的产品开发团队只有在10人以内,我们使用一个跨职能的Scrum团队,可以很容易地按照scrum和敏捷的方式开发产品。 但是,如果产品团队规模较大,比如是几十人,甚至几百人的开发团队的时候,我们就需要考虑团队的结构和组织方式。

在一个大的开发组织中,Scrum会把大的开发团队划分成多个5-9人的小团队,那么我们应该按照什么方式来划分呢?

在传统的开发模式下,我们习惯于按照系统的架构模块,或者系统分层组织团队,也有的团队按照系统需求、开发、测试结合系统架构混合组织的方式。这种团队组织的方式,我们称之为组件团队,是指每个团队只是完成系统功能的某一个部件,而不是一个端到端用户可见的功能。

组件团队看起来像这个样子:

组件团队

按照Scrum和敏捷的交付模式,组件团队有如下一些限制:

第一:按照组件来组织团队,很难避免团队之间的依赖,跨团队的协调和依赖管理更加复杂,不利于跨组件或者各个层之间的沟通。

第二:每个团队专注在自己的模块,由于各模块、或分层需求工作量的不同,很容易产生等待,并且容易产生低价值的交付。

第三:由于职责单一,限制了学习,使得专业更加单一化

第四:Sprint结束的时候无法提交可交付的增量产品功能,延迟价值交付

按照Scrum和敏捷的交付模式,以用户为中心,按照用户场景作为边界来组织团队是比较推荐的做法。这种以用户为中心的团队叫做特性团队。

特性团队的特点:

  • 长期稳定的团队,逐个端到端完成客户特性
  • 以客户为中心的特性驱动
  • 跨职能、完整团队
  • 共享代码库,统一的持续集成
  • 拥有通用型专家

 

特性团队看起来像这个样子:

feature team

特性团队的好处:

  • 团队内可以做到端到端,所以减少了等待,周期加快
  • 比较容易在一个Sprint中交付可用的产品增量
  • 减少了团队之间依赖,计划会更容易
  • 责任范围的扩大,各种不同领域的专家在一个团队,增加了
  • 个人学习和团队学习的机会

用户故事

 

什么是用户故事?

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:

1. 角色:谁要使用这个功能。

2. 活动:需要完成什么样的功能。

3. 商业价值:为什么需要这个功能,这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达:

英文:

As a , I want to , so that .

中文:

作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例

作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。

 

Ron Jeffries的3个C

关于用户故事,Ron Jeffries用3个C来描述它:

  • 卡片(Card) – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述,工作量估算等。
  • 交谈(Conversation)- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
  • 确认(Confirmation)- 通过验收测试确认用户故事被正确完成。

 

用户故事的六个特性 – INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好的用户故事应该遵循INVEST原则。

  • 独立性(Independent)— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划,确定优先级,工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
  • 可协商性(Negotiable)— 一个用户故事的内容要是可以协商的,用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述,不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节,实际上限制了和用户的沟通。
  • 有价值(Valuable)— 每个故事必须对客户具有价值(无论是用户还是购买方)。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。
  • 可以估算性(Estimable)—开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。但是让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。
  • 短小(Small)— 一个好的故事在工作量上要尽量短小,最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大,在安排计划,工作量估算等方面的风险就会越大。
  • 可测试性(Testable)—一个用户故事要是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子:软件应该是易于使用的。

 

敏捷估算

无论是团队研发一款产品或者开发某一个项目,我们都需要回答“我们大概什么时间能够完成?”, 或者到某一个时间点,我们能够做到什么程度, 因此和传统的开发模式一样,我们在工作开始之前需要对我们需要做的事情进行工作量的估算。

相对与传统的工作量估算方式,敏捷估算有如下几个特点:

 

1. 团队集体估算

在Scrum的开发过程中,团队共担责任,集体承诺每个Sprint的工作,因此对于工作量的估算敏捷团队采用集体估算的方式。集体估算,通常采用估算扑克作为工具,团队通过玩估算游戏进行集体估算。使用估算扑克来做工作量估算是最有效,也是非常有趣的一种估算方式。估算扑克由一组类似斐波纳契数列的数字组成,这些数字包括:0,0.5,1,2,3,5,8,20,40,?,∞, 每幅扑克有四组这样的数字,可供4个人使用。

估算扑克的使用方法:

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

关注Scrum中文网微信公众号可以获得微信版估算扑克。

 

2. 估算大小,而不是估算时间周期,使用相对估算,而不是绝对估算

一瓶矿泉水,让一个3岁的小妹妹把它喝完所花的时间和一个成年人把它喝完所花的时间肯定不一样,因此同一项工作,不同能力的人完成它花费的时间显然是不一样的。如果我们要估算从家到公司的绝对距离时多少公里,您可能不一定知道,但是如果您时做地铁上班,从家里到公司有多少站,你一定很容易知道,当我们知道有多少站之后,我们就可以大概清楚路上需要花多长时间了。敏捷估算时,我们不会估算绝对时间和周期,我们估算大小,和相对值,也就是倍数。敏捷估算时,我们使用故事点作为计量单位,它是一个倍数,我们会先找一个我们认为最小的一个功能的大小作为参考基准,定义为1个故事点,把其它的故事和它做比较,如果是2倍大小,就是2个故事点,如果是5倍大小,就是5个故事点。

storypoint

 

3. 记录每个Sprint的团队速度

团队速率是一个Scrum团队在一个Sprint中实际完成的故事点数,通过团队速率可以知道团队做的有多快。新开始的项目或产品开发,或者是新团队,没有初始速度,我们可以做1-2个Sprint测算一个速度,作为初始速度。在Sprint执行过程中,我们要记录每个Sprint的速度,为以后的计划做参考。

velocity

我们估算了产品Backlog的故事点总数,然后又知道了每个Sprint团队的平均速度,那么我们就可以推算我们大概需要多少个Sprint可以做完,这样我们就得到了周期。

duration

 

Sprint是什么

Scrum是一种迭代和增量式的产品开发方法,Scrum通过Sprint来实现迭代。一个Sprint是指一个1周-4周的迭代,它是一个时间盒。Sprint的长度一旦确定,保持不变。Sprint的产出是“完成”的、可用 的、潜在可发布的产品增量。Sprint 在整个开发过程中的周期一致。新的 Sprint 在上一 个 Sprint 完成之后立即开始。 
Sprint 包含并由 Sprint 计划会议、每日站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。

Scrum采用迭代增量的方式,是因为需求是涌现的,我们对产品和需求的理解是渐进式的,Sprint长度越长,我们需要预测的越多,复杂度会提升、风险也会增加,所以Sprint的长度最多不超过4周。越来越多的团队使用2周的Sprint,很多市场变化快、竞争激烈的领域,比如互联网和移动互联网产品开发团队也会使用1周的迭代。

在Sprint进行过程中,如下内容不能发生变化:

  • Sprint的目标
  • Sprint的质量目标和验收标准
  • 开发团队的组成

 

集中优势兵力各个击破

在Sprint执行的过程中,团队要避免一个萝卜一个坑的工作方式,团队要协作,并且要集中优势兵力各个击破。

团队按照蜂拥式(Swarming)的工作方式,团队先集中工作在少数几个需求上面,协作完成它们,然后在开始下一批需求。按照这样的方式一方面可以加强团队协作,另外也有利于及早完成一些需求,让这些需求及早验收。

 

取消一个 Sprint

Sprint 可以在 Sprint 时间盒结束之前取消。只有产品负责人才有取消 Sprint 的权 力,但他做这样的决定也可能是受到利益干系人、团队或是 Scrum Master 的影响。

如果某个 Sprint 的目标过时了,那么就需要取消该 Sprint。比如公司的发展方向, 或是市场、技术等情况发生了变化,这些变化都可能导致取消 Sprint。总的来说,如果某 个 Sprint 对于其所在环境来说失去了价值和意义,那么它就应该被取消。然而,因为 Sprint 周期都较短,所以很少发生取消 Sprint 的情况。

当某个 Sprint 被取消时,任何做完和“完成”的产品待办事项列表条目都需要评审。假如有些条目已经潜在可交付,那产品负责人就会采纳它。所有未完成的条目就都要 放回到产品待办事项列表中,并重新估算。花在它们身上的工作会迅速贬值,所以需要频 繁地重估。

取消 Sprint 会消耗资源,因为每个人都需要在新召开的 Sprint 计划会议中重新开始 另一个 Sprint。Sprint 终止通常会对团队造成重创,因此这种情况也非常少见。

 

每日站会

 

每日站会的目的

在介绍如何开每日站会前,让我们先了解一下召开每天的站会的目的和意义是什么?敏捷宣言强调个体交互重于过程和工具,敏捷原则阐述了面对面的沟通和自组织的团队这些敏捷的核心思想。Scrum的团队是一个自组织的团队,团队每天进行每日站会是团队面对面沟通和团队自组织的体现。Scrum的理论基础是通过保持过程透明性让参与过程的所有人了解真实状况,然后进行检查和调整,每日站会是Scrum过程进行每天的检查和调整的环节。

 

每日站会是团队自己的会

  • 团队商量决定谁做什么(不能有领导任务指派),为当天排一个计划
  • 团队沟通状态,了解现状,发现障碍
  • 团队回顾昨天的工作,做调整,持续改进

 

什么时候、在什么地点开每日站会?

Scrum定义了开展每日站会的一些基本的规则。每日站会必须每天在同一时间、同一地点召开,最好的方式是在团队的可视化的任务板前面召开。 任务板上可以看到当前Sprint的燃尽图(Burn Down Chart)和Sprint中每个任务的状态。

在每日站会开始之前,团队需要在任务板上更新任务的状态。这样的好处是在开会的时候,每个人都可以看到当前的进展情况。

每日站会是Scrum团队每天的第一件事情,这样可以让每个人在每天一开始就清楚的了解他一天的安排。对于跨国界的团队,存在时间差的情况,可以根据实际情况做调整。

 

每日站会的纪律

会议时间最多不超过15分钟。所有的团队成员自觉按时到场,因为会议很短,按时召开按时结束是很重要的。团队需要建立他们的工作协议来确保团队成员按时出席,并且遵守站会纪律,比如团队可以商量对于迟到的人员要有一些让他们改进的措施,比如适当的给一些罚金,多少由团队共同决定,这些钱如何支配也由团队共同决定, 或者做俯卧撑、挂一个迟到的牌子等等。

每日站会一定要站着开,每个人要精神集中,不能有懒散的表现。

每个人回答三个问题:

我昨天完成了什么任务?

我今天打算完成什么任务?

我遇到了哪些障碍或困难?

同一时间只能有一个人发言,会上只说和这三个问题相关的话题,任何跑题的讨论,需要被ScrumMaster制止。一些的确需要讨论的问题,可以先记录下来,会后作为专题来讨论。

 

为什么每日站会没有效果?

每日站会和传统的项目会议有如下几点不同:

  1. 不会有ScrumMaster或者其他任何人来指派任务。
  2. 团队成员不是向ScrumMaster汇报情况,每日站会是团队自己的会。
  3. 团队成员不会在会上讨论或者解决问题,大家会把问题记录下来,会后找相关的人讨论或召开具体的讨论会议。
  4. 任何团队之外的人不得发言或干扰会议。

Scrum的最基本原则是“Inspect and Adapt”(检视然后适应),如果什么事情做得很好,问问自己为什么,然后寻找提升的办法。

如果每日站会没有效果,检查一下这些规则:你是不是每天在认真开每日站会?如果不是为什么?如果你改变了Scrum的一些基本的规则,你可能会面临一些风险,因为这些规则都是经过锤炼和项目考验的一些通用规则。所以第一步,你可以先按照书本上的方式来做。

如果这还不够,参考一下其他人的实践经验,比如:Martin Fowler’s 《Patterns of Daily Stand-up Meetings》

 

你如何知道每日站会起到了很好的效果?

一个好的每日站会有如下几个特点:

  1. ScrumMaster不会逐个的问每个人问题,如果是,那么这个会议已经沦为了报告会。
  2. 团队成员互相交流,不是向ScrumMaster报告。
  3. 每日站会都会在15分钟以内完成。如果你遵守了规则并按照正确的方式开会,你就不需要再担心超时了。
  4. 站会结束后,ScrumMaster知道哪些问题需要帮助团队成员解决。

一个自组织的团队有一个非常明显的每天的节奏:Daily Scrum之前非常安静,每日站会之后会有一段活跃的讨论,到中餐前的时候就慢慢安静下来了。午饭之后会有另外一个阶段的活跃讨论,当下班前慢慢的安静下来。这就是一个自组织团队的脉冲。如果你能够感受到这个节奏,则说明团队是很健康的,每日站会起到了很好的效果。

 

“完成”的定义

当产品代办事项列表条目或者增量被描述为“完成”的时候,每个人都必须理解“完 成”意味着什么。虽然这在不同的 Scrum 团队之间会有巨大的差别,但是团队成员必须对 完成工作意味着什么有相同的理解,这样才能保证透明性。这就是 Scrum 团队的“完成” 定义,用来评估产品增量在什么时候完成。

这个定义也同时被用来指导开发团队了解在 Sprint 计划会议的时候他们能选择多少 产品代办事项列表条目。每个 Sprint 的目标都是交付遵循 Scrum 团队当前的“完成”定 义的潜在可交付功能增量。

开发团队在每个 Sprint 交付产品功能增量。这个增量是可用的,所以产品负责人可以选择立即发布它。每个增量都附加于之前所有增量并经过充分测试,以此保证所有的增量都能工作。

随着 Scrum 团队的成熟,我们预期“完成”的定义会扩大,包含更严厉标准来保证高质量。

需要注意的是,如果在每个迭代,我们对“完成”的标准要求过低,那么这会导致在每个迭代,我们都会遗留一些完成外的工作,完成外的工作持续累计会增加项目的风险,有可能导致产品负责人决定发布的时候,产品却因为累积了过多的完成外的工作而无法发布,以致于我们还需要一个额外的Sprint来使它稳定。

 

Scrum Master检查清单

一位合格的ScrumMaster通常能够同时处理2到3个团队的事务。如果你愿意把你的角色限制在组织会议,控制时间盒以及处理团队成员提出的障碍的话,你可以将这个角色当作成兼职来对待。在这种情况下,团队仍然有可能达到预期的目标,而且有可能不会发生什么重大事故。但是如果你展望团队能够做到你之前无法想象的事情的时候,你就成为了一位出色的ScrumMaster。

一位出色的ScrumMaster一次能够负责一个团队。

我们推荐每个7人左右的团队都有一位专职的ScrumMaster,尤其是刚开始实施Scrum的时候。

如果你还没有发现你能够做的事情的话,尝试聆听Product Owner,团队还有团队以外的公司成员的想法。下面我列出了一些ScrumMaster常忽略的东西。

 

Product Owner干得怎么样?

  1. 你可以通过帮助Product Owner维护产品待办事列表和发布计划来提高他的效率。(需要注意的是只有Product Owner才能给待办事列表里面的项目排列优先级。)
  2. 产品待办事列表里面的项目已经根据Product Owner的最新想法排好优先级了吗?是不是所有来自股东的需求都已经被待办事列表中的项目涵盖了?要记得待办事列表是涌现的。
  3. 产品待办事列表的大小是否还能够维护呢?为了使列表更容易维护,应该将细粒度的项目放在靠前的位置,而把粗粒度的项目放在底部。但是要注意的是如果在分析需求上面花费过多的时间,效果只会适得其反,因为你的需求会在团队和客户/股东的持续谈话中发生变化。
  4. 需求(特别是在产品待办事列表最顶端的需求)能够以独立的、有价值的、可协商的、可估计的、可测试的小粒度用户展现出来吗?
  5. 你是否已经让你的Product Owner了解什么是技术债务以及如何避免吗?其中一个方法就是把自动化测试和重构这两项任务加入到每个待办事列表项目的完成的定义中。
  6. 待办事列表是不是能让所有股东都能够看懂?
  7. 如果你正在使用自动工具来管理你的待办事列表,想一下它真的能够帮助你吗?自动化的管理工具有可能成为ScrumMaster了解信息的障碍。
  8. 你能够通过有效地把信息打印出来然后传达给其他人吗?
  9. 你能够通过制订可视化图表来传达足够的信息吗?
  10. 你有曾经帮助过Product Owner整理待办事列表项目,然后分配到不同的版本中去吗?
  11. 是否所有人(包括股东和团队)都知道目前的团队速率是否能够赶上发布的计划呢?
  12. Product Owner有根据上次Sprint评审会议来调整发布计划吗?通常Product Owner应该至少在个Sprint之后调整发布计划,一般来说会把一些工作放到后面的版本中,原因是发现了一些更重要的工作要做。你可以在每个Sprint评审会议的时候给大家展示Mike Cohn的产品和版本燃尽图,这样就可以更早地发现当前的进度是不是能够符合预期。

 

团队做得怎么样?

  1. 团队成员是否在大多数时间里都能够进入“流”的状体?下面是这种状态的一些特征(摘录自Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi):有清晰的目标();集中且专注,高度集中在某个特定的领域或事物上;失去自我意识,完全沉浸在动作和兴趣中;扭曲的时间感受,只能感受到主观世界的时间;直接和立即的反馈(无论是成功还是失败都能够马上感知到,以马上对行为进行调整);在能力和挑战之间保持平衡;自我的控制能力;行为能够从本质上有所回报,所以感觉毫不费力。
  2. 团队成员之间相处得怎么样?气氛融洽吗?有为彼此的成功感到高兴吗?
  3. 团队成员之间会以高标准要求对方吗?会互相挑战来促进成长吗?
  4. 有没有一些事情团队会觉得不舒服而避免讨论的?(详见:Crucial Conversations: Tools for Talking When Stakes are High)或者引入专家来缓解不安的谈话情绪。
  5. 有没有试过以不同方式或者在不同地点举行Sprint回顾会议?详见:Agile Retrospectives: Making Good Teams Great (Esther Derby/Diana Larsen)
  6. 团队在开发过程中有没有集中在验收标准上?也许你应该在Sprint当中举行一次会议来评审当前Sprint所承诺的产品待办事列表项目的验收标准。
  7. Sprint待办事列表能够真正反映出团队正在做的事情吗?所有对Sprint的目标的打断和干扰都应该被视为障碍。
  8. 团队有保持更新任务版吗?
  9. 团队的任务版和燃尽图都能够很容易地被团队看见和使用吗?
  10. 团队成员都能够自己领取任务吗?
  11. 团队能够被保护得足够好而避免微管理吗?
  12. 用于解决技术债务的事项都能够在待办事列表里面反映出来吗?还是需要和Product Owner另外沟通呢?
  13. 团队成员会在团队的房间外忽略自己的职称吗?
  14. 是不是整个团队都将团队看作一个整体,对测试和编写文档共同担当责任呢?

 

工程实践进行得怎么样?

  1. 你们正在开发的系统有“开始测试”按钮能让每个都很容易地察觉到自己是否破坏了某些功能呢?通常这个是靠xUnit框架来实现的(JUnit,NUnit等等)。
  2. 你们能够在自动化端对端系统测试和自动化单元测试之间保持平衡吗?
  3. 团队在开发系统功能测试和单元测试的时候使用的是同一种语言吗(而不是使用团队里只有部分成员懂的脚本语言)?这个是可能的。
  4. 你的团队能够发现系统测试和单元测试之间的灰色地带吗?
  5. 你们的持续集成服务器能够在回归测试出现错误的一个小时(或者一分钟)内自动发出警报吗?
  6. 所有的测试都能够在CI服务器的测试结果报告中反映出来吗?
  7. 团队能够发现持续设计和无情的重构,而不是一开始就进行详细的设计带来的乐趣吗?重构拥有一个严格的定义:改变系统的内部结构而不改变其外部行为。重构需要在每个小时内进行多次,每当有重复代码,复杂的条件逻辑(通常表现为过量的缩进和冗长的方法),糟糕的命名,对象间的过度耦合,一个对象的职责过多等等问题出现的时候就需要进行重构。要在重构的时候有充足的信心,就要有足够的自动化测试覆盖率。测试覆盖率的漏洞和推迟的重构被称作技术债务。
  8. 在你的每个产品待办事列表项目的验收标准中都包含了完全自动化测试和代码重构这两项吗?如果不学习使用极限编程的工程实践,你就不可能在每个Sprint都能完成潜在可交付的产品(正如Kent Beck, Ron Jeffries等人所说的)。
  9. 团队成员多数时间都在结对编程吗?结对编程可以大幅度提高代码的可维护性,也可以大大降低bug出现的机率。但是有时候结对编程实在挑战大家的极限,有时候甚至会使完成任务的时间变长(如果我们更重视数量而不是质量的话)。所以,比较推荐的做法是和团队成员先讨论以选择在一周内大家愿意尝试使用结对编程的时间,而不是从一开始就强迫团队使用结对编程。然后慢慢地,部份人会开始喜欢结对编程的。

 

整个公司的做得怎么样?

  1. 团队之间有没有适当地交流合作呢?Scrum of Scrums是唯一的解决方案。也可以考虑在团队中选出代表参加别的团队的每日站会。
  2. ScrumMaster之间有互相交流吗?
  3. 来自公司内部的困难会在适当的时候被贴到开发总监的办公室的墙上吗?成本能够以金钱、丢失市场的份额、损失的质量或者损失的客户来量化吗?
  4. 你的公司的职业发展道路和你的团队的集体目标相符吗?如果以测试、自动化测试或者开发文档为代价来鼓励编程或者设计架构,那么答案就是否定的。
  5. 你能够帮助公司成为一个学习型企业吗?
  6. 你的公司已经被外界认定为最好的工作场所或者业界的领头羊了吗?

 

恐惧是你的朋友, 一旦你开始意识到你能够做些事情来改变现状,你可能会感到恐惧而退缩。然而,这正是你走上正轨的标志。

原文地址:http://www.scrumalliance.org/articles/194-an-example-scrummasters-checklist

 

0
0
小时
0
分钟
0
由Scrum.org主办的 2024中国Scrum大会 8月17日将在上海开幕
0
0
小时
0
分钟
0
预约回电
留下您的手机号,我们会在第1时间联系您。
热线电话:400-696-6280
Get in Touch
预约回电
预约成功,我们会尽快联系您。
Get in Touch