似乎在针对用户故事的最佳实践方面存在竞争，而我却无法提出应对方法。主要是：
我觉得很难同时实现这两个目标。
例如，有时您需要重构事物。有些代码很复杂，只需要时间。如果作为功能用户故事的一部分完成，则该用户故事将变得更大。但是重构不应该成为用户的故事，因为它不能传递客户价值。您可能会争辩说，也许我们不应该首先让代码签入，而是要更改需求并因此更改假设，所以我认为这不是现实的期望。
另一个例子可能是处理一个新项目；我们需要设置存储库，项目，CI / CD管道。所有这些都是基础架构工作项，不会带来任何直接的客户价值。我想在这种情况下，我们可以使用“工程师”作为客户，但目前尚有争议，这是否是一个好习惯。
现在我可以改变规则，并将其作为用户案例。但是我很好奇，如果人们严格遵循scrum规则，是否有技巧和窍门同时满足这两个要求？
答案 0 :(得分：1)
Scrum没有为产品待办事项规定任何格式。因此，您的产品待办列表可以包含用户故事，也可以包含任何其他种类的项目。
您所说的用户故事应能带来价值，通常要符合INVEST的首字母缩写词，但您的产品待办列表可以包含与实现功能相关的项目，例如升级库，实施日志系统或任何有助于团队潜在地发布产品的项目。考虑到您的产品积压中也将存在错误，因此不仅仅涉及新功能。因此，不要愚弄自己组成的不存在的用户。
话虽如此，通常来说，大的重构是一种在适当的时候无法解决的问题的气味（产生高昂的技术债务，薄弱的国防部等等）。这就是许多作者说您应该在开发新功能的同时重构的原因（您的代码应采用正确的格式）。
最后，如果您处于需要大量重构的情况下，我的建议是尝试将重构分解为小块，并创建良好的测试工具来放心地重构。
答案 1 :(得分：0)
我可以想到几种剪裁故事的方法。但是，请记住，这些想法是可行的，但根据工作原理也没有任何意义。我只想分享我的经验。