The Scrum Framework — 第二版

本章保留第二版的历史与实践教学语境。下方目录也提供第三版课程。

---

敏捷项目管理中的 Scrum 团队与职责［完整指南］

敏捷交付环境的 Scrum 团队由承担具体责任的人组成，通常包括 Scrum Master、产品负责人和开发团队。Scrum Master 帮助 （Scrum Master 的 10 大品质与团队技能） 遵循原则和实践，产品负责人代表业务和组织利益。

什么是 Scrum 团队，如何组织？

跨职能成员密切合作，在称为 Sprint 的短迭代中交付优质产品。透明、检查、适应和自组织，让团队持续改善、回应客户变化。

数字时代管理不仅是投入多少小时细致规划，更是估算投入及推进速度。高校和培训师日益关注兼顾效率质量的方法，案例和回顾也突出敏捷中的 Scrum。本指南提供丰富内容，介绍基础和团队协调，让专业人士熟练开展敏捷管理。若组织希望加快增量且不损质量，追求效率，就深入掌握团队，释放潜能！

Scrum 团队跨职能，包括 Scrum Master、产品负责人和开发人员。这些自管理团队共同负责从功能开发到待办管理的全部产品活动，用短 Sprint 交付增量价值。互动是成功关键，最好 10 人以下以优化沟通效率。重要活动和定期评审提供提问反馈的平台。

Scrum 团队概述

许多项目管理高校都教授 Scrum：它以团队和迭代方式，高效开发交付软件，管理复杂项目。核心团队有三项责任：开发人员、产品负责人、Scrum Master。（参阅 Scrum示例）开发人员每次产出潜在可发布增量。产品负责人投入于最大化价值、明确交付需要。Scrum Master 指导支持最佳表现及遵循价值观。这些职责支持项目和组织成功。

借橄榄球比喻，团队共同争取达阵。开发像前锋，承担重活、推向目标；产品负责人像敏捷的传球中卫，评估局势和待办，预见下一步；Scrum Master 像资深教练，帮助执行战术、提高表现。持续互动承诺，让三者互补高效达标。

没有有效团队或充分理解其功能，实施敏捷可能徒劳。

通过比喻理解优秀团队后，深入看看结构。高效互动和开放沟通的承诺至关重要。

Scrum 团队及组织结构

跨职能合作是成功开发的基础，前提是清楚理解方法并共同解复杂问题。当前 Scrum Guide 指团队通常 10 人以下，是指南，不要求必须 5–10 人。开发、质量控制和领域专家协作，像组织内小企业，共同解题、交付优质服务，体现公司人员结构的缩影。

大型团队看似有优势，研究却显示长期障碍可能多于收益。决定规模时，应考虑职责互动的复杂性，以及领导支持不足等影响团队动态的因素。

像驾船，大船保持移动或转向需要更多资源精力，小船能快速过风浪。管理团队同理。像读书练习提升技能，企业也常发现：合适领导支持下，小而凝聚的团队更善于管理待办和高效交付。组队时“少即是多”或许是关键策略，营造健康环境，既快又不牺牲质量。

自管理是敏捷和 Scrum 核心。团队对任务负责，保持高效互动；在合格培训师指导下，自行决定组织执行方式。产品负责人仍对产品待办排序负责，开发人员拥有 Sprint 计划和每日 Scrum。

例如开发可选有利协作生产力的语言或工具，增强归属授权，改善员工参与。自管理还让不同背景发挥传统管理甚至部分领导不会鼓励的独特技能。

Scrum 团队与敏捷自管理

自由伴随责任，需要纪律、问责和从合作培训机构持续学习。团队须有充分信任及共同职业伦理认识。

理解自管理后，深入看看具体职责及其他生产力因素。

三项主要职责为 Scrum Master、产品负责人（PO）和开发人员。

明确团队职责

Scrum Master（SM）： 主要是引导，通过 Sprint 限时、每日站会等结构流程支持敏捷原则。像商业世界的图书管理员，保持一致、不遗漏问题。

产品负责人（PO）： 把相关方、客户和领导期望转为符合价值流的产品愿景，连接业务与开发，保持目标导向，是各方沟通枢纽及功能主要决策者。分析销售、成本、运营数据，知情决策，兼顾最高质量与成本效率。

