康：
Richard Hundhausen带我们了解Nexus如何进行冲刺评审。
插播：
我们将拥有Nexus Nexus，nexus，nexus。
Richard：
让我在这里转个弯。这里有一个地方规模化Scrum与Scrum不同的是：我们不让各个团队进行单独的冲刺评审。我们有一个整体的冲刺评审，叫做Nexus冲刺评审，整个Nexus参与。所以所有Scrum团队、他们的产品负责人、Scrum Master，以及与该冲刺目标相关的利益相关者，都来参加评审，他们检查已完成的集成工作，不只是说，嘿，我们要回顾团队一完成的六个PBI，但诚实地说，这些PBI可能汇总成更大的功能想法。所以我们要检查Nexus在该冲刺中交付的这些更大的功能，并获得反馈。我们有一些技术。我的意思是，这可能是在一个大房间里的长会议。
Richard：
如果你在观看功能一到十的电影，而我在那里是因为我关心功能八。哦是的。就像，我真的不在乎这部电影的前两幕，直接到我的部分吧。所以我们建议规模化时采用一些更大型的房间引导技术，比如科学展览会、集市，你可以在冲刺评审室周围设置站点。
康：
嗯。
Richard：
不同的利益相关者可以去不同的领域区域或角色，以这种方式查看他们一直在做的工作。
康：
所以你是团队的一部分，你在团队交付的某个部分上工作。
Richard：
是的。
康：
你可能有点不耐烦，嗯嗯，确实如此。关于坐在满屋子其他人中间，无论格式是什么，你正在谈论采用不同的格式来解决这个问题。是的。在某些方面，我认为这是一个好问题，因为如果我对我们整个Nexus正在交付的东西不感兴趣，那可能存在一些问题。也许问题出在我身上，也许问题出在Nexus上，我不知道。但我只是说，这也可能是一个健康的方式来找出如何解决这个问题。
Richard：
这是对的。如果你想不采用发散合并方法，而是有更多的单一反馈点，这样所有不同的Nexus团队都可以交叉学习并看到，你知道，我实际上从未见过Android应用程序的样子。对吧。所以是的。让我们把它放在大屏幕上。我更多是从利益相关者的角度来说的。
康：
哦，我明白了。哦是的，是的。那总是一个，
Richard：
你不想让他们疲惫，因为那样他们下次可能就不会出现了。对吧。
康：
不，那实际上是个大问题。
Richard：
你知道，没有利益相关者反馈的产品注定要失败。所以。
康：
是的。是的。
Richard：
所以我们确实建议为所有事件设置时间盒，但我们从不建议具体是什么。
康：
我明白了。
Richard：
我们唯一说的是每日Scrum应该不超过15分钟，但是这些大房间事件，让Nexus决定时间盒是什么。可能通常两周冲刺的四小时会议由于分布式团队或多地点或其他原因必须是14小时。除此之外，在这里总结一下，转个弯，冲刺评审之后，我们有回顾会，但我们将其分解为预备会议。所以就像我们有Nexus每日Scrum，来自不同团队的代表聚在一起，使过去24小时的集成问题透明化。我们在Nexus冲刺回顾会有这个预备会议，来自不同Scrum团队的代表使整个冲刺中什么进展顺利、什么没有进展顺利、学到的经验透明化，与其他团队分享。
康：
哦，好的。
Richard：
因为，你知道，团队一可能没有经历团队三在冲刺中遇到的问题，团队二可能没有经历团队四在冲刺中取得的成功。
康：
嗯。
Richard：
所以我们有这个小的预备会议，是对话式的，你可以做笔记。这些输出进入各个Scrum团队的回顾会，不只是正常的那种。这是Scrum指南中的。它只面向Scrum团队，他们检查并调整流程，寻找改进。记住新的Scrum指南，你必须至少带一个改进回到你的团队用于下一个冲刺。
康：
好的。
Richard：
这个大房间事件的不同之处，抱歉，Nexus冲刺回顾事件是我们有一个后会议。所以来自各个Scrum团队的代表，也许与之前相同的人，在各个Scrum团队回顾会结束后聚在一起，使这些改进或实验透明化。我不想说这是为了问责，
康：
对。
Richard：
但这也只是为了自下而上的智慧。嘿，看看我们在学什么，看看我们在做什么。看看我们如何在团队二那里应用它。团队三在那个后会议中记录这些。就像，那很酷。
康：
好的。让我快速描述一下。所以有一个框叫做Nexus冲刺回顾，它是一个有三个子框的框。最右边的是你正在描述的Nexus预备会议，
Richard：
Nexus预备会议，不同Scrum团队的代表相互透明化冲刺中什么进展顺利、什么没有进展顺利、学到的经验。
康：
然后中间有一系列，想象成一堆便利贴，这是所有Scrum团队然后进行他们自己的Scrum回顾会的地方。
Richard：
是的。
康：
然后最后，有另一个Nexus事件，像是后期的，某种
Richard：
后期的，这样各个Scrum团队回顾会的输出可以重新汇集并透明化，这样我们可以分享学习和这些讨论的结果。我个人也认为这有点关于问责。所以，嘿，你知道，我们必须告诉团队二，在下一个冲刺中，当我们处理财务计算时，我们的团队将在我们的完成定义中添加测试优先。
康：
哦，我明白了。
Richard：
哦，哇。好吧。我们要，我们要记住这个，你知道，一个月后或两周后。我想听听进展如何。
康：
对于想了解更多关于Nexus的人，我知道你描述了一点。让我们再次点击这些要点。他们应该去哪里？另外，因为这是播客，它会存在很多很多年。是否有一个循环性的年度活动，他们应该留意？
Richard：
Scrum.Org是专业Scrum的家园，这是你会找到Nexus指南的地方。这是scrum.org的规模化方法。它非常简约。它基于Scrum框架。所以如果你去scrum.org，它应该在主页上醒目地提供。如果你想在网上搜索Nexus，你知道，Scrum指南，你可以很容易找到它。它基本上是一个很小的PDF，我在这个播客中讲了整个内容，但是，我的意思是，它每隔几年更新一次。有时我们会删除一些内容，你知道，让它不那么规定性。有时随着Scrum指南的改进，我们会添加一些内容，Nexus指南也可能如此。所以我会说你可能想定期回来查看。但是一旦你到了Nexus页面，就有关于研讨会的信息。有关于案例研究的信息。有一本关于规模化Scrum的Nexus框架的书刚刚在几个月前出版。它解释了并在这里有一些更多的案例研究和一些例子，特别是关于Nexus集成团队如何运作的。
康：
酷。这本书是Pearson出版的吗？
Richard：
是的。它是由scrum.org的人写的，
康：
Kurt Bitner、Patricia Kong和Dave West。
Richard：
是的。Ken Schwaber作序。我们这些帮助制定Nexus框架的人，我们也对此进行了编辑。
康：
这是与Richard Hundhausen的Nexus系列的结尾。这一切从第30集开始，延续到31、32、33和34集。去访问敏捷思想档案来追踪那些其他集数。
康：
在敏捷思想秀档案中，你会看到与Boss Vodde（Less规模化框架的创始人之一）完成的一系列集数。下一集，我们得到另一位创始人，就是Craig Larman，他将谈论一些敏捷和在敏捷宣言创建者中出现的一些争议。
Craig：
现在一个历史观点，很少有人知道的是：因为小组中的大多数人都是自雇顾问，他们有以下想法，如果我们投票支持”适应性”这个词，Jim将获得所有业务<笑>。”敏捷”这个词比”适应性”这个词得到更多票数的原因是出于所有教练的自私愿望，即Jim不会获得所有业务<笑>。这就是我们如何到达今天的位置。很容易出现这样的情况，你的聚会小组被称为适应性西雅图或其他什么，而不是超越敏捷。
