Scrum 概述

Scrum 概述

在 Scrum 中,项目经理被称为 Scrum Master,项目团队被称为 Scrum 团队。有一个产品负责人优先考虑要在产品待办事项列表上开发的功能和要求。

Scrum 方法使用冲刺来交付少量的工作并从客户那里获得反馈。

共有三 (3) 个 Scrum 支柱:

SCRUM使用经验方法(或有时称为经验主义)以适应客户不断变化的需求。经验主义是根据实际经验做出决定的行为。实证方法是指以事实为基础、以经验为基础、以证据为基础的工作方式,特别是进展是基于对现实的观察,而不是基于大量前期需求的虚构计划。

简而言之,我们可以从过去的错误和经验中学习和改进。支持经验过程控制的每个实施的 Scrum 的三大支柱是:透明性、检查和适应,如下图所示:

Scrum的三大支柱

  • 透明度——一种共同语言和标准,以确保一致和共同理解。
  • 检查——经常审查 Scrum 进度和可交付成果以获得反馈。重要的是不要隐藏项目的进展情况。
  • 适应 – 易于整合收到的反馈并在出现问题时解决问题

Scrum流程的组成部分

Scrum 框架本身非常简单。它只定义了一些通用的指导方针,只有一些规则、角色工件和事件。然而,这些组件中的每一个都很重要,服务于特定目的,并且对于成功使用框架至关重要。

Scrum 框架的主要组件是:

下图显示了 SCRUM 框架的关键元素。该流程已被敏捷软件工具——Scrum Process Canvas 应用

Scrum 框架
Scrum 框架

Scrum 角色 (Role)

当组织决定采用 Scrum 时,首先要了解的事情之一是 Scrum 角色与传统项目执行角色有何不同。虽然 Scrum 中只有三个主要角色,但它们不会自动与我们大多数人熟悉的头衔保持一致。让我们从每个的简要定义开始:

产品拥有者 (Product Owner)

产品负责人是代表业务或用户社区并负责与用户组合作以确定产品版本中将包含哪些功能的人员的 Scrum 开发角色。产品负责人的主要职责是:

  • 制定产品和服务的方向和战略,包括短期和长期目标;
  • 提供或获得有关产品或服务的知识;
  • 为开发团队理解和解释客户需求;
  • 收集、优先排序和管理产品或服务需求;
  • 接管与产品或服务预算相关的任何责任,包括其盈利能力;
  • 确定产品或服务功能的发布日期;
  • 每天与开发团队一起回答问题并做出决定;
  • 接受或拒绝与 Sprint 相关的已完成功能;
  • 在每个 Sprint 结束时展示开发团队的主要实现;
  • 负责产品Backlog

Scrum Master

Scrum Master 是敏捷开发团队的推动者。Scrum 是一种方法,它允许团队根据敏捷原则自组织并快速进行更改。Scrum Master 管理信息交换的过程。Scrum Master 的主要职责是:

  • 作为教练,帮助团队遵循 Scrum 价值观和实践;
  • 帮助排除障碍,保护团队免受外部干扰;
  • 促进团队和利益相关者之间的良好合作;
  • 促进团队内的常识;
  • 保护团队免受组织干扰;

Scrum团队 (Team)

Scrum 团队(又名开发团队)由 3 到 9 人组成,他们必须满足交付产品或服务的所有技术需求。他们将由 Scrum Master 直接指导,但不会直接管理。他们必须是自组织的、多才多艺的,并且有足够的责任感来完成所有必需的任务。

开发团队负责从分析、设计、开发、测试到技术写作等每个 sprint 交付潜在可交付的产品增量。 Scrum 团队具有以下特征非常重要:

  • 团队必须是自组织的。所有团队成员都必须管理自己的努力以完成已分配的任务。在敏捷 Scrum 中,没有团队领导或直线经理的形象。每个人都必须有足够的承诺来开展自己的活动并为团队的成功做出贡献。如果一个失败,每个人都会失败。
  • 团队必须是跨职能的。所有团队成员都必须具备所有必需的知识和技能,才能提供完善且随时可用的服务或产品。在必要的情况下可以使用专家,但只能作为教练将知识传递给团队以弥补特定的差距。
  • 成为产品负责人需要有商业远见。产品负责人代表客户的声音,需要将他们的需求传达给 Scrum Master 和开发团队。这通常是一份全职工作。
  • Scrum Master 不是直线经理。他们帮助为开发团队提供所需的教练,并帮助消除团队面临的任何障碍。

产品积压 (Product Backlog)

这包含要在项目中完成的所有工作的有序列表。它以故事形式呈现,通常称为用户故事。

用户故事——是用户如何与项目可交付成果(产品、服务或结果)交互的不同表示。通过用户故事,团队确定可交付成果所需的特性和功能。

因此,产品待办事项列表包含产品/服务/结果的优先用户故事(特性和功能)。产品负责人负责对积压工作进行优先排序。

请注意,在工作开始之前,您不需要为整个项目创建所有故事(这是敏捷方法的优势)。创建您知道的故事并以此开始,随着您了解的更多,您可以添加到待办事项并根据需要重新确定优先级。

冲刺计划 (Sprint Planning)

与瀑布方法不同,敏捷团队不会计划一次。在这里,团队计划了一点;当前冲刺需要什么(冲刺通常在 2 到 4 周之间),交付它,从中学习,并再次计划下一个冲刺。

Scrum 团队查看产品待办列表并选择他们可以在 Sprint 时间框中完成的用户故事数量。选定的用户故事成为冲刺待办事项。冲刺积压是冲刺的目标。

完成的定义也被确立。完成的定义可以称为积压工作项的验收标准。

只计划符合团队能力的工作;也就是说,团队可以在每个 sprint 中完成的工作。 

每日 Scrum 会议 (Daily Standup Meeting)

团队利用这次会议相互微承诺,发现问题,并确保 sprint 工作在团队中顺利进行。通常为 15 分钟。团队回答以下问题:

  • 自上次 Scrum 会议以来我完成了什么?
  • 今天的计划是什么?我是否打算在现在和下一次 Scrum 会议之间完成?
  • 是我的障碍(问题、问题或风险)吗?

请记住,此会议不是状态会议,因此不是用于解决问题,而是用于意识到存在问题(如果有)。如果需要召开会议来解决问题,请召开会议。

冲刺评审 (Sprint Review Meeting)

团队在每个冲刺结束时演示所有已完成的工作项。此审查会议用于接收来自项目利益相关者和任何变更请求的反馈。

重要的是要注意,根据计划阶段定义的完成定义,未 100% 完成的工作项不会被展示,因为它们没有“完成”。

冲刺回顾 (Sprint Retrospective Meeeting)

这是在冲刺审查之后完成的。目的是帮助团队从冲刺中学习。这个过程是关于持续改进,而不是在冲刺期间如果某些事情进展不顺利,而责怪团队。

团队反思如何变得更有效和其他改进领域。

Scrum 主管对每个改进项目的重要性进行排名,然后团队选择适当数量的改进项目以用于下一个 sprint