敏捷项目管理Scrum连载系列之Scrum理论与应用篇（一）

目录：

敏捷项目管理Scrum连载系列之初识Scrum

前言

在上一篇中老程向大家介绍了Scrum，我们做个简单的回顾：

何为Scrum及Scrum的起源；
软件研发中的Scrum发展史；
Scrum敏捷项目管理VS传统瀑布式项目管理；
Scrum框架包含的3个角色、3个工件、5个事件、5个价值；
Scrum创始人Jeff Sutherland与Ken Schwaber以及两位作者的履历和敏捷项目管理的诞生；
正文
在本篇老程和大家分享敏捷的理论和应用方面的知识，内容概览如下：

理论部分：

方法
核心思想
事件
价值观
应用部分：

应用的范围PO、项目经理、团队、Scrum教练等角色和在产品研发中的应用

---

正文部分

Scrum理论

Scrum核心理论：基于经验主义。经验主义主张知识源于经验，而决策基于已知的事物。Scrum 采用迭代增量式的方法来优化可预测性和管理风险。透明性、检视、调整是经验型流程的三大支柱，支撑起每个经验型控制流程的实施。

什么是经验主义？

经验主义诞生于古希腊。距今已有2400余年的历史。

感性经验是知识的唯一来源，一切知识都通过经验而获得，并在经验中得到验证。经验主义通常指相信对现代科学方法，认为理论应建立于对于事物的观察，而不是直觉或迷信。意即通过实验研究而后进行理论推导优于单纯的逻辑推理。这句话不难理解，各位可以看看招聘信息，80%都要求有相关工作经验，可见经验的重要性；

在实际工作中，Scrum和其他的方法一起组合使用，看板、用户故事、燃烧图、价值流图等工具，将长期沉淀的下来的经验运用到实际工作中，进行验证。

Scrum 采纳一种迭代、增量式的方法来优化对未来的预测和控制风险。

核心思想
透明、检视和适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。

透明（Transparency）：
项目开展过程中，关键环节对所有利益干系人及研发团队必须是显而易见的。为关键环节制定统一的标准是拥有透明的第一步，第二步，这些统一的标准必须要放到需关注每个环节的人都能轻易观察到的地方，同时确保所有人对观察到的事务有统一的理解。

例如

• 所有参与者谈及过程时都必须使用统一的术语。
• 负责完成工作和检视结果增量的人必须对“完成”的定义，有一致的理解。
• 看板、待办列表、Sprint列表、燃烧图、价值流图等等需要放在显而易见的地方。

检视（Inspection）：

Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进展，以便发现不必要的差异。

检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤勉地执行时，效果最佳。

适应（Adapt）/调整（Adaptation）：

如果在检视过程中，发现流程中一个或多个方面背离了可接受的标准（缺陷率太高、需求变动、需求不明、过度会议、过度开发等等），并且这些因素会导致产品不合格时，就必须对流程本身或者流程化的内容进行裁剪，以缩小多种事件引起的偏差，努力缩小偏差，确保质量；

Scrum价值观/核心思想

• 承诺（Commitment）：我们对团队承担的工作有了更大的掌控，更加坚定了对成功的承诺。
• 专注（Focus）：我们将全部精力和技能都聚焦在所承诺的工作上，团队同心协力来促使更快的交付。
• 公开（Openness）：团队通过自己的方式共同完成工作，每个成员都对进展和问题了如指掌。
• 敬重（Respect）：团队中的每个人都有其特定的背景和经验，互相尊重，谦虚学习。
• 勇气（Courage）：我们不是一个人在战斗，有了整个团队的支持，我们有了更大的勇气来进行挑战。

当承诺、勇气、专注、开放和尊重五大价值观为 Scrum 团队所践行与内化时，Scrum 的透明、检视和适应三大支柱成为现实，Scrum 团队成员相互尊重，彼此是有能力和独立的人，并且在每个人之间构建信任。

Scrum 团队成员通过 Scrum 的角色、事件和工件来学习和探索这些价值观。 Scrum 的成功应用取决于团队成员随着Scrum项目持续的深入，变得更为精通践行五项价值观。

团队成员致力于实现 Scrum 团队的目标，Scrum 团队成员有勇气去做正确的事并处理那些棘手的问题而不是积极甩锅。每个人专注于 Sprint 工作和 Scrum 团队的目标。Scrum 团队及其干系人同意将所有工作和执行工作上的挑战进行公开，从而保证项目对所有干系人及需关注的人员透明，及各项标准有着统一的认知。

