在本系列的前几篇，我们梳理了敏捷的起源和目前的主要落地框架。其中 Scrum 框架是敏捷实践的绝对主流，几乎是团队级敏捷实践的事实标准。而规模敏捷框架也大多是在 Scrum 的基础上来进行扩展。因此我们后续的总结将以 Scrum 为基础，探讨敏捷在软件研发过程中落地实践的主要做法运作方式。

本篇我们将从探讨 Scrum 框架的角色组成来谈起。

Scrum 团队

在 Scrum 中，Scrum 团队只面向一个目的，就是每次都是为了完成产品的一个有价值的目标而存在。Scrum团队作为敏捷组织中有凝聚力的最小生产力单位，Scrum团队内不再有层级结构。团队由跨职能的专业人员组成，团队成员应该具备完成产品目标的所有技能。

在运作中，Scrum团队会负责所有与产品目标相关的活动，包括同利益相关者的协作、验证、维护、操作、实验、研究和开发，以及其他任何可能需要的活动。Scrum团队是自组织并自我驱动的，以一种可持续的节奏，保持专注并不断交付价值。

虽然在团队规模上没有明确约束，但通常一个 Scrum 团队的理想规模应该限制在 10人以内。小型团队会有更好的沟通效率，更高的单位生产力。

在每个迭代（Sprint）中，交付有价值的增量（Increment）是整个团队的职责所在。Scrum 针对这个目标，定义了团队中的三种不同角色：开发团队（Developers）、产品负责人（Product Owner）和 Scrum 教练（Scrum Master）

产品负责人 Product Owner

PO这个角色，从命名也可以看出，是团队工作产物-产品 的拥有者。产品最终要做成什么样子，PO有决定权。 在团队中，他是最终用户的代言人，是需求的来源方、定义者和最终决策人。

所以PO的职责，包括以下几方面：

1. 定义需求，管理产品待办清单

作为PO最主要的职责，也就是定义需求。需求是团队工作的源头，也是基础。需求的定义和确定，虽然并不完全是PO独立完成的工作，团队成员也会参与到需求的讨论、梳理和完善中，但PO会是需求最终的决策拍板者。完成定义的需求，也就是产品待办清单PBI(Product Backlog Item), PO 是PBI的管理人和负责人，即便团队也会参与到需求条目的维护和一些技术细节的细化工作中，但PO会对PBI中的每一个条目负责。

PBI中包含的需求，是所有未实现的需求清单，包括当期和远期的需求，所以在管理 PBI时，PBI的一个重要属性就是它的优先级，定义 PBI 的优先级是PO的职责。PO要根据需求对产品的价值，以及团队的反馈，综合风险和收益，确定每一个需求的优先排列顺序。

这也是 PBI 以列表形式存在的一个先天优势，每一条需求在列表中都会有一个唯一的位置，这个位置就代表优先级。列表中越排得靠前，代表优先级越高。PO管理待办清单，重要的一点就是要管理好每条需求对应的排列顺序。有效管理的 PBI 是后续迭代启动的基础。

2. 向团队澄清需求，及时反馈

而对于敏捷团队而言，既然需求是工作的输入，所以 PO 还有一个重要的职责就是向团队解释需求的定义，澄清可能存在的误解或不够清晰明确的描述。

这个过程是持续贯穿在研发活动中的，既包括前期，在迭代计划会之前的需求梳理精炼会（grooming meeting），也包括在迭代进行中，当成员对需求有疑问或需要决策的时候，能够及时给出反馈和说明。这也是为什么说 Scrum 团队是应该要大家一起工作，保持沟通效率的重要因素。

3. 维系和利益干系人的关系

Scrum 团队在工作中，必然会牵涉各种利益干系人，包括投资人（各产品各相关部门的主管），客户，终端用户、内部关联部门（销售、售后、客服、法务合规、安全、审计、质量等等）都会有一些和产品的关联，这些不同渠道的意见、声音和反馈可能都会影响到产品相关需求、实现的定义，所以PO是维系这些渠道，和这些不同干系人进行沟通和协调的责任人。这也是为什么作为PO这个角色的成员，应该是一个具备很好沟通能力和协作能力的人。

4. 工作产出（Increment）的成果确认人

作为产品的Owner，团队每个迭代的工作成果，是否符合要求，能否达到预期的产品要求，是由PO来进行确认的。

Scrum中虽然没有定义单独的测试角色，但测试这个工作其实是包含在开发团队中的，对产品的验收确认，虽然最终是PO拍板，但并不是说 PO会负责这里的测试工作。更多还是根据测试成员的评估或者迭代的演示评审会上的反馈，来判断产品目标是否达成。

总而言之，PO 作为Scrum团队中一个非常核心的角色，极为关键。 专人专职其实很有必要，在有的敏捷项目中，PO可能身兼数职，游离于团队之外，其实都是没搞清楚这个角色的重要性。

Scrum大师（教练） Scrum Master

