Go offline with the Player FM app!
031 创建 Nexus
Manage episode 485762579 series 2494146
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 Noir.
326 episodes
Manage episode 485762579 series 2494146
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 Noir.
326 episodes
All episodes
×Welcome to Player FM!
Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.