保持用户故事小的想法
在用户故事方面，似乎存在着相互竞争的最佳实践，而我还没有想出一个方法来处理这些问题。主要是：
- 使用户故事保持较小。
- 用户故事应该提供客户价值，因此，以工程为重点的项目(如重构)不应是单独的用户故事，而应是正在进行的工作的一部分。
我觉得很难同时实现这两个目标。
例如，有时候你需要重构一些东西。有些代码很复杂，只需要时间。如果它是作为特性用户故事的一部分完成的，那么这个用户故事就会变得更大。但是重构不应该是一个用户故事，因为它不能提供客户价值。您可能会说，也许我们一开始就不应该让代码签入，但是需求会发生变化，因此假设也会发生变化，所以我不认为这是现实的期望。
另一个例子可能是如何启动一个新项目；我们需要设置存储库、项目、CI/CD管道。所有这些都是基础结构工作项，不提供任何直接的客户价值。我想，在这种情况下，我们可以使用“工程师”作为客户，但有一些争论，这是否是一个良好的做法。
现在我可以改变规则，把这些作为用户故事。但我很好奇，如果人们严格遵守scrum规则，是否存在实现这两种需求的技巧和技巧？
回答 2
Stack Overflow用户
发布于 2020-05-14 17:40:48
Scrum没有为Product项目规定任何格式。因此，产品待办事项清单可以包含用户故事，也可以包含任何其他类型的项目。
正如您所说的，用户故事应该提供价值，通常满足投资缩略词，但您的产品待办事项可以包含与功能相关的项，例如升级库、实现日志系统或任何可能帮助团队发布产品的内容。考虑到在您的产品积压中也会有bug，所以这不仅仅是关于新的功能。所以，不要自欺欺人，编造不存在的用户。
正因为如此，通常一个大的重构是一个问题的气味，没有在适当的时候解决(产生一个高的技术债务，一个弱的DoD等等)。这就是为什么许多作者说你应该在开发新功能的同时进行重构(你的代码应该是良好的)。
最后，如果您所处的场景需要一个大的重构，我的建议是尝试将重构分解成小块，并创建一个良好的测试工具来自信地重构。
Stack Overflow用户
发布于 2020-08-31 07:28:16
我可以想出几种你可以删减故事的方法。然而，请记住，这些想法可以工作，但也可能没有任何意义，取决于工作。我只想分享我的经验。
- 想一想三个基本领域:用户界面、数据计算、数据检索，如果您需要重复，尝试按照以下三个方面减少故事，为每一次迭代创建一个故事，
- 尽可能地为第一个实现创建一个故事，然后创建更多的故事用于升级和微调
- ，即使一个故事看起来很简单，试着删减它；作为一个团队，您可以更好地讨论较小的项目，以及您可以更好地改进它，并且迫使您考虑细节，这真的可以使
F 29产生影响。
https://stackoverflow.com/questions/61801318
复制相似问题
腾讯云开发者
