在Scrum中，是否应该将功能积压和技术性积压分开？

在我们的Scrum团队中，我们使用积压的订单，其中大部分包含功能主题，但有时也包含技术主题。拥有1个待办事项的好处是可以轻松选择下一个冲刺的主题，但是我有一些疑问：

• 首先，对我来说，有一个单独的技术待办事项似乎更合乎逻辑，开发人员自己可以在其中添加纯粹的技术项目，例如：我们可以用这种方法提高性能，该类缺少一些技术文档，...通过拥有一个待办事项，所有开发人员总是必须通过产品所有者来将其主题添加到待办事项中，这对于产品所有者而言似乎是额外的，不必要的工作。
• 其次，如果您的产品所有者只关注纯功能性项目，纯技术性项目（例如缺少技术文档，侵蚀代码并应进行重构的代码），则此类类在调试期间总是会出现问题，因为它们没有一个稳定的基础，应该进行重构，...）总是排在最后，因为“它们不直接为客户服务”。通过有单独的技术待办事项，并在每个sprint中为这些纯技术项目保留时间，我们可以在功能上改进应用程序，但也可以使其内在健康。

最好的方法是什么？一两个积压？

我不是专家，但我想您每个团队只能积压一本。团队需要确定哪些问题是紧急的，哪些可以推迟。如果将问题分为不同的堆栈类型，则会违背scrum核心的核心思想，即存在大量问题，团队中的每个冲刺都会处理最紧急的问题。如果您（细分）团队，您也许可以划分与他们相关的任务类型，但是从根本上来说，您将要建立并行工作的团队。紧急程度/必要性是计划下一个冲刺的首要决定因素。您可以对任务进行分类，但这不会影响您的决策过程。

我想向建议每种产品积压的那些人添加声音。创建另一个积压订单是一种理性的反应，但实际上只是在避免核心问题：产品负责人为什么不将技术项目放在功能项目之上？您应该专注于解决此问题，而不是解决它。例如，您可以使用5种“为什么”技术来探究一切。

采购订单不优先考虑技术问题的原因可能有很多。例如，也许技术团队没有解释不解决技术债务的长期成本（以$$$表示）。也许完全是另一回事。很有可能是由于沟通问题，而长期的解决方案是着手解决并解决问题-消除障碍。

此外，我还有另一个问题要考虑：为什么首先产生技术债务？理想情况下，诸如重构等工作应该在功能故事中进行，并在sprint中完成。它们本身不应该是多余的故事，否则您没有潜在的可移植代码。

您所指的通常称为“技术债务”。有时可能很难以与缺陷相同的方式来了解技术债务的工作方式如何适应Scrum流程。

您提出的建议类似于建议也存在单独的“缺陷待办事项”，将待办事项分为3个。

就个人而言，我根本不主张拆分产品积压。产品积压的想法是代表出色的工作项目。从这个角度来看，功能和技术债务项之间的唯一区别是需求来自开发团队，而不是来自客户。它仍然是一项工作，仍然需要对其进行管理，包括优先处理其他工作。如果技术债务项目需要测试，则尤其如此，在这种情况下，技术债务项目应通过与常规功能完全相同的质量检查流程。

我同意Onno的观点，即每个项目应该只有一个积压。否则，团队基本上会自己决定一些理应属于产品所有者的决策。

即使是“纯技术”项目也必须对用户（因此对于产品所有者）具有一定的实用价值，才有资格获得冲刺积压。您的任务是向产品负责人解释这些好处，并说服他/她增加成本的合理价值。这个过程迫使您自己思考这些问题，并选择最不费力就为项目带来最大价值的技术变更。

我同意以上所有答案。在商业现实的热度中，PO将继续优先处理功能性故事，而不是技术性故事。通常会使团队感到沮丧。团队应该避免使用没有任何用户价值的技术故事（如果速度不是问题，谁会关心优化？），并学会查看功能故事所隐含的某些其他技术任务。“完成的定义”也起着重要作用。其余的功能案例会在待办事项列表上进行排序，以便对PO进行优先级排序。

例如，技术文档：技术文档的可用性（在适用的情况下）是DOD中的一个典型项目，因此，每个功能实例均暗含对其进行更新。

例如，重构代码：在有益于产品开发时应执行。在产品变成技术债务时，不要早（团队不应该假定产品将朝哪个方向发展），也不要晚。审查设计也可能是国防部的一部分。

我同意MelR。如果有什么是“技术性的”，我们需要看一下为什么要这样做-甚至对用户来说短期和长期的因果关系是什么？

我已经看到许多积压的待办事项清单，其中可以轻松地以一种商业价值的方式编写所谓的“技术任务”。

技术任务通常也是大量分解的故事的结果，因为它可能是分解问题的简便方法。但这会导致真正的附加值（或反馈机会）的迭代速度变慢，甚至使冲刺失败。

关于Patrick提到的“侵蚀并应重构的代码”，我相信我们需要询问-该代码影响系统功能的哪些方面？如果我们现在不重构它，对用户的长期影响是什么？

还有一个主题是“让事情比我们发现的要好一些”，以减少长期的技术债务，这是否可以作为每个sprint中小故事的一部分来完成，而又不会对整个项目产生太大影响？

最终，我看不到需要两个积压订单，这没有机会降低适当优先的需求-但是需要产品所有者，他们应该受过技术影响方面的教育，并且具有确定真实价值的强大能力，因此垂直分解故事-Adobe对垂直切片提供了很好的解释。

不，您永远不应该创建技术故事。这是一个常见错误。您的故事必须反映业务需求。技术上的东西从来不是真正来自业务需求。Scrum管理员和团队的角色是评估达到目标或故事所需执行的所有技术任务。

例如，如果您的故事是关于创建登录屏幕的，则您还必须考虑创建数据库（如果尚未创建）。

我看不到使用PO来创建以IT团队为用户的任务的问题。如果任务可以被采购订单理解并且可以根据业务价值进行评估，那么可以的话，您就可以创建一种技术故事。您只使用系统。