我们在软件中应做的工作积压了很多，涉及很多不同的类别，例如：

• 我们的产品需要解决的新问题领域
• 支持现有问题区域的新功能
• 现有用户要求的新功能
• 可用性和"外观"增强
• 从架构上升级到后端
• Bug修复

以明智的方式管理所有这些都是产品管理的工作，但是由于许多原因，这很棘手。首先，我们有许多不同的系统来容纳不同的内容(文件中的市场需求文档，错误数据库中的错误，帮助台系统中的客户要求，Intranet上的引擎愿望清单等)。其次，许多项目的规模，范围，复杂性和当然价值都千差万别，这意味着选择并不像仅按优先级排序列表那样简单。

因为我们现在很大，拥有一个复杂的产品和许多客户，所以基本的解决方案(电子表格，google文档，basecamp待办事项列表)不足以解决这个问题。我们需要一种以各种方式将事物组合在一起的方法，不断地对它们进行优先级排序，明确我们在做什么和即将发生的事情，而这无需所有人花费所有时间来管理某种工具。

我们如何以一种允许企业始终执行对现有客户最有价值的事情，帮助获得新客户并保持软件内向健全的方式进行管理？

请注意，这与开发方面有所不同，我认为我们对此感到满意。我们以迭代，敏捷的方式开发一切，一旦选择了某种东西进行设计和实现，我们就可以做到。这是我们需要找出下一步最难的部分！

我们找到有效的方法或者工具了吗？如果是这样，请分享！ (如果我们也想知道答案，请对问题进行评分，以使其保持可见状态：)

<I>附录：当然，首先修复所有错误是很不错的，但是在实际安装在客户计算机上的真实系统中，这并不总是可行的。例如，我们可能有一个只很少发生的错误，并且要花费大量的时间和体系结构的巨变来修复，因此我们可能要花一会儿时间。否则，我们可能会遇到一个错误，即有人认为某些内容难以使用，而我们认为修复该错误应等待对该区域进行更大的改进。因此，有很多原因使我们不能立即将它们全部修复，而是将它们保持打开状态，以便我们不会忘记。此外，非错误的优先级是最难的。试想一下我们没有任何:)

解决方案

我不确定该工具是否与过程同样重要。我已经看到团队使用索引卡和白板之类的简单内容来管理相当大的项目非常成功。在优先级排序方面，我建议我们确保一并列出这些项目的完整列表。这样，我们可以权衡解决问题与新功能等的优先级。

我认为我们必须将它们全都放在一个位置，以便可以对它们进行优先级排序。必须整理几种不同的来源，这实际上是不可能的。一旦有了这些信息，那么某人/一个小组就必须对每个错误，所需的功能和所需的开发进行排名。

我们可以优先考虑的事情是：

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

我们应该首先修复所有错误，然后再考虑向其添加新功能。

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

例子：

• 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象限内确定任务优先级的好方法。

除了任何工具和过程，还应该有一些人;)

在我们的商店中，他被称为发布经理，他确定要交付生产的下一个功能范围。
然后有一个Freeze Manager，他实际上了解代码，文件和错误(他通常是程序员之一)，并将执行发布管理器的选择，并监视必要的合并，以便进行测试然后发布。

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

具有良好功能的Bug跟踪系统可以跟踪所有这些东西，该系统具有以下功能：

• 能够将工作项标记为错误或者增强请求
• 工作项所属的责任区域的类别字段(UI，后端等)
• 计划完成修复或者功能的"版本号"字段
• 状态字段(进行中，已完成，已验证等)
• 优先领域

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

修复使客户迅速离开的问题，并添加更多功能以保持客户的到来。推迟一些只会影响少数人的问题，除非它们很容易解决。

由于我们已经以敏捷的方式进行操作，因此我们可以借鉴XP的一些想法：

• 将所有故事放入大量索引卡(或者某些此类工具)中
• 现在，开发人员应该估计这些故事的大小(此处是最终决定)
• 并让客户(或者他们的代理人-如产品经理)按照其业务价值来订购这些故事(此处是客户的最终决定)
• 如果开发人员认为有些技术更重要(例如修复那些讨厌的错误)，则他们必须与客户(业务人员)进行沟通，并让客户提高优先级(客户仍然有最终决定权)
• 在团队速度允许的情况下，为下一次迭代选择尽可能多的故事

这条路：

• 只有一个任务队列，按业务需求排序
• 客户获得最高的投资回报
• 商业价值驱动发展，而不是技术或者极客
• 开发人员可以说很难实施
• 如果没有投资回报率，任务将停留在该堆底部附近

有关更多信息，请参见Kent Bech和Martin Fowler的《规划极限编程》。他们说这比我能做的要好得多。

以激进的方式管理大量积压几乎总是浪费的。到了优先排序的中间时，事情通常已经改变了很多。我建议采用类似Corey Ladas所谓的优先级过滤器的方法：

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

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

编辑：艾伦(Allan)问如果任务大小不同该怎么办。基本上，完成这项工作的很大一部分是正确确定任务的大小。我们仅将此优先级应用于用户案例。用户故事通常比"创建社区站点"小得多。我认为社区站点有点史诗甚至是项目。必须将其分解为更小的位，以便进行优先级排序。

话虽如此，使故事的大小相同也可能是一个挑战。有时我们只是做不到，所以我们在计划决策中进行了沟通。

关于摆动两个像素，许多容易的事情可以"免费"完成。我们只需要小心地平衡这些平衡，并且只有在它们真的接近于免费并且它们实际上有些重要时，才可以使用它们。

我们以类似的方式对待错误。错误获得以下三种类别之一："立即"，"不久"或者"最终"。我们会尽快修复Now and Soon错误，唯一的区别是发布修复程序的时间。最终，错误不会得到解决，除非开发人员感到无聊且无事可做，否则它们将成为更高的优先级。