032 Nexus 如何制定计划

Agile Thoughts

Richard: 你已经在一个团队中使用Scrum一段时间了，他们接受产品待办事项增量——团队在冲刺结束时交付的需求。现在，你将其扩展到一个更大的组织，多个团队需要协调他们的努力来交付一个产品待办事项增量。团队数量可能是两个、五个、十个。想象一下让这些团队朝着一个产品待办事项增量工作所需的协调努力。Richard Hundhausen告诉我们这在Nexus中是如何完成的。 Richard: 这是一个正常的产品待办事项列表，尽管是大规模的。它会在顶部有更准备就绪的项目。 康： 而那个产品待办事项列表是为整个Nexus的。 Richard: 它是为整个产品的。我们相信使用Nexus框架进行扩展是关于许多团队在单一产品上工作。 康： 我明白了。 Richard: 这很快就会分解为”什么是我的产品？”有很多技术来识别这一点。Nexus框架不是关于将Scrum引入每个部门——比如维护、IT或财务。我见过组织尝试这样做。那不是扩展。这是为了多个Scrum团队想要在单一产品、单一产品待办事项列表、单一产品负责人上工作的情况。 Richard: 就像在Scrum中一样，我们用冲刺计划会议开始冲刺。在Nexus中，冲刺计划会议包括每个团队的预测和计划。这是那些大房间会议之一，来自每个Scrum团队的代表在预会议中会面，使依赖关系透明化。 有细化、规模估算和一些权衡，这样团队可以交付在冲刺期间没有PBI跨越团队边界的项目。此外，最适合的团队选择每项工作——注意依赖关系并在冲刺结束时交付可演示的价值。 Richard: 然后这些代表将PBI带回到他们各自的Scrum团队的冲刺计划中。团队决定预测是否符合他们的容量、速度和完成定义。使用新的Scrum指南，每个冲刺都期望有改进。如果团队同意他们可以完成PBI，他们就制定计划。当最后一个Scrum团队完成他们的冲刺计划时，整个Nexus冲刺计划会议结束。每个人都等到最后一个团队预测并最终确定他们的计划。例如，如果第五个团队意识到他们缺少培训人员，他们可能需要与其他团队协调以调整依赖关系。 康： 所以听起来他们在为下一个冲刺中能够交付的内容在团队间构建一个共享的待办事项列表。 Richard: 某种程度上。我们实际上没有共享的冲刺待办事项列表，除了作为跨团队依赖关系的视图。在规模化时有一个新的工件叫做Nexus冲刺待办事项列表。你可以把它想象成来自每个Scrum团队待办事项列表的PBI在流程图中可视化——每个团队一行：待办、进行中、完成，也许还有一个”阻塞”列。 康： 嗯嗯。 Richard: Nexus中的任何人都可以说，”哇，第一个团队在等第二个团队的PBI，而第二个团队甚至还没开始——冲刺已经过半了。” 康： 嗯嗯。 Richard: 所以这是个别团队冲刺待办事项列表预测的只读、聚合视图。 康： 嗯嗯。 Richard: 谁维护或查看它？你在那个工件上举行每日Scrum吗？这由Nexus来决定。 Richard: 日常中，就像在Scrum中一样，我们有每日Scrum——一个同步会议来计划当天。规模化的不同之处是Nexus每日Scrum，在各个团队的每日Scrum之前举行。来自每个Scrum团队的代表参加这个预会议。它像正常的每日Scrum一样有时间盒限制。在这里，他们使过去24小时的集成或依赖问题透明化。其他团队可能会说，”我们今天正要涉及那个——谢谢提醒。” 康： 嗯嗯。 Richard: 或者”审计员在大楼里？好的，我们会注意。”依赖关系可能在人员、领域、技术组件或甚至代码库之间——尽管我们不建议团队之间有私有存储库。Nexus每日Scrum的输出成为各个团队每日Scrum的输入。 康： 嗯嗯。 Richard: 这就像Scrum的Scrum，除了它是必需的并且首先发生。 康： 我喜欢它首先发生的想法。我和其他教练在一天结束时做过多团队Scrum，很难对我们这么晚学到的东西做出反应。这很有道理。 Richard: 有时我被问到，”我们还能做Scrum的Scrum吗？”我说，”嗯，就像在单团队Scrum中一样，不行——你不被允许和人交谈。” 康： <笑> Richard: 那是个玩笑。 康： 太好了。<笑> Richard: …

The post 032 Nexus 如何制定计划 first appeared on Agile Noir.