Scrum 团队由产品负责人、开发团队和 **Scrum Master **三种角色组成，他们一起工作以交付所需的产品增量。简单来说，产品负责人确定 Scrum 团队交付什么并解释为什么做这些工作，Scrum Master 引导团队探索如何交付的最佳方式，开发团队则是执行具体工作任务的人员。
相较于传统意义上的项目团队，Scrum 团队同样强调所有成员遵循共同目标、遵守规范准则、尊重彼此，但同时也拥有着不同的特点：
-
轻量级。一般情况下 Scrum 团队的规模在5至9名成员之间，包括产品负责人和 Scrum Master 各1人，以及3至7名开发人员。开发人员实际数量基于两方面的考虑：在确保完成工作要求的同时，保持团队整体的敏捷性。
-
跨职能（Cross-functional）。跨职能是指 Scrum 的开发团队拥有完成工作所需的全部技能，而不需要依赖团队以外的专业资源介入。Scrum 开发团队的成员不再按照设计、开发、测试、运维等单一职能定岗，为了能在任一时间让每人都有任务执行，避免人力闲置，通常要求每人都能胜任多项开发过程所涉及的“工种”。
-
自组织（Self-organizing）。Scrum 团队的角色划分是为了支撑其经验主义理论对所需职责进行的最低限度的定义，以使团队能够对他们的组织和工作方式负责，并不断改进，同时不需要由类似项目经理的统筹角色或团队之外的其他人来指导、管控。由于面对的产品不同，每个 Scrum 团队的规模和所需技能也都不尽相同，刚开始团队掌握信息有限，恐怕难以做出合理预判，而自组织则意味着团队将随着项目进展灵活调整。
顾名思义，产品负责人是真正对产品负责的人，其职责是推动产品投资回报率，并将 Scrum 团队工作价值的最大化。为了实现这个目的，产品负责人既要作为连接产品用户、各相关方与开发团队的“桥梁”，又是 Scrum 团队的“舵手”，拥有着对产品需求定义与优先级排序的最高权力。其主要工作包括：
-
管理产品待办列表（Product Backlog）。并非只有产品负责人能将产品需求和任务放进产品待办列表中，但是只有产品负责人对产品代办列表最终负责 —— 他深知客户想要什么以及他们想要的业务价值，有权接受或拒绝新的产品待办事项，同时不断完善每个事项的表述、颗粒度及整体排序，以确保所有 Scrum 团队成员正确理解产品愿景与实现路径。
-
主导产品发布计划。产品负责人是产品需求优先级排序的唯一信息源，这意味着由他来确定每个产品版本的增量目标、具体内容和发布时间。他需要将这些信息及时有效地传递给开发团队，让每个人对什么是当前最重要的交付内容清晰可见，有一致且充分的理解。
-
协调产品相关方。显然，产品负责人需要同产品的各个相关方保持密切沟通，尤其是获取产品终端用户的反馈意见。他需要将开发决策与产品商业层面的目标以及各相关方的诉求协调契合，尽可能让开发团队的工作价值获得最大程度的体现和认可。
如果 Scrum 团队是做自己公司的产品研发，通常意义上的产品经理就是产品负责人。如果团队是以乙方的身份做甲方项目的外包开发，产品负责人即是客户同开发团队对接的人 —— 这也体现了“敏捷宣言”中的一大原则：开发团队并不是和客户去谈判，而是真正把客户放在开发的过程之中，与他合作。
如果来自客户方的产品负责人难以如开发团队所希望的那样频繁参与，或欠缺将产品需求清晰呈现的技能，往往会任命一位代理人（Product Owner's Agent/Proxy）代表他在一定程度上行使他的权责。代理人可能是专门任命的，也可能是开发团队中的某个人。我们建议尽量不要采取这样的做法，因为会增加产品开发中的沟通与决策风险。不论产品负责人或代理人来自哪里，都需要尽可能满足“ CRACK 原则”，即：
- Collaborative，易于协作、易于沟通；
- Representative，能代表用户、客户、市场的需求；
- Authorized，拥有对需求的决策权，且被产品所属单位授权；
- Committed，能够尽职尽责地工作；
- Knowledgeable，熟悉需求，对相关市场、业务等足够在行。
从人数上来看，毋庸置疑开发团队是 Scrum 团队的主力。他们负责：
- 决定在每个 Sprint 中交付多少工作，以及如何更好地实现目标；
- 交付潜在可发布并且满足“完成”标准的产品增量；
- 在这个过程中通过协作关系与组织行为，将 Scrum 的理论支柱、价值观、团队特点具象化。
Scrum 开发团队的成员并非都是狭义上的“码农”，而会根据产品需求，组成可能包括软件工程师、架构师、程序员、业务分析师、UI/UX 设计师、QA、测试和运维人员等各类专业人员的跨职能协作团队。但是在这个团队中，以上XX师、XX员不再成为某个人的特定头衔 —— 不管谁在承担哪种工作，统一都被叫作开发人员。这个团队是自组织的，无论团队内外，没有人有权告诉他们应该如何把产品待办列表变成潜在可发布的功能增量；同时也是扁平的，没必要再往下设所谓的“子团队”，无论其需要处理的是诸如测试、架构、运维或业务分析等各种领域的问题。
开发团队成员所掌握专业技能的广泛性和重叠度越高，能够形成的协作组合就越多，需要承认的是，Scrum 的这个主张是一种理想状态。可能对于大多数开发团队来说，不可避免地会有且只有个别成员才具备某种专业领域的技能。例如，某产品需要专业的 UI/UX 设计技能，而在整个组织中，掌握这种技能的员工都是专才。在这种情况下，该组织可以让 UI / UX 的专才进入多个 Scrum 团队承担设计任务，同时需要明确，各团队的交付责任属于该团队，而不是要让设计师对所有设计工作负责。此外，由于 Scrum 中的任务都是个人主动领取的，这就为开发团队成员之间相互学习提供了空间。
Scrum Master 无疑是 Scrum 的行家，他通过组织关键仪式和会议，确保 Scrum 过程服务于目标并能顺利进行。借助丰富的经验，他能够指导团队中的每个人理解 Scrum 框架的方方面面。不同于传统意义上的团队成员管理者、团队负责人或项目经理，Scrum Master 不会利用自上而下的管控方式来解决如何完成工作的问题，而是作为一名“仆人式”领导者，竭尽全力地帮助产品所属组织创建 Scrum 的支持环境，帮助产品负责人定义价值，帮助开发人员交付价值，帮助 Scrum 团队实现更好的发展 —— Scrum Master 更像是助推器和粘合剂。
Scrum Master 的主要职责包括：
- 作为教练指引 Scrum 团队适应和掌握 Scrum 框架，实践敏捷开发的价值观和原则；
- 帮助 Scrum 团队理解和有效使用产品 / Sprint 代办列表等工件，使每次增量带来最大化价值；
- 在被请求或需要时，引导 Scrum 仪式开展执行；
- 建立 Scrum 团队内外的良好关系，移除团队工作进展中的障碍，保护团队不受外界打断和分心；
- 激发团队活力，为团队创造自主改进其工作流程和方式的机会；
- 在组织范围内规划 Scrum 实施，与其他 Scrum Master 共同增强组织中 Scrum 应用效果。
为了确保 Scrum 过程高效运转，Scrum Master 在必要的情况下，也会为团队引入专业的 Scrum 协作工具，利用图表展示和分析团队效能，和团队成员或产品相关方一对一沟通协调，在不同话语体系之间充当“翻译”媒介……
那么，谁适合被“任命”为 Scrum Master 呢？显然，这个角色需要在组织中有一定的影响力，在此基础上，根据 Scrum 团队的成熟度，可以有几下几种模式：
- 专职 Scrum Master ，即 Scrum 团队中某个人的唯一工作，就是履行好 Scrum Master 的职责—— 这种模式最适合初学 Scrum 的团队。
- 参与多个团队的专职 Scrum Master，即第一种形式的延伸。如果一个组织有多个成熟度较低的 Scrum 团队且能胜任 Scrum Master 的人较少时，若有足够精力，可以尝试这种模式。
- 敏捷教练。Scrum 团队具备一定的成熟度，没有同某个专职 Scrum Master 完全“绑定”，当他们有需求时，才会邀请这个角色介入。
- 兼职 Scrum Master，即开发团队中的某个特定成员除了承担开发任务以外，还需承担 Scrum Master 的职责。
- 轮值 Scrum Master，即开发团队有多个成员能够兼任 Scrum Master，他们以 Sprint 为周期进行“轮值” —— 能够实现这种模式的 Scrum 团队已然拥有相对很高的成熟度。
关于Scrum团队的更多问题可参考文章：《scrum团队内部的角色与分工》。