简介：
本文分析了跨区域特别是跨时区 Scrum 团队项目中容易遇到的问题，并根据笔者的实际经验，提出了相应的解决方案。虽然跨区域开发团队与本地开发团队在应用
Scrum 上存在一些重要的差异，但这些差异造成的问题都可以通过适当的方法得以顺利解决。
Scrum 团队项目基本特性
Scrum 是一个敏捷开发框架，在这个框架中，整个开发周期被分为若干个小的迭代周期，每个小的迭代周期称为一个
Sprint，每个 Sprint 的建议长度为 2 到 4 周。Scrum 以经验过程控制理论为依据，采用迭代、增量的方法来提高产品开发的可预见性，并控制风险。
Scrum 团队中的主要角色包括：
产品负责人（Product
Owner，以下简称为PO） 负责确定产品的方向和愿景，维护产品Backlog（按照商业价值排序的需求列表，列表条目的表现形式通常为
User Story），定义产品发布的内容、优先级及交付时间。在每个 Sprint 开始前，PO 应整理产品
Backlog 条目，以确保其定义清晰且分解适当，并调整 Backlog 条目的优先级；在 Sprint
结束时，PO 有权接受或拒绝接受开发团队的工作成果。
Scrum Master
作为 Team Leader 和 PO 紧密合作，负责确保 Scrum 被理解并实施，是 Scrum 团队中的服务型领导。Scrum
Master 应及时地为团队成员提供帮助，移除项目实施中遇到的障碍，保证各个角色及职责的良好协作，同时作为团队与外部的接口，屏蔽外界对团队成员的干扰，从而保证开发过程按计划顺利进行。
开发团队 (Team)
一个跨职能且自组织的小团队，人数一般建议为 5 - 9 人。整个团队需拥有交付可用软件所需要的各种技能，团队成员应协同配合，在每个
Sprint 中将选定的产品 Backlog 条目转化为潜在可交付的功能增量。
下面的图形反映了Scrum 团队中各个角色的基本关系：
图 1. Scrum 团队
Scrum 短周期迭代，小步快跑的开发模式决定了开发目标必须明确，同时对所有开发过程中遇到的问题必须尽快解决。为此，Scrum
Master 需负责发起并组织以下活动：
Sprint 计划会议 (Sprint Planning Meeting)
每日站会 (Daily Scrum Meeting)
Sprint 评审会议 (Sprint Review Meeting)
Sprint 回顾会议 (Sprint Retrospective Meeting)
在 Sprint 计划会议中，PO 根据团队的能力及以往的表现，与团队成员一起从产品
Backlog 中挑选最有价值（或风险最大）的条目，经过初步估算，确定出下一个 Sprint 的工作目标（即明确做什么），进而由开发团队对挑选出的条目进行分析、讨论和进一步估算形成任务列表（即明确怎么做）。
每日站会中，每个团队成员通过回答“从上次会议到现在都完成了哪些工作”，“下次每日会议之前准备完成什么工作”，“工作中遇到了哪些障碍”，来加强团队成员的交流沟通，提高每个成员对项目的认知程度，检验项目实施情况，并通过快速决策，排除开发过程中遇到的障碍，保证项目的顺利进行。
Sprint 评审会议在 Sprint 的末尾举行，通过成果展示，围绕团队在
Sprint 内完成的可交付物来确定目标完成情况，并为后续 Sprint 计划提供参考。
Sprint 回顾会议通过回顾已经完成的 Sprint，总结经验教训，确定做出什么样的改善可以使接下来的
Sprint 更加高效、更加令人满意，从而实现对开发过程的持续改进。
跨区域Scrum团队面临的挑战
Scrum 通过加强沟通快速解决项目实施过程中遇到的问题，同时通过对各个
Sprint 的回顾和评审，来改进开发过程，并为后续 Sprint 提供参考，有效地保证了 Scrum
短周期迭代的顺利进行。
但是，对于跨区域 Scrum 团队，尤其是分布在不同时区的 Scrum
团队（如笔者参与开发的项目，就涉及分布在亚洲和北美洲的 3 个时区的数个开发团队）而言，则面临着许多新的问题，主要表现在：
会议成本增加，有时很难进行面对面沟通，每日站会往往无法全员参加。
项目启动的 Sprint 计划会议往往需要相对较长时间（数小时到一天），处在其他区域的
PO 往往在时间上无法保证。
由于无法进行实时沟通，一旦项目进行过程中出现之前无法预料的问题，尤其是是功能模块或接口的相互依赖问题，所造成的时间延迟往往比本地项目出现类似问题所造成的延迟要多得多，从而直接影响受影响团队
Sprint 目标的达成。
解决方案
在笔者参与的跨区域 Scrum 开发团队中，为了解决以上问题，项目团队以
Scrum 指导原则为基础，对项目团队的工作作出调整，并提出了几个有针对性的解决方案。
团队代表制，解决跨区域 Scrum 会议问题
组成 Scrum of Scrums 团队，采用 Weekly Scrum
Meeting（每周电话或电视会议）同步各 Scrum 团队项目进展情况，并重点解决团队依赖问题；同时成立独立的架构咨询团队，负责协助在会后讨论并解决（主要以邮件的形式）在该会议上无法快速解决的团队依赖问题。
由于涉及多个时区的原因，每周电话或电视会议无法保证在工作时间举行，因此，由各团队成员轮流参加，各
Scrum 团队每周派一名代表提前收集意见，为会议作准备，并代表本 Scrum 团队在会议上发言。会议的内容除汇报各
Scrum 团队的进度外，还包括：是否对产品的公共模块作出了重大修改，是否有大量的代码提交，是否在某一方面依赖于其他
Scrum 团队的工作，是否需要其他 Scrum 团队提供技术支援（就某一技术问题提供专家意见，并非直接参与项目的实施），并预告重大的架构调整及受影响的模块，预告即将引入的新技术或功能及可能带来的影响等等。
此外，架构咨询团队还负责为各开发团队提供架构设计方面的指导，最大程度上减少团队依赖问题的产生。
对于 Scrum 团队的设置，虽然本地团队可以更好地保证沟通的质量和效率，但在大多数的情况下，并不要求同一
Scrum 团队的所有成员处在同一地点或同一时区。现代通信手段丰富多样，只要保证沟通顺畅，Scrum 团队的设置应以相互配合、相互补充为主要考虑因素，保证团队自我管理、独立解决问题的能力，这在一定程度上也可以解决前面提到的团队依赖的问题。
提前准备，保证跨区域情况下 Sprint 的顺利启动
采用多核制，除整个产品的 PO 外，设立本地 PO（一般由 People
Manager 兼任）。结合上面提到的 Scrum of Scrums 的组织形式，整个 Scrum 团队的结构如下图所示：
图 2. 本地 PO 及 Scrum of
Scrums 团队
在下一 Sprint 计划会议开始前数天，由本地 PO 及其他核心成员与产品
PO 讨论下一个 Sprint 需要完成的 Backlog 条目，对所有备选 Backlog 条目排列优先级（由于各
Scrum 团队在设立时在技术上往往有所偏重，某一 Scrum 团队备选 Backlog 条目应该是全部有效
Backlog 条目的子集），指出哪些条目必须在下一个 Sprint 内完成，哪些条目应尽可能安排进下一个
Sprint，哪些条目可以视情况而定，作为本地 Scrum 团队 Sprint 计划会议的前期准备，即
Sprint 计划会议需要解决的“做什么”的问题在会议开始前已经基本明确。
实际的 Sprint 计划会议将由本地 PO 负责，从已由产品 PO
确定优先级的条目中根据团队的容量（即 Capacity，由于休假、培训、人员变动等因素，团队的容量在不同
Sprint 间往往是变化的）选取待完成的条目，进行评估与分解，并于 Sprint 计划会议结束后进行整理，并交由产品
PO 确认。如果必要的话，可以在次日或当日晚些时候由本地 PO 与产品 PO 举行较为简短的会议，来审查经过本地
Scrum 团队二次讨论过的 Sprint 计划，得到产品 PO 的确认或局部调整意见。由于之前已经经过产品
PO 的初步确认，此时需要进行调整的可能性往往很小。这样，Scrum 团队就可以快速开始新的 Sprint
的开发工作，避免不必要的延迟。
充分调研，未雨绸缪，避免架构缺陷及团队依赖
各区域由核心成员组成核心团队，将调研及讨论工作提前，在前一个 Sprint
的中后期开始下一个 Sprint 可能需要完成的 Backlog 条目的分析调研工作，以达到在前一个 Sprint
结束前充分理解下一个 Sprint 需要完成的工作的目的。
对于重要的架构设计问题，应与架构咨询团队协商讨论决定；对于存在团队依赖的情况，也应通过
PO（或技术负责人）协调各 Scrum 团队的工作安排，将相互依赖的两个模块安排在两个 Sprint 内完成（必要时，也可以安排在一个
Sprint 的前期和后期完成，但这种情况下，需要两个团队加强配合，及时沟通进度，并尽可能留出缓冲时间），从而最大程度上降低后期架构风险出现的可能，并避免团队依赖。
总结
跨区域开发团队，特别是跨时区开发团队，与一般的本地开发团队存在一些重要的差异，但只要我们采用适当的方式来解决这些差异所造成的问题，跨区域开发团队也可以适应短周期迭代的开发模式，顺利采用
Scrum 进行产品开发。
| 
