The Scrum Framework — 第二版

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

---

分布式 Scrum：项目与团队最佳实践

分布式 Scrum 发挥 Scrum 原则的力量，使之适用于远程团队协作。这反映了人员地理分散的现代趋势，同时保持项目效率和有效性。不同地区成员带来的多元视角，甚至能比传统 Scrum 产生更多独特方案和创新，让项目每一步既顺畅又丰富。准备好了解如何做到吗？

分布式团队实施 Scrum，需要清晰沟通、专用协作工具和持续改进的承诺。 开展每日 Scrum 对保持分布式团队的专注、协作和问题解决能力十分重要。

分布式 Scrum 概述

分布式 Scrum 像乐团指挥，即使成员相隔各地，也能引导并协调努力。它调整成熟的 Scrum 框架，满足远程团队特有需求，始终突出适应性、开放协作、持续学习和自组织。

这种调整让世界各地的团队利用现代通信技术和协作工具顺畅合作，共同规划、执行和跟踪项目，同时尊重每位成员的自主权和专长。

敏捷原则的实践

敏捷原则像指路星，照亮分布式团队的成功道路。适应性鼓励灵活响应变化；开放协作形成包容文化，让思想跨越地域自由交流；持续学习则确保远程团队了解行业发展和技术进步。

不断学习是应对专业环境演进的必要条件。自组织让成员自主承担工作，形成不受距离限制的责任意识和自主性。

Gartner 的见解

Gartner 表示，到今年，90% 的敏捷开发团队将把远程工作纳入业务连续性计划。这一数字说明分布式团队在全球化职场中越来越普遍和重要。

想象成员分处不同时区，各有独特视角和优势。分布式 Scrum 将多样人才协调成整体，形成全天候推进、进展不停的工作安排。

就像组建国际专家团队，共同开展全天顺畅运作的突破性项目。每个人独特的见解都丰富集体知识。

采用分布式 Scrum 的原则与实践，远程团队就能克服地理分离，通过共同努力和不受边界限制的协作取得出色成果。

证据表明，有策略地采用分布式 Scrum 能给远程组织带来多种益处。下面看看这一方法在不断变化的工作环境中的优势。

分布式与大型 Scrum 项目

目前介绍的 Scrum 框架最适合单个、同地团队。但现实中，一个团队常无法完成整个项目，或资源分布多地，因此需要增加团队或分布式工作。原因可能是技术性的（当地缺少专家）、规模性的（项目太大），或业务性的（使用低成本国家资源，或利用时区加快交付）。

沟通是 Scrum 的组成部分，分布式环境尤其需要克服沟通挑战。所有成员应有合适工具，例如视频会议和摄像头，以打破障碍。

项目组织：多个团队

大型项目扩展 Scrum 最简单的方式，是增加同一地点的团队数量。

需要多团队实施需求时，不要扩张过快。最好从一个团队开始，完成最初几个 Sprint 后再增加少数团队。待它们稳定高效后，如有需要再增加。

建立新团队有两种方式：

• 拆分现有团队并加入新成员
• 加入全新的团队

拆分的优点是知识已经存在，能更快进入高效状态；缺点是打散运作良好的团队。

加入全新团队让现有团队少受干扰，继续工作；但新团队建立必要系统知识的时间更长。

无论采用哪种方式，都应遵循：

• 从少量团队开始
• 始终等到基础建立、团队稳定后再扩展
• 小步增加团队数量

项目组织：分布式团队

新团队分布多地会更加复杂，沟通障碍更常见，必须特别注意充分介绍并纳入所有成员。

为让新成员尽快了解情况并获得知识，可以暂时把他们加入现有团队，最好甚至在另一地点。这样既转移知识，也与其他团队和地点建立人际关系。

虚拟团队

另一种分布形式是同一个团队的成员分处多地，称为“虚拟团队”。

主要挑战是保持良好沟通，因为有人无法亲自参会，或无法查看 Sprint 看板等沟通辅助工具。

可使用协作和通信工具。远程与同地成员都通过视频加入，或完全在大多数协作平台提供的“虚拟房间”开会。

Scrum 产品负责人团队

产品负责人和团队的良好沟通是成功关键。本版以多个产品联系人改善可联系程度。这些联系人可以支持一位最终负责的产品负责人，而不是成为同一产品的独立产品负责人（详见 多个 Scrum 团队）共同工作。同一产品始终只有一位最终负责的产品负责人，即使多个团队参与。不同产品可以有不同负责人。

