22

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

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

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

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

您如何以一种允许企业始终做对现有客户最有价值的事情、帮助获得新客户并保持软件内部健全的方式来管理这一点？

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

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

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

4

9 回答 9

12

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

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

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

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

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

With regards to moving wibbles two pixels, many of these things that are easy can be done for "free". You just have to be careful to balance these and only do them if they're really close to free and they're actually somewhat important.

We treat bugs similarly. Bugs get one of three categories, Now, Soon or Eventually. We fix Now and Soon bugs as quickly as we can with the only difference being when we publish the fixes. Eventually bugs don't get fix unless devs get bored and have nothing to do or they somehow become higher priority.

于 2008-09-20T21:18:22.230 回答
5

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

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

于 2008-09-20T20:08:55.783 回答
3

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

例子：

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

于 2008-09-20T20:01:47.390 回答
1

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

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

  • 产品附加值
  • 对现有和潜在客户的重要性
  • 任务规模
于 2008-09-20T19:56:42.863 回答
1

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

于 2008-09-20T19:57:05.840 回答
1

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

  • 能够将工作项标记为错误或增强请求
  • 工作项所属责任区域的类别字段（UI、后端等）
  • 计划完成修复或功能时的版本 # 字段
  • 状态字段（进行中、已完成、已验证等）
  • 优先领域
于 2008-09-20T20:07:43.337 回答
1

由于您已经在以敏捷的方式做事，您可以从 XP 中借鉴一些想法：

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

这边走：

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

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

于 2008-09-20T20:24:51.813 回答
0

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

于 2008-09-20T19:56:31.070 回答
0

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

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

在它们两者之间，可以在高级（功能请求）和低级（错误和技术问题）上建立优先级

于 2008-09-20T20:07:07.283 回答