您如何处理“在某些时候”要解决的不断增长的问题？

我们正在使用JIRA来跟踪软件项目中的问题。我们注意到的一个效果是，我们经常会创建一个新问题，但是根本不知道何时/是否要解决该问题。因此，我们发明了一个伪造的“遥远的未来”里程碑，将其分配给这些问题。

碰巧的是，分配给该里程碑的一堆问题一直在不断增长，因此这似乎不是一个好方法。到现在为止，它们太多了，以至于要审查它们的有效性成为了很多工作。由于与您相关的组件已被删除，因此其中一些变得无效。其中一些被其他问题重复。其中一些描述的措辞很差，以至于没有人真正知道它们的含义了。

其他软件开发团队如何处理有效的问题，但这些问题可能随时都无法解决。您是否会麻烦录制它们？您是否将它们分配给下一个计划的版本，然后在下一个发行版本临近时再次查看它们？还有吗

这些都是很好的初次接触错误，可用于刚刚加入您公司的新开发人员。或供初级开发人员扩展对系统的了解。

如果不是，您可以将它们标记为“无法修复”，如果它们不够严重，不足以证明修复所需的时间。

仅当应用程序更有价值而不包含该错误时，才应修复该错误。

如果文本字段未对齐并且需要三天时间进行修复，则成本可能太高，您应该保留它。相反，如果用户根本无法在文本字段中写入内容，则应尽快对其进行修复。

通常，发现问题后立即修复更容易。如果让时间流逝，开发人员可能会忘记代码的那部分是如何工作的，并且修复该错误将花费更长的时间，因此会更加昂贵。

如果仍有错误待解决，一些公司不会编写新的代码行。其他人直到交付之前的测试阶段才开始打扰。

在您的公司中，显然，您在解决新错误之前要花很多时间，以便它们不断积累。看到大量错误对于团队的士气也是不利的。

我建议您花一天的时间来整理现有的错误，确定应该修复的错误和不值得修复的错误，然后将这些错误分配给现有团队成员，以期在下一个里程碑之前解决问题。 。

在我们的问题跟踪中，状态为“时间限制”。如果问题已存在数月甚至数年，并且没有客户敦促或重新提出该问题，则此状态将用作最终状态。每当经理要求我们清理未解决的问题时，这不是自动完成，而是手动完成。在此过程中，某些问题也很可能已得到解决，因为它们很容易解决和/或相对重要（尽管不被敦促或提起诉讼）。

我不使用JIRA，我正在使用fogbugz，但是我敢肯定这适用于大多数错误跟踪器。在撰写本文时，我意识到我的工作方式比瀑布更敏捷，但截止日期对我而言并不具体，重要的是优先事项。

• 如果您的老板关心打开过多的票证，请不要首先创建琐碎的票证。您应该务实，不要添加没有好处的任何功能/修复。如果这可以使您更轻松地完善一些代码或调整UI，那么请添加它。不要仅仅通过尝试修复产品中的细微缺陷为自己工作，没有什么是完美的。
• 将不重要的错误/功能放入当前里程碑，但优先级较低。如果提到更多关于此问题的投诉/请求，那么您可以提高优先级。
• 关闭/解决您无法解决的问题，无法重现，复制等问题。有些错误太微不足道，无法修复，或者它们是功能请求，需要花费太长时间。有时您只需要告诉要求这些修复/功能的人员“对不起，我们没有时间”。
• 根据需要对错误进行优先级排序，并根据优先级和里程碑对故障单列表进行排序。
• 如果他们不打算实现这一里程碑，则将其移至未来的里程碑。
• 如果票证依赖于其他已完成的票证，则将其标记为已阻止或将票证组织到一个层次结构中，因此很明显票证x和票证y是相关的。
• 如果票证需要某人的反馈，请将该票证分配给该人。

最终，您总是会遇到一堆低优先级的故障单，但是以上几点将帮助您最大程度地减少故障。

我们使用JIRA，并具有一个称为的其他解决状态Suspended-如果某个功能/错误是我们只需要放弃一段时间的东西，它将被解析为Suspended。这样，它就不会与我们必须引起注意的当前活动问题列表或令人满意的已解决问题列表相混淆，并且仍在数据库中。

我会定期（但不是很经常）查看“已暂停的问题”列表，以根据需要重新打开。

不确定正确的JIRA术语，但可以考虑在每个“票证”上注明有效期。如果尚未按照功能需求或错误严重性将其升级到一定时间内实施，那么一开始它可能并不那么重要。这应有助于自动修剪桩。我经常根据“难道不是很好”或“这不是我想要的那样完美地工作”来获得门票。如果没有其他人为此付出足够的力气，或者该用户没有足够的影响力，那么它就不会完成，而我会在几个月后关闭车票。