图示的“Scrum 产品负责人团队”是一种可选协调模式。产品专家或授权联系人可与最终负责者合作；该历史例子称其为“首席 Scrum 产品负责人”。此头衔不新增强制 Scrum 角色，也不分割最终产品责任。

由于负责整体需求协作，加入架构师、客户代表等其他职责和相关方也可能有益。

所有参与同一产品的人共用一个产品待办列表，由产品负责人负责排序。

组件团队或功能团队

分配工作时，可按组件或功能组织团队。

组件团队

组件团队只实现系统的指定组件。完成故事通常需要拆成可在单个组件内实现的小块，团队间依赖要求定期集成。一项故事往往无法在单个 Sprint 内完成，因为依赖其他团队尚未提供的结果。这种“流水线式衔接”应尽量避免。

组件团队更容易保证系统架构合理；但成员只专精局部，可能失去整体知识。缺少全局认识时，会只优化单个组件，而错过更好的系统级方案。

功能团队

功能团队对待办列表中的故事全面负责，不按组件分工，而是实现完成故事所需的一切。

功能团队需跨学科，理想情况下能自主行动，同时与其他团队协调集成。优点是传播系统知识、方便集成；难点是保持架构一致，并让所有团队拥有足够知识，这可能需要时间。

组件团队与功能团队

现实中，许多大型项目同时使用专门的组件团队和功能团队。

团队 C 是组件团队，为作为功能团队的其他团队提供基础设施。它不直接实现故事，而从功能团队承诺的故事获取需求，以减少所需专家人数，例如数据库专家。

分布式环境中的 Scrum Master

这种环境通常有更多需要关注和处理的障碍，因此 Scrum Master 更加重要。

贴近团队有助于理解障碍，但 Scrum 不要求同地办公。分布式支持应在各地点方便获取。本地引导者可提供帮助，但不应让各地点成为独立、相互竞争的 Scrum Master 权力中心。

分布式 Scrum 的优势

分布式 Scrum 为远程团队的敏捷项目管理带来众多价值。看看这些如何积极影响团队和项目。

获取多元人才

主要优势之一是使用各地广泛、多样的人才，组队不再受地理限制。企业能招聘附近缺少的专门技能，例如纽约公司与班加罗尔开发人员或柏林 UX 设计师合作，获得丰富项目的独特能力和视角。思想与方法交融，促进创新和创造力，也能建立真正全球化、全面多元的工作环境。

24 小时工作安排

另一优势是跨时区保持连续流程，实现 24 小时工作覆盖。通过有计划的人员配置、重叠时段和清晰交接，可以形成接力工作。地理分散本身不保证连续覆盖，也不应要求任何个人每天工作 24 小时。这还能有效利用时间和资源，提高生产力并减少项目中的闲置。

增强适应能力与学习

远程安排自然促进团队适应和持续学习。 成员分布不同地区，带来不同观点和经验，改善问题解决与决策。视角交融为持续创新和成长创造机会。远程合作还要求灵活适应工作方式、沟通方法和文化差异，进一步增强适应性。不断接触新思想和实践，也逐步提升技能，营造持续学习环境。

分布式 Scrum 不只是容纳远程工作，还提供多元人才、连续流程以及更强适应与学习的机会；这些都是远程敏捷项目成功的基础。

制定克服分布式挑战的策略时，必须认识潜在障碍。不有效处理，就会显著影响团队互动和项目结果。

克服分布式 Scrum 障碍

尽管有多种优势，团队仍需应对特有挑战。最重要之一是沟通。同地团队可直接转身询问同事，远程团队则依赖数字工具，有时造成误解或遗漏消息。

有效沟通工具

克服分布式沟通挑战，关键是选择合适工具。这些平台让成员协作、分享信息、跟踪进展并有效交流，减少距离障碍，使远程合作像在同一办公室一样高效。

应对孤立感

另一障碍是成员的孤立感。在家或分散办公，可能让人与同事脱节。应把定期线上团队建设纳入日程，鼓励彼此问候、分享个人经历，培养开放协作，减轻孤立并加强联系。

项目知识管理

协调各地项目知识也是常见挑战。稳健的知识分享实践不可缺少，例如建立集中信息库，让所有人查看并贡献文档、流程和最佳实践。

