Scrum敏捷项目管理知识

一、什么是scrum

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

Scrum流程如下图：

SCRUM框架包括3个角色、3个工件、5个活动、5个价值，具体说明如下：

3个角色

1.产品负责人（ProductOwner）

2.ScrumMaster

3.Scrum团队

3个工件

1.产品Backlog（ProductBacklog）

2.SprintBacklog

3.产品增量（Increment）

5个活动

1.产品Backlog梳理会议（ProductBacklogRefinement）

2.Sprint计划会议（SprintPlanningMeeting）

3.每日站会（DailyScrumMeeting）

4.Sprint评审会议（SprintReviewMeeting）

5.Sprint回顾会议（SprintRetrospectiveMeeting）

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：迭代

AgileManifesto：敏捷宣言

Empirical：经验性的

EmpiricalProcess：经验性过程

Transparency：透明性

InspectandAdapt：检视与调整

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

SprintGoal：Sprint目标

ProductOwner：产品负责人简称PO

ScrumMaster：简称SM,一般不翻译

DevelopmentTeam：Scrum开发团队

ScrumTeam：指PO,SM和开发团队

ScrumRoles：Scrum角色，指PO,SM和开发团队

Emergent：涌现的

ProductBacklog：产品待办列表，指需求清单

SprintBacklog：Sprint待办列表，指Sprint任务清单

SprintBurn-downChart：Sprint燃尽图，团队用于做Sprint内的进展跟踪

ReleaseBurn-downChart:发布燃尽图，产品负责人做发布进展跟踪

SprintPlanningMeeting:Sprint计划会议

DailyScrumMeeting：每日站会

SprintReviewMeeting：Sprint评审会议

SprintRetrospectiveMeeting:Sprint回顾会议

ProductBacklogRefinement:产品待办列表梳理

ProductBacklogItem:产品待办清单条目，简称PBI

UserStory:用户故事，指一条需求

StoryPoint：衡量用户故事的工作量大小的计量单位

Velocity:团队速度

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

DefinitionofDone:DoD，完成的定义

Stakeholders：干系人

Backlog：待办列表

Artifact：工件

Estimation：估算

Collaboration：协作

ScalingScrum：大规模Scrum

三、SCRUM起源

Scrum的原始含义

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

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

1986年，竹内弘高和野中郁次郎在NewNewProductDevelopmentGame文章首次提到将Scrum应用与产品开发，他们指出：

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

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

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

1995年JeffSutherland和KenSchwaber规范化了Scrum框架，并在OOPSLA95上公开发布。

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

2001年，KenSchwaber和MikeBeedle推出第一本Scrum书籍《Scrum敏捷软件开发》。

2002年KenSchwaber和MikeCohn共同创办了Scrum联盟。

四、经验性过程

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

图-01

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

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

图－02

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

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

——B.A.OgunnaikeandW.H.Ray

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

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

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

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

第一：透明性（Transparency）

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

第二：检验（Inspection）

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

第三：适应（Adaptation）

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

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

五、SCRUM团队的三个角色

Scrum团队中包括三个角色，他们分别是产品负责人、开发团队和ScrumMaster。

Scrum团队是自组织、跨职能的完整团队。自组织团队决定如何最好地完成他们的工作,而不是由团队外的其他人来指挥他们。

跨职能的团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人。Scrum团队模式的目的是最大限度地优化适应性、创造性和生产力。

Scrum团队通过迭代和增量交付产品功能的方法最大化反馈的机会。增量交付潜在可交付的产品增量保证了每个迭代都有潜在可发布的版本。

Scrum角色之：产品负责人

产品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组织、Scrum团队以及单个团队成员的不同而不同。

产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括:

∙清晰地表达产品代办事项列表条目

∙对产品代办事项列表中的条目进行排序,最好地实现目标和使命

∙确保开发团队所执行工作的价值

∙确保产品代办事项列表对所有人可见、透明、清晰,并且显示Scrum团队的下一步工作

∙确保开发团队对产品代办事项列表中的条目达到一定程度的理解

产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是负责任者。

产品负责人是一个人,而不是一个委员会。产品负责人可能会在产品代办事项列表中体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。

为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。

Scrum角色之：开发团队

开发团队包含了专业人员,负责在每个Sprint的结尾交付潜在可发布的“完成”产品增量。只有开发团队的成员才能创造增量。

开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化开发团队的整体效率和效力。开发团队有以下几个特点:

