三个团队，一款产品：Nexus 给一个重启项目上的一课
2021 年初，一家区域服务机构重启了一个停滞的软件项目，手上有三个 Scrum 团队，各自单独运作时都不错。问题在于，它们在打造的是同一款产品，而「各自单独」悄然变成了症结所在。过去两周就能完成的发布，如今要拖到六周。每个 Sprint 结束时都要经历一周手忙脚乱的代码合并、重测和相互指责。这些团队并非不擅长 Scrum，恰恰相反，它们在各自孤立的状态下表现出色——而这完全是另一回事。
管理层读了 Scrum.org 的 Nexus 框架，决定试一试，而不是再自创一套土法协调机制。Nexus 刻意做得很轻：它把三到九个围绕同一款产品工作的 Scrum 团队组织起来，新增一项职责——Nexus 集成团队——以及一个新的事件焦点，要求所有人把集成当作头等大事来对待，而不是 Sprint 末尾才冒出来的意外。下面平实地讲讲究竟发生了什么变化，因为纸面上的框架，和在一个部分远程的混合办公环境里落地的框架，并非同一种体验。
第一个惨痛教训：集成人人有责，但必须有人对它负责
Nexus 集成团队并不是一支专门把活儿从别人手里抢走的专家团队。它是一项协调职责，通常由同时身处各常规 Scrum 团队的人来承担，包括 Product Owner，往往还有最资深的工程师。他们的职责是确保合并后的增量真正拼得起来。在这个重启项目里，最初的错误是把它当成可有可无的兼职。集成工作总是输给功能开发，因为功能开发有明确的负责人，而集成没有。等到组织点名指定了具体的人、给了他们受保护的时间，并把「完成」唯一地定义为已集成的增量之后，原本六周的发布周期才重新开始缩短。
把所处的时代背景重新摆正也有帮助。刚走出上一年的动荡，人们仍在家与办公室之间两头跑，供应周期也不可靠，于是很容易让每个团队只顾优化自己的一亩三分地。Nexus 正是有意要对抗这种本能。
跨团队依赖要么在规划时浮现，要么日后伏击你
Nexus 把依赖的发现提前。在各团队规划各自的 Sprint 之前，代表们先聚到一起共同审视 Product Backlog，找出一个团队的工作在哪里依赖另一个团队。这并不是一场繁重的仪式，而是一次产出共识的工作会议——明确哪些东西必须集成、以及按什么顺序集成。
尽早让依赖可见。 把待办项细化、拆解到足够程度，使跨团队的关联在 Sprint 规划之前就一目了然，而不是 Sprint 进行到一半才被发现。
优先安排有风险的集成。 如果两个团队必须接入一个共享服务，就把这次对接安排在 Sprint 早期，万一出错也还有时间补救。
频繁集成，而非临到末尾。 争取至少每天产出一个已集成的增量；Nexus 每日站会的目的就是发现集成问题，而不只是跟踪个人进度。
始终保持增量可发布。 全体团队共用一份「完成的定义」，能维持质量一致，避免某个团队的偷工减料拖垮整体。
数字和会议室都印证了什么
几个 Sprint 之内，可见的迹象就变了。Nexus 每日站会——代表们在各团队开各自的每日站会之前先聚焦集成问题——能在问题还便宜的时候就把它们抓出来。Nexus Sprint 评审向干系人展示的是一款集成好的产品，而不是三场拼不到一块儿的演示。回顾会也不再是团队之间的牢骚清单，而变成了一场关于他们共享的那套系统的对话。
规模化不等于加流程，而是消除团队之间的盲区。
衡量进度唯一诚实的尺子是已集成的增量，而非各团队各自的产出。
混合办公让「多沟通」从成本变成了优点——共享且可见的依赖，胜过那种已经不复存在的走廊式协调。
这家机构没有一夜之间变成 Nexus 的样板，也无需如此。这个框架的意义朴素而实用：保留 Scrum 的轻量精神，同时给多个团队一种有纪律的方式去共同交付同一件东西。纪律在于集成，而集成本身就是工作。
如果您的项目拥有优秀的团队，却难以作为一个整体交付，XNM 的项目群与项目交付咨询 可以帮您把恰当的协调机制——以及问责机制——落到实处。