Scrum规划与多层次团队

Question

在过去的一年中，我们的组织已经开始使用Scrum。在过去的几个Sprint中，很明显我们的Scrum并没有真正起作用 - 我们在某些任务的依赖性方面存在困难，而且我们在烧毁图表上已经走了。

从历史上看，我们从未关注过产品的速度和复杂性，而且一切都是猜测。

我们的新项目即将结束第一次Sprint。在过去的几天里，我一直在努力确保我们有一个优先的，复杂的估计产品积压。我回顾性地添加了我们在第一个sprint中正在处理的用户故事。很明显，我们咬的比我们咀嚼的要多。

我们估计我们的团队速度为28个故事点，然而，我们实际上还没有完成任何用户故事。我们的团队速度实际上是零，如果是，我该如何开始尝试计划下一个sprint？我们是否需要重新估算进入Sprint 2的团队速度？或者我们可以根据我们实际完成的用户故事的百分比来最好地猜测我们的速度实际上是什么？

我们遇到的另一个问题是我们的团队分为三层 - 数据，用户界面和服务。由于技能组合不同，这可能使Sprint难以计划。例如，我们有一个非常大的用户故事，涉及从我们的遗留系统导入数据（几乎整个冲刺价值），但只有我们的数据人员能够处理这个故事，所以我们需要添加额外的故事，这将允许UI和服务团队也参与了sprint。然后我们进一步伸展自己。

团队中没有多少人了解Scrum。大约4年前，我做了一个Scrum大师课程，我忘记了很多我学到的东西，而且我真的很难让这个Scrum团队运作良好。

我们有一支14人的scrum团队。这太大了，我们是否应该尝试拥有两个较小的Scrum团队？我们都在开展同一个项目。

我非常感谢经验丰富的Scrum Masters提供的一些建议，帮助我们尝试和帮助我们的Scrum流程。

Answer 1

听起来这个冲刺的回顾会很有趣！这些是我可能尝试的一些事情，并鼓励团队专注于回顾展：

1. 你的速度很不幸0因为没有故事完成。我鼓励团队考虑：
   • 未完成的故事出了什么问题？什么阻止他们去完成？
   • 这些故事是太大还是太复杂？如果是这样，他们怎么可能被打破？注意将故事分成“层” - 故事应该分成垂直切片，这样每个故事仍然会增加用户价值。
   • 团队是否开始过多而不是专注于完成已经开始的工作（进行中的工作太多）？
   • 您可能需要提醒他们整个团队成功或失败 - 如果团队中的一部分人挣扎，则由团队的其他成员来支持他们并提出解决方案。
2. 如上所述，故事应该是垂直的功能片，而不是水平片。这很棘手，因为软件工程师经常在“层”中思考。你如何通过“分层”团队克服这个问题？特别是，如何避免三组之间的交接（交接费用昂贵并导致延误）。一些想法：
   • 数据小组是否已提供存根（例如，返回硬编码虚拟数据的接口）以允许UI和服务团队在数据层完成时继续进行？
   • 一个跨职能小组是否已经涌入每个故事（因此所有三个“层级”都被迫在完成一个故事时一起工作）？
   • 层级如何交叉训练，以便他们可以在专业领域之外开展工作（这是“推广专家”或“专业通才”的概念）。这将使他们在发生粘性时互相支持。
3. scrum团队是否太大（可能）？
   • 5-9名成员的“两个披萨”团队是理想的
   • 是否有可能将团队分成两个scrums，每个scrum中的所有三个层次的人都会这样做？
   • 每个scrum都可以独立完成史诗

在回顾展之外，scrum主管和产品所有者可能想要考虑几件事情：

• 积压管理非常重要（而且很难做到正确） - 听起来你已经做了很多工作，但保持这一点至关重要。一个训练不足的积压将使团队停滞不前。
• 如果你有筒仓（例如在“层”之间），你需要努力将它们分解。 Silos降低了团队的灵活性，并创造了昂贵的交接。

最后，"Succeeding with Agile" by Mike Cohn是一本非常好的书，涵盖了在现实世界中制作Scrum的实际方面。我发现它非常有用。

Answer 2

投标给出了很好的建议以及我认为标题问题的答案，但它被埋在那里。我想明确地说出来：

  

是否有可能将团队分成两个scrums，每个scrum中的所有三个层次的人都会分开？

在Scrum中，故事是通过系统的垂直切片。您应该重组您的团队，以便他们具备开发端到端功能的专业知识。这将产生巨大的差异，我会在做任何其他调整之前尝试这个。

没有完成任何故事都很糟糕。您应该限制正在进行的工作量。

我建议你只给团队一个故事并让他们一起工作。他们显然是一个全新的团队，需要在跑步前学会走路。

如果没有充分利用团队成员，这会浪费吗？也许吧，但团队还没有证明他们可以提供任何东西。至少提供一件事会证明一定程度的生产力，这会迫使他们实际上作为一个团队工作。