如果我将一个特定功能的开发分成多个故事：
这是否意味着我正在做瀑布？
此外 - 如果我将先前确定的独立部分的开发划分为设计和实现。
这是否意味着我正在做瀑布？
注意：我是 Scrum 新手。
【问题讨论】：
标签： agile scrum requirements
没有像设计和实施故事这样的东西，User Stories 应该为用户提供某种程度的端到端功能（即交付客户价值）。
您将术语 stories 和 features 混用这一事实无助于交流，但您所描述的内容实际上听起来像是任务（Sprint Backlog 级别），不是用户故事（产品待办事项级别）。
如果它们不是任务，那么它们就是非常糟糕的故事。也许“功能”太大了，你应该put the story on diet，但我在这里看到的是典型的story smell。
如果您是用户故事的新手，我强烈建议您使用常规的template（作为
回到真正的问题（我在做瀑布吗？）：在 Sprint 中进行这样的设计（作为故事的任务）没有任何问题。但如果你的整个故事都是关于设计的，那么你并不是真的在做 Scrum，你应该在 Sprint 结束时交付一个可证明的端到端增量。
【讨论】：
Scrum 故事往往与“business value”有关：
业务价值是一个描述任何开发工作对业务的相对价值的概念。商业价值通常无法量化，但通常与金钱有关。
您可以将商业价值视为在项目停止后仍可出售的东西。
如果您编写一个故事来创建：“功能的高级设计”，那么您通过实施该故事所产生的东西并不是企业可以出售的东西。这不是客户可以尝试、购买、使用的东西。实际上，该故事的商业价值为零。
“垂直”地思考故事可能会更好。 “Vertical slices”是涵盖整个技术堆栈的最小功能。例如：“用户应该能够在文本框中输入他们的姓名，单击一个按钮，然后在数据库中显示他们的记录。”它本身并不是特别有用，但它比功能设计更有价值。
【讨论】：
不，你不是。子任务可以添加到待办事项中（大概具有大致相同的优先级，因此它们大约在同一时间出现），然后超级任务将是集成/测试/等单独的组件。
对我来说，这听起来像是分解大型组件的有效方法。只要确保你适当地调整了不同的块。我发现 4-16 小时的块效果最好。为一项任务分配 40 小时意味着他们将完成 2 小时的工作，直到周五他们把另外 32 小时塞进去（还有很多错误）。
【讨论】：