我的团队最近进行了sprint，我们正在将用户故事分解为任务。分解用户故事的最佳实践是什么？
每项任务都应该包括开发、设计、测试等等吗？或者这些任务可以单独分解？如果是这样，与测试无关的任务是否应该直接完成并跳过工作流中的"验证"或"待测试"列？
从我在网上读到的内容来看，似乎没有"固定"的方式，人们的做法也不同。我很好奇人们是否在做这件事的方式上有问题
任何帮助都是有用的！
分解用户故事的最佳实践是什么
拆分用户故事：汉堡法
大象鲤鱼
每项任务都应该包括开发、设计、测试等等吗
如你所愿。也许，您可以测试功能，而不是任务。但测试小部分（任务）比测试整个功能（如果可能的话）更容易。但sprint产品也应该进行测试。
+1对于大象鲤鱼：-）
目标是了解精简和垂直增量开发的威力：
- 精简：编写的代码越小，为将来的故事所需更改的代码就越少
- 垂直：每个故事都应该改变n层的任何部分建筑学代码（表示、逻辑、数据），以便每个故事都能提供直接商业价值
我促成了它，并见到了他的创造者（阿利斯泰尔·科克伯恩）。对于面临频繁更换需求和少量现金资金的客户的团队来说，这个游戏/练习真的很有趣。