∙他们是自组织的,没有人(即使是ScrumMaster都不可以)告诉开发团队如何把产品代办事项列表变成潜在可发布的功能。

∙开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。

∙Scrum不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。

∙开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队

∙开发团队不包含如测试或业务分析等负责特定领域的子团队。

开发团队的规模

开发团队最佳规模是小到足以保持敏捷性,大到足以完成重要工作。少于3人的开发团队没有足够的交互,因而所获得的生产力增长也不会很大。小团队在Sprint中可能会受到技能,从而导致无法交付可发布的产品增量。大于9人的团队需要过多的协调沟通工作。大型团队会产生太多复杂性,不便于经验过程管理。产品负责人和ScrumMaster的角色不包含在此数字中,除非他们也参与执行Sprint代表事项列表中的工作。

Scrum角色之：ScrumMaster

ScrumMaster负责确保Scrum被理解并实施。为了达到这个目的,ScrumMaster要确保Scrum团队遵循Scrum的理论、实践和规则。ScrumMaster是Scrum团队中的服务式领导。

ScrumMaster帮助Scrum团队外的人员了解他们如何与Scrum团队交互是有益的。ScrumMaster通过改变这些交互来最大化Scrum团队所创造的价值。

ScrumMaster服务于产品负责人

ScrumMaster以各种方式服务于产品负责人,包括:

∙找到有效管理产品代办事项列表的技巧

∙清晰地和开发团队沟通愿景、目标和产品代表事项列表条目

∙教导开发团队创建清晰简明的产品代表事项列表条目

∙在经验主义环境中理解长期的产品规划

∙理解并实践敏捷

∙按需推动Scrum活动

ScrumMaster服务于开发团队

ScrumMaster以各种方式服务于开发团队,包括:

∙指导开发团队自组织和跨职能

∙教导并领导开发团队创造高价值的产品

∙移除开发团队进展过程中的障碍

∙按需推动Scrum活动

∙在Scrum还未完全被采纳和理解的组织环境下指导开发团队

ScrumMaster服务于组织

ScrumMaster以各种方式服务于组织,包括:

∙领导并指导组织采用Scrum

∙在组织范围内计划Scrum的实施

∙帮助员工及干系人理解并实施Scrum和经验性产品开发

∙发起能提升Scrum团队生产力的变革

∙与其他ScrumMaster一起工作,帮助组织更有效的应用Scrum

六、SCRUM的三个工件

Scrum的工件以不同的方式展现工作和价值,可以用来提供透明性以及检验和适应的机会。Scrum中所定义的工件能最大化关键信息的透明性,来保证Scrum团队成功地交付完成的增量。

ProductBacklog–产品待办事项列表

产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

产品待办事项列表是一个持续完善的清单,最初的版本只列出最初始的和众所周知的需求。产品待办事项列表根据产品和开发环境的变化而演进。待办事项列表是动态的,它经常发生变化以识别使产品合理、有竞争力和有用所必需的东西。只要产品存在,产品待办事项列表就存在。

产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变。产品待办事项列表条目包含描述、次序和估算的特征。

产品待办事项列表通常以价值、风险、优先级和必须性排序。它是一个按照优先级由高到低排列的一个序列，每个条目有唯一的顺序。排在顶部的产品待办事项列表条目需要立即进行开发。排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值的意见越一致。

排序越高的产品待办事项列表条目比排序低的更清晰、更具体。根据更清晰的内容和更详尽的信息就能做出更准确的估算。优先级越低,细节信息越少。开发团队在接下来的Sprint中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过,因此,任何一个条目在Sprint的时间盒内都可以被“完成”。开发团队在一个Sprint中可以“完成”的产品待办事项列表条目被认为是“准备好的”或者“可执行的”,能在Sprint计划会议中被选择。

随着产品的使用、价值的获取以及市场的反馈,产品待办事项列表变成了更大、更详尽的列表。因为需求永远不会停止改变,所以产品待办事项列表是个不断更新的工件。业务需求、市场形势和技术的变化都会引起产品待办事项列表的变化。

若干个Scrum团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办事项列表只能有一个。那么这就需要使用对产品待办事项列表条目进行分组的属性。

通过产品Backlog地梳理来增添细节、估算和排序。这是一个持续不断的过程,产品负责人和开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表梳理的时候,条目会被评审和修改。然而,产品负责人可以随时更新产品代办事项列表条目或酌情决定。

