Scrum 概述

Scrum 概述

在 Scrum 中，项目经理被称为 Scrum 主管，项目团队被称为 Scrum 团队。有一位产品负责人负责对产品待办事项列表中的功能和需求进行优先级排序。

Scrum 方法论使用冲刺（Sprints）来交付工作的小增量，并从客户那里收集反馈。

有三个（3）Scrum 基石：

SCRUM采用经验主义方法（有时称为经验主义）来适应不断变化的客户需求。经验主义是基于实际经验做出决策的做法。经验主义方法意味着以事实为基础、以经验为基础、以证据为基础的方式工作——尤其是在进展基于对现实的观察，而非基于详尽的前期计划和大量初始需求的情况下。

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

The Three Pillars of Scrum

  • 透明性 — 使用共同的语言和标准，以确保一致性和共同理解。
  • 检查 — 频繁审查 Scrum 的进展和交付成果以获取反馈。不要隐藏项目进展非常重要。
  • 适应 — 能够轻松地融入收到的反馈，并在问题出现时及时应对。

Scrum 流程的组成部分

该 Scrum 框架本身非常简单。它仅定义了一些通用指南，以及一小套规则，角色, 工件，以及事件。然而，这些组件中的每一个都非常重要，具有特定用途，并且对于成功使用该框架至关重要。

Scrum 框架的主要组成部分是：

下图展示了 SCRUM 框架的关键要素。该流程已应用于敏捷软件工具——Scrum 流程画布.

Scrum Framework
Scrum 框架

Scrum 角色

当一个组织决定采用 Scrum 时，首先要理解的是 Scrum 角色与传统项目执行角色之间的区别。尽管 Scrum 只有三个主要角色，但它们并不会自动对应我们大多数人熟悉的头衔。让我们先简要定义每个角色：

产品负责人

产品负责人是负责代表业务或用户群体，并与用户群体合作确定产品发布中包含哪些功能的 Scrum 角色。产品负责人的主要职责包括：

  • 确定产品或服务的方向和战略，包括短期和长期目标；
  • 提供或获取有关产品或服务的知识；
  • 帮助开发团队理解并解读客户需求；
  • 收集、优先排序并管理产品或服务的需求；
  • 承担与产品或服务预算相关的任何责任，包括其盈利能力；
  • 确定产品或服务功能的发布日期；
  • 每天与开发团队一起回答问题并做出决策；
  • 接受或拒绝与冲刺相关的已完成功能；
  • 在每个冲刺结束时展示开发团队的关键交付成果；
  • 负责产品待办事项列表。

Scrum Master

Scrum Master 是敏捷开发团队的促进者。Scrum 是一种使团队能够根据敏捷原则自我组织并快速调整的方法。Scrum Master 负责管理信息交换的过程。Scrum Master 的主要职责包括：

  • 担任教练，帮助团队遵循 Scrum 的价值观和实践；
  • 帮助消除障碍，并保护团队免受外部干扰；
  • 促进团队与利益相关者之间的良好协作；
  • 在团队中倡导常识；
  • 保护团队免受组织干扰。

Scrum Team

Scrum Team（也称为开发团队）由 3 到 9 名成员组成，他们共同具备交付产品或服务所需的所有技术技能。他们由 Scrum Master 直接指导，但并非直接管理。他们必须具备自我组织、多才多艺和足够的责任感，以完成所有必需的任务。

开发团队负责在每个冲刺中交付可交付的产品增量——从分析、设计、开发、测试到技术写作。Scrum 团队的关键特征包括：

  • 团队必须是自我组织的。所有团队成员必须自主管理自己的努力以完成分配的任务。在敏捷 Scrum 中，没有团队领导或直线经理的角色。每个人都必须足够投入，以完成自己的工作并为团队的成功做出贡献。如果一人失败，所有人皆失败。
  • 团队必须是跨职能的。所有团队成员都必须具备交付完整、可立即使用的服务或产品的知识和技能。在需要时可以使用专家，但仅作为教练向团队传授知识并填补特定缺口。
  • 产品负责人需要具备商业愿景。产品负责人代表客户的声音，必须将客户的需求传达给 Scrum Master 和开发团队。这通常是一个全职角色。
  • Scrum Master 不是直线经理。他们为开发团队提供所需的指导，并帮助团队消除任何障碍。

产品待办事项列表

这是项目所有待办工作的有序列表。它以故事的形式呈现，通常称为用户故事。

用户故事 — 用户与项目交付成果（产品、服务或成果）交互方式的不同表现形式。通过用户故事，团队可以识别出交付成果所需的功能和特性。

因此，产品待办事项列表包含针对产品/服务/成果的优先级用户故事（功能和特性）。产品负责人负责对待办事项列表进行优先级排序。

注意：在开始工作之前，你不需要为整个项目创建所有故事（这是敏捷方法的一个优势）。从你已知的故事开始，随着你了解得越来越多，可以向待办事项列表中添加新内容，并根据需要重新排序优先级。

冲刺计划

与瀑布模型不同，敏捷团队不会提前规划所有内容。在这里，团队只做部分计划：确定当前冲刺所需的内容（冲刺通常为2到4周），交付成果，从中学习，然后再次计划下一个冲刺。

Scrum团队审查产品待办事项列表，并选择在冲刺时间框内可以完成的用户故事数量。选定的用户故事将成为冲刺待办事项列表。冲刺待办事项列表代表了冲刺的目标。

“完成的定义”也会被确立。完成的定义可以被视为待办事项条目的验收标准。

只计划团队能力范围内的工作——即团队在每个冲刺中实际能够完成的工作。

每日Scrum会议（每日站会）

团队利用此会议相互做出小承诺，识别问题，并确保冲刺工作在团队内部顺利推进。会议通常持续15分钟。团队回答以下问题：

  • 自上次Scrum会议以来，我完成了什么？
  • 我今天的工作计划是什么？我打算在接下来到下次Scrum会议之间完成什么？
  • 是否有任何阻碍（问题、障碍或风险）阻碍了我？

请记住，这次会议不是进度汇报会议——它不是用来解决问题的，而是为了意识到问题（如果有的话）。如果需要专门解决这些问题，应另设会议。

冲刺评审会议

每个冲刺结束时，团队展示所有已完成的工作项。此次评审会议用于接收项目干系人的反馈和任何变更请求。

需要注意的是，根据计划阶段确立的“完成的定义”未完全完成的工作项将不会被展示，因为它们并未真正“完成”。

冲刺回顾会议

该会议在冲刺评审之后进行。目的是帮助团队从冲刺中学习。该过程注重持续改进，而不是在冲刺进展不顺时责备团队。

团队反思如何变得更加高效，并识别其他需要改进的领域。

Scrum主管对每个改进项的重要性进行排序，然后团队选择适当数量的改进项在下一个冲刺中实施。冲刺.

Leave a Reply