识别Scrum中的冗余需求

Question

我正在研究如何解决分布式Scrum中的需求冲突，其中团队分布在多个位置。我提出了一个由五个步骤组成的模型，包括识别冗余需求、删除它们、为每个需求分配唯一I、存储需求信息和解决需求冲突。我想问的是：

1. 如何在分布式Scrum中识别冗余需求？
2. 如何删除冗余需求？
3. 如何为每个需求分配唯一的ID？
4. 需求信息是如何存储的？
5. 以及如何解决需求冲突？

Answer 1

在Scrum中，所有需求(以及产品所需的所有其他更改)都在Product中维护。产品负责人最终负责产品待办事项的内容和排序。Scrum指南对多个团队的指导意义不大，但是有一些轻量级的Scrum框架，如Nexus (来自Ken和Scrum.org)、Scrum@Scale (来自和Scrum，Inc.)和来自和Bas的大规模Scrum )。在这些缩放的框架中有一些共同点--对于所有在单个产品上工作的团队来说，都是一个单一的产品待办事项清单，以及一个最终负责这个产品待办事项的产品负责人。

无论使用何种流程或框架，都将在产品待办事项处理过程中确定冗余需求。理想情况下，Product和任何支持Product的人都能够在添加冗余需求之前识别这些冗余需求，但是细化应该是在团队识别冗余需求时进行。

在一个复杂的系统和分布式团队中，我推荐一个管理产品积压日志的工具。这个工具应该允许搜索和其他分类项目的方法(例如标签和标签)。这将提高产品负责人和支持产品负责人的人员搜索已完成和计划完成的工作的能力，以确定是否存在相关或冲突的需求。

不同开发团队的知识也可以使用，但是对于多个团队和分布式团队来说，这可能更难，因为他们可能不具备整个系统的完整和深入的知识。管理产品和所有需求的大部分工作由产品负责人和任何支持产品负责人的产品经理、分析师或其他人员承担。

不管谁发现了相互冲突的需求--开发团队、产品管理人员、产品负责人--解决通常都是通过交谈完成的，产品负责人对产品待办事项有最终的决定，因此对产品的正确要求也是如此。

Scrum或任何缩放的Scrum框架都不需要对任何冲突的需求进行特殊处理。没有必要将is分配给或做任何特殊的事情。