康： Richard Hundhausen向我们介绍Nexus集成团队。
Richard： 我想指出，Nexus中有一个新角色，可能是最容易被误解的角色，这可能是因为它的名字。它叫做Nexus集成团队。这不像其他规模化框架，那些框架中他们是做工作的人，他们负责合并代码、编写测试和修复构建问题。而这个团队实际上是一个来自Nexus的即时团队。比如说我们在Nexus中有五个七人团队，总共有35个实际做工作的人。在任何一个冲刺中，其中几个人会戴着臂章，上面写着”我在Nexus集成团队”。日常工作中，我在我的Scrum团队里做我的事情。我在写代码，写测试，做一些部署工作。但是如果那种信号灯亮起，比如我们的构建服务器停止了，
康： 有趣。
Richard： 那么戴着臂章的人会说，好吧，那是我的事，或者是我们的事。然后他们会去处理那些集成问题，或者试图清理那些依赖关系，这些可能是技术依赖。你知道，我们的图表，你们看不到，但我们有三个齿轮在三角形的三个角上，叫做集成工作。我喜欢称之为持续集成、持续测试、持续交付，或者自动化构建、自动化测试、自动化交付，随你怎么称呼。但这些轮子一起转动，需要有人照看并保持它们的润滑，确保我们的云账户有订阅，确保构建在运行，服务器没有满载。这类运维工作。
Richard： Nexus外部没有人帮助这项工作。有一个叫做Nexus集成团队的团队，但他们就是我们自己。这不像你去找一个固定团队说，嘿，（敲门）构建变慢了，你们能修复吗？不是的，这些人作为他们日常工作的一部分来照看这些。所以实际上这与其他方法没有太大不同，比如团队做工作，不仅是做什么，还有怎么做。对吧。我们也一样。只是我们说需要有一些戴臂章的人对此负责，这样如果没有其他人站出来，这些人就必须要做。除此之外，观念是一样的。
康： 对我个人来说，这里有很多很酷的想法，不管我是否在使用Nexus，都值得思考对我意味着什么。比如那些总是处于红色状态的持续集成环境是没有帮助的。这确实在公司中发生。你有人可以去找，说，嘿，这不起作用，你能为我做什么？所以这很好。
Richard： 让我澄清一下。就像单个团队的Scrum Master一样，Nexus集成团队有点像Nexus规模化的Scrum Master。他们应该始终采取教练、咨询、培训、引导的立场，只有在这是唯一方法时才动手。换句话说，假设我在那里，我是Jenkins专家，我戴着Nexus集成团队的臂章，Jenkins停止了。这不是说我会收到电击去修复Jenkins。我会说，好吧，哪个团队报告的？让我们和他们坐下来，也许以群体方式。
康： 嗯嗯。
Richard： 向他们展示，哦，嘿，这是发生的事情。
康： 嗯嗯。
Richard： 你们正在运行一个较旧的构建，使用的框架在Jenkins中不受支持，所以这不是Jenkins的问题。
康： 对。
Richard： 但我们可以在那里添加这些组件。我可以向你们展示ood或其他东西是如何工作的，对吧。如果你们需要的话，可以拉取那些引用。是的，也许我们会从中创建一个wiki并让所有人都能使用。但我不是直接去那里修复它。Nexus集成团队应该始终从教练、咨询的立场开始。我就在你们肩膀后面向团队展示。
康： 酷。
Richard： 如何做这些事情。但如果他们完全迷失了，是的，我是说，我会谈论，嘿，如果Scrum团队，一个团队因为这样的事情无法工作一天。
康： 嗯嗯。
Richard： 我们谈论的是数千美元的损失。
康： 嗯嗯。
Richard： 如果一个Nexus因为某些自动化问题或其他什么原因而陷入僵局，比如他们的仓库满了或丢失了，那可能是几万美元的损失。
康： 这确实会发生。
Richard： 这确实会发生。
康： 无论他们是否使用Nexus，那种僵局都会发生，而Nexus能更快地暴露这个问题，因为有人在关注它。
Richard： 所以我认为我们需要有人负责。我是说，最后的手段。
康： 嗯嗯。
Richard： Nexus集成团队必须让车轮重新回到轨道上。
康： 对我来说，Nexus是团队之间的一个设计联盟，现在有了这个设计联盟，如果你叫它北约或其他什么名字，比如，如果其中一个团队遇到问题，那么这就变成了整个组织的问题。然后当他们去对抗组织时，实际上会获得更多的推动力。我是什么意思？有些组织有票务系统和那些不在乎的人。他们有一个大的票务队列，按先来先服务的原则处理事情。有时候实际上并不完全是先来先服务，因为这关乎谁喊得最大声和其他一些因素。我见过团队的集成系统环境崩溃，因为某个地方有一个环境团队需要有登录和更改的密钥。
康： 并不是他们不愿意，而是有很多因素让他们说不能。这些因素可能需要几个月才能解决，但如果你在一个组织中有一个设计联盟，那么就会有一个更大的”会叫的轮子”。嗯嗯。
Richard： 对的。
康： 所以我们可以使用通常的方法，无论你是否有流程。如果你有更多人为此呼喊，它会更快得到修复。
Richard： 是的。
康： 而且你有一个内置的流程，呃，通过Nexus集成团队来解决问题。
Richard： 确实如此。
康： 所以你可以有相关的人，也许是有那个环境密钥的人，你实际上可以让它发生。
Richard： 我想回到从Nexus角度看的依赖关系不仅仅是技术依赖。可能我们要进入一个季节，也许我们的DevOps基础设施很棒，但我们要进入一个需要开始与一些特别积极的利益相关者合作来构建他们系统的季节。所以我们可能想要在Nexus集成团队中配备更多的Scrum Master或教练类型的人，因为我们要进入一个依赖关系更多是人际关系而非技术的季节。
康： 我明白了。
Richard： 所以就像任何责任的变化一样，我们建议评估Nexus集成团队的构成，改变谁在其中，你知道，在下一个冲刺的回顾会上把臂章交给不同的人。
康： 嗯嗯。
Richard： 在下一个冲刺的回顾会上。
康：哦，酷。是的。
康： 你有兴趣学习在企业范围内扩展Scrum的基础知识吗？你在做Scrum但不确定当产品开发需要多个团队时如何有效？商业小说《敏捷大师》将通过戏剧性的故事讲述来教授你这些技能。涵盖的概念包括：扩展Scrum系统、系统思维、组织设计、系统建模，以及如何为你和你的组织制定转型计划。你可以在LeanPub.com免费获得《敏捷大师》的预发布版本。链接在节目说明中。下一集，Richard会告诉我们更多关于Nexus的内容。
Richard： 我们不让各个团队单独进行冲刺评审。我们有一个整体的冲刺评审，叫做Nexus冲刺评审。
