5分钟学习会scrum

5分钟学习会scrum

Scrum是一种专注但灵活的项目管理策略，它使团队能够通过迭代的软件开发过程进行工作。Scrum是经验性的，因为它为团队提供了一种方法，让团队建立一个关于他们如何思考某件事情的假设，尝试它，反思经验，并做出适当的调整。也就是说，当框架被正确使用时。

Scrum的结构允许团队将其他框架中的实践结合起来，这些实践对于团队的环境是有意义的。在敏捷世界中，Scrum已经成为软件开发的领先方法。Scrum的概念是可靠的，并得到了全球数千个开发团队的验证。Scrum最适合于跨职能团队在产品开发环境中工作的情况，在这种环境中，有大量的工作需要拆分为多个2-4周的迭代。

 

Scrum 起源

1986 年：Takeuchi 和 Nonaka在《哈佛商业评论》上发表了他们的文章“新产品开发游戏”。这篇文章描述了一种橄榄球方法，其中“产品开发过程来自一个精心挑选的多学科团队的不断互动，该团队的成员从头到尾一起工作。” 这篇文章经常被引用为 Scrum 框架的灵感来源。

 

Scrum价值观 (Scrum Values)

以下原则支持 Scrum 的经验性质：

透明度
团队必须在一个每个人都知道其他团队成员遇到的问题的环境中工作。团队会在组织内部暴露问题，通常是那些已经存在很长时间的问题，这些问题阻碍了团队的成功。

检查
框架中内置的频繁检查点，使团队有机会反思流程的运作方式。这些检查点包括每日 Scrum 会议和 Sprint 审查会议。

适应
团队不断调查事情的进展情况并修改那些似乎没有意义的项目。

开发团队 (Development Team)

产品负责人

该产品所有者是一个角色的团队负责，以达到球队期望完成的预期结果管理产品积压。

产品负责人角色存在于 Scrum 中，以解决产品开发团队在构建内容方面面临的多个、相互冲突的方向或根本没有方向的挑战。

Scrum Master

在Scrum管理员是负责确保团队的团队角色生命敏捷的价值观和原则，并遵循流程和球队同意他们将使用的做法。

这个名字最初是用来表示一个 Scrum 专家，因此可以指导他人。

该角色通常没有任何实际权限。担任这个角色的人必须从有影响力的位置领导，通常采取仆人式领导的立场。

开发团队
的开发团队由谁提供一个Sprint内的产品增量的人。

开发团队的主要职责是交付能够在每个 Sprint 中产生价值的增量。如何分配工作由团队根据当时的情况确定。

 

Scrum Artifacts

产品待办列表产品待办列表是
对产品进行的所有可能更改的有序列表。产品待办列表上的项目是选项，而不是承诺，因为它们存在于产品待办列表中并不能保证它们会被交付。

产品负责人持续维护产品待办列表，包括其内容、可用性和订购。

Sprint Backlog
Sprint Backlog 是选择在 Sprint 中交付的产品 backlog 项的集合，如果团队确定了任务，交付这些产品 backlog 项并实现 Sprint 目标所需的任务。

增量

增量是在 Sprint 结束时满足团队定义的产品待办列表项的集合。产品负责人可能会决定在未来的 Sprint 中发布增量或基于它进行构建。

完成的定义

完成的定义是团队就产品待办列表项在被视为完成之前必须满足的标准达成的共识。

 

Scrum Events

Sprint

的Sprint是一个时间盒一个月或更少，在此期间该球队产生潜在可交付产品的增量。Sprints的典型特征：

• 在整个开发过程中保持一致的持续时间
• 一个新的 Sprint 紧跟在上一个 Sprint 的结论之后
• Sprint的开始日期和结束日期是固定的

Sprint 计划 (Sprint Planning)

一个团队开始一个 Sprint，讨论以确定他们将在 Sprint 期间处理产品待办列表中的哪些项目。Sprint Planning的最终结果是Sprint Backlog。

Sprint 计划通常分为两部分。在第一部分，产品负责人和团队的其他成员就 Sprint 中将包含哪些产品待办事项达成一致。

在 Sprint 计划的第二部分，团队确定他们将如何成功交付已识别的产品待办事项，作为潜在可交付产品增量的一部分。如果这是他们的实践之一，团队可能会确定实现这一目标所需的特定任务。为交付和任务确定的产品待办列表项（如果适用）构成了 Sprint 待办列表。

一旦团队和产品负责人按照产品待办列表项的描述确定了 Sprint 的范围，就不能再将任何项添加到 Sprint 待办列表中。这可以保护团队免受该 Sprint 内的范围变化的影响。

每日站会 (Daily Standup)

在每日的Scrum是短（一般不超过15分钟）的讨论，其中团队协调他们的活动，为次日。每日 Scrum 会议并非旨在成为状态报告会议或解决问题的讨论。

冲刺回顾 (Sprint Review)

在 Sprint 结束时，整个团队（包括产品负责人）与产品的利益相关者一起审查 sprint 的结果。本次讨论的目的是讨论、演示并可能让利益相关者有机会使用增量以获得反馈。Sprint 评审不旨在提供状态报告。来自冲刺审查的反馈被放入产品待办事项列表中以备将来考虑。

冲刺回顾 (Sprint Retrospective)

在 sprint 评审之后的 Sprint 结束时，团队（包括产品负责人）应该反思上一个 sprint 期间的情况，并确定他们可以在未来进行的调整。这次回顾的结果是至少一个行动项目包含在以下 Sprint 的 Sprint Backlog 中。

5个价值

• 开放 (Openness)
• 尊敬 (Respectful)
• 勇气 (Courage)
• 集中 (Focus)
• 承诺 (Commitment)

 

生命周期

Scrum 是一个框架，它允许开发团队灵活地响应不断变化的情况。该框架有足够的控制点来确保团队不会偏离预期的结果，并且可以在工作仍在进行的同时识别和解决问题并进行流程调整。

Scrum 生命周期从一个优先级的待办事项开始，但没有提供关于如何开发或确定该待办事项优先级的任何指导。

Scrum 生命周期由一系列 Sprint 组成，最终结果是潜在的可交付产品增量。在这些冲刺中，产品开发所需的所有活动都发生在整个产品的一小部分上。下面是对 Scrum 生命周期中关键步骤的描述：

1. 建立产品待办列表。
2. 产品所有者和开发团队进行 Sprint 计划。在 Sprint 计划的第一部分确定 Sprint 的范围，并在 Sprint 计划的后半部分确定交付该范围的计划。
3. 随着 Sprint 的进行，开发团队执行必要的工作来交付选定的产品待办事项。
4. 每天，开发团队在 Daily Scrum 中协调他们的工作。
5. 在 Sprint 结束时，开发团队交付在 Sprint 计划期间选择的产品待办列表项。开发团队举行 Sprint Review，向客户展示增量并获得反馈。开发团队和产品负责人还反思 Sprint 到目前为止的进展情况，并在回顾中相应地调整他们的流程。
6. 团队重复步骤 2-5，直到达到产品的预期结果。

主要利益

Scrum 对软件开发领域的主要贡献是一种简单但有效的方法来管理参与产品开发的小型协作团队的工作。它提供了一个框架和一组简单的规则，允许进行适当数量的规划、工作控制、风险识别和缓解以及问题识别和解决。