在有些似是而非的敏捷项目中，会把SM和传统的项目经理PM混为一谈，认为Scrum Master的工作就是传统PM的作用。这是完全错误的理解。

1. 并不是团队成员的上级

传统项目中，PM是一个项目的负责人，需要对项目的成功负责。同时PM也会具备相应的项目管理权，对项目成员的工作分配权，对成员的工作成果的考核权，和项目成员是不同层级的关系。

但是在Scrum中，SM和团队成员是平级的关系，更没有考核、评估权。SM的主要职责是保证团队工作的顺利开展，是作为协调人，以自己对敏捷的专业理解和实践经验，引领团队尽可能高效地完成迭代工作。其实定位是一个服务者的角色。在sprint执行过程中，通过观察和监测迭代运作情况，及时消除阻碍，并鼓舞大家的干劲，必要时给大家打打鸡血。

2. 敏捷价值观和敏捷实践的推行

作为Scurm大师，敏捷教练。SM的职责是贯彻敏捷的价值观，并把这个价值观传递给所有成员，并以自己的实践经验让团队的运作符合敏捷的原则。

作为Scrum团队的牵头人，SM会需要负责迭代中的一些主要活动的组织，最主要的就是Scrum中的四大仪式会议。当然还会包括一些其他的需要协调组织的活动，比如一些紧急事项的讨论，重要的澄清、评审等等。在这些活动中，SM通常需要作为主持者，保证活动的效果，避免跑偏。

3. 团队的防火墙

SM职责中很关键的一点就是，SM需要作为团队的防火墙。这也是作为SM非常有挑战的地方。对一个迭代来说，迭代目标的达成是团队在sprint周期中最重要的事项，迭代过程中的工作都应该围绕这个目标展开。

但在任何组织中，都难免可能出现一些干扰到团队成员工作的地方。比如一些领导会临时交办一些额外的任务，做临时的人员抽调等等。这时SM需要起到防火墙的作用，要能够将这些任务顶回去或者通过协调，寻求外部支持等保证当前的迭代目标不受到影响。一切以完成sprint的既定目标、保持团队战斗力为目的。而不是让团队成员直接被各种外部事务干涉，影响到当前迭代任务的完成。

开发团队 Developers

Scrum团队的主体其实就是开发者团队Developers Team。但这里的开发者，并不应该理解成传统理解的程序员。Scrum团队的定义，是团队应该具备完成产品目标的所有技能，所以这里的开发者团队，其实是一个笼统的概念。除了程序员，还会包含测试人员、视觉设计，可能还会有架构师、DBA、配置管理等等多种传统项目中不同的角色，但在Scrum中，都统称为Developers。

1. 具备各种完成目标的技能

所以对于开发者团队来说，首要的职责，就是要具备完成产品目标的各项技能。包括设计、开发、测试、部署、配置等等。但这些工作，是被看作一个整体，不会明确对应到具体的单个成员。也就是团队中成员的技能可能会是综合的，一专多才，不会将团队整体能力建立在对个别成员的依赖上。

相对传统研发，Scrum的开发团队成员，应该是跨职能的，每个成员都会有承担不同任务类型的技能要求和对应能力。简单来说，这里的开发者团队，每个成员的技能会有侧重点，会承担对应的任务类型，但不绝对，也有可能会要承担非主技能范畴的工作，一切以完成迭代工作目标为目的。

2. 待办清单和需求的评估

开发团队的另一项职责是要评估PBI中的待办项。

PBI中需求的实现终归还是开发团队负责，实现的方案、技术、团队的能力成熟度都会对完成每一条需求的实现工作量产生影响。

而实现需求的工作量，又直接影响需求的完成和交付，所以在敏捷中，对需求的估算是一个重要的事项。

这里的估算就是开发团队的主要职责之一。在Scrum中估算一般会发生在需求澄清会或者计划会时完成。可以通过经验估算法或者按计划扑克法尽可能客观地评估出每个需求的实现复杂度和工作量。

估算的准确度会直接影响迭代目标的完成情况和迭代运作的健康水平。也是开发团队成熟度的一个指标。

3. 目标分解和任务认领

在PBI中，需求主要是业务层面的要求。但其具体的实现方案和实施，通常还需要拆分成不同的任务，比如前端任务、设计任务、后端任务、测试任务等等。这些都需要开发团队来完成任务的分解和通过自组织的认领、分配。这个工作一般会在计划会上，团队集体完成分派和认领。

4. 完成承诺，交付价值

最后就是完成迭代的承诺并交付产品增量，提供产品价值。保质保量地完成迭代计划时承诺的既定目标，是开发团队整体工作的核心。迭代的承诺达成率是一个Scrum团队是否成熟，Scrum敏捷落地是否成功，最直接的一个观察指标。

总结

以上就是对Scrum框架中三大角色，其各自职责和要求的分享。用三句话提炼总结就是：

• PO负责让大家做对的事
• 开发团队负责把事做成
• SM负责让团队把事做好