敏捷理念

康： Richard Hundhausen带我们了解Nexus如何进行冲刺评审。 插播： 我们将拥有Nexus Nexus，nexus，nexus。 Richard： 让我在这里转个弯。这里有一个地方规模化Scrum与Scrum不同的是：我们不让各个团队进行单独的冲刺评审。我们有一个整体的冲刺评审，叫做Nexus冲刺评审，整个Nexus参与。所以所有Scrum团队、他们的产品负责人、Scrum Master，以及与该冲刺目标相关的利益相关者，都来参加评审，他们检查已完成的集成工作，不只是说，嘿，我们要回顾团队一完成的六个PBI，但诚实地说，这些PBI可能汇总成更大的功能想法。所以我们要检查Nexus在该冲刺中交付的这些更大的功能，并获得反馈。我们有一些技术。我的意思是，这可能是在一个大房间里的长会议。 Richard： 如果你在观看功能一到十的电影，而我在那里是因为我关心功能八。哦是的。就像，我真的不在乎这部电影的前两幕，直接到我的部分吧。所以我们建议规模化时采用一些更大型的房间引导技术，比如科学展览会、集市，你可以在冲刺评审室周围设置站点。 康： 嗯。 Richard：

康： Richard Hundhausen向我们介绍Nexus集成团队。 Richard： 我想指出，Nexus中有一个新角色，可能是最容易被误解的角色，这可能是因为它的名字。它叫做Nexus集成团队。这不像其他规模化框架，那些框架中他们是做工作的人，他们负责合并代码、编写测试和修复构建问题。而这个团队实际上是一个来自Nexus的即时团队。比如说我们在Nexus中有五个七人团队，总共有35个实际做工作的人。在任何一个冲刺中，其中几个人会戴着臂章，上面写着”我在Nexus集成团队”。日常工作中，我在我的Scrum团队里做我的事情。我在写代码，写测试，做一些部署工作。但是如果那种信号灯亮起，比如我们的构建服务器停止了， 康： 有趣。 Richard：

Richard:  你已经在一个团队中使用Scrum一段时间了，他们接受产品待办事项增量——团队在冲刺结束时交付的需求。现在，你将其扩展到一个更大的组织，多个团队需要协调他们的努力来交付一个产品待办事项增量。团队数量可能是两个、五个、十个。想象一下让这些团队朝着一个产品待办事项增量工作所需的协调努力。Richard Hundhausen告诉我们这在Nexus中是如何完成的。 Richard:  这是一个正常的产品待办事项列表，尽管是大规模的。它会在顶部有更准备就绪的项目。 康： 而那个产品待办事项列表是为整个Nexus的。 Richard: 它是为整个产品的。我们相信使用Nexus框架进行扩展是关于许多团队在单一产品上工作。 康： 我明白了。 Richard: 这很快就会分解为”什么是我的产品？”有很多技术来识别这一点。Nexus框架不是关于将Scrum引入每个部门——比如维护、IT或财务。我见过组织尝试这样做。那不是扩展。这是为了多个Scrum团队想要在单一产品、单一产品待办事项列表、单一产品负责人上工作的情况。 Richard:

Richard Hundhausen和我讨论如何形成Nexus。 康（01:20）： Nexus是以某种程序化的方式形成的吗？还是有一些规则？ 理查德（01:26）： 嗯，我们更喜欢自组织，因此我们希望Nexus尽可能地自组织，就像其他框架需要一些组织重新设计来创建一个“泡泡”，让这个东西能够运作一样。与基于Scrum的其他框架一样。我们没有为管理者提供故事，因为在Scrum中没有管理者，只有自组织、自管理的团队。Scrum Master负责日常Scrum，帮助提高团队的生产力，提供教育和咨询。但最终是团队完成工作，是他们解决自己的问题。 康（02:13）： 我现在在考虑集成点。有Nexus冲刺审查吗？我正在看图表。 Richard（02:18）： 是的，如果你允许的话，让我解释一下。我们正在查看的图表可以在scrum.org上找到。它在Nexus指南中。这是一个PDF，就像Scrum指南一样。这是一个基本框架，免费提供的。它来自Ken Schwaber和我以及其他几位培训师。但scrum.org还有他们基于该免费框架的专业Scrum规模的实例，称为SPS（Scaled

康美国声音： 理查德·亨道森（Richard Hundhausen）为我们介绍了Nexus，这是一个用于进行多团队软件开发的框架。 康： 你刚才说Nexus是最简单的扩展框架。 理查德： 我研究了所有这些，其中一些需要一些严重的组织变革、重新设计或重构。而在Nexus中，我们只是假设你正在使用Scrum，所以Scrum已经存在并运作良好。我们在Scrum.org推荐首先使用专业的Scrum。我们有一个术语，我们称之为“nail it before you scale it”（在扩展之前先掌握），但我们理解组织正处于其发展过程中，如果你愿意，Nexus框架就像是一个外骨骼，你可以把它放在现有的Scrum框架周围，以便有机会进行扩展。 康： 听起来实际上与Less相似，至少在表面上是这样。因此，它谈到了团队的持续集成。现在，我不知道他们是否对谁应该进行持续集成有明确的规定，我也不知道它是否涉及任何产品定义类型的事物。Nexus在持续集成方面是否有规定，还是只是说：“嘿，他们应该使用持续集成”？ 理查德：