梳理在Sprint中是一项兼职活动,在产品负责人和开发团队之间展开。通常,开发团队有自行优化的领域知识。然而,何时如何完成优化是Scrum团队的决定。优化通常占用不超过开发团队10%的时间。

开发团队负责所有的估算工作。产品负责人可以通过协助团队权衡取舍来影响他们的决定。但是,最后的估算是由执行工作的人来决定的。

监控向目标前进的进度

在任何时间,达成目标的剩余工作量是可以被累计的。产品负责人至少在每个Sprint评审的时候追踪剩余工作总量。产品负责人把这个数量与之前Sprint评审时的剩余工作量做比较,来评估在希望的时间点完成预计工作达成目标的进度。这份信息对所有的干系人都透明。

Scrum不考虑已经花在产品代办事项列表条目上的工作时间。我们只关心剩余工作和日期这两个变量。

各种趋势燃尽图、燃烧图和其他计划实践都能用来预测进度。它们已经被证实有用。然而,这并不能代替经验主义的重要性。在复杂的环境下,将要发生的东西是未知的,只有已经发生的事情才能用来做前瞻式的决策。

SPRINTBACKLOG

Sprint代办事项列表是一组为当前Sprint选出的产品代办事项列表条目,外加交付产品增量和实现Sprint目标的计划。Sprint代办事项列表是开发团队对于哪些功能要包含在下个增量中,以及交付那些功能所需工作的预计。

Sprint代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量所需要执行的工作。Sprint代办事项列表使开发团队确定的、达到Sprint目标所需的工作清晰可见。

Sprint代办事项列表是一份足够具体的计划,使得进度上的改变能在每日例会中得到理解。开发团队在整个Sprint中都会修改Sprint代办事项列表,Sprint代办事项列表也会在Sprint的进程中慢慢显现,比如开发团队按照计划工作并对完成Sprint目标所需的工作有更多的了解。

当出现新工作时,开发团队需要将其追加到Sprint待办事项列表中去。随着任务进行或者被完成,需要更新每项任务的估算剩余工作量。如果计划中某个部分失去开发的意义,就可以将其除去。在Sprint内只有开发团队可以对Sprint待办事项列表进行修改。Sprint待办事项列表是高度可见的,是对团队计划在当前Sprint内完成工作的实时反映,并且,该列表只属于开发团队。

ProductBacklog功能点被放到Sprint的固定周期中，SprintBacklog会因为如下原因发生变化:

1.随着时间的变化，开发团队对于需求有了更好的理解，有可能发现需要增加一些新的任务到SprintBacklog中。

2.程序缺陷做为新的任务加进来，这个都做为承诺提交任务中未完成的工作。

ProductOwner也许会和Scrumteam一起工作，以帮助team更好的理解Sprint的目标，ScrumMaster和team也许会觉得小的调整不会影响sprint的进度，但会给客户带来更多商业价值。

监控Sprint进度

在Sprint中的任意时间点,Sprint待办事项列表的所有剩余工作总和都可以被计算。开发团队至少在每日例会时追踪所有的剩余工作。开发团队每天追踪剩余总和并预测达成Sprint目标的可能性。通过在Sprint中不断追踪剩余工作,开发团队可以管理自己的进度。

Scrum不考虑已经花在Sprint待办事项列表上的工作时间。我们只关心剩余工作和日期这两个变量。

燃尽图（BURN-DOWNCHART)

Sprint燃尽图（SprintBurn-downChart)

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

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

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

发布燃尽图（ReleaseBurn-downChart）

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

七、SCRUM的五个活动

Scrum活动:产品待办事项列表梳理

产品待办事项通常会很大,也很宽泛,而且想法会变来变去、优先级也会变化,所以产品待 办事项列表梳理是一个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下的内容:

∙保持产品待办事项列表有序

∙把看起来不再重要的事项移除或者降级

∙增加或提升涌现出来的或变得更重要的事项

∙将事项分解成更小的事项

∙将事项归并为更大的事项

∙对事项进行估算

产品待办事项列表梳理的一个最大好处是为即将到来的几个Sprint做准备。为此,梳理时会特别关注那些即将被实现的事项。需要考虑不少因素,这包括但不限于以下的内容:

理想情况下,下一个Sprint的备选事项都应该提升“商业价值”。 开发团队需要能够在一个Sprint内完成每一个事项。每个人都需要清楚预期产出是什么。

产品开发决定了,有可能需要其它的技能和输入。因此,产品待办事项列表梳理最好是所有团队成员都参与的活动,而不单单是产品负责人。

