敏捷开发和“愿望清单”[关闭]

Question

我们正在尝试在我们的软件开发中实施一些敏捷/精益实践，我读过的一件事不是维持一个长长的“愿望清单”，而是让产品积压尽可能短，并附上详细的注释仅关于列表顶部附近的内容。我可以清楚地理解这背后的原因。

但是，我们经常会遇到这样的情况，即测试人员的客户发现了一个晦涩难懂的问题或边缘情况。我们通常会进行一些调查以找到问题的确切根源，以便我们知道它可能有多严重（例如，它会影响其他情况吗？）并经常考虑我们将如何解决它和/或有哪些可用的解决方法。在某些情况下，我们不会进行实际修复，因为我们认为当时的成本/收益不值得，但我仍然想记录我们的调查结果，以便将来如果问题再次发生，很容易识别它并查看我们使用了哪些解决方法，因为我们可能会认为它毕竟值得修复

目前，我们为此类内容创建了一个名为“愿望清单”的特殊类别的 jira 票。我们应该使用更多“敏捷”的方法吗？

Answer 1

对你的 jira 保持无情，记录你发现的每一个问题都没有任何收获。记住敏捷宣言——“工作软件胜过文档”。

立即修复阻止程序，将关键问题放入积压工作并安排在下一个 sprint 中，对于任何不值得修复的内容，进行调查（始终调查错误），写一些简短的笔记，然后关闭它jira 状态为“无法修复”。

Answer 2

在 Jira 或您使用的任何工具中，以“拒绝”或“已回答”的关闭原因关闭此类工单是常见的敏捷实践。这将保留最少的文档来证明该问题已被调查，但也表明进一步调查该问题的成本效益是不值得的。然后，这些积压工作应在任何报告汇总中被视为已完成，并且不应在未来的积压工作梳理或计划会议期间分散团队的注意力。