使用有效工具、定期互动以减轻孤立并促进协作，分布式团队即使相隔各地，也能更高效、更有效地运作。

分布式 Scrum 的关键工具

有效管理分布式敏捷项目，重要的一点是采用正确平台。它们不仅克服地域障碍，也支持顺畅沟通、项目管理与协作。下面详细了解成功实施所需的主要工具。

Jira

Jira 提供专为问题跟踪与项目管理设计的多种功能，是分布式团队管理的支柱。它集中组织任务、跟踪进展和规划 Sprint，适应敏捷方法，帮助团队高效管理任务与周期。它不只是跟踪工具，还让进展和个人贡献清晰可见，促进合作与透明。

Confluence

分布式环境离不开知识共享与透明沟通，Confluence 正擅长此道。作为协作内容工具，它支持共同创建、分享和编写项目文档，方便各地获取知识。实时编辑、评论等功能帮助高效记录需求、用户故事、Sprint 目标和其他关键信息；与 Atlassian 产品的顺畅集成形成完整的开发管理生态。

Zoom 与 Slack

Zoom 和 Slack 是保持团队凝聚的重要工具。Zoom 提供实时音视频，支持团队会、每日站会和规划会；Slack 通过即时消息、文件分享和分频道讨论形成沟通中心。互动渠道跨越距离，支持动态协作、持续对话、实时更新和屏幕共享，培养远程成员情谊。

这些工具各自支持有效沟通、协作及项目管理。融入敏捷流程，可以简化过程、提高透明度、合作及生产力，不受地域限制。

了解合适工具的重要性后，接下来看看成功实施分布式 Scrum 的指导原则。

成功的分布式 Scrum 原则

清晰沟通十分重要。机器需要保养才能顺畅，远程团队也依靠透明开放的渠道统一目标并有效推进。这不只是交流文字，而是让人相互理解、感到连接；不只定期会议和邮件，还要建立跨地域信任与融洽关系。

想象传统消防队从水井起排队传递水桶。如果前面不说需要更多桶，或后面没准备好，流程就会变慢甚至停止。信息流也必须顺畅不断。无论用消息、视频还是协作平台，及时回应和支持都能保持势头。

坚持持续改进

实施敏捷意味着培养不断学习和改进的文化，不是固守惯例，而是鼓励团队适应需求变化、持续优化流程，提高生产力。

互联网初作为通信方式时并不完善，却逐渐变得可靠。同样，远程团队定期反思有效与无效的做法，即使小幅调整，长期也能产生显著改善。

允许创新和改进，既促进个人成长，也有利整个项目。沿途认可大成就和小胜利，能积极鼓励大家寻找改进流程、设计更好工作方式和创新方案的机会。

采用清晰沟通及持续改进原则，能营造有效协作、主动适应项目需求的环境。

案例：有效的分布式 Scrum

看看创新科技公司 X，团队分布多个大洲。要同步努力、保持有效流程，并让远程沟通协作顺畅，绝非易事。

时区、文化、语言和工作风格差异，都需要细致规划和执行。公司没有把它们视为无法跨越的障碍，而把它们当作优化敏捷实践、定制策略并围绕共同目标团结团队的机会。

为应对时差，团队建立全员可用的重叠工作时段，支持实时互动和共同及时解题。还实施重视文化敏感度与能力的全面入职流程，通过语言交流和课程克服语言障碍，营造包容、理解的沟通环境。

采用的策略：

尽管转向分布式实践最初充满挑战，公司 X 通过主动策略获益良多。看看团队取得的积极结果，以及项目管理互动如何显著转变。

公司 X 有效应对复杂挑战，充分利用远程敏捷管理的丰富机会。现在看看分布式 Scrum 持续提升的努力。

分布式 Scrum 中的持续改进

在动态环境中，持续改进是一种生活方式，而非口号。成员不断追求更好，从经验中学习，迭代改善流程。这是敏捷项目管理的基本原则，显著影响远程成功。

鼓励定期回顾是基础实践，让成员反思工作、发现改进机会并调整流程，获得更好结果。

每个 Sprint 以回顾结束。其他时间也可检查改进，但额外讨论不能替代规定活动。目标是安全坦诚地讨论什么有效、什么无效及如何改善，不是找错或指责，而是让大家放心分享观察和想法。

例如，回顾时讨论跨时区协调的挑战，提出改善内部沟通协作的实用方案。

