您如何管理大量产品积压？ [关闭]

Posted 2023-02-25

【中文标题】您如何管理大量产品积压？ [关闭]

【英文标题】：How do you manage a large product backlog? [closed]

【发布时间】：2010-09-11 16:03:47

【问题描述】：

我们在软件中积压了大量应该做的事情，有很多不同的类别，例如：

我们的产品需要解决的新问题领域 支持现有问题领域的新功能 现有用户要求的新功能 可用性和“外观”增强 后端架构升级 错误修复

以明智的方式管理所有这些是产品管理的一项工作，但由于很多原因，这很棘手。首先，我们有许多不同的系统来保存不同的东西（文件中的市场需求文档、错误数据库中的错误、我们的帮助台系统中的客户需求、我们内部网上的工程愿望清单等）。其次，许多项目的大小、范围、复杂性和价值都大相径庭，这意味着选择并不像按优先级排序那样简单。

因为我们现在规模相当大，产品复杂且客户众多，所以基本解决方案（电子表格、谷歌文档、大本营待办事项列表）不足以解决这个问题。我们需要一种方法来以各种方式将事物组合在一起，持续对它们进行优先排序，明确我们正在做什么以及即将发生的事情 - 而无需花费所有人的时间来管理某个工具。

您如何管理这一点，让企业始终做对现有客户最有价值的事情，帮助获得新客户并保持软件内部健全？

请注意，这与开发方面不同，我认为我们已经做得很好。我们以迭代、敏捷的方式开发所有东西，一旦选择了某些东西进行设计和实施，我们就可以做到。这是我们需要弄清楚下一步要做什么的部分，这是最难的！

您是否找到了有效的方法或工具？如果有，请分享！ （如果您也想知道答案，请对问题进行评分，使其保持可见:)

附录：当然最好先修复所有错误，但在实际安装在客户机器上的真实系统中，这并不总是可行的。例如，我们可能有一个很少发生的错误，并且需要大量的时间和架构巨变来修复 - 我们可能会暂时搁置它。或者我们可能有一个错误，有人认为某些东西很难使用，我们认为修复它应该等待对该区域进行更大的改造。所以，有很多原因我们不只是立即修复它们，而是保持它们打开，这样我们就不会忘记。此外，最难的是对非错误进行优先级排序；想象一下我们没有:)

【问题讨论】：

另见sqa.stackexchange.com/q/17385/8992

【参考方案1】：

我不确定该工具是否与流程一样重要。我已经看到团队使用索引卡和白板这样简单的东西来管理相当大的项目非常成功。我建议优先考虑的一件事是确保您拥有这些项目的完整列表。通过这种方式，您可以权衡解决问题与新功能等的优先级。

【参考方案2】：

我认为您必须将它们全部集中到一个位置，以便优先考虑。必须整理几个不同的来源使得这几乎是不可能的。一旦你有了它，那么某人/一个小组必须对每个错误、请求的功能和期望的开发进行排名。

您可以优先考虑的事情是：

产品增值 对现有和潜在客户的重要性 任务规模

【参考方案3】：

您应该先修复所有错误，然后再考虑为其添加新功能。

【讨论】：

虽然从开发人员的角度来看很重要，但如果错误很小，添加新功能可以让更多人购买对公司更重要的软件。

【参考方案4】：

一种简单的技术是使用优先矩阵。

例子：

http://erc.msh.org/quality/pstools/psprior2.cfm

http://it.toolbox.com/blogs/enterprise-solutions/sample-project-prioritization-matrix-23381

Covey 提出的优先级象限（两个维度：重要性、紧迫性）也很有用：http://www.dkeener.com/keenstuff/priority.html。关注重要和紧急，然后关注重要和不紧急。不重要的东西......好吧......如果有人想在他们的下班时间这样做:-)。我使用的 Covey 象限的一个变体是重要性和轻松的维度。轻松是在 Covey 象限内确定任务优先级的好方法。

【参考方案5】：

除了任何工具和流程之外，还应该有……一些人；）

在我们的车间里，他被称为发布经理，他负责确定下一个要交付生产的功能范围。 然后有一个Freeze Manager，他实际上知道代码、文件和错误（他通常是程序员之一），并将强制发布经理的选择，并监控必要的合并，以便有东西要测试，然后发布。

在这两者之间，可以在高级（功能请求）和低级（错误和技术问题）上确定优先级

【参考方案6】：

所有这些东西都可以通过具有以下功能的良好错误跟踪系统进行跟踪：

能够将工作项标记为错误或增强请求 工作项所属职责区域的类别字段（UI、后端等） 修复或功能计划完成时间的版本号字段 状态字段（进行中、已完成、已验证等） 优先级字段

【参考方案7】：

关键是积极的分类和优先级。

解决使客户快速离开的问题，并添加更多功能以保持客户光顾。推迟只影响少数人的问题，除非它们很容易解决。

【参考方案8】：

既然你已经在以敏捷的方式做事，你可以借鉴 XP 的一些想法：

将所有你的故事放在一大堆索引卡片（或一些类似的工具）中 现在，开发人员应该估计这些故事的大小（此处开发人员有最终决定权） 并让客户（或他们的代理人——比如产品经理）根据他们的业务价值来排序这些故事（这里客户有最终决定权） 如果开发人员认为存在更重要的技术问题（例如修复那些讨厌的错误），他们必须将其传达给客户（业务人员）并让客户提高优先级（客户仍有最终决定权） 在团队速度允许的情况下为下一次迭代选择尽可能多的故事

这边：

有一个任务队列，按业务需求排序 客户获得最佳投资回报 商业价值推动发展，而不是技术或极客 开发人员可以说出实现这些事情的难度 如果没有

ROI

，任务将停留在该堆的底部附近

有关详细信息，请参阅 Kent Bech 和 Martin Fowler 的规划极限编程。他们说的比我做的都好。

【参考方案9】：

以积极的方式管理大量积压几乎总是浪费。当您到达优先事项的中间时，事情往往会发生变化。我建议采用类似 Corey Ladas 所说的优先级过滤器：

http://leansoftwareengineering.com/2008/08/19/priority-filter/

本质上，您有几个大小不断增加和优先级降低的存储桶。您允许利益相关者填补它们，但迫使他们忽略其余的故事，直到桶中有空缺。非常简单但非常有效。

编辑：艾伦问如果任务大小不同怎么办。基本上，完成这项工作的很大一部分是正确调整您的任务。我们仅将此优先级应用于用户故事。用户故事通常比“创建社区站点”要小得多。我会认为社区网站有点史诗，甚至是一个项目。需要将其分解为更小的部分才能获得优先级。

也就是说，制作类似大小的故事仍然具有挑战性。有时你就是做不到，所以你在计划决策时就传达了这一点。

关于移动 wibbles 两个像素，许多这些简单的事情可以“免费”完成。你只需要小心平衡这些，并且只有在它们真的接近免费并且它们实际上有点重要时才这样做。

我们同样对待错误。错误获得三个类别之一，现在、很快或最终。我们会尽快修复现在和很快的错误，唯一的区别是我们发布修复程序的时间。除非开发人员感到无聊并且无事可做，或者它们以某种方式变得更高优先级，否则最终错误不会得到修复。

【讨论】：

我喜欢这个。你建议我们如何处理一堆东西中可能有非常不同大小的东西这一事实？我的意思是，我们一直在谈论从“将 wibble 移动 2 个像素”到“创建社区网站”......