Scrum活动：Sprint计划会议

每个Sprint都以Sprint计划会议作为开始， 这是一个固定时长的会议，在这个会议中,Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作。

整个团队都要参加Sprint计划会议。针对排好序的产品待办事项列表(Product Backlog),产 品负责人和开发团队成员讨论每个事项,并对该事项达成共识,包括根据当前的“完成的定 义”,为了完成该事项所需要完成的所有事情。所有的Scrum会议都是限定时的。Sprint计划会议推荐时是Sprint中的每周对应两⼩时或者更少(译者注:比如,一个Sprint包含2个星 期,则Sprint计划会议时长应为4个小时或者更少)。因为会议是时长的,Sprint计划会议的成功⼗分依赖于产品待办事项列表的质量。这就是产品待办事项列表梳理十分重要的原因。

在Scrum中,Sprint计划会议有两部分:

1.决定在Sprint中需要完成哪些工作

2.决定这些工作如何完成

第一部分:需要完成哪些工作?

在会议的第一部分,产品负责人向开发团队介绍排好序的产品待办事项,整个Scrum团队共同理解这些工作。

Sprint中需要完成的产品待办事项数目完全由开发团队决定。为了决定做多少,开发团队需要考虑当前产品增量的状态,团队过去的工作情况,团队当前的生产能力,以及排好序的产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其它人,都不能给开发 团队强加更多的工作量。

通常Sprint都有个目标,称作Sprint目标。这将十分有效地帮助大家更加专注于需要完成的工 作的本质,而不必花太多精力去关注那些对于我们需要完成的工作并不重要的⼩小细节。

第二部分:如何完成工作?

在会议的第二部分⾥里,开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增 量。他们进⾏行⾜足够的设计和计划,从而有信心可以在Sprint中完成所有工作。头几天的工作会 被分解成⼩小的单元,每个工作单元不超过一天。之后要完成的工作可以稍⼤大些,以后再对它 们进⾏行分解。

决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责。

在计划会议的第二部分,产品负责人可以继续留下来回答问题,以及澄清一些误解。不管怎样,团队应该很容易找到产品负责人。

Sprint计划会议的产出 Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识,并预期在一个合理的条件范围内完成它们。开发团队预测并共同承诺他们要完成的工作量。 总而⾔言之:在Sprint计划会议中,开发团队和产品负责人一起考虑并讨论产品待办事项,确保他们对这些事项的理解,选择一些他们预测能完成的事项,创建足够详细的计划来确保他们能够完成这些事项。

最终产生的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”。

Scrum活动:每日Scrum会议

开发团队是自组织的。开发团队通过每日Scrum会议来确认他们仍然可以实现Sprint的目标。 这个会议每天在同样的时间和同样的地点召开。每一个开发团队成员需要提供以下三点信息:

从上一个每日Scrum到现在,我完成了什么; 从现在到下一个每日Scrum,我计划完成什么; 有什么阻碍了我的进展。

每日Scrum中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。通常,许多团队 会在每日Scrum之后⻢马上开会处理他们遇到的任何问题。

每日Scrum既不是向管理层汇报,也不是向产品负责⼈人或者ScrumMaster汇报。它是一个开发 团队内部的沟通会议,来保证他们对现状有一致的了解。只有Scrum团队的成员,包括 ScrumMaster和产品负责⼈人,可以在会议中发⾔言。其他感兴趣的⼈人可以来旁听。在必要时, 开发团队会基于会议中的发现重新组织他们的工作来完成Sprint的⺫⽬目标。

每日Scrum是Scrum的一个关键组成部分,它可以带来透明性,信任和更好的绩效。它能帮助 快速发现问题,并促进团队的自组织和自⽴立。所有Scrum会议都是限定时长的。每日Scrum通 常不超过15分钟。

Scrum活动:Sprint评审会议

Sprint结束时,Scrum团队和相关⼈人员一起评审Sprint的产出。所有Scrum会议都是限定时长 的,Sprint评审会议的推荐时长是Sprint中的每一周对应一个小时(译者注:⽐比如,一个Sprint 包含2个星期,则Sprint评审会议时长为2个小时)。

