Richard:
你已经在一个团队中使用Scrum一段时间了，他们接受产品待办事项增量——团队在冲刺结束时交付的需求。现在，你将其扩展到一个更大的组织，多个团队需要协调他们的努力来交付一个产品待办事项增量。团队数量可能是两个、五个、十个。想象一下让这些团队朝着一个产品待办事项增量工作所需的协调努力。Richard Hundhausen告诉我们这在Nexus中是如何完成的。
Richard:
这是一个正常的产品待办事项列表，尽管是大规模的。它会在顶部有更准备就绪的项目。
康：
而那个产品待办事项列表是为整个Nexus的。
Richard:
它是为整个产品的。我们相信使用Nexus框架进行扩展是关于许多团队在单一产品上工作。
康：
我明白了。
Richard:
这很快就会分解为”什么是我的产品？”有很多技术来识别这一点。Nexus框架不是关于将Scrum引入每个部门——比如维护、IT或财务。我见过组织尝试这样做。那不是扩展。这是为了多个Scrum团队想要在单一产品、单一产品待办事项列表、单一产品负责人上工作的情况。
Richard:
就像在Scrum中一样，我们用冲刺计划会议开始冲刺。在Nexus中，冲刺计划会议包括每个团队的预测和计划。这是那些大房间会议之一，来自每个Scrum团队的代表在预会议中会面，使依赖关系透明化。
有细化、规模估算和一些权衡，这样团队可以交付在冲刺期间没有PBI跨越团队边界的项目。此外，最适合的团队选择每项工作——注意依赖关系并在冲刺结束时交付可演示的价值。
Richard:
然后这些代表将PBI带回到他们各自的Scrum团队的冲刺计划中。团队决定预测是否符合他们的容量、速度和完成定义。使用新的Scrum指南，每个冲刺都期望有改进。如果团队同意他们可以完成PBI，他们就制定计划。当最后一个Scrum团队完成他们的冲刺计划时，整个Nexus冲刺计划会议结束。每个人都等到最后一个团队预测并最终确定他们的计划。例如，如果第五个团队意识到他们缺少培训人员，他们可能需要与其他团队协调以调整依赖关系。
康：
所以听起来他们在为下一个冲刺中能够交付的内容在团队间构建一个共享的待办事项列表。
Richard:
某种程度上。我们实际上没有共享的冲刺待办事项列表，除了作为跨团队依赖关系的视图。在规模化时有一个新的工件叫做Nexus冲刺待办事项列表。你可以把它想象成来自每个Scrum团队待办事项列表的PBI在流程图中可视化——每个团队一行：待办、进行中、完成，也许还有一个”阻塞”列。
康：
嗯嗯。
Richard:
Nexus中的任何人都可以说，”哇，第一个团队在等第二个团队的PBI，而第二个团队甚至还没开始——冲刺已经过半了。”
康：
嗯嗯。
Richard:
所以这是个别团队冲刺待办事项列表预测的只读、聚合视图。
康：
嗯嗯。
Richard:
谁维护或查看它？你在那个工件上举行每日Scrum吗？这由Nexus来决定。
Richard:
日常中，就像在Scrum中一样，我们有每日Scrum——一个同步会议来计划当天。规模化的不同之处是Nexus每日Scrum，在各个团队的每日Scrum之前举行。来自每个Scrum团队的代表参加这个预会议。它像正常的每日Scrum一样有时间盒限制。在这里，他们使过去24小时的集成或依赖问题透明化。其他团队可能会说，”我们今天正要涉及那个——谢谢提醒。”
康：
嗯嗯。
Richard:
或者”审计员在大楼里？好的，我们会注意。”依赖关系可能在人员、领域、技术组件或甚至代码库之间——尽管我们不建议团队之间有私有存储库。Nexus每日Scrum的输出成为各个团队每日Scrum的输入。
康：
嗯嗯。
Richard:
这就像Scrum的Scrum，除了它是必需的并且首先发生。
康：
我喜欢它首先发生的想法。我和其他教练在一天结束时做过多团队Scrum，很难对我们这么晚学到的东西做出反应。这很有道理。
Richard:
有时我被问到，”我们还能做Scrum的Scrum吗？”我说，”嗯，就像在单团队Scrum中一样，不行——你不被允许和人交谈。”
康：
<笑>
Richard:
那是个玩笑。
康：
太好了。<笑>
Richard:
如果你想做Scrum的Scrum——为了教练、开发人员或数据库人员——那很好。这些团队应该是跨职能的、同地办公的、长期存在的。我们也推荐特性团队——能够接受面向客户的PBI并在整个技术栈中完全交付它的团队。他们可以编写SQL并访问服务器。但Nexus并不要求特性团队。
康：
哦，好的。
Richard:
我们推荐特性团队，但认识到有角色团队、特性集团队、旅程团队和客户体验团队。有些是其他模型的同义词。但我们强烈建议反对组件团队。
康：
好的。
Richard:
我们不希望整个团队只管理数据库。
康：
哦，我明白了。
Richard:
因为那样每个PBI都会依赖那个团队。
康：
UX团队怎么样？
Richard:
同样的情况。
康：
好的。
Richard:
任何只专注于一个层面的团队——UX、数据、中间层、安全、网络、Android——这些都是红旗。这意味着每个特性都可能需要他们。相反，我们更喜欢像招聘会这样的东西：让所有40个人聚集并自组织成他们想加入的团队。
康：
酷。
Richard:
团队可以拥有应用程序的部分——领域、角色。可能有一个工作板：”来帮助司机团队建立一个伟大的Uber或Lyft类似的司机应用程序。”他们需要原生开发人员、后端开发人员、有出租车驾驶经验的人、地图、地理等等。让他们组建自己的团队。
Richard:
不是所有组织都为此做好了准备。他们可能更喜欢经理来组建团队。如果所有UX人员或测试人员都向单一VP汇报，这很困难。在那种结构中很难做Scrum。
康：
你有兴趣学习在企业中扩展Scrum的基础知识吗？你在做Scrum但不确定当产品开发需要许多团队时如何有效？商业小说《敏捷大师》将通过戏剧性的故事讲述教你这些技能。涵盖以下概念：扩展Scrum、系统思维、组织设计、系统建模，以及如何为你和你的组织制定转型计划。你可以在Leanpub.com免费获得Lance Kind的《敏捷大师》预发布副本。链接在节目说明中。
康：
下一集，Richard Hundhausen告诉我们关于Nexus集成团队。
Richard:
Nexus中有一个新角色，可能是最被误解的——主要是因为名字。它叫做Nexus集成团队。这不像其他扩展框架，团队合并代码、编写测试和修复构建。这是一个来自Nexus的人员的即时团队。
