我们正试图在我们的软件开发中实施一些敏捷/精益实践，我读过的一件事就是不要保留很长的“愿望清单”，而是要通过详细的笔记尽可能缩短产品积压只是关于列表顶部附近的事情。我可以清楚地理解这背后的原因。
但是，通常我们会遇到测试人员发现一个模糊问题或边缘情况的情况。我们通常会进行一些调查以找出问题的确切来源，以便我们知道它可能有多严重（例如它是否会影响其他情况？）并经常考虑我们如何解决它和/或可用的解决方法。在某些情况下，我们没有完成实际的修复，因为我们认为当时的成本/收益不值得，但我仍然想记录调查结果，以便将来再次出现问题，它很容易识别并看到我们使用了哪些变通方法，因为我们可能会认为它毕竟是值得修复的
目前我们为这样的事情创建了一个名为“愿望清单”的特殊类别的jira票证。我们应该使用更多的“敏捷”方法吗？
答案 0 :(得分：0)
在Jira，或者你使用的任何工具中，通常的敏捷实践是关闭这样一张票，其中一个关闭理由被拒绝＆＃34;或者＆＃34;回答＆＃34;。这将保持最低限度的文件证明该问题已被调查，但也传达了进一步追求该问题的成本效益是不值得的。然后，在任何报告汇总中都应该认为这些积压工作已经完成，并且在未来的积压工作或计划会议期间不应该分散团队的注意力。
答案 1 :(得分：0)
对你的jira无情，通过记录你发现的每一个问题都无法获得。记住敏捷宣言 - “在文档上运行软件”。
立即修复阻止程序，将重要的阻止程序放入待办事项并安排在下一个sprint中，对于任何不值得修复的事情，进行调查（总是调查错误），写几个快速笔记，然后关闭它jira状态'不会修复'。