团队成员（开发人员）： 开发人员是主要实施者，跨职能技能共同创造可用增量。目标是高效执行 Sprint、控制成本并不断改善流程。理想个人技能多样，涵盖设计、代码、测试、业务、成本及用数据促进销售。培训鼓励提升技能与客户服务，学习最新 UX 或进修 Scrum Master II 可显著提高效率和节约成本。

关系像作曲家与指挥：产品负责人结合销售成本澄清价值优先级，开发人员决定如何转为产品。培训支持技能，不是额外 Scrum 责任。课程所学使细节执行认真，改善客户服务。

更重要的是集体负责，成败不归于单项职责。共同使命及成本约束下的和谐合作，支持顺畅沟通、持续改进和创新。

理解职责后，本完整指南继续看大小项目管理，包括优化运营、提高服务质量、促进销售并省钱。

开发人员用 Scrum Master II 等课程知识，把故事转成可用增量。其劳动占整体运营的重要成本，支持整个框架有效性。

开发与产品负责人协作，按需细化并把完成的功能集成可用增量，不等全部功能经过独立阶段。参加培训、分析销售、与社区分享，提升技能理解及服务。

整体跨职能是核心特点。持续学习建立团队所需技能，但不要求每人精通一切。销售数据、成本、编程、测试和界面等多技能，让人从不同角度解题，形成创新有效方案。

敏捷 Scrum 开发中的开发人员

强调责任协作，成员应持续互通进展。每日会议像课堂，更新任务、障碍和支持需求，保持信息流，也帮助跟踪成本和服务对销售、满意度的影响。

例如某人调试受阻 2 天，有经验或类似经历的同事可用 Scrum Master II 所学协助，省时间金钱、改善运营。规划中与负责人和 Scrum Master 明确开发事项，像一起学习合作的课堂，共同探索创新与规模化。LinkedIn 也可提供扩展方法的成长见解。

之后开发估算各任务所需工作并考虑风险。平衡效率和复杂性、时间等因素，是课程常见收获，也支持持续收入增长。

最终每个 Sprint 末交付潜在可发布增量。培训支持的稳定产出，逐步展示价值、维持相关方投入，成为可持续收入和成长来源。

Scrum 的职责围绕具体功能而非传统层级规则。培训社区、LinkedIn 等平台的 Scrum Master II 课程可帮助对齐。Product Owner 与 Scrum Product Owner 是同一责任的两种名称，并非共同拥有的两个人。产品领导管理能力帮助跨 Sprint 最大化价值，通过迭代增量实现商定范围。

开发与产品负责人协作，按需细化并把完成的功能集成可用增量，不等全部功能经过独立阶段。参加培训、分析销售、与社区分享，提升技能理解及服务。

Scrum Master 与软件开发人员和 Scrum 产品负责人协调合作，发挥敏捷领导作用。他们推动而非强制规定软件开发流程，通过帮助团队灵活应对挑战、跟踪进展，并引导站会和 Sprint 评审等 Scrum 事件与活动，尽可能提高团队工作效率，体现敏捷领导与有效 Scrum 实践相结合的价值。

Scrum Master 确保团队遵循 Scrum，并理解其价值观、实践及框架概念。这两个角色都对 Scrum 团队的有效沟通至关重要：他们加强利益相关者之间的协作，帮助团队更好地实现项目目标。为此，一些 Scrum Master 和产品负责人甚至参加 LinkedIn 上的领导力课程，扩充知识并取得相关认证，从而更有效地指导团队。

Scrum Master 与产品负责人

要确保 Scrum 团队有效沟通，我们必须了解这两个角色如何协作并有效交流。这是此类产品管理安排的前提，也要求通过 Scrum 培训与教育的创新，持续提升人际交往技能和知识。

有效沟通是敏捷项目管理的支柱，对 Scrum 团队顺畅运作至关重要。每位成员都必须紧密配合才能取得成果，而这离不开持续沟通。清楚地传达想法能够避免误解和延误，最终提升产品质量，降低时间与资源浪费的风险。

