agile - 与多层团队一起进行 Scrum 计划

Question

关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。












想改进这个问题？将问题更新为 on-topic对于堆栈溢出。

8年前关闭。




Improve this question




在过去的一年里，我们的组织开始使用 Scrum。在过去的几个 Sprint 中，很明显我们的 Scrum 并没有真正发挥作用——我们在某些任务的依赖性方面遇到了困难，而且我们在燃尽图上还差得很远。

从历史上看，我们从来没有关注过我们产品的速度和复杂性，一切都只是猜测。

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

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

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

团队中没有多少人能很好地理解 Scrum。大约 4 年前，我参加了一个 Scrum 大师类(class)，但我已经忘记了很多我学到的东西，我真的很难让这个 Scrum 团队运作良好。

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

我非常感谢经验丰富的 Scrum Master 提供的关于我们可以做些什么来帮助我们的 Scrum 流程的建议。

Answer 1

听起来这个 sprint 的回顾会很有趣!这些是我可能会尝试并鼓励团队在回顾中关注的一些事情:

不幸的是，您的速度为 0，因为没有完成任何故事。我会鼓励团队考虑:

未完成的故事出了什么问题？是什么阻止了他们完成任务？

故事是否太大或太复杂？如果是这样，他们怎么可能被打破？小心把故事分成“层”——故事应该被分成垂直的片断，这样每个故事仍然可以提供用户值(value)的增量。

团队是否开始太多而没有专注于完成已经开始的工作(正在进行的工作太多)？

您可能需要提醒他们整个团队的成功或失败——如果团队中的某个部分陷入困境，则由团队的其他成员来支持他们并提出解决方案。

如上所述，故事应该是功能的垂直切片，而不是水平切片。这很棘手，因为软件工程师经常在“层”中思考。您如何通过“分层”团队克服这一点？尤其是，如何避免三组之间的切换(切换代价高昂并导致延迟)。一些想法:

数据团队能否提供一个 stub (例如，返回硬编码虚拟数据的接口(interface))以允许 UI 和服务团队在数据层完成时继续进行？

一个跨职能小组是否会在每个故事上蜂拥而至(因此所有三个“层”都被迫在完成一个故事时一起工作)？

层级如何进行交叉培训，以便他们可以在其专业领域之外从事工作(这是“通才”或“专精通才”的概念)。当事情变得棘手时，这将使他们能够相互支持。

Scrum 团队是否太大(可能)？

一个5-9人的“两个披萨”团队是理想的

是否有可能将团队分成两个 scrum，每个 scrum 中有来自所有三层的人员？

每个 scrum 都可以独立处理史诗

在回顾 session 之外，scrum master 和产品负责人可能想考虑以下几点:

积压管理非常重要(而且很难做到正确) - 听起来您在这方面做了很多工作，但保持它至关重要。一个糟糕的积压工作将使团队停滞不前。

如果你有孤岛(例如在“层”之间)，你需要努力打破它们。筒仓降低了团队的灵 active ，并产生了代价高昂的交接。

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