Scrum密接开发知识
什么是敏捷？
敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。
什么敏捷软件开发？
敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。
自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。
敏捷开发简史
20世纪90年代初，一些轻量级的软件开发方法越来越受到公众的关注，这些方法包括：
1991, Rapid Application Development（RAD）
1994 Dynamic systems development method (DSDM)
1995, Scrum
1996, Crystal Clear ，Extreme Programming (XP)
1997, Feature-driven development（FDD）
这些方法论强调了开发团队和业务干系人之间的密切合作；商业价值频繁交付；紧密合作的自组织团队，以及代码匠艺、验证和交付代码的巧妙方法。
2001年，17位软件开发人员聚集在犹他州的Snowbird，讨论他们的共同想法和各种软件开发方法。经过讨论他们达成了在价值观和原则的共识，并共同发布了敏捷软件开发宣言和相应的十二条原则，宣告了敏捷开发运动的开始。
会议之后，敏捷联盟成立，鼓励业界从业者进一步探索和分享想法和经验。
Scrum的框架
Scrum框架包括3个角色、3个工件、5个事件、5个价值
3个角色
- 产品负责人（Product Owner）
- Scrum Master
- 开发人员（Developers）
3个工件
- 产品Backlog（Product Backlog）
- Sprint Backlog
- 产品增量（Increment）
5个事件
- Sprint（Sprint本身是一个事件，包括了如下4个事件）
- Sprint计划会（Sprint Planning）
- 每日站会（Daily Scrum）
- Sprint评审会（Sprint Review）
- Sprint回顾会（Sprint Retrospective）
5个价值
- 承诺 – 愿意对目标做出承诺
- 专注– 把你的心思和能力都用到你承诺的工作上去
- 开放– Scrum 把项目中的一切开放给每个人看
- 尊重– 每个人都有他独特的背景和经验
- 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
Scrum的理论基础
Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。
Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下：
第一：透明性（Transparency）
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
第二：检验（Inspection）
开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。
第三：适应（Adaptation）
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
敏捷开发十二原则
我们遵循以下原则：
我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何能提高成效，并依此调整自身的行为表现。
Scrum三个角色
Scrum的基本单位是一个小团队，即Scrum团队。Scrum团队由一名Scrum Master、一名产品负责人和若干开发人员组成。在Scrum团队内部，没有子团队或等级制度。它是一个由具备专业技能的成员组成的有凝聚力的团队，每次只聚焦一个目标，即产品目标。
Scrum团队是跨职能的，意味着团队成员拥有在每个Sprint创造价值所需的所有技能。Scrum团队同时也是自管理的，他们在内部自己决定由谁做什么，何时做以及如何做。
Scrum团队要足够的小，以保持灵活性，同时又要足够大，以便能够在一个Sprint中完成特定的工作。Scrum团队的人数通常不超过十人。一般来说，我们发现小团队能够更好的沟通且更加高效。如果Scrum团队变得太大，他们应该考虑重组为多个有凝聚力的Scrum团队，这些团队都专注于同一个产品。因此，他们应该共享同样的产品目标，产品Backlog，和产品负责人。
Scrum团队负责所有与产品相关的活动，包括干系人协作、验证、维护、运营、实验、研发以及其他任何可能需要的活动。他们被以特定的方式组织并授权管理他们自己的工作。在每个Sprint中以可持续的稳定步调工作，可以提高Scrum团队的专注度和一致性。
整个Scrum团队负责在每个Sprint中创造出有价值的，可用的产品增量。Scrum框架在定义了三个在Scrum团队中的特定角色：开发人员（Developers），产品负责人（Product Owner），以及Scrum Master.
Scrum Master
Scrum Master的职责
如Scrum指南中所描述的，Scrum Master负责践行Scrum。他们通过帮助Scrum团队内部及组织的每个人理解Scrum理论和实践来实现这一目标，同时为Scrum团队及更大的组织服务。
然而，Scrum Master 的意义远不止于此，Scrum Master的角色有许多层次和方面。在培养Scrum意识和建立敏捷性的同时，Scrum Master还需要具备一些软技能，来辅导Scrum团队以及组织中的其他成员。Scrum Master有责任帮助团队获得成功，这意味着以小组或一对一的形式为大家提供支持。他们可能通过引导练习，给予指导，或帮助人们自己得出结论。并非每个人都具备成为Scrum Master所需的技能，这一点在考虑职业道路时需要谨记。
最后，Scrum Master要为团队的效率负责，他们帮助Scrum团队改进协作方式，持续创造价值。
Scrum Master具体做什么？
Scrum Master利用他们独特的技能，来完成许多对Scrum团队和组织有帮助的重要工作，具体如下：
Scrum Master**以多种方式帮助Scrum团队:
- 作为教练在自管理和跨职能方面辅导Scrum团队
- 帮助Scrum团队专注于创建符合“完成定义”的高价值增量
- 促进移除 Scrum 团队工作进展中的障碍
- 确保所有 Scrum 事件都发生，且是积极的、富有成效的，并在时间盒内完成
Scrum Master**以多种方式服务于Product Owner:
- 帮助找到有效定义 Product Goal 和管理 Product Backlog 的技巧
- 帮助 Scrum 团队理解为何需要清晰且简明的 Product Backlog 条目
- 帮助建立针对复杂环境的基于经验主义的产品规划（empirical product planning）
- 当需要或被要求时，引导干系人协作
Scrum Master 以多种方式服务于组织，包括：
- 带领、培训和作为教练辅导组织采用 Scrum
- 在组织范围内规划并建议 Scrum 的实施
- 帮助员工和干系人理解并实施针对复杂工作的经验主义方法（empirical approach）
- 消除干系人和 Scrum团队之间的隔阂
Scrum Master 的立场
为了取得成功，Scrum Master必须根据团队所面临的情况或挑战戴上不同的帽子。这些帽子通常被称为立场，在Barry Overeem的白皮书《Scrum Master的8种立场》中有所描述。在任何特定的情况下，Scrum Master都会利用他们重要的软技能来充当服务式领导、引导者、教练、经理、导师、教师、清道夫或变革先锋，具体取决于他们所面临的情况。
例如，Scrum Master可能引导一个新活动，来帮助Scrum团队开展一个更加鼓励成员参与的Sprint回顾会，也可能帮助指导新开发人员如何与团队合作。还可能以教师的立场教授团队成员一些处理冲突的新技巧。这些仅仅是Scrum Master多面技能中的一些部分。
Product Owner
Product Owner的职责
正如Scrum指南中所描述，产品负责人（Product Owner）负责将Scrum团队的工作所产生的产品价值最大化。如何做到这一点，可能在不同的组织、Scrum团队和个人之间存在很大差异。
作为 Scrum 团队的成员之一，产品负责人向团队阐明产品的愿景和目标。所有工作都是根据产品目标衍生出来的，并根据产品目标确定优先级，以便为所有干系人（包括组织内部的干系人和组织内外的所有用户）提供价值。产品负责人在整个产品生命周期中识别、衡量和最大化价值。
Product Owner 具体做什么？
产品负责人（Product Owner）负责对Product Backlog 进行有效的管理，包括：
- 开发并明确地沟通 Product Goal
- 创建并清晰地沟通Product Backlog条目（Items）
- 对Product Backlog 条目进行排序
- 确保Product Backlog是透明的、可见的和可理解的
产品负责人可以完成上述工作，也可以将责任委托给 Scrum 团队的其他成员。无论由谁来做，产品负责人都要对工作的完成和交付的价值负责。
除了Product Backlog 的管理之外，赢得整个组织的尊重对于产品负责人来说非常重要，这样才能在做出决策时获得所需的支持。这是产品负责人成功的关键。这些决策需要在Product Backlog中透明化，并在Sprint Review中展示的增量中可见。
记住，产品负责人是一个人，而不是一个委员会。在 Product Backlog 中，产品负责人可以代表许多干系人的期望要求。那些想要改变 Product Backlog 的人可以尝试通过说服 产品负责人来做到这一点。但最终还是由产品负责人做出决定。产品负责人还需要从最终用户那里获得产品相关的反馈。
Product Owner 的立场
为了实现价值最大化的最终目标，产品负责人可以采取不同的立场。这些立场包括远见者、合作者、客户代表、决策者、实验者和影响者。例如，产品负责人在与所有相关方明确沟通产品愿景、战略、业务目标和目的时，有时会采取远见者的立场；当他们与Scrum团队合作定义目标时，会扮演合作者的角色；或者他们会充当决策制定者，在日常工作中做出各种决定。
产品负责人的职责往往也会被错误地理解，在企业内部有几种被误解的模式，其中包括将产品负责人视为故事编写者、项目经理、主题专家、办事员、把关人或经理。
Developer
Developer的职责
如Scrum 指南所述，开发人员是 Scrum 团队中致力于在每个Sprint中创建可用的增量的人员。
Developer 具体做什么？
重要的是要记住，开发人员并不一定是软件开发人员。他们可以专注于任何类型的产品工作，无论是否是软件，以及帮助设计、构建、测试或交付产品的任何方面。开发人员所需的具体技能往往很宽泛，会根据他们所从事的工作类型而有所不同。不过，开发人员始终对以下方面负责：
- 为 Sprint 创建计划，即Sprint Backlog
- 通过遵循 “Definition of Done” 来内建质量
- 每天根据 Sprint Goal 调整计划
- 作为专业人士对彼此负责
除了这些责任之外，开发人员在一些情况下可能还需要拥抱诸如引导，指导，教授等实践，例如：
- 每日站会（Daily Scrum）是Scrum团队开发人员的活动，需要有人来引导活动的展开。团队自行设法确定引导者。
- 开发人员可能拥有一些其他人不具备的技能，他们可以教授或辅导其他团队成员来完成工作。利用这些技能的绝佳机会往往是采用一种称为“结对编程”的做法，开发人员结对开展工作，分享彼此的技能并相互学习。
对于开发人员和所有 Scrum 团队成员来说，记住始终拥抱 Scrum 价值观非常重要。例如在某些情况下，他们可能需要：勇于提出团队之间的冲突并共同解决；以开放的态度接纳彼此的想法；专注于自己正在做的工作，注意不要分心；承诺创建一个 “完成的增量”；尊重 Scrum 团队的所有成员及他们的想法。
Scrum三个工件
Scrum 的工件代表工作或价值。它们旨在最大限度地提高关键信息的透明度。从而每个检视它们的人都能在相同的基础上进行调整。
每个工件都包含一项承诺，以确保提供用于度量进展所需的透明度和关注点。
- 对于 Product Backlog 而言，它是 Product Goal。
- 对于 Sprint Backlog 而言，它是 Sprint Goal 。
- 对于 增量（Increment） 而言，它是完成的定义（Definition of Done）。
这些承诺的存在是为了强化 Scrum 团队及其干系人的经验主义和 Scrum 价值观。
Product Backlog
如Scrum 指南所述，Product Backlog是一份涌现式的、有序的清单，包含了改进产品所需的工作内容。它是 Scrum 团队开展工作的唯一来源。
在Sprint Planning活动时，Scrum团队能够在一个Sprint之内完成的Product Backlog 条目，被认为是可以选择的。通常在Backlog梳理活动后能够将待办项细化到这个程度。Product Backlog refinement是指把待办项分解并进一步定义成更小更精确的项目。这是一项持续进行的活动，如添加细节和描述，调整排序以及大小。这些属性通常根据工作领域的不同而变化。
工作规模由将进行该项工作的开发人员确定。产品负责人可以通过帮助开发人员理解工作内容，以及进行方案权衡，来施加影响。经常有多个Scrum团队在同一个产品上协作。产品的相关工作都在同一个Product Backlog中进行管理。
Product Backlog Refinement
Product Backlog Refinement（产品Backlog细化）是将产品待办列表中的事项进一步分解并定义为更小更精确的项目的行为。细化可以在Sprint中的任何时间进行，可以通过一次或多次正式会议，可以持续进行或者按需进行。细化工作不是强制的，但为了增加透明度并使工作内容更加精确，细化是一个值得考虑的好实践。
承诺：Product Goal
Product Goal（产品目标）描述了产品未来的状态，可以作为Scrum团队进行计划的目标。产品目标体现在产品的Backlog中。Backlog中的其余部分用来定义产品目标将通过“什么”来实现。
产品是传递价值的载体。它具有明确的边界、已知的干系人和定义明确的用户或客户。产品可以是一种服务、实体产品或其他更抽象的东西。
Product Goal 是 Scrum 团队的长期目标。他们必须先实现（或放弃）一个目标，然后再开始下一个目标。
Sprint Backlog
如Scrum指南所述，Sprint Backlog 由 Sprint Goal （为什么做）、为 Sprint 选择的 Product Backlog 条目（做什么）以及交付 Increment（增量）的可执行计划（如何做）组成。
它是 Developers 在 Sprint 期间为实现 Sprint Goal 而计划完成的工作，是一个高度可视且实时的工作画面。因此，在整个 Sprint 中，Sprint Backlog 会随着了解到更多信息而不断更新。它应该有足够的细节，以便他们能在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 的范围。
Increment
如Scrum指南所述，Increment（增量）是迈向 Product Goal 的一块坚实垫脚石。每个增量都是之前所有的增量累加起来的，并经过彻底地验证，以确保整合在一起的所有增量都能工作。为了提供价值，增量必须是可用的。
在一个 Sprint 中可以创建多个增量。所有累加的增量会在 Sprint Review 中进行展示，从而为经验主义提供支撑。但是，增量可以在 Sprint 结束之前交付给干系人。Sprint Review 决不应该被视为发布价值的关口。
一项工作除非符合 Definition of Done ，否则不能将其视为增量的一部分。
承诺：Definition of Done
如果你刚刚开始使用或学习 Scrum，你会听到很多关于“Done”和“Definition of Done”的说法。把“Done”看作是完成一个产品增量所需的所有要素。Definition of Done 是开发人员对增量的承诺，就像 Sprint Goal 是开发人员对 Sprint Backlog 的承诺，Product Goal 是产品负责人对 Product Backlog 的承诺一样。Definition of Done 包括增量发布所需的所有特性和标准。
Scrum指南指出，Definition of Done 是当增量符合产品所需的质量度量标准时对其状态的正式描述。一旦满足了 Definition of Done，增量就完成并可以交付了。
Definition of Done 通过使每一个人对作为增量的一部分、什么样的工作算是已完成的工作有一个共同的理解来创建透明。如果一个 Product Backlog 条目不符合 Definition of Done ，那么它就不能发布。把 Definition of Done 看作是为已交付产品设定的标准。
有时，增量的 Definition of Done 包括组织的标准。在这种情况下，所有 Scrum 团队都必须至少遵循这些标准。他们可以根据产品需要满足的任何其他标准或特性对其进行详细说明。如果没有特定的组织标准，Scrum 团队必须创建适合自己产品的 Definition of Done。
Scrum五个事件
Scrum 事件是 Scrum 框架的关键元素。他们为Scrum 三大支柱：检视、适应和透明提供了定期的实践机会。此外，它们还帮助团队与 Sprint 目标和产品目标保持一致，提高开发人员的工作效率，移除障碍，并且减少了安排过多其他会议的需要。
Scrum 中共有五个事件（Sprint、Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective），每个事件都有自己的目的、时间限制和参与者。
目的
虽然了解每个事件的细节对于实践有效的 Scrum 非常重要，但在最高的层面上，每个事件的目的其实非常简单：
- Sprint —— Scrum 中的所有工作都是在一系列称为 Sprint 的短项目中完成的。这就能够实现快速反馈的循环。
- Sprint Planning – 每个Sprint 从 Sprint Planning（Sprint 计划会）开始，在这个会议上，开发人员针对打算在 Sprint 中完成的工作进行计划，这能够在团队之间建立一致性和共同的理解。
- Daily Scrum – 开发人员每天碰面，检视他们实现 Sprint 目标的进展，讨论遇到的任何挑战，并根据需要调整第二天的计划。
- Sprint Review —— 在 Sprint 将结束时，团队向干系人展示他们完成的产品，并获得干系人的反馈。
- Sprint Retrospective —— 最后，Scrum 团队聚在一起讨论这一 Sprint 做得如何，看看有哪些方面可以在下一个 Sprint 中改进。
- 以上是一些介绍性的描述，强烈建议大家对每个事件进行更深入的了解。
时间限制
为了帮助建立约束和聚焦，每个 Scrum 事件都有一个预定义的时间限制或时间盒：
- 一个 Sprint 的时间盒不超过一个月，通常持续两周时间。
- 对于长度为一个月的 Sprint，Sprint Planning、Sprint Review和 Sprint Retrospective 的时间盒分别为 8 小时、4 小时和 3 小时。当 Sprint 时长短于一个月时，这些事件的时间盒通常也相应缩短一些。
- 无论 Sprint 的长度为多少，Daily Scrum 的时间盒都是 15 分钟。
时间盒的设置可以使得大家更加聚焦在与会议主题相关的讨论中，不鼓励与会议目标无关的闲谈或讨论。如果团队在时间盒之前已经达成会议目标，那么他们可以简单地结束会议。
如果团队在活动时间盒之内无法达成目标，那么应该想办法找到能使得会议效率提高的改进机会。
让团队将注意力集中在限时的固定事件中，可以让大家花费更少的时间在会议上，从而能有更多的时间完成工作。
参与者
每个Scrum事件都需要来自 Scrum 团队的成员参与。但是，并非所有 Scrum 团队的成员都需要参加所有会议。特别是对于 Sprint Review，有必要邀请 Scrum 团队以外的干系人提供反馈和建议。每个事件中都有正确的参与者，可以确保大家聚焦于会议的目标。
Scrum 事件****概览
如下是带时间盒的 Scrum 事件的简单总结。Sprint 是所有这些事件的容器，最长持续时间为一个月。
| 事件 | 检视 | 调整 | 参加者 | 时间盒 |
|---|---|---|---|---|
| Sprint Planning | Product Backlog, Product Goal, Definition of Done | Sprint Backlog，Sprint Goal | Scrum 团队 | 8 小时（当Sprint周期为1个月时） |
| Daily Scrum | Progress toward Sprint Goal | Sprint Backlog | Developers | 15分钟 |
| Sprint Review | Increment, Sprint, Product Backlog, Product Goal的进展 | Product Backlog | Scrum 团队，利益相关者 | 4 小时（当Sprint周期为1个月时） |
| Sprint Retrospective | Sprint， Definition of Done | 可行的改进，完成的定义 | Scrum 团队 | 3 小时（当Sprint周期为1个月时） |
Sprint Planning 简介
每个 Sprint 都从 Sprint Planning （Sprint 计划会）开始，在 Sprint 计划会中，Scrum 团队共同确定他们在即将到来的 Sprint 中计划要完成的工作。
在会议期间，Scrum 团队专注于：
- 在 Sprint 中能够创造的价值
- 选择将在 Sprint 期间解决的产品待办列表项
- 对达成目标所需的工作进行计划
- 计划创建一个满足“完成定义”的增量
Scrum 团队通过创建 Sprint Backlog 来让一点变得透明，其中包括 Sprint Goal、选定的产品待办项和开发人员交付工作的计划。
Sprint Planning 概览
| 事件 | 检视 | 调整 | 参与者 | 时间盒 |
|---|---|---|---|---|
| Sprint Planning | Product Backlog, Product Goal, Definition of Done | Sprint Backlog，Sprint Goal | Scrum 团队 | 8 小时（针对为期1个月的 Sprint） |
Daily Scrum 简介
为保证工作顺利进行，开发人员每天聚在一起15分钟，关注 Sprint Goal 的实现情况，并计划接下来一天的工作。在 Daily Scrum 中，大家识别出需要帮助解决的问题，寻求支持，并在必要的情况下调整Sprint Backlog。
Daily Scrum 确保所有团队成员信息对齐，了解发生的任何变化或更新，并保证团队正朝着 Sprint Goal 的方向进展。每日站会还能促进快速的决策，并减少了可能召开其他临时会议的需要。
Daily Scrum 概览
| 事件 | 检视 | 调整 | 参与者 | 时间盒 |
|---|---|---|---|---|
| Daily Scrum | Sprint Goal 的进展情况 | Sprint Backlog | 开发人员 | 15 minutes |
Sprint Review 简介
Sprint Review是一次工作会议，会议中 Scrum 团队向干系人展示他们已完成的工作，并寻求反馈和指导。Scrum 团队和干系人一起讨论产品目标的进展情况，沟通在业务或技术环境中出现的任何变化，并共同探讨下一步的行动计划。
Sprint Review****概览
| 事件 | 检视 | 调整 | 参与者 | 时间盒 |
|---|---|---|---|---|
| Sprint Review | 增量, Sprint, Product Backlog, Product Goal的进展 | Product Backlog | Scrum 团队 ,干系人 | 4小时（针对长度为一个月的Sprint） |
Sprint Retrospective 简介
Sprint Retrospective（Sprint回顾会）是 Sprint 中的最后一个活动，是为 Scrum 团队留出时间，来寻找提高效率和改进团队协作的方法。不同于其他 Scrum 活动，着重检视和调整改进产品的方法，Scrum回顾会是Scrum团队检视和调整工作实践的机会。
在回顾中，团队通常会讨论：
- 团队成员互动和沟通的情况如何
- 团队遇到的任何障碍
- 清除障碍的情况如何
- “Definition of Done”是否仍然适用，或是需要更新
- 在未来的 Sprint 中，团队的工作方式上是否有任何可行的改进方法
Sprint Retrospective 概览
| 事件 | 检视 | 调整 | 参加者 | 时间盒 |
|---|---|---|---|---|
| Sprint Retrospective | 冲刺，完成的定义 | 可行的改进计划、Definition of Done | Scrum 团队 | 3 小时（针对为期1 个月的 Sprint ） |
五种价值观：
承诺、专注、开放、尊重 和勇气
Scrum 团队致力于实现目标并相互支持。
他们专注于Sprint期间的工作，尽可能朝着这些目标取得最佳进展。
Scrum 团队及其干系人对工作和挑战持开放态度。
Scrum 团队成员相互尊重，相信彼此是有能力且独立的人，同时也受到合作伙伴的尊重。
Scrum 团队成员勇于做正确的事，并挑战棘手的问题。
这些价值观为 Scrum 团队的工作、行动和行为指明了方向。
做出的决定、采取的步骤以及使用 Scrum 的方式都应强化这些价值观，而不是削弱或破坏这些价值观。Scrum 团队成员在工作中学习和探索这些价值观。
Scrum团队成员通过Scrum事件和工件来学习和探索这些价值观。当这些价值观在 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, 一般不翻译
Development Team ： Scrum开发团队
Scrum Team：指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 Meeting: Sprint计划会议
Daily Scrum Meeting：每日站会
Sprint Review Meeting：Sprint评审会议
Sprint Retrospective Meeting: 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