第一步是建立清晰的沟通渠道，营造有利于在多个团队乃至整个组织中成功推广 Scrum 方法的环境。

使用 Jira 或 Asana 等共享平台，把这些沟通渠道付诸实践，使平台成为跟踪任务进展、识别需要立即处理的问题的共同参考。软件支持的方式让包括软件开发人员在内的所有成员实时了解情况，借助技术帮助大家掌握信息、及时响应。积极参与有助于迅速解决难题，推动产品交付。

例如，软件开发人员在开发产品时发现问题，与产品负责人合作时就需要始终保持有效且持续的沟通，确保所有关键功能都得到关注。我们网站最近的一篇文章将这类方法的成功，包括敏捷领导原则的运用，归因于 Scrum 联合创始人 Ken Schwaber 提供的指导。

• 《敏捷状态报告》发现，58% 的组织已在项目管理中采用敏捷实践，例如 Scrum。
• 同一份报告还指出，遵循建议规模、成员少于 10 人的 Scrum 团队，项目完成成功率更有可能较高。
• 《Journal of Systems and Software》刊登的研究发现，Scrum 团队限制在制工作数量，并专注于完成当前任务后再开始新任务时，效率显著提升。

自组织 Scrum 团队中的有效沟通

其次，团队应安排经常性的会议，让成员讨论正在进行的任务、遇到的困难或障碍，以及各个已达成里程碑的状态。每日站会（Sprint 的每个工作日举行的 15 分钟事件）也是敏捷领导价值实践的重要组成部分，能够及时掌握影响交付成果的问题。

例如，开发人员在开发产品时发现问题，与产品负责人合作时就需要始终保持有效且持续的沟通，确保所有关键功能都得到关注。我们网站最近的一篇文章将这类方法的成功，部分归因于 Scrum 联合创始人 Ken Schwaber 提供的指导。

其次，团队应安排经常性的会议，让成员讨论正在进行的任务、遇到的困难或障碍，以及各个已达成里程碑的状态。每日站会（Sprint 的每个工作日举行的 15 分钟事件）也有助于及时掌握影响交付成果的问题。

最后，在 Scrum 团队中建立开放文化，鼓励成员持续反馈，有助于在后续 Sprint 中改进遇到困难的环节。定期以建设性的方式给予和接收反馈，能够改善成员之间的关系。

在 Scrum 团队结构中建立有效沟通后，让我们看看 Scrum 的决策过程。

Scrum 团队围绕共同目标协作，同时各自承担明确的责任。开发人员与产品负责人一起选择并规划 Sprint 工作；这并不要求每项待办列表决策都进行一人一票的表决。Scrum 因而促进所有成员协作，增强他们的能力，让他们能够自由参与决策。

有效沟通对敏捷项目管理和 Scrum 团队的成功至关重要。团队应建立清晰的沟通渠道，利用 Jira 或 Asana 等共享平台，让每个人实时掌握信息。每日站会等经常性的会议让成员讨论任务、困难和已达成的里程碑。鼓励持续反馈的开放文化能够改善成员关系，并推动后续 Sprint 的改进。

跨职能 Scrum 中的决策过程

不过，团队决策时仍有一些具体准则。团队可以在有助于决策时寻求共识，应共同商定切实可行的决策流程，而不应假定 Scrum 要求每项提议都获得全体一致批准。

这就像一艘船：决定暴风雨中的绕行路线或必要维修之前，会考虑所有人的意见。

如果一位成员不同意某项决定，其他成员应与其共同澄清并解决疑虑。不过，达成共识并不总意味着每个人都必须完全赞同，而是找到整个团队都能安心接受的共同立场。

如果无法达成共识，团队可以选择其他合适的决策方法，包括投票。无论选择哪种方法，都必须尊重产品负责人对待办列表的责任，以及开发人员对工作开展方式的责任。

需要强调的是，Scrum 旨在支持自组织，因此决策权最终属于整个团队。利益相关者在 Sprint 评审和持续协作中提供宝贵见解。Sprint 回顾用于 Scrum 团队改进工作方式；有需要时也可以邀请其他人参加。

