第15章 我们怎样管理多个Scrum团队
- 在多个Scrum团队开发同一个产品的状况下，很多事情都会变得更加复杂、棘手。这个问题普遍存在，跟Scrum没太大关系。更多开发者=更多复杂情况
- 这里有下面两个核心问题
- 要创建多少个团队？
- 如何把人员分配到各个团队中？
创建多少个团队
- 我的经验是，宁可团队数量少，人数多，也比弄上一大堆人总在相互干扰的小团队强。要想拆分小团队，必须确保他们彼此之间不会产生互相干扰！
虚拟团队
- 在“大团队”和“多团队”之间权衡利弊之后，你做出了自己的决策，可怎么知道这种决策是对还是错呢？
- 如果注意观察、仔细聆听，也许你会注意到“虚拟团队”的存在。如果类似虚拟团队一直这样保持下去的话，那就表示做错了；如果只是暂时的话，那就没问题
例1 问题：你选择了使用“大团队”。不过观察一下sprint中的交流方式，你就能发现事实上这个大团队自动分成了两个子团队 解决办法：如果这两个虚拟的子团队一直变化（也就是大家在虚拟团队中换来换去），那把他们放在一直团队中就没有问题。如果二者的构建在整个sprint中保持不变，在下个sprint中可能就得考虑把他们分成两个真正的Scrum团队了
例2 场景：你选择了使用三个小团队的方式。不过观察一下sprint中的交流方式，你就会发现团队1和团队2一直在交流，而团队3比较孤立 解决办法：如果团队1和团队2在整个sprint中一直聊来聊去（把团队3扔在一边），在下个sprint中你大概就得把团队1和2合并到一块。如果在sprint的前半阶段，团队1和团队2一直交流，然后在后半阶段，团队1和团队3又相谈甚欢，那合并或者保持原样就都是可行的。你可以在sprint回顾会议上提出这个问题，让团队自己决定
- 需要重视的是，必须要让团队对所处环境感到舒适，而且不会常常彼此干扰
最佳的团队规模
- 在我读过的大多数书中，5到9个人被公认是“最佳的”团队构成人数
- 不过我会建议说3到8个人。而且我相信，为了达到这种团队规模，花上一定代价还是值得的
是否同步多个sprint
- 同步进行的有如下优点
- 可以利用sprint之间的时间来重新组织团队！如果各个sprint重叠的话，要想重新组织团队，就必须打断至少一个团队的sprint进程
- 所有团队都可以在一个sprint中向同一个目标努力，他们可以有更好的协作
- 更小的管理压力，即更少的sprint计划会议、sprint演示和发布
为什么我们引入“团队领导”的角色
- 假设我们有三个团队开发同一个产品。标记为P是产品负责人，标记为S是ScrumMaster
- 通过引入“团队领导”的角色来解决这个问题。你也许称之为“Scrum中的ScrumMaster”，或者“老大“。他不用领域某个团队，但是会负责跨团队的问题，例如谁担任哪个团队的ScrumMaster，大家如何分组等等
我们怎样在团队中分配人手
- 让一个指定的人来做分配，例如我前面提到的”团队领导“，或产品负责人，或职能经理（如果他的参与度比较高，就可以做出正确的决定）
- 让团队自己决定
我们发现二者组合以后的效果最好
- 在计划会议上，我们首先遍历产品backlog中优先级最高的条目。然后团队领导说：”各位，我们建议下一个像下面这样分配人手“
- "你们看，我们会从4个团队变成3个。每个团队中的人员名单已列出来了。你们可以凑到一块，自己商量一下要墙上的哪块地方"
- ”目前这个团队分配只是初步计划！就是为了节省点大家的时间。接下来开会的时候，你们还可以去另一个团队，或者把你们这个团队一分为二，或者跟另一个团队合二为一，怎么都行。做选择的时候动动脑子，考虑一下产品负责人定下来的优先级“
- 我们发现这种方式效果最好。最开始使用一些集中式控制，然后再用分散式优化
是否使用特定的团队
方式1：特定于组件的团队
- 例如客户端团队、服务器团队和DB团队
- 我们以这种方式开始。但效果不太好，要是大多数故事都涉及到多个组件就更糟了
方式2：跨组件的团队
- 如果大多数故事都包括多个组件，那这种团队划分方式的效果就很好。每个团队都可以自己实现包括客户端、服务器和DB三部分的完整故事。他们可以互相独立工作，这就很好
- 不过，要是有很强烈的需求，我们也会临时创建针对特定组件展开工作的团队
是否在sprint之间重新组织团队
- ”团队凝聚力“是Scrum的核心要素之一，如果一个团队合作工作达多个sprint之久，他们就会变得非常紧密。他们会学会如何达成团队涌流（group flow），生产力会提升至难以置信的地步。不过要达到这个地步需要花上一定时间。如果不断变换团队组成，你就永远无法得到强悍的团队凝聚力
- 这里有个例外：第一次在大型团队中开始实施Scrum的时候，你需要就团队拆分进行一些实验最后才能找到令所有人全都满意的做法。要确保所有人都能够理解：在最开始几次时犯些错误是可以接受的，只要能够持续改进
兼职团队成员
- 我很认同Scrum书中所说的话——在Scrum团队中含有兼职成员一般都不是什么好主意
- 一般来说，我宁愿要三个全职工作的成员，也不愿意要8个只能做兼职的
- 如果有一个人需要把他的时间分配给多个团队，就像上面提到的DBA一样，那最好让他有一个主要从属的团队。找出最需要他的团队，把它当作他的”主队“。如果没有其他人把他拖走，那他就得参加这个团队的每日scrum会议、sprint计划会议、回顾等等
我们怎样进行Scrum-of-scrums
- Scrum-of-scrums是一个常规会议，为了让所有ScrumMaster聚在一起交流
产品层次的Scrum-of-Scrums
- 这个会议非常重要。我们一周开一次，有时候频率会更高。在会议上我们会讨论集成问题，团队平衡问题，为下个sprint计划会议做准备，等等。我们为此分配了30分钟时间，但常常超时。其实也可以每天进行Scrum-of-Scrums，但我们一直没有时间尝试
- 议程安排如下
- 每个人围着桌子坐好，描述一下上周各自的团队都完成了什么事情，这周计划完成什么事情，遇到了什么障碍
- 其他需要讨论的跨团队的问题，例如集成
团队层次的Scrum-of-Scrums
- 我们把这个会议称为”脉动“。我们试过多种形式，参与者也多种多样。后来就放弃了整个概念，换成了每周的全体会议。时长15分钟
- 会议的形式如下
- 主管介绍最新情况。例如即将发生的事件信息
- 大循环。每个产品组都有一个人汇报他们上周完成的工作、这周计划完成的工作，以及碰到的问题。其他人也会作报告 （配置管理领导，QA领导等）
- 其他人都可以自由补充任何信息，或者提问问题
- 这是一个发布概要信息的论坛，而不是提供讨论或者反映问题的场所。只要保证这一点，15分钟常常就跔了。有时我们也会超时，但极少会占用30分钟以上的时间。如果出现了热死的讨论，我就会打断它，请感兴趣的人在会后留下继续讨论
- 为什么我们要进行全体的脉动会议呢？因为我们发现团体层次上的Scrum-of-Scrums主要以报告形式进行，很少出现真正的讨论。另外，在这个圈子以外，有许多人都对这种信息非常感兴趣。基本上大家都想知道其他团队在做些什么
交错的每日例会
- 所以我们要求团队避免在同一时刻进行每日例会
- 每日例会不会在团队房间中进行，而是安排在不同的房间。每个会议大约15分钟，但是每个团队在房间中都可以使用30分钟的时间，以备他们会稍稍超出一点儿时间
- 这种做法超级有效，原因有二
- 像产品负责人和我这样的人可以在一个早上参加所有的例会。想清楚了解到当前的sprint进展状况，有什么严重的风险，这是最好的方式
- 团队成员可以参加其他团队的例会。这种情况不常发生，不过有时两个团队会在相似的环境下工作，所以会有几个人参加彼此的例会来保持同步
救火团队
- 曾经有那么一次，在一个大型产品的开发过程中，我们实施不了Scrum，因为团队成员花了太多时间来救火——拼命忙着修复早期版本中的bug。这是个恶性循环，影响很坏，他们花了太多时间救火，最后根本没有时间进行前瞻性的工作来防火（改进设计、自动化测试、创建监控工具与警报工具等）
- 我们创建了一个专门的救火团队，一个专门的Scrum团队，从而解决了这个问题
- 救火团队（实际上我们管他们叫”支持团队“）有两项工作
- 救火
- 保护Scrum团队远离各种干扰，包括挡开那些不知从何而来的、增加临时特性的要求
- 救火团队被安排在离门最近的地方，Scrum团队坐在房间的最里面。所以救火团队可以真正地从物理上保护Scrum团队，使他们不会受到急切的销售人员或者怒气冲冲的客户的干扰
- 两个团队中都有高级工程师，这样一个团队就不会过于依赖另一个团队的核心人员
- 当然，Scrum团队也不是完全远离干扰。救火团队常常需要Scrum团队中核心人员的帮助，在最糟糕的状况下，甚至会需要整个团队
- 经过几个月以后，这个系统达到了足够稳定的状态，然后我们解散了救火团队，另外创建了一个新的Scrum团队
是否拆分产品backlog
策略1：一个产品负责人，一个backlog
- 就是”只能有一个“的模型，也是我们最推崇的模型
- 优点：可以让团队根据产品负责人当前的优先级来自行管理。产品负责人关注他所需要的东西，团队决定怎么分割工作
- 在会议开始之前，产品负责人指定一面墙壁用做”产品backlog墙“，把故事贴在上面（以索引卡的形式），按相对优先级的顺序。他不断往上面贴故事，直到贴满为止。通常他贴上去的东西都要比一个中所能完成的条目多
- 图中的箭头表示故事卡从产品backlog墙移动到团队墙的过程
策略2：一个产品负责人，多个backlog
- 产品负责人会维护多个产品backlog，每个团队对应一个
- 劣势：产品负责人要把故事分配给团队，而这项工作交给团队自己处理会更好
策略3：多个产品负责人，每人一个产品backlog
代码分支
- 总结一下我们团队到目前为止学到的最重要的一些经验
- 主干的状态要严格保持一致：最起码所有的东西都要能够进行编译，所有的单元测试都可以通过。每时每刻都能创建一个可以工作的发布版本。如果可以做到持续构建系统在每晚进行构建，并把结果自动部署到测试环境中就更好了。
- 给每个版本打上标记（tag）。无论什么时候，只要是为验收测试进行发布，或是发布到产品环境，在主线中就应该进行版本标记，用来精确票房所发布的内容。这便意味着在将来的任一时刻，你都可以回退到某个历史版本中，创建一个维护分支
- 只在必需的时候创建分支。这里有一条很好的规则：如果你无法在不违反现有代码基线策略的情况下使用该代码基线，那么只有在这种情况下，才能创建新的代码基线。如果摸不准是什么情况，那就不要创建分支。为什么？因为每个活动分支都会增加复杂性，提高管理成本
- 将分支主要用于分离不同的生命周期。无论你是否决定让每个团队在他们自己的代码基线上进行编码，如果你打算在同一个代码基线上将短期的修复版与长时间的变化进行合并，到时候就会发现：只发布这个短期的修复版绝非易事！
- 经常同步。如果你在分支上工作，那么只要有了一些代码可以构建，就应该与主线进行同步。在每天的编码工作开始之前，都把代码从主线同步到分支上，这样你的分支就可以与其他团队所做出的变化 保持 更新。如果会产生让你觉得生不如死的合并情况，那也只能接受这种现实，因为等下去的结果只会更糟
多团队回顾
- 在sprint计划会议上（因为我们在同一个产品中使用的是同步的sprint，所以所有团队均会参加），第一件事情就是让每个团队找出一个发言人，站起来总结他们回顾中得出的关键点。每个团队都有5分钟的时间。然后我们会进行大约10到20分钟的开放讨论。之后稍作休整，开始真正的sprint计划
