谁将故事分解为任务？通过scrum大师？还是团队成员？
什么时候分手？冲刺计划之前/期间/之后？
如何分解故事？通过技术，例如数据建模，SQL或用例（每个故事可能有几个用例和错误处理）。
感谢。
答案 0 :(得分：7)
谁将故事分解为任务？通过scrum大师？还是团队成员？
团队成员这样做。 SM便利。 PO回答关于“什么”的问题并澄清用户故事。
何时打破这些故事？在sprint计划之前/期间/之后？
绝对是在Sprint规划期间。实际上，有时候你可能不得不将故事分解成更小的块并在冲刺期间将它们任务化。只有在团队处理模糊的故事或高度复杂的故事时才会发生这种情况。我知道不建议采用含糊不清的故事而对团队来说很难，但可能会有一些罕见的时刻，你必须开始做某事。 绝对不是之后，它有点挫败了任务的目的，不是吗？ ：）
如何打破这些故事？通过技术，例如数据建模，SQL或用例（每个故事可能有几个用例和错误处理）。
在任务分配时，不要考虑sql，数据建模，编码，ui等功能区域。相反，在用例，测试用例，粒度特征方面进行思考（记住，tdd思维方式总是有帮助）。在计划期间所有列出的用例都已知之后，请考虑完成所有任务以使这些用例，功能正常工作。之后，将它们分成8-16小时（不多）的块。当然，用例可以作为完成标准提及，并且应该与正在处理的用户故事直接相关。
答案 1 :(得分：5)
谁将故事分解为任务？
团队成员。
Scrum master on帮助或促进。他们不构建东西。
何时打破这些故事？
期间。这就是sprint计划 。
如何打破这些故事？
这是团队的选择。无论做什么都有意义。敏捷方法的关键在于实际上是敏捷并做正确的事情。按照愚蠢的过程教条不是敏捷。
阅读本文以获取有关如何与团队成员互动并进行规划的指导：
实际上，在每个每日站立开始时，作为一个小组大声朗读，直到对团队中的每个人都有意义。
答案 2 :(得分：2)
谁将故事分解为任务？通过scrum大师？还是团队成员？
项目团队将故事分解为任务。由于他们是从事实际工作的人，因此他们最有能力确定完成故事所需的小步骤。 Scrum master的唯一目的是为团队服务并确保流程顺利进行。这意味着召集（不是领导）会议，消除任何障碍，清除障碍以及可能破坏项目成功的任何其他因素。
何时打破这些故事？在sprint计划之前/期间/之后？
在整个团队之前的Sprint计划会议中分解了任务。强烈建议Scrum master和Product owner出席本次会议，以帮助团队确定完成工作的优先级。 scrum master不是必需的，但在我看来，参加可能会帮助他/她更好地完成工作。
如何打破这些故事？通过技术，例如数据建模，SQL或用例（每个故事可能有几个用例和错误处理）。
应将任务分解为可在两种状态之一中运行的可完成任务。完成而非完成。如果任务很容易陷入某种停滞状态，在“有点完成但没有”的情况下，并且不容易（和非常黑白）完成或不完成，那么你需要更多地分解它。例如，电子商务网站的完整支付网关将是一项任务，因为虽然需要进行几项工作才能完成此任务（设置安全交易，将支付API集成到代码中，创建网络表单等），这些都是总结一些可以在大约一两天内完成的事情。如果支付网关工作正常但不安全，那么答案是“它完成了吗？”不是“嗯......这是一个简单的不。”在我以前的工作中，我们试图确保任务可以在1-2天内完成，故事应该在sprint中完成。 （如果sprint是10天，我们试图将大约5x2天的任务与之相关联）。我希望回答你的问题。