Scrum 团队中的共识，是指全体成员对产品开发过程中的具体行动、流程和决定形成总体认同。团队通过透明的沟通渠道达成这种认同，让每位成员都能表达意见和想法，而不必担心遭到报复或评判。

Scrum 团队中的共识

共识有助于协作，但 Scrum 并不强制每项决定都必须全体一致。产品负责人负责产品待办列表排序，开发人员决定如何组织并完成所选工作。这种安排有助于大家朝同一目标努力。实质上，所有成员都参与决策，而这对持续稳定地交付产品至关重要。

例如，一家公司想开发一项新软件功能。产品负责人将其列为高优先级任务，希望在两个 Sprint 内完成。在 Sprint 规划中，开发人员提出一种替代方案，能比原计划带来更多价值，但也更复杂。全体成员经过认真讨论和协作，一致认为替代方案能为最终产品增加显著价值，因此决定采用它。

因此，Scrum 团队中的共识能够促进成员合作与团结，加快实现项目目标。它也能建立信任，避免强势意见压制其他观点，同时维护 Scrum 各项责任，支持有效决策。

了解共识之后，现在来看价值交付及其在 Scrum 中的作用。

Scrum 框架中的价值交付

价值交付是敏捷项目管理方法中最重要的方面之一。它使开发工作符合公司目标和客户需求，推动项目成功。Scrum 团队的价值交付有两个关键方面：在 Sprint 中逐步交付价值，并在每个 Sprint 结束时交付可发布的功能。

Sprint 规划会帮助团队确定 Sprint 中能够完成哪些事项，并利用产品负责人定义的需求界定价值。每个价值增量都是获得客户反馈、持续改进最终产品的机会。

例如，假设产品负责人确定了三项对改善软件用户体验至关重要的功能。开发团队决定在连续三个 Sprint 中交付，每个 Sprint 都交付整体功能中可用且有价值的一部分。这种方式确保客户每隔几周就获得新增或改进的功能，并能逐次对每个发布增量及时反馈。

价值交付提高客户与开发团队之间的透明度，让客户及时对已交付的价值增量反馈。客户经常获得有价值的功能升级，无须等待大型发布，因此满意度也会提高。

以 Sprint 开展工作

Scrum 团队的一项鲜明特点是重视以 Sprint 开展工作。Sprint 是明确的限时周期，让团队在持续改进产品的同时完成短期目标。通常持续一至四周，其中两周最为常见。

在 Sprint 中，Scrum 团队协作实现一组具体目标，推动整个项目完成。Sprint 规划会让成员讨论并确定当前任务的优先级，随后建立 Sprint 待办列表，列明本轮 Sprint 将开展哪些工作。

实质上，Sprint 支持增量开发和迭代改进，避免长期投入某个最终可能无法满足利益相关者需求的计划。

每个 Sprint 结束时，团队举行评审会，展示上一轮迭代完成的目标。利益相关者可以就项目进展，以及后续是否需要调整提出反馈。通过这种频繁的反馈循环，团队能迅速适应和改进，同时始终关注最终目标。

客户反馈与适应

如前所述，客户反馈在 Scrum 团队的敏捷项目管理过程中至关重要。Scrum 团队会在每个 Sprint 结束时的评审或其他产品演示中，尽量多地收集客户反馈。

通过持续、实时收集客户意见，Scrum 团队能够根据客户需求快速调整产品，而不是自行假定什么对客户最好。

企业的一种失败模式是：不同部门或角色（例如开发人员、产品负责人）根据各自假设制定解决方案，却不向真实客户验证。

Scrum 团队在整个项目中促进跨职能团队协作，采用快速交付周期，并强调尽早获得真实用户反馈，以此聚焦客户满意度。尽早采取这种做法，能让开发流程更好地在后续 Sprint 中考虑客户反馈，并据此转变或调整方向。

较大 Scrum 团队面临的挑战

Scrum 团队的一项主要挑战，是在承诺交付成果的同时，保持专注并产出高质量工作。团队人数会影响工作流程和内部沟通，可能导致会议延长以及阻碍进展的人际冲突。较大团队的成员可能难以统一目标、达成共识，从而减少了用于向客户交付价值的时间。

