敏捷软件开发之 - Scrum

Scrum 是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

Scrum流程如下图：

 

 

 

SCRUM框架包括3个角色、3个工件、5个事件、5个价值

3个角色

1. 产品负责人（Product Owner）
2. Scrum Master
3. 开发团队

产品负责人(Product Ower)

主要负责构建正确的产品，确定 Scrum 团队交付什么并解释为什么做这些工作。产品负责人是产品方面的佼佼者。他们专注于了解业务、客户和市场要求，然后相应地确定工程团队需要完成的工作的优先顺序。高效的产品负责人应能：

• 构建和管理产品待办事项。
• 与企业和团队密切合作，以确保所有人都能了解产品待办事项中的工作项。
• 明确指导团队接下来提供哪些功能。
• 确定何时发布产品，且倾向于更频繁地交付产品。

产品负责人并不一定是产品经理。产品负责人专注于确保开发团队为企业带来最大价值。此外，产品负责人是一个个体，这一点非常重要。没有开发团队需要多个产品负责人所提供的的混合指导。

Scrum Master

主要负责帮助产品负责人和开发团队中的每个人理解和拥抱Scrum的价值观、原则和实践。

Scrum master 是其团队中在 Scrum 方面的佼佼者。他们负责对团队、产品负责人和企业进行 Scrum 流程方面的培训，并寻找方法细调他们在此方面的实践。

高效的Scrum 主管应深入了解团队正在执行的工作，并可协助团队优化其透明度和交付流程。作为最主要的推动者，此角色负责安排冲刺规划、每日短会、冲刺审核和冲刺回顾所需的资源（人力和物力）。

Scrum 团队

负责以正确的方式构建产品，执行具体工作任务。Scrum团队是具体工作的执行者，成员通常为 5 到 7 名。确定团队规模的一种方法是亚马逊首席执行官 Jeff Bezos提出的著名“两个披萨原则”（团队应该足够小，以便分享两个披萨）。

团队成员具有不同的技能，并且彼此互相锤炼，因此没有人会成为交付工作的瓶颈。强大的Scrum 团队遵循自我组织原则，且会在处理项目时采取明确的“我方”立场。团队的所有成员会互相帮助，以确保成功完成冲刺。

Scrum团队可推进每个冲刺的计划。他们将自己的历史速度用作指导，预测他们认为自己在迭代过程中可以完成的工作量。保持迭代长度固定可为开发团队提供有关其预估和交付流程的重要反馈，进而使其能随着时间的推移做出更加准确的预测。

 

3个工件

1. 产品Backlog（Product Backlog）
2. Sprint Backlog
3. 产品增量（Increment）

产品待办事项（Product Backlog）

产品待办事项集合，整个产品的用户故事集合，这些用户故事可以来自甲方客户、终端用户、PO自己对产品的理解、研发团队等。

本质上，这是团队的“待办事项”列表。产品负责人对产品待办事项进行不断反思、重新排定优先级和维护，因为随着我们了解的更多或随着市场的变化，列表中的项目可能不再相关，或是可能会以其他方式解决问题。

冲刺待办事项（Sprint Backlog）

冲刺待办事项列表，一个冲刺目标阶段内的用户故事列表。这些用户故事来自Product Backlog，每次冲刺前，PO根据交付价值，将优先级最高的用户故事放入迭代。

每次冲刺之前，在冲刺规划会议（我们将在后文进行讨论）中，团队从产品待办事项中选择为进行冲刺而处理的项目。冲刺待办事项可能较为灵活，可以在冲刺期间发展。但是，基本的冲刺目标（团队希望通过在当前冲刺中实现的目标）不能受到影响。

增量（或冲刺目标）

增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。

在完成以上三个工件的时候，团队可以选择定义很多变体，因为工件维护最好保持开放态度。比如“已完成”、“故事点”重新定义能更好的提升效率和品质，那你完全可以根据需求进行新的定义。

5个事件

1. Sprint（Sprint本身是一个事件，包括了如下4个事件）
2. Sprint计划会议（Sprint Planning Meeting）
3. 每日站会（Daily Scrum Meeting）
4. Sprint评审会议（Sprint Review Meeting）
5. Sprint回顾会议（Sprint Retrospective Meeting）

Sprint计划会(Sprint planning meeting)

由整个开发团队在本次会议期间规划当前冲刺期间要执行的工作（范围）。本次会议由 Scrum MAster主持，而团队则在会议期间决定冲刺目标。接着，可将产品待办事项中的特定用途故事添加到冲刺中。这些故事应与目标始终保持一致，且 Scrum 团队也承诺可在冲刺期间完成。 在规划会议结束时，每位 Scrum 成员均需清楚在冲刺期间可以交付的内容，以及如何交付增量变化。

Scrum每日站会(Daily Standup Meeting)

这是每天在同一时间（通常是早晨）和地点举行的超短例会，以确保此会议简洁明了。很多团队试图在15 分钟内完成会议，但这只是一个参考。此会议也被称为“每日短会”，它强调需快速举行会议。每日 Scrum 旨在让团队中的每一个成员都保持同步，共同朝着冲刺目标努力，并制定未来 24 小时的计划。 您可在每日短会上说出自己在实现冲刺目标或解决任何障碍时遇到的问题。 每日短会的其中一种常见举行方法是让每个团队成员在实现冲刺目标的过程中回答三个问题： • 我昨天做了什么？ • 我今天打算做什么？ • 是否存在障碍？ 然而，我们发现会议很快会变成大家陈述昨天和第二天的日程表。每日短会的理论基础是：它可以分散日常会议的注意力，这样团队就可以在当天剩下的时间里专注于工作。因此，如果它不幸沦为了每日日程表阅读会，则应果断做出改变以求创新。

Sprint评审会(Sprint Review Meeting)

在冲刺结束时，团队聚集在一起进行非正式会议，以观看增量演示或检查增量。开发团队向利益相关者和团队成员展示目前处于“已完成”状态的待办事项，以征求他们的反馈意见。尽管在多数情况下都会发布增量，但产品负责人仍可决定是否发布增量。

此次审核会议也是产品负责人根据当前冲刺重新处理产品待办事项之时，当前冲刺可为下一次冲刺规划会议提供相关信息。对于为期一个月的冲刺，可考虑将您的冲刺审核时间限制为最长四个小时。

Sprint回顾会(Sprint Retrospective Meeting)

是指团队聚集在一起共同记录和讨论冲刺、项目、人员或关系、工具甚至在某些仪式中哪些有效以及哪些无效。我们的思路是创造一个地方，让团队能够专注于哪些工作进展顺利和哪些地方有待改进，而不是专注于出了什么问题。

5个价值

1. 承诺 – 愿意对目标做出承诺
2. 专注– 把你的心思和能力都用到你承诺的工作上去
3. 开放– Scrum 把项目中的一切开放给每个人看
4. 尊重– 每个人都有他独特的背景和经验
5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

 

标签：软件开发,Scrum,冲刺,待办,产品,敏捷,Sprint,团队
来源： https://www.cnblogs.com/SF8588/p/16290079.html