我们在软件中应该做很多积压的事情，包括很多不同的类别，例如：
以合理的方式管理所有这些是产品管理的一项工作，但由于很多原因它很棘手。首先，我们有许多不同的系统，包含不同的东西（文件中的市场需求文档，错误数据库中的错误，我们的帮助台系统中的客户需求，内联网上的引擎环境愿望清单等）。其次，许多项目的大小，范围，复杂性和当然价值都大不相同，这意味着选择并不像按优先级排序列表那么简单。
因为我们现在相当庞大，拥有复杂的产品和众多客户，基本的解决方案（电子表格，谷歌文档，大本营待办事项列表）仅仅不足以解决这个问题。我们需要一种方法，以各种方式将事物组合在一起，持续地对它们进行优先排序，明确我们正在做什么以及将要发生什么 - 没有它需要所有人的时间来管理一些工具。
如何管理这种方式，使企业能够始终对现有客户做最有价值的事情，帮助获得新客户，并保持软件内在的理智？
请注意，这与开发方面不同，我认为我们已经相当不错了。我们以迭代，敏捷的方式开发所有东西，一旦选择了设计和实现的东西，我们就可以做到。这是我们需要弄清楚下一步该做什么最难的部分！
您找到了有效的方法或工具吗？如果是这样，请分享！ （如果您也想知道答案，请加快问题，使其保持可见：）
附录：当然最好先修复所有错误，但在实际安装在客户机器上的实际系统中，这并不总是实用的。例如，我们可能有一个很少发生的错误，并且需要花费大量时间和架构动荡才能修复 - 我们可能暂时搁置一段时间。或者我们可能有一个人认为难以使用的错误，我们认为修复它应该等待对该区域进行更大的改造。所以，有很多理由说明为什么我们不能立即修复它们，而是让它们保持开放，这样我们就不会忘记。此外，最困难的是非缺陷的优先次序;想象一下，我们没有任何：）
答案 0 :(得分：13)
以积极的方式管理大量积压工作几乎总是浪费。当你到达优先级堆积的中间时，事情经常发生变化。我建议采用Corey Ladas称之为优先级过滤器的东西：
http://leansoftwareengineering.com/2008/08/19/priority-filter/
基本上，你有一些不断增加的大小和优先级降低的桶。您允许利益相关者填写它们，但迫使他们忽略其余的故事，直到桶中有空缺。非常简单但非常有效。
编辑： Allan询问如果任务规模不同，该怎么办。基本上，做这项工作的很大一部分是正确调整你的任务。我们仅将此优先级应用于用户故事。用户故事通常比“创建社区网站”小得多。我认为社区网站是一个史诗甚至是一个项目。为了优先考虑，需要将其细分为更小的位。
尽管如此，制作类似大小的故事仍然具有挑战性。有时候你不能，所以你在规划决策时就这样沟通。
关于移动wibbles两个像素，很多这些容易的事情可以“免费”完成。你只需要小心平衡这些，只有当它们真的接近自由时才会这样做，而它们实际上有点重要。
我们同样对待错误。错误得到三个类别之一，现在，很快或最终。我们尽可能快地修复现在和很快的错误，唯一的区别就是我们发布修复程序时。最终，除非开发者感到无聊并且无所事事或者他们以某种方式变得更高优先级，否则不会得到修复。
答案 1 :(得分：5)
关键是积极的分类和优先排序。
解决使客户远离客户的问题，并添加更多功能以吸引客户。推回仅影响少数人的问题，除非他们很容易修复。
答案 2 :(得分：3)
一种简单的技术是使用优先级矩阵。
示例：
Covey提出的优先级象限（两个维度：重要性，紧急性）也很有用：http://www.dkeener.com/keenstuff/priority.html。注重重要和紧迫，然后重要而不紧急。非重要的东西......好吧..如果有人想在他们的下班时间那样做:-)。我使用的Covey象限的一个变体是具有重要性和易用性的尺寸。轻松是在Covey象限内确定任务优先级的好方法。
答案 3 :(得分：1)
我认为你必须将它们全部放在一个地方才能确定优先顺序。必须整理几个不同的来源使这几乎不可能。一旦你有了这个，那么某人/某个小组必须对每个错误，请求的功能和所需的开发进行排名。
您可以优先考虑的事项是：
答案 4 :(得分：1)
你应该先修复所有错误，然后考虑添加新功能。
答案 5 :(得分：1)
所有这些东西都可以通过具有以下功能的良好错误跟踪系统进行跟踪：
答案 6 :(得分：1)
既然你已经以敏捷的方式做事，你可以借用XP中的一些想法：
这样：
有关详细信息，请参阅 Kent Bech 和 Martin Fowler 的规划极限编程。他们说这比我做得好得多。
答案 7 :(得分：0)
我不确定该工具是否与流程一样重要。我见过团队非常成功地使用像索引卡和白板这样简单的东西来管理相当大的项目。我在优先级排序中建议的一件事是确保您有一个完整的这些项目列表。通过这种方式，您可以权衡解决问题与新功能的优先级等。
答案 8 :(得分：0)
除了任何工具和流程之外，还应该......某些人;）
在我们的商店，他被称为发布经理，他决定下一个功能周边投入生产。
然后有一个冻结管理器谁真正了解代码和文件以及错误（他通常是程序员之一），并将强制执行发布管理器的选择，并监视必要的合并以便有东西要测试然后发布。
在它们之间，可以建立优先级，包括高级别（功能请求）和低级别（错误和技术问题）