反馈机制

另一个重要方面是有效反馈机制。反馈循环让成员分享优化流程的见解和建议，培养持续改进文化。

定期一对一、匿名调查或专门反馈会等开放渠道，让大家不怕后果地表达，揭示不明显的问题，并建设性讨论如何处理。

团队领导和 Scrum Master 应主动鼓励并落实反馈，证明每种意见都重要，团队重视个人的改进贡献。

持续改进不只是小步提升，更是人人承诺从经历学习、开放分享并主动改善的文化。它既提高流程效率，也建立信任与合作，为适应能力、生产力和长久成功奠定基础。让不断优化的精神推动远程项目管理。

实施分布式 Scrum 的主要挑战是什么？

答：沟通障碍、时区差异、缺少面对面交流及难以建立凝聚力。VersionOne 调查中，33% 把沟通列为最大障碍。地理分散也让依赖管理和有效协作更加困难。

哪些工具或技术支持分布式 Scrum？

答：例如用于线上会议的 Zoom 或 Microsoft Teams、管理任务的 Jira 或 Trello，以及快速交流的 Slack 或 Microsoft Teams。VersionOne 调查中，92% 的敏捷团队使用协作工具，说明其对远程管理的重要性。

有哪些企业有效使用分布式 Scrum 的案例？

答：XYZ Tech 是一个突出例子。跨时区和地点的团队利用实时工具及清晰沟通协议顺畅协调，生产力提高 25%，上市时间缩短 30%。满意度和留任也改善，流失率下降 20%。

如何保持分布式团队的有效沟通？

答：利用视频、即时消息和协作平台，实现不受地点限制的实时沟通与合作。Harvard Business Review 调查中，62% 的远程员工表示技术工具改善与同事的沟通。因此，采用这些工具有助于弥合距离。

管理分布式团队时差有哪些最佳实践？

答：有多种最佳实践。首先，明确沟通规范，让所有人理解可联系时间和响应时限。安排跨时区成员定期重叠工作，支持实时协作。采用支持异步交流和记录进展的在线工具，也能提高生产力。Agile Alliance 调查显示，有效管理时差的团队，比不重视这一方面的团队满意度更高、项目结果更好。

多个 Scrum 团队开发同一产品时，应如何分配需求？

答：必须确保各团队一致理解需求。集中的产品待办列表作为共同资料库，为功能和优先级提供统一可靠来源。Scrum Master 与产品负责人定期沟通、同步，保持一致并处理冲突。分配需求时重视协作和透明，能形成共享愿景，共同推进整体目标。

为什么每个产品只能有一位产品负责人？

答：这样能维持清晰一致的开发愿景。单一决策责任确保一致判断和问责，避免优先级或目标冲突。沟通渠道更直接，对需求变化响应更快、更有效，减少歧义，提高效率，使整个生命周期的流程更顺畅。

分布式 Scrum 项目与团队的主要收获

分布式项目和团队在软件开发中有独特挑战及机会。主要收获之一是有效沟通互动的重要性。同地团队常面对面交流，分布式团队则需数字平台和工具弥合距离。Scrum Master 促进互动，确保问题得到回应，开发人员持续投入并符合整体策略。

分布式 Scrum Master 应调整策略以保持高透明度。每日站会使大家了解进展和障碍，保持一致。高要求的协作需要聚焦解决问题。无论开发还是团队互动出现困难，都应快速解决、主动应对，保持项目势头。

速度是一种常与 Scrum 配合使用的可选预测指标，在分布式环境更显重要。理解团队速度有助于准确估算和排序。团队应策略性地确定任务优先级，使之符合整体目标。清楚理解待办列表，开发人员才能处理高优先级事项并交付具体成果。

分布式项目中，迭代开发更加重要。每个迭代或 Sprint 都需细致规划和估算。Scrum Master 帮助开发人员有效规划，开发人员自行决定如何拆分成符合整体产品策略的可管理任务。良好待办管理和迭代规划保持稳定节奏，避免延误，使开发更顺畅。

多种因素影响成功。开发人员适应不同协作模式的能力，以及 Scrum Master 建立团队团结感的能力，都会显著影响结果。 有力执行应对策略，能优化互动、高效解题并取得开发成功。总之，稳健策略、主动的 Scrum Master 和协作的开发人员，是克服挑战、交付质量并持续提高效率的关键。