任务，比如 "refactoring needed" 应该存储在产品待办事项列表中吗？
Should task, like "refactoring needed" be stored in product backlog?
在 Scrum 项目中，开发人员有时会完成他们在产品待办事项列表项上的工作，但他们也会产生某种技术债务。技术债务可能是由于当时的一些障碍或缺乏时间而产生的，有时也是因为缺乏知识。
现在，当团队成员发现应该修复的技术债务时，推荐的跟踪方式是什么？工作不一定与任何特定的相关特征。团队成员是否应该创建新的产品待办列表项？
假设开发团队和产品负责人之间有足够的信任，因此没有理由向他隐瞒技术债务。
Scrum 团队的一个常见做法是，一旦发现技术债务工作就立即处理，并将工作打包到确定技术债务的故事中。
这样做有两个原因：
- 在技术债务被发现的时候尽可能早地处理它通常更容易。团队成员通常 在代码中 ，因此可以高效地完成工作。
- 延迟技术债务可能会给人一种进步的错误印象。例如，团队显示在一个冲刺中完成了 5 个故事，但实际上仍然积累了技术债务需要解决。
与特定故事无关的技术债务可以添加到积压工作中。
技术债务工作将与所有其他积压项目一起进行评估。因此，确定技术债务工作的 价值 很重要。例如：
If this technical debt is not completed it will be more difficult to work on the code base and so the team's productivity will be reduced.
您可能还希望考虑将积压的技术债务包装到其他积压故事中。例如，一个团队意识到站点主页正在使用一个已弃用的库版本。他们将这种技术债务添加到触及主页的功能性故事中，以便债务工作将与功能性工作同时修复。
有时开发人员知道他们最近的代码中存在技术债务；然而，有（很多）次他们在那一刻没有意识到这一点。后来，他们自己或另一组开发人员发现了问题，到那时，债务变得相当大（修复起来并不容易）。
虽然，我也相信必须尽早重构债务实例，但很多时候由于规模和复杂性，不可能在给定时间内重构。在这种情况下，必须跟踪债务实例。作案手法取决于 project/organization.
中遵循的流程和做法
在 Scrum 项目中，开发人员有时会完成他们在产品待办事项列表项上的工作，但他们也会产生某种技术债务。技术债务可能是由于当时的一些障碍或缺乏时间而产生的，有时也是因为缺乏知识。
现在，当团队成员发现应该修复的技术债务时，推荐的跟踪方式是什么？工作不一定与任何特定的相关特征。团队成员是否应该创建新的产品待办列表项？
假设开发团队和产品负责人之间有足够的信任，因此没有理由向他隐瞒技术债务。
Scrum 团队的一个常见做法是，一旦发现技术债务工作就立即处理，并将工作打包到确定技术债务的故事中。
这样做有两个原因：
- 在技术债务被发现的时候尽可能早地处理它通常更容易。团队成员通常 在代码中 ，因此可以高效地完成工作。
- 延迟技术债务可能会给人一种进步的错误印象。例如，团队显示在一个冲刺中完成了 5 个故事，但实际上仍然积累了技术债务需要解决。
与特定故事无关的技术债务可以添加到积压工作中。
技术债务工作将与所有其他积压项目一起进行评估。因此，确定技术债务工作的 价值 很重要。例如：
If this technical debt is not completed it will be more difficult to work on the code base and so the team's productivity will be reduced.
您可能还希望考虑将积压的技术债务包装到其他积压故事中。例如，一个团队意识到站点主页正在使用一个已弃用的库版本。他们将这种技术债务添加到触及主页的功能性故事中，以便债务工作将与功能性工作同时修复。
有时开发人员知道他们最近的代码中存在技术债务；然而，有（很多）次他们在那一刻没有意识到这一点。后来，他们自己或另一组开发人员发现了问题，到那时，债务变得相当大（修复起来并不容易）。
虽然，我也相信必须尽早重构债务实例，但很多时候由于规模和复杂性，不可能在给定时间内重构。在这种情况下，必须跟踪债务实例。作案手法取决于 project/organization.
中遵循的流程和做法