讨论围绕着Sprint中完成的产品增量。由于Sprint的产出会涉及到一些⼈人的“利益”,因此一个明 智的做法是邀请他们参加这个会议,这会很有帮助。这个会议是个⾮非正式的会议,帮助⼤大家 了解我们⺫⽬目前进展到哪⾥里,并一起讨论我们下一步如何推进。每个⼈人都可以在Sprint评审会议 上发表意⻅见。当然,产品负责⼈人会对未来做出最终的决定,并适当地调整产品待办事项列表 (Product Backlog)。

团队会找到他们自己的方式来开Sprint评审会议。通常会演⽰示产品增量,整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表 的状态、可能的完成日期以及在这些日期前能完成什么。

Sprint评审会议向每个⼈人展⽰示了当前产品增量的概况。因此,通常都会在Sprint评审会议中调 整产品待办事项列表。

Scrum活动:Sprint回顾会议

在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在 的改进事项,为将来的改进制定计划。所有的Scrum会议都是限定时长的,Sprint回顾会议的 推荐时长是Sprint中的每一周对应一个小时(译者注:⽐比如,一个Sprint包含2个星期,则 Sprint回顾会议时长为2个小时)。

Scrum团队总是在Scrum的框架内,改进他们自己的流程。

八、SCRUM的五个价值观

承诺 – 愿意对目标做出承诺

专注– 把你的心思和能力都用到你承诺的工作上去

开放– Scrum 把项目中的一切开放给每个人看

尊重– 每个人都有他独特的背景和经验

勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

九、SCRUM的四大支柱

迭代开发

在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计划

∙每天跟进工作进展，并对他们的工作做检查和调整

∙每个迭代对产品和团队的工作过程做检查和调整

开发团队有如下10方面的特征：

∙自组织

∙多元化、跨职能的完整团队

∙团队成员符合T型技能，即一专多长

∙持续改进

∙最大的沟通

∙透明沟通

∙2个披萨的团队大小（5-9人）

∙专注、投入

∙按照可持续的节奏工作

∙团队长期存在，人员稳定

十一、自组织团队

 什么是自组织团队？

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

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

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

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

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

∙团队决定谁做什么，即任务的分配

∙团队决定如何做，如何实现目标，即团队做技术决策

∙团队需要在确保目标的前提下制定团队内的行为准则

∙团队有义务保持过程的透明性

∙团队监督和管理他们的过程和进度

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

∙确定团队目标和愿景

∙确定团队上下文，组织结构、团队结构、团队组成

∙提供环境和支持（安全感、良好的团队空间、氛围，技能辅导等）

∙授权团队

∙训练协作

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

∙误解1：团队自己决定目标是什么 ； 纠正：管理层决定团队目标

∙误解2：团队自己决定谁进入团队； 纠正：管理层决定团队上下文

∙误解3：团队自己设计团队结构； 纠正：管理层决定团队上下文

∙误解4：自组织团队不需要管理者； 纠正：管理者从微观管理转向目标驱动、授权团队的管理方式

∙误解5：自组织团队需要员工更加主动； 纠正：自组织让团队更加主动，每个人都不喜欢被命令和控制，每个人期望有成就感、期望被认可

∙误解6：自组织团队想干什么就干什么； 纠正：管理层决定团队目标，团队决定如何实现目标

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

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

十二、特性团队

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

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

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

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

按照Scrum和敏捷的交付模式，组件团队有如下一些：

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

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

第三：由于职责单一，了学习，使得专业更加单一化

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

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

特性团队的特点：

∙长期稳定的团队，逐个端到端完成客户特性

∙以客户为中心的特性驱动

∙跨职能、完整团队

∙共享代码库，统一的持续集成

∙拥有通用型专家

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

特性团队的好处：

∙团队内可以做到端到端，所以减少了等待，周期加快

∙比较容易在一个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个故事点。

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

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

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

十五、Spring

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.不会有Scrum Master或者其他任何人来指派任务。

2.团队成员不是向Scrum Master汇报情况，每日站会是团队自己的会。

3.团队成员不会在会上讨论或者解决问题，大家会把问题记录下来，会后找相关的人讨论或召开具体的讨论会议。

4.任何团队之外的人不得发言或干扰会议。

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

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

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

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

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

1.Scrum Master不会逐个的问每个人问题，如果是，那么这个会议已经沦为了报告会。

2.团队成员互相交流，不是向ScrumMaster报告。

3.每日站会都会在15分钟以内完成。如果你遵守了规则并按照正确的方式开会，你就不需要再担心超时了。

4.站会结束后，Scrum Master知道哪些问题需要帮助团队成员解决。

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

十七、“完成”的定义

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

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

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

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

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