如何为集成团队分解待定项?

“峰值”和“设计任务”的目的是什么还不清楚，特别是在Scrum环境中。我将这些事情与Scrum的产品Backlog细化活动联系起来。使用您的工作管理工具来识别需要做的特定事情，从而将产品待办事项项移动到更接近于准备在Sprint计划中进行选择的状态，这可能是有帮助的，但在这里它们似乎有所不同。

鉴于此，我会关注他们的改进活动。产品Backlog细化在这个团队中是如何工作的?涉及到的是谁?整个团队多久开一次会?人们花了多少时间在精致上?细化的产品待办事项列表项是什么样子的?这些是我要问的问题。

你有什么想法如何更好地分解，团队在哪里集中于集成?

分解不是挑战。Scrum不是某种将需求分解成块，然后在sprint中实现的简化活动。

你现在的经历有点像康威定律。系统需求的分解反映了公司中现有的社会边界，而不是有价值增量的生产。一个“集成团队”，负责集成工作，然后努力以一种有意义的方式进行Sprint。

Scrum是关于学会在正确的时间做正确的事情在那里，每个Sprint都是一个经验学习实验。您的情况看起来像“混乱”，因为您对价值没有清晰的视线，只有集成工作，因此没有明确的方法将价值交付的内在复杂性置于经验过程控制之下。考虑:

• 影响是什么其他团队工作不整合?
• 其他团队目前如何生产有价值的产品完成在没有整合的情况下工作?
• 为什么集成理所当然地落在了一个单独的团队——您的团队身上?

你好托马斯,

谢谢你在任何情况下的评论:)

我知道，它们是互补的。到目前为止，我已经与他们合作了1.5个月，仍然在被收购。作为一个新手，我专注于了解他们，他们当前的环境，他们的工作是关于什么的，他们作为一个团队是如何运作的，以及框架中有哪些明显的地方需要改进。

不管怎样，我也问了同样的问题。峰值用于PBI需要对HOW进行更多说明的情况。所以他们进行研究，Spike是当前Sprint的一部分。例如:prepare - integration相关的密钥管理流程和工具。然后是一个相关的设计任务(我仍然不明白):“定义与集成相关的关键管理流程和工具”。这些也是Sprint的一部分。在我的理解中:Spike是看看有什么实现选项。设计任务:我们计划如何实现该选项。然后是一个故事，或者一个任务。希望这能有所帮助。

这个团队非常积极主动，他们不断改进(dev-dev, dev-PO)。它只是在我看来，他们需要更多的指导，把这些分解成sprint大小的工作项目。

差点忘了:我们使用的是Jira和Confluence。PB当然是由PO创建的，但她已经按照价值将项目拉入即将到来的2个sprint。当计划到来时，他们已经讨论过这些，他们会尽可能地准备这些项目。我的意思是，他们对它有一个共同的理解，他们添加了环境，接受标准/或预期结果和估计。

谢谢!

嗨,伊恩,

谢谢您的反馈。我明白你的意思。我觉得重要的是要提到并回答你的问题:

该团队的目标是将3个独立的遗留系统(3个独立的银行)集成到一个系统中，同时进入云计算。形势根本不是垂直的，而是水平的。他们并没有集成他们正在构建的应用程序，但是他们基本上是在为已经存在或将来将存在的任何应用程序奠定基础。

我并没有把减少工作量作为主要目标，但他们无法在一次冲刺中完成他们的工作。当我到达时(1.5个月前)，许多故事/任务都经过了7-9个sprint。所以假设像这样的一大块工作有可能被更好地衡量，我不认为这是一个不正确的观点。

根据你的描述，spike和至少部分设计任务应该被考虑改进。通过将这些活动转移到细化过程中，并在每个Sprint中留出一部分能力用于细化，团队将能够在有价值的产品待办事项项上取得进展，这些产品待办事项项可用于向关键涉众展示进展。

我相信，如果团队开始区分“准备好”和“未准备好”产品待办事项项，并确保在Sprint计划中有足够的“准备好”产品待办事项项，每个人都将看到团队在预测和实现Sprint目标方面的能力的改进，而不会有大量的工作滚动。

您不可能将细化融入到单个Sprint中。这需要时间，特别是当您考虑相互关联的工作，并做出相互影响的设计决策时。将这种类型的工作转移到持续改进中，并将Sprint Backlog集中在可以交付的有价值的工作上，这将是一个很大的改进。然而，它也可能揭示出其他需要解决的问题。