面向对象设计与分析（40）敏捷开发流程之Scrum：3大工件、3个角色、5个会议、12原则_scrum工件包括

本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。

一、Scrum的定义和目的

Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程，目的是让开发人员像打橄榄球一样迅猛并充满激情，通过团队合作，提高工作效率。通过团队间的有效交互，为企业创造价值。

二、敏捷宣言

其实，在发表《敏捷宣言》之前，很多的敏捷实践都已经存在且使用了，比如：Scrum、XP、KanBan等。之所以发表《敏捷宣言》，是因为这些实践都是在单打独斗地推进敏捷开发，而不是以一个联合体的形式，且没有一个统一的指导方针。所以17位敏捷联合创始人决定发表《敏捷宣言》，共同在全世界推进敏捷开发运动。下面是敏捷宣言的4句话：

三、Scrum中的人员角色

3个角色

Scrum中的人员分为3个角色：产品所有者（Product Owner）, Scrum Master，开发团队(Team)。

• 产品所有者：定义所有产品功能，决定产品发布的内容以及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理地调整产品功能和迭代顺序，认同或者拒绝迭代的交付。
• ScrumMaster ：ScrumMaster不是项目经理，他没有分配任务的权力，没有考核的权力，没有下命令的权力，他指导项目组的成员按照Scrum的原则、方法做事情，领导团队完成Scrum的实践以及体现其价值，排除团队遇到的困难，确保团队胜任其工作，并保持高效的生产率，使得团队紧密合作，使得团队个人具有多方面职能的工作能力，保护团队不受到外来无端影响。
• 开发团队：经典团队拥有 5-9 人，团队成员包含程序员、测试员、用户体验设计等等，团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开始时发生调整，团队自我组织和管理（自组织，自驱动），团队成员都全职工作。

四、Scrum的开发流程

（图片源自网络）

不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周，最常见的为2周。Scrum并非以一段时间集中完成一个过程，而是将所有过程中必须的每一部分集中在这段时间内完成。需求、设计、编码、测试、上线都必须在一个迭代中完成，每个迭代必须产生一个可以工作的软件。

4.0 Scrum三大工件

Scrum 工件是团队要完成的事情，就像是解决问题的工具。在 Scrum 中，常见的三个工件分别是 Product Backlog（产品待办事项）、Sprint Backlog（迭代待办事项），以及你对“DoD（已完成）”定义的增量变化。它们是 Scrum 团队中的三个常量，团队需要不断地对其进行重新审视，并投入额外的时间进行改进。

1、Product Backlog（产品待办事项）

Product Backlog 是整个产品的用户故事集合，这些用户故事可以来自甲方客户、Product Ower 自己对产品的理解、研发团队、公司战略规划拆解等等。

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

2、Sprint Backlog（迭代待办事项）

Sprint Backlog 指的是在一个迭代周期中要完成的用户故事列表。这些用户故事来自 Product Backlog，每次迭代前，Product Ower 根据交付价值，将优先级最高的用户故事放入迭代。

每次进入迭代之前，团队需要召开迭代规划会议，团队从 Product Backlog 中选择本次迭代计划完成的需求。迭代待办事项可能较为灵活，也可以在迭代期间变化。但是，基本的迭代目标（团队希望通过在当前迭代中实现的目标）不能受到影响。

3、增量（或迭代目标）

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

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

Tips：你应该像处理产品一样敏捷地处理 Scrum 框架，花一些必要的时间来检查事务的进展情况（无论是通过 PingCode 这样的工具或者是其他），并在必要时做出调整，而不要仅仅为了一致性而强迫自己执行某些事项。

4.1 五个会议

Scrum 整个开发过程分为五个会议:

1）待办事项整理会议（Backlog Grooming Meeting）

迭代计划会议开始之前3天召开，Product Owner与Scrum Master必须参加，关键开发者或架构师需要参加；时间控制在30分钟到1小时。

由Product Owner将一批希望团队在下次迭代时实现的用户故事，按照实现顺序描述给在场的团队成员，Scrum Master与在场成员分析用户故事，明确指出团队认为需求不明确的地方，Product Owner现场记录，会后补全，Scrum Master与架构师，还有在场成员分析用户故事需要包含哪些技术任务，Scrum Master先把子任务建立，方便迭代计划会议的时候团队可以更准确地预估任务故事点。

会议结束时，Product Owner确保在迭代计划会议开始之前团队提出的问题都能被解决，会议重点如果团队发现需要加强或是完善的地方，Product Owner还有两到三天的时间可以补强，而不是浪费迭代计划会议的时间去做这件事情。

2）迭代计划会议（Sprint Planning Meeting）

产品负责人建立产品功能列表（Product Backlog）。产品功能列表是一组条目化需求，它必须从客户价值角度描述，并按优先级排序。

Scrum Master召集相关人员召开迭代计划会，迭代计划会在每个迭代第一天召开，目的是选择本次迭代的Backlog和估算本次迭代的工作量。

产品负责人逐条讲解最重要的产品功能，开发团队共同估算Backlog所需工作量，直到本迭代工作量达到饱和。产品负责人参与讨论并回答和需求相关的问题，但不干扰估算结果。队员认领任务（或由组长协商分发），独立或与别人一起完成任务；会议时间控制在1-2小时内。

3）每日站会（Standup Meeting）

团队内部利用每日立会来沟通进度，15分钟结束，开发团队利用燃尽图来展示整体进度；如无特殊原因，迭代期内无变更，在每日站会上团队成员需要回答以下3个问题：

• 昨天你做了什么?
• 今天你将要做什么?
• 你有需要帮助的地方吗?

这些都是团队成员的彼此承诺。

4）评审会（Retrospective Meeting）

小组向产品负责人展示迭代工作结果，产品负责人给出评价和反馈。以用户故事是否能成功交付来评价任务完成情况。整个团队都需要参加，ScrumMaster、产品所有者、团队，可能还有客户，时间控制在1-2小时内。

5）反思会（Retrospective Meeting）

在每个迭代后召开简短的反思会，总结哪些事情做得好，哪些事情做得不好。做得好的保留，不好的摒弃。会议得出这样的结论：开始做什么、继续做什么、停止做什么，一般控制在15-30分钟。

Scrum是一套开发流程，是敏捷的一种，实施主要还是看人，强调是自组织、自驱动的，只有不断的在实际应用中仔细体会，才能理解Scrum的真谛，把Scrum用好。

4.2 12原则

下面给出敏捷开发的12原则，这12原则作为敏捷开发对于软件开发流程的指导性纲领，也是对敏捷宣言进行了具有实际操作意义的解释，希望大家在实际应用中仔细体会。

我们遵循以下准则：

• 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
• 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
• 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
• 项目过程中，业务人员与开发人员必须在一起工作。
• 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
• 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
• 可用的软件是衡量进度的主要指标。
• 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
• 对技术的精益求精以及对设计的不断完善将提升敏捷性。
• 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
• 最佳的架构、需求和设计出自于自组织的团队。
• 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。