【发布时间】：2011-09-19 22:42:00
【问题描述】：
谁将故事分解为任务？由 Scrum 大师？还是团队成员？
何时拆分故事？在 Sprint 计划之前/之中/之后？
如何拆分故事？通过技术，例如数据建模、sql 或按用例（每个故事可能有多个用例和错误处理）。
谢谢。
【问题讨论】：
【发布时间】：2011-09-19 22:42:00
【问题描述】：
谁将故事分解为任务？由 Scrum 大师？还是团队成员？
团队成员这样做。 SM 方便。 PO 回答有关“什么”的问题并阐明用户故事。
什么时候拆分故事？在 sprint 计划之前/期间/之后？
绝对是在 Sprint 计划期间。实际上，有时您可能不得不将故事分解成更小的块并在冲刺期间将它们分配出去。只有当团队处理模糊的故事或高度复杂的故事时，才会发生这种情况。我知道不建议使用模糊的故事，这对团队来说很艰难，但可能会有一些罕见的时候你必须开始做某事。 绝对不是之后，但这样做有点违背了任务的目的，不是吗？ :)
如何分解故事？通过技术，例如数据建模、sql 或按用例（每个故事可能有多个用例和错误处理）。
在执行任务时不要考虑 sql、数据建模、编码、ui 等功能领域。而是从用例、测试用例、细粒度特性的角度来思考（记住，tdd 的思维方式在这里总是有帮助的）。在规划过程中列出所有已知的用例后，想想需要完成哪些任务才能使这些用例、功能正常工作。之后，将它们分成 8 到 16 小时（不多）的块。当然，用例可以作为完成标准提及，并且应该与正在处理的用户故事直接相关。
【讨论】：
谁将故事分解为任务？
团队成员。
Scrum master 提供帮助或便利。他们不建造东西。
什么时候拆分故事？
期间。这就是 sprint 计划是。
如何分解故事？
这是团队的选择。任何对完成某事有意义的事情。敏捷方法的重点是真正敏捷并做正确的事。教条地遵循愚蠢的过程不是敏捷。
阅读本文，了解如何与队友互动和进行规划：
实际上，作为一个小组，在每次每日站会开始时大声朗读，直到团队中的每个人都明白为止。
【讨论】：
谁将故事分解为任务？由 Scrum 大师？还是团队成员？
项目团队将故事分解为任务。因为他们是做实际工作的人，所以他们最有能力确定需要哪些更小的步骤才能完成故事。 Scrum Master 的唯一目的是为团队服务并确保流程顺利进行。这意味着召集（而不是领导）会议、消除任何障碍、清除障碍以及任何其他可能破坏项目成功的事情。
什么时候拆分故事？在 sprint 计划之前/期间/之后？
在整个团队之前的 Sprint 计划会议中分解任务。强烈建议 Scrum 主管和产品负责人出席本次会议，以帮助团队确定已完成工作的优先级。 Scrum master 不是必需的，但在我看来，参加会议可能会帮助他/她更好地完成工作。
如何分解故事？通过技术，例如数据建模、sql 或按用例（每个故事可能有多个用例和错误处理）。
应将任务分解为可完成的任务，这些任务以两种状态之一运行。完成与未完成。如果一项任务很容易陷入某种停滞状态，处于“有点完成但没有完成”的边缘，并且不容易（而且非常黑白）完成或未完成，那么你需要更多地分解它。例如，电子商务网站的完整支付网关将是一项任务，因为虽然需要完成几件事才能完成此任务（设置安全交易、将支付 API 集成到代码中、创建 Web 表单等），但这些都是集体总结一两天左右可以完成的事情。如果支付网关工作正常但不安全，则回答“完成了吗？”不是“嗯……这是一个简单的不”。在我以前的工作中，我们试图确保任务可以在 1-2 天内完成，故事应该在 sprint 内完成。 （如果 sprint 是 10 天，我们试图有大约 5x2 天的任务与之相关）。我希望这能回答你的问题。
【讨论】：