他们觉得这太夸张了《Nexus日报

我目前正在帮助一家政府机构内的小型软件商店，那里有多个Scrum团队在为同一个目标服务。他们正在构建一个具有多个子系统的产品，这些子系统有时需要集成。大多数情况下，它们在团队和系统之间的依赖性很低。今天，风向正在慢慢变化，趋势是“统一”，所以子系统需要紧密集成。我建议他们使用Nexus框架来帮助管理他们的开发。他们决定逐步整合系统，从两个Scrum团队开始，然后逐渐增加更多团队。他们已经实施了Nexus Daily Scrum。

在开始开发前几周，开发团队细化了他们的相关项目。我知道他们有些焦虑。当时，他们正在进行Nexus Daily Scrums，但觉得这些除了Daily Scrums之外的日常会议太过了，因为子系统之间没有依赖关系。所以他们决定停止。相反，他们在线下专门讨论即将到来的“依赖”工作。然而，在几次sprint之后，他们选择了需要开发的依赖项，并决定恢复Nexus Daily Scrum并每天进行同步。

各小组组织了一次特别的预先规划会议，每个小组都有一些成员参加。他们写下了相关项目的列表，并就如何整合他们的工作进行了高层对话。经过讨论，他们决定将发布推迟一周，以便“恢复”和“稳定”。这两个字使我立刻抽搐。“稳定期”的习惯太让人沮丧了!这些都是使用瀑布法和糟糕的技术实践留下的旧习惯。在Sprint结束时“完成”意味着什么?如果你已经“完成”了，为什么还需要一段稳定期?现在你能做些什么来更早地降低风险?我和队员们吵了一架。 I saw heads nodding, reasons were disclosed and it occurs to me that they were using a risk assessment practice that they used in the past. Anyhow, a potential topic for the next retrospective.

冲刺还在继续。每天，在Nexus Daily Scrum上，大多数开发人员都会这样开始他们的回合:“没有依赖关系，我们现在可以走了吗?”然后，最后，有人会说:“我要做这个技术含量很高的事情，我该如何与其他事情结合起来呢?”这样的谈话就会引起每个人的兴趣。相当于Nexus Sprint Backlog的内容将被更新为新信息，他们将继续工作。

即使团队还没有准备好将他们的部分完全实现，Nexus每日Scrum也会继续每天举行。它使团队成员能够在深入开发之前发现他们可以做的小实验。

此外，尽管他们还没有像Nexus指南中描述的那样完全使用Nexus框架，但他们创建了相当于Nexus Sprint计划的东西，并创建了一个Nexus Sprint Backlog来跟踪他们的依赖关系。我迫不及待地想看看他们会在Nexus Sprint回顾和Nexus Sprint回顾中出现什么!

欢呼,
西蒙

从联系指导，你可以阅读:

Nexus每日Scrum

Nexus每日Scrum是为来自各个Scrum的适当代表举办的活动开发团队检查集成增量的当前状态并进行识别集成问题或新发现的跨团队依赖关系。

在Nexus每日Scrum中，与会者应该关注每个团队对整合的影响增量和讨论:

前一天的工作成功整合了吗?如果不是，为什么不是?
●发现了哪些新的依赖关系?
●在Nexus中需要跨团队共享哪些信息?

在Nexus每日Scrum期间，应该使用Nexus Sprint Backlog来可视化和管理当前的依赖关系。

在Nexus Daily Scrum中确定的工作将被带回单个Scrum中团队在每日Scrum活动中进行计划。