Scrum：如何一次处理一个故事

我被提名为新成立的Scrum团队的Scrum Master。我们已经完成了一些冲刺。一开始，我试图让我的团队一次处理一个故事。但这没有用。我的团队难以以可以同时处理一个故事的方式分配任务。也许我们做错了什么？

例如：我们有一个故事来创建一个新对话框。我们创建以下任务：

• 创建模型类
• 从数据库读取模型数据
• 将模型类与视图连接
• 实施对话框处理
• 关闭保存数据
• 测试文件
• 解决方案说明

这些任务可以一次由多个人完成吗？任务（或多或少）是相互依赖的。还是我们以错误的方式设计任务？

为什么所有团队都需要一个故事？

为什么不将故事做得足够小（并且足够独立），以使一个人（或者更好的是一对做结对编程）可以处理一个故事。此过程还有助于更好地定义需求，并更多地考虑问题和实施。估算值也可能会变得更准确，但此处没有保证。

尽管这在很大程度上取决于用户故事的大小，但在许多情况下，应该只将一个开发人员分配给一个故事，以避免您的开发人员互相踩脚趾。虽然较大或非常复杂的故事可能需要更多开发人员，但也有可能将这些故事分解为许多较小的故事，这些故事可以单独分配。

我们通常要做的是将故事分解为dev / infra / analyst子任务。

1. 通常，超过一天的工作就是一个故事。

2. 分解任务后，将根据手头任务的编号在故事中工作一个或最多两个。通常是一个。

3. 我们记录所花费的时间，并在离开前一天或每天站起来之前更新剩余的估算值。

4. 将为工作中出现的任何新问题创建子任务。

5. 一个工作超过2周的故事被视为史诗。

6. 史诗可以由许多故事组成

您希望您的团队做的事情被称为蜂拥而至，但是并不是每个积压项目都可以被整个团队蜂拥而至。人们普遍认为，蜂拥需要一些先决条件：

• 跨职能，并置的团队
• 一个不平凡的故事
• “完成”的定义意味着整个团队的参与

将故事分解为任务时，团队应该已经处于群集模式，这样生成的任务就可以与群集兼容并且可以使整个团队参与其中。

但是，当过于频繁或一次与太多人一起使用群体时要小心，因为您可能会遇到一个难以解决的问题，当团队成员之间因为太多人从事同一项目而可能出现一些冲突。

您可能需要阅读Mike Cohn的“ 团队应该一次集中处理一个积压项目吗？或我昨天（写过）写的这篇文章更具体地讨论了错误：蜂拥而归

SCRUM的很大一部分是团队应该做出此类决策。积压的用户故事应具有足够的信息来生成任务。

虽然可以将用户故事强制为整个团队可以同时处理的项目，但更重要的是，团队选择要处理的项目，定义完成用户故事的任务，并使用日常工作台看看您是否按照承诺的工作进行。

团队一次必须承认您一次尝试只处理一个故事时所遇到的痛苦，并且在sprint回顾中需要提出潜在的解决方案。找出正确的做法以及需要改进的地方。

使用您难以分发可以同时处理的任务的示例，一个可能的解决方案是处理多个故事并在冲刺中取消3或4个项目。由于此用户故事的任务彼此重叠，因此很难分发工作。因此，与其战斗，不如拥抱它。

如图所示，您的任务似乎“很小”到可以分发的程度，但是任务之间存在一些耦合，例如关于数据建模和从数据库检索的任务。

可以将其分为人们可以同时进行的三项主要工作，以及一些额外的工作/设置：

• 后端（数据库，模型等）
• 前端（使用模拟数据）
• 测试（设定期望，方案等）

不能拆分的任务可以成对完成。当然，在任何一点上都在进行着一个以上的故事，这并没有内在的错。只要团队中的每个成员都知道其他人在做什么，他们就可以在需要时提供帮助（例如，“共享代码所有权”）。

是的，您应该保持团队专心，但是同时您需要让每个人和每个人都忙。

另外，您的团队有多大？这也是一个因素。一个故事要有十个人一起工作是非常困难的，而且如果可以的话，您的故事太远了，太大了，应该分开（就像您的团队一样）。