在敏捷(scrum)中，如何分解用户故事？

Question

在敏捷(scrum)中，一个人应该如何将事情分解成一个用户故事。

如果有差异的话，团队规模大约是6名开发人员，迭代时间为3周。

是用点和小时来打破用户故事被认为是敏捷的，还是只为给定用户故事的用户点？

我们是否也应该将用户故事分解为任务？

在用户故事的实际工作流中，有以下内容：

1. 需求收集
2. 经理对用户故事的回顾等。
3. 用户工作流中的qa相关任务

在敏捷环境中如何处理这些事情？

Answer 1

用户故事通常是根据系统的客户端或潜在用户所表达的需求创建的。它的格式通常是“作为一个{角色}，我想要{目标}，这样{效益}”。集合的用户故事捕获正在构建的系统中所需的功能。客户或客户代表对每个用户故事进行排序，通常是基于通过在故事中指定功能而增加的价值。

一旦写好了，用户故事就会被大小和估计。有许多技术可以做到这一点。我见过的最常见的估算方法是完成任务所需的工作量(以任意值表示)。有一个每个人都能达成一致的基本单元，并将其作为一个公共框架，用于提供所需工作的估计。我认为这些都是被称为“故事点”的单一值，但我不明白为什么你不能在几个小时内估算用户故事。关键是要在所有用户故事中保持一致。

对于第一个迭代，团队估计他们可以在给定的迭代中完成多少个故事点，并将其提升到一个迭代的待办事项清单中。如果您是以小时为单位来估算，那么您可以确定您的开发团队在迭代期间将花费多少小时用于项目，并减少这几个小时的工作量。在迭代之后，确定实际完成的点或小时数，并为下一次迭代提取该工作量。

在整个过程中，您的故事总积压正在发生变化。可以删除功能、添加新功能或更改优先级。但是，所有这些都不会影响当前迭代的工作。只有在迭代之间，才能调整正在进行的工作。您通常会有一位现场客户代表，或者可以充当客户的代言人，并与客户组织的适当人员保持联系的人。他们不断完善整个项目的要求和验收标准。

如何将用户故事进一步分解为任务取决于您。它可能是工程师的一种无文档化的偏好，也可能是对每个用户故事所包含的具体内容的详细分析。这需要通过定制流程来满足组织、团队和项目的需要。

您应该有一个已完成的定义，它可以用来确定某个特定的用户故事何时可移植。这定义了从设计、实现、测试、质量保证、验收标准到文档的所有内容。您可以指定使用哪些工具和方法来确保完成用户故事指定的给定功能。一旦完成并集成了一个用户故事，该产品就应该处于一个潜在的可移植状态，这意味着将其打包并交付给客户将为他们的业务增加一些价值或满足他们的一些需求。

最终，您需要调整流程，以便为您的组织、团队和项目工作。“按书”做任何事通常都是解决问题的良方。仅仅因为某些东西已经被记录下来，并且在某些特定的项目上工作很好，并不意味着它适合你需要它做的所有事情。

您可能对这个InfoQ关于用户故事估计的文章和斯科特·安布勒对用户故事的介绍都感兴趣。

Answer 2

在我工作的地方，我们有几种不同的条件，它们会导致一个故事被分解成多个故事：

1. 它的扑克点数太高，或者这个故事看上去太模糊，甚至无法估计。如果故事有超过X点，那么它太大了，不能作为一个故事来完成一个冲刺。这可以防止团队过度投入，因为有时一个重大事件很难估计要花多少个小时才能完成，以及完成的速度有多快。“作为一个网站访问者，我想买一些产品，这样我就可以在家里买到那些产品了，”这类故事太模糊了。Amazon.com不是在两周的冲刺中建成的。
2. 在sprint中完成这个故事似乎不太可能，而且有一个简单的方法可以将故事分成多个部分。例如，第一部分可能是调查和设计一个解决方案。另一部分是实现该解决方案。每个部分都可以在一个sprint中完成，但似乎不太可能在相同的sprint中同时完成。

有时，可能是在看到与一个故事一起的任务列表，它将显示它属于第二种情况，或者会有如此多的QA需求，因为一些主要的功能被重建，故事必须被细分。