例如，一个 Scrum 团队有 20–30 人时，沟通会变得复杂，影响心理安全感，以及成员分享想法、表达疑虑或在评审中坦诚回应的意愿。成员可能变得不愿彼此交流，削弱有效协作的能力。结果是更多时间花在人际冲突上，而不是专注于高质量产出。

沟通路径增多造成信息孤岛，成员在缺乏协调的情况下兼顾不同角色，这种复杂性会降低项目效率。研究表明，Scrum 团队少于 10 人时，吞吐量增加，结转工作减少。这一规模适合开展规划和每日站会。

在不适合命令式层级的敏捷环境中，自组织团队至关重要。将规模过大的群体重新组成独立、跨职能的功能团队，是改善协调的一种方法，无须在 Scrum 团队内部建立有层级的子团队。合适的团队规模让技能互补的成员紧密协作，从而提高交付效率。

与 Scrum 团队合作没有放之四海而皆准的方法。不过，要有效管理较大团队，可以采用一些实用做法，例如明确团队角色，并提供支持机制，建立开放的沟通渠道。

组织多个紧密协作的 Scrum 团队

在项目中组建多个紧密协作的 Scrum 团队时，首先要确保每个团队都能独立产出高质量成果，同时保持良好的一致性。可以先识别主要利益相关者和项目工作流程，再按优先级划分不同团队，以实现这一点。

围绕同一产品工作的团队共享产品负责人、产品待办列表和产品目标。不同产品可以有不同的产品负责人。每个 Scrum 团队也都需要有人承担 Scrum Master 的责任；如果能够有效履职，同一个人可以服务多个团队。团队之间应公开协调，以管理依赖关系并消除障碍。

另一种有用的方法，是定期让所有 Scrum 团队一起参加 Sprint 评审，促进团队间协调。这有助于整个项目保持凝聚力，同时确保每位成员对自己的产出负责。

在多个团队参与的大型项目中，通过紧密协调扩展 Scrum 时，仍须坚持其核心原则。这意味着所有 Scrum 团队都要保持专注、透明、积极性和开放的沟通渠道。大型团队群起初可能令人望而生畏，但只要周密规划并认真执行，也能取得成功。

同时要记住，每个项目都不同，一个项目群中有效的做法，换到另一个项目群未必同样奏效。因此，要找到组织多个紧密协作的 Scrum 团队的合适方法，可能需要一些尝试。

了解较大 Scrum 团队面临的挑战，以及组织多个紧密协作的 Scrum 开发团队的最佳实践之后，现在来看看处理团队内部冲突的一些有效方法。

关于 Scrum 团队工作技能、责任与跨职能协作的问题

谁对 Scrum 团队的绩效和工作负责？

Scrum 团队以自组织著称，每位成员运用独特技能和专业知识实现项目目标。团队中的协作精神和责任意识，让他们能够高效、有力地交付高质量的软件解决方案、产品与服务。

Scrum 团队与其他类型的项目团队有何不同？

Scrum 团队重视灵活性、协作和持续改进，这一点使其有别于其他项目团队。相较于传统项目团队，Scrum 团队采用敏捷方法，提高生产力，更快地向客户交付价值。项目管理协会（PMI）的一项调查显示，采用敏捷项目管理的组织报告的成功率，平均比使用传统方法的组织高 28%。Scrum 团队还设有产品负责人、Scrum Master 和团队成员等明确角色，确保团队责任清晰、沟通高效。

Scrum 团队常遇到哪些挑战，如何克服？

Scrum 团队在敏捷项目管理中常遇到的挑战，包括沟通与协作不畅、期望不切实际，以及范围蔓延。为应对这些挑战，团队可以通过定期会议和共享文档改善沟通，预先设定现实目标以管理期望，并通过确定任务优先级、让利益相关者参与决策来主动管理范围。VersionOne 的调查中，58% 的受访者将沟通不足列为敏捷项目的一大障碍，凸显了主动解决这一问题的重要性。

在项目管理中采用 Scrum 团队方式有哪些好处？

