敏捷框架 - Scrum (一）

Posted 2021-04-25 LEAP研究所

LEAP就是用项目（Project）的方式来完成一个目标，通过高效（Efficiency）的方法和工具来快速落地，用敏捷 (Agile) 的思维来贴近最终用户强调价值和变化，最后用精益 (Lean) 的思想来改善、持续优化以达到质量提高。

我们将会用几个章节来系统、详细地介绍一下目前使用最广、也最被人们熟知的敏捷框架 - Scrum

 

什么是Scrum？

我们说敏捷是一种思想，而Scrum则是将这个思想付之于行动的一套框架。使用这个框架就可以很好的执行敏捷的特点。类似于PMBOK是项目管理的方法和知识域的介绍，而PRINCE2是一套可以用于实际的框架体系。

 

Scrum的特点是：

• 轻量级
• 简单易懂
• 难于精通

 

一张图看懂Scrum框架：

 

 

了解和学习Scrum可以从Scrum的 3 3 5 5 内容看出其运作的全貌：
3个工件（Artifcat）

3个核心角色

5个活动

5个核心价值

 

<  3个工件 (Artifact)  >

 

• Product Backlog

由PO (Product Owner)来维护的对于整体产品的代办列表。这个backlog本身是动态的，包含新功能、优化、修复等相关内容。由于市场和需求的随时变化，这个列表会由PO随时进行更新和优先级变化的修改

 

• Sprint Backlog

是由开发团队商议决定的对于本次Sprint要进行开发的内容，包括任务、Story和问题修复等内容。内容一旦确定下来后，Sprint Backlog当中的内容就作为本次Sprint需要完成的工作项了。

 

• Increment (Sprint Goal)

增量，一般指的是在一个Sprint结束后开发团队能够交付出来的一些产品Demo。我们不会在实际的项目中特别强调这个增量的词，往往是通过设定Sprint目标来定义的。开发团队需要确定什么样的任务集合算是完成的，Definition of Done。而这个任务集完成的内容是可以被用户或是PO来验收的。

 

<  3个核心角色  >

 

• Product Owner

PO为产品最终负责，他们聚焦在理解业务、客户和市场需求，根据优先级不停的变换Product backlog中的工作内容排序，让产品按时、按需的展现在最终用户面前。他们的工作一般包括：

• 创建和管理Product Backlog
• 帮助开发团队更深入的理解业务需求
• 对于下一个要交付的内容给出指导
• 决定什么样的产品和什么时候能够发布给到最终用户

PO必须是一个单独的个人，不能是一个团队分工的角色，开发团队应当遵从PO的指示来开发产品，而不需要听从其他人的需求。

 

• Scrum Master

Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。 Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。

Scrum Master服务于产品负责人

Scrum Master 以各种方式服务于产品负责人，包括:

• 确保 Scrum     团队中的每个人都尽可能地理解目标、范围和产品域;
• 找到有效管理产品待办列表的技巧;
• 帮助 Scrum     团队理解为何需要清晰且简明的产品待办列表项;
• 理解在经验主义的环境中的产品规划
• 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值;
• 理解并实践敏捷性;以及，当被请求或需要时，引导     Scrum 事件。

 

Scrum Master 服务于开发团队

Scrum Master 以各种方式服务于开发团队，包括:

• 作为教练在自组织和跨职能方面给予开发团队以指导;
• 帮助开发团队创造高价值的产品;
• 移除开发团队工作进展中的障碍;
• 按被请求或需要时，引导 Scrum 事件;以及在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。

 

• Dev. Team (开发团队）

开发团队包含各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。在 Sprint 评审会议上，一个“完成”增量是必需的。只有开发团队成员才能创建增量。开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。由此产生的正面效应 能最大化开发团队的整体效率和效用。

开发团队具有下列特点:

他们是自组织的。没有人(即使是 Scrum Master)有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量;
 

开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能;
Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作(他们都叫开发人员)。Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析;同时开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
 

开发团队的规模  

开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在 Sprint 内完成重要的工作。少于 3 个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的团队在 Sprint 中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可发布的产品增量。超过 9 人的团队则需要过多的协调沟通工作。对经验过程而言，大型开发团队会产生太多的复杂性而变得无用。产品负责人和 Scrum Master角色不包含在开 发团队人数中，除非他们同时也参与执行 Sprint 待办列表中的工作。

 

<  5个活动  >

• Sprint

Sprint 是 Scrum 的核心 ，其长度(持续时间)为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint 的长度保持一致。前一个 Sprint 结束后，下一个新的 Sprint 紧接着立即开始。

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

在Sprint 期间:

• 不能做出有害于 Sprint 目标的改变;

• 不能降低质量的目标;以及，

• 随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可以加以澄清和重新协商。

每个Sprint 都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint 被用于完成某些事情。每个 Sprint 都会有一个要构建什么的目标，还有一份设计过和灵活的计划用来指导如何做这些事、工作内容和最终产品增量。

Sprint 的长度限制在一个月内。当 Sprint 的长度太长的话，对要构建什么的定义就有可能会改变，复杂性也有可能会增加，同时风险也有可能会增加。Sprint 通过确保至少每月一次对达成目标的进度进行检视和适应，来实现可预测性。Sprint 同时也把风险限制在一 个月的成本上。

 

• Sprint 计划会议

Sprint 中要做的工作在 Sprint 计划会议中来做计划。这份工作计划是由整个 Scrum 团队    共同协作完成的。

Sprint 计划会议是有时间盒限定的，以一个月的 Sprint 来说最长为 8 小时。对于较短的 Sprint，会议时间通常会缩短。Scrum Master 要确保会议顺利举行，并且每个参会者都理解会议的目的。Scrum Master 要教导Scrum 团队遵守时间盒的规则。

 

Sprint 计划会议回答以下问题:

• 接下来的Sprint 交付的增量中要包含什么内容?

• 要如何完成交付增量所需的工作?

 

这次 Sprint 能做什么?  

开发团队预测在这次 Sprint 中要开发的功能。产品负责人讲解 Sprint 的目标以及达成该目标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。

Sprint 会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的预测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发 团队可以评估接下来的 Sprint 可以完成什么工作。

在Sprint 计划会议中，Scrum 团队还草拟一个 Sprint 目标。Sprint 目标是在这个 Sprint 通过实现产品待办列表要达到的目的，同时它也为开发团队提供指引，使得开发团队明确开发增量的目的。

 

如何完成所选的工作?  

在设定了Sprint 目标并选出这个 Sprint 要完成的产品待办列表项之后，开发团队将决定如何在 Sprint 中把这些功能构建成“完成”的产品增量。这个 Sprint 中所选出的产品待办列表项加上如何交付它们的计划称之为 Sprint 待办列表。

开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需要的工作。工作有不同的大小，或者不同的预估工作量。然而，在 Sprint 计划会议中， 开发团队已经挑选出足够量的工作，以此来预估他们在即将到来的 Sprint 中能够完成。在 Sprint 计划会议的最后，开发团队规划出在 Sprint 最初几天内所要做的工作，通常以一天或更少为一个单位。开发团队自组织地领取 Sprint 待办产品列表中的工作，领取工 作在 Sprint 计划会议和 Sprint 期间按需进行。产品负责人能够帮助解释清楚所选定的产品待办列表项，并做出权衡。如果开发团队认为 工作过多或过少，他们可以与产品负责人重新协商所选的产品待办列表项。开发团队也可以邀请其他人员参加会议，以获得技术或领域知识方面的建议。

在Sprint 计划会议结束时，开发团队应该能够向产品负责人和 Scrum Master 解释他们将如何以自组织团队的形式完成 Sprint 目标并开发出预期的产品增量。

 

Sprint 目标
Sprint 目标是在当前 Sprint 通过实现产品待办列表要达到的目的。它为开发团队提供指引，使得团队明确为什么要构建增量。Sprint 目标在Sprint 计划会议中确定。Sprint 目标为开发团队在 Sprint 中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供一个连贯一致的功能，也即是 Sprint 目标。Sprint目标可以是任何其他的连贯性来促使开发团队一起工作而不是分开独自做。开发团队必须在工作中时刻谨记Sprint 目标。为了达成 Sprint 目标，需要实现相应的功能和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商Sprint 待办列表的范围。

 

• 每日 Scrum 站会          

每日Scrum 站会是开发团队的一个时间盒限定为 15 分钟的事件。每日 Scrum 站会在 Sprint 的每一天都举行。在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制定计划。通过检视上次每日 Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化团队协作和效能。每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。

开发团队籍由每日 Scrum 站会来检视完成 Sprint 目标的进度，并检视完成 Sprint 待办列表的工作进度趋势。每日 Scrum 站会优化了开发团队达成 Sprint 目标的可能性。每天，开发团队应该知道如何以自组织团队来协同工作以达成 Sprint 目标，并在 Sprint 结束时开发出预期中的增量。

会议的结构由开发团队设定。只要会议专注于达成 Sprint 目标的进展，开发团队可以采用不同的方式进行。一些开发团队会以问题为导向来开会，有些开发团队会基于更多的讨 论来开会。以下是一个可以使用的范例:

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么?

• 今天，我为帮助开发团队达成 Sprint 目标准备做什么?

Scrum Master 教导开发团队将每日 Scrum 会议时间控制在 15 分钟内。

每日 Scrum 站会是开发团队的内部会议。如果有开发团队之外的人出席会议，Scrum Master 必须确保他们不会干扰会议进行。

每日Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与适应的关键会议。

 

• Sprint 评审会议

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

 

Sprint 评审会议包含以下内容:

• 参会者包括 Scrum 团队和产品负责人邀请的主要利益攸关者;
• 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”;
• 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的;
• 开发团队演示“完成”的工作并解答关于所交付增量的问题;
            

产品负责人讨论当前的产品待办列表的情况。他/她根据到目前为止的进度来预测可
  能的目标交付日期(如果有需要的话);参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下了的 Sprint 计划会议提供有价值的输入信息;
评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变; 同时为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。
Sprint 评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。
 

• 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 回顾会议提供了一个专注于检视和适应的正式机会。

 

<  5个核心价值  >

 

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

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

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

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

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

往期精彩内容：

• 
  

LEAP研究所 - 致力于对以下几个领域的研究：

L - Lean
E - Efficiency
A - Agile
P - Project

欢迎大家一起学习分享交流经验！

喜欢的朋友别忘了操作一波关注哈~