031 创建 Nexus

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 Professional Scrum）。所以有了Nexus框架，去利用它，享受它。但是如果你想了解一些关于规划、追踪工作、可视化和持续集成、持续交付的在规模上的经过验证的实践，以及你现在听到的一些更DevOps的东西，那么就是scrum.org的专业Scrum规模，专业Scrum规模项目。当你问我关于实践的问题时，我喜欢将这两者区分开来。Nexus框架没有提到它。就像Scrum没有提到它一样。好吧，在scrum.org，我们有一些我们认为在规模上非常有价值的实践。就像对于单个团队的专业Scrum一样，我们有关于如何实施Scrum指南的想法。 康（03:36）： 一个实践的例子可能是… 理查德（03:40）： 产品积压的细化。哦，哦，等等，不，这是单个团队Scrum中的一项实践。在规模上，它实际上是一个新的事件。所以我们做出的改变之一是，这个外骨骼现在需要进行细化，不仅仅是“嘿，这是个好主意”。让Scrum团队定义何时何地以及时间段，它可以为零。现在它是一个事件，何时何地以及细化的深度由Nexus决定。但同样，我们有关于跨团队细化和单个团队细化的实践。我应该回到一开始并说Nexus框架的目的。第一目的是识别、透明化、减轻/消除依赖关系。我们认为依赖关系是不好的，是摩擦点，是无法完成的原因，是无法交付价值的原因。在规模上，这只会加剧。其他的规模框架可能会以不同方式定义“依赖关系”，或者将其视为协调/学习的机会。而我们的根本动机不是将依赖关系视为学习的机会，而是认为依赖关系是不好的，应该被可视化和减轻。 康声音解说（05:07）： Nexus是通过将多个Scrum团队团结在一个产品周围而形成的组织工具。通过创建一个具有相互依赖以生产产品的团队组，Nexus成为围绕共同目标组织团队的强大工具。 康（05:45）： 团队学到了，总的来说，似乎依赖较少 理查德（05:48）： 是的，Scrum并不反对学习，Nexus也不反对学习，但我们不将学习作为消除依赖关系的途径。我们在框架中有其他的方式来处理这个问题。 康声音解说（06:04）： 下一集，Richard Hundhausen告诉我们Nexus如何进行计划。 康（06:11）： 而且产品积压是为整个Nexus的。 Richard（06:13）： 它是为整个产品的。我们认为，使用Nexus框架进行扩展是许多团队共同努力完成一个产品的过程。

The post 031 创建 Nexus first appeared on Agile Thoughts.