在项目管理中采用 Scrum 团队方式有许多好处。首先，它加强成员之间的协作与沟通，提高生产力。其次，它支持灵活适应需求变化，提升客户满意度。第三，Scrum 的迭代特性促进团队持续改进和学习。最后，研究表明，相较于传统项目管理方法，采用 Scrum 的组织平均上市时间缩短 28%，交付速度提高 60%（来源：《敏捷状态报告》）。

有哪些值得推荐的策略或技巧，能够有效管理 Scrum 团队？

在敏捷项目管理中，有多种值得推荐的策略和技巧可以有效管理 Scrum 团队。首先，保持开放的沟通渠道、加强成员协作至关重要。其次，定期举行站会和 Sprint 规划会，有助于确保大家对项目目标和任务保持一致。此外，看板等可视化工具有助于跟踪进展和发现瓶颈。最后，赋予团队决策权，并通过回顾鼓励持续学习，能显著提升生产力和满意度。麦肯锡的一项研究显示，有效管理 Scrum 团队的组织，其项目成功率比未做到这一点的组织高 66%。

Scrum 团队中通常有哪些角色和职责？

Scrum 团队通常有三个核心角色：产品负责人、Scrum Master 和开发团队。产品负责人负责定义产品目标、确定功能优先级，并确保利益相关者满意。Scrum Master 发挥引导作用，消除障碍，确保团队遵循 Scrum 实践。开发团队则负责在每个 Sprint 中交付有价值的产品功能增量。《敏捷状态报告》的调查显示，78% 的组织表示，其 Scrum 团队配有专职产品负责人和 Scrum Master，说明这些角色在敏捷项目管理中十分重要且普遍。

什么是 Scrum 团队和 Scrum 角色？

Scrum 团队通常是跨职能团队，成员具备开发、测试和设计等不同技能，因此能以协作、高效的方式交付项目。团队遵循透明、检视和适应原则，在称为 Sprint 的短迭代中共同工作，不断改进流程，交付满足客户需求的高质量产品。

Scrum 团队及 Scrum 在敏捷项目管理中作用的回顾

Scrum 团队是敏捷项目管理的核心动力，通过协作、适应能力和效率推动成功。以下关键认识说明了 Scrum 团队的重要性：

• 跨职能协同： Scrum 团队汇集不同技能和专业知识，形成跨职能合作，成员优势互补。这种结构使团队效能提高 30%，确保全面覆盖项目各方面。
• 获得授权的自组织： Scrum 团队以自主和自组织为核心，有权决策并迅速适应不断变化的需求。这种自主性使项目风险因素减少 35%。
• 更强的主人翁意识与责任感： Scrum 团队的每位成员对具体任务负责，形成责任意识。共同担责让项目按期完成的表现提高 25%。
• 高效沟通与协作： 每日站会和定期活动建立开放的沟通渠道。Scrum 团队报告协作与信息共享提高 40%，从而更快解决问题、理顺工作流程。
• 适应性问题解决： Scrum 团队采用迭代方式，持续获得反馈并作出调整。这种方式使创新性问题解决策略增加 20%，确保产品随客户需求演进。
• 更高的员工满意度与留任率： 在 Scrum 框架内工作的团队，工作满意度更高，员工留任率因此提高 15%。
• 关于 Scrum 团队的其他重要统计数据：
  1. Scrum 团队平均有 7 名成员。
  2. 95% 的 Scrum 团队表示，采用 Scrum 框架后生产力有所提高。
  3. 与传统项目管理方式相比，Scrum 团队的项目失败率降低 50%。
  4. 使用 Scrum 的组织中，85% 的客户满意度有所改善。
  5. Scrum 团队管理的项目成功率约为 75%，高于行业平均水平。

Scrum 团队重视协作、适应能力和主人翁意识，是敏捷项目管理的关键支撑。其结构和方法让个人携手取得出色成果，使 Scrum 成为当今不断变化的项目环境中的重要变革力量。

现在轮到您与 Scrum 团队一起取得成功，实现前所未有的效率和生产力。

Scrum 重视协作、迭代开发和持续改进，帮助团队敏捷、灵活地应对复杂任务，确保向利益相关者交付最大价值。您和同事正是让这一切成真的人！