精诚所至金石为开是对Scrum所提倡的价值观最好的诠释；

---

Scrum事件
Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其他会议的必要。所有事件都是有时间盒限定的事件，也就是说每一个事件限制在最长的时间范围内。一旦 Sprint 开始，它的持续时间是规定的，不能缩短或延长。而其他事件则可以在该事件的目标达成之后可以立即终止，如此确保时间被适当地使用而不会造成过程中的浪费。

Sprint

Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum 中的每个事件都是用来进行检视和适应的正式机会。这些事件都是被特别设计用来确保达成透明和检视。如果 Sprint 不能成功地包含这些事件中的任何一个事件，导致透明化的降低，同时也会丧失进行检视与适应的机会。

Sprint 是 Scrum 的核心，其长度（持续时间）为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量（即应该有的、会有的、可能有的、绝对不会有的）。在整个开发过程期间，Sprint 的长度保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始（有点像接力棒的运动，但又与该运动不同）。

在 Sprint 期间：
不能做出有害于 Sprint 目标的改变；
不能降低质量的目标；
随着对信息掌握的增加，PO与Team成员之间对范围内要做的事可能会澄清和重新协商。

Sprint 由 Sprint 计划会议、每日 Scrum 站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。

• Sprint 计划会议
  在每个迭代之初，开发团队和 Product Owner 共同来计划在迭代周期内要完成的工作。
  Product Owner 负责向团队讲解要完成的工作的内容，开发团队负责对工作进行估计。
  可以这么理解：每个 Sprint 都可以被视为一个项目，为期不超过一个月。
  就如同项目一样，Sprint 被用于完成某些事情。
  每个 Sprint 都会有一个要构建什么的目标，还有一份设计过和灵活的计划用来指导如何做这些事、工作内容和最终产品增量。

• 每日 Scrum 站会
  每天，开发团队和产品负责人都要进行一个短暂的（15分钟）沟通。在会议期间，每个团队成员都要回答 3 个问题：
  “我昨天做了什么？”，
  “我今天准备做什么？”，
  “我遇到了什么问题？”。
  旨在帮助团队成员解决问题，及保持现有进度透明可视；

• Sprint 评审会议
  在迭代周期结束时，开发团队向产品负责人及所有干系人进行演示，并接受反馈。
  Sprint 评审会议在 Sprint 快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办列表。
  在 Sprint 评审会议中，Scrum 团队和干系人协同讨论在这次 Sprint 中所完成的工作。
  根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。
  这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。
  对于长度为一个月的 Sprint 来说，评审会议时间最长不超过 4 小时。
  对于较短的 Sprint 来说，会议时间通常会缩短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。
  Scrum Master 教导每位参会者遵守时间盒的规则。

• Sprint 评审会议包含以下内容：
  产品负责人邀请 Scrum 团队和主要的干系人参加会议；
  产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”；
  开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；
  开发团队演示“完成”的工作并解答关于所交付增量的问题；
  产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可能的目标交付日期（如果有需要的话）；
  参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下来的 Sprint 计划会议提供有价值的输入信息；
  评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；
  为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。

Sprint 评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。
评审会的目的在于发现问题，解决问题和总结经验，而非*大会，这是Scrum要充当防护墙的作用，隔绝引起
研发团队人员不适的环境 ，避免引起恐慌情绪的蔓延。

Sprint 回顾会议

Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。

回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。对于长度为一个月的 Sprint 来说，回顾会议时间最长不超过 3 小时。对于较短的 Sprint 来说，会议时间通常会缩短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。

Scrum Master 确保会议是积极的和富有成效的。 Scrum Master 教导大家遵守时间盒的规则。Scrum Master 作为 Scrum 过程的责任者，作为团队的一员参加该会议。

Sprint 回顾会议的目的在于：

• 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；

• 找出并加以排序做得好的和潜在需要改进的主要方面； 同时，

• 制定改进 Scrum 团队工作方式的计划。

Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在下个 Sprint 中更高效更愉快。在每个 Sprint 回顾会议中，如果适用并且不与产品或组织标准相冲突，Scrum 团队计划不同的方式通过改进工作过程或调整“完成”的定义来提高产品质量。

在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。在下一个 Sprint 中实施这些改进是基于 Scrum 团队对自身的检视而做出的适当调整。虽然改进可以在任何时间执行，Sprint 回顾会议提供了一个专注于检视和适应的正式机会。

---

Scrum应用
在下一篇中，老程将和各位分享Scrum应用在团队中，以及产品负责人、开发团队、ScrumMaster敏捷教练在Scrum框架中的应用。