如果我将特定功能的开发分为多个故事：
这是否意味着我在做瀑布？
此外 - 如果我将之前确定的独立部分的开发分为设计和实施。
这是否意味着我在做瀑布？
注意：我是Scrum新手的大时间。
答案 0 :(得分：3)
没有设计和实现故事，User Stories应该为用户提供某种程度的端到端功能（即提供客户价值）。
您混合术语故事和功能的事实无助于沟通，但您所描述的内容实际上就像任务（Sprint Backlog级别），不是用户故事（产品Backlog级别）。
如果他们不是任务，那么他们就是非常糟糕的故事。也许“功能”太大了，你应该put the story on diet，但我在这里看到的是一个典型的story smell。
如果您不熟悉用户故事，我强烈建议您使用常规template（作为＆lt;用户类型＆gt;，我想要＆lt;某些目标＆gt;以便＆lt;某些原因＆gt; ）并遵循INVEST模型。这将真正帮助您避免陷阱，例如您的问题。
回到真正的问题（我在做瀑布吗？）：在Sprint中进行设计（作为故事的任务）没有任何问题。但如果你的整个故事都是关于设计的，那么你并不是真的在做Scrum，你应该在Sprint结束时提供可证明的端到端增量。
答案 1 :(得分：1)
Scrum故事往往是关于“business value”：
商业价值是描述任何开发工作对业务的相对价值的概念。商业价值往往无法量化，但往往与金钱有关。
如果项目停止，您可以将商业价值视为仍可以出售的商品。
如果你写一个故事要创作：“这个特色的高级设计”，你通过实现这个故事所产生的东西不是企业可以出售的东西。这不是客户可以尝试，购买，使用的东西。实际上，该故事的商业价值为零。
你可能会更好地思考“垂直”的故事。 “Vertical slices”是覆盖整个技术堆栈的最小功能。例如：“用户应该能够在文本框中输入他们的名字，单击按钮，并在数据库中显示他们的记录。”它本身并不特别有用，但它比功能设计更有价值。
答案 2 :(得分：0)
不，你不是。子任务可以添加到积压（可能具有大致相同的优先级，因此它们大约在同一时间出现），然后超级任务将是集成/测试/等单独的组件。
这听起来像是将大型组件分解给我的有效方法。只需确保适当调整不同的块大小。我发现4-16小时的块效果最好。给一个任务40个小时意味着他们将在星期五之前完成2个小时的工作，当他们填补其他32个（以及许多错误）时。