我的团队正在使用Scrum和TFS来管理一个新的软件项目。团队中的某些成员希望以一种非常不寻常的方式解决问题。我需要知道是否有人处理过类似的事情。 （这部分是scrum /项目管理问题，部分是TFS，因为如果TFS使一种方法比另一种方法容易得多，那将影响决策。）
该软件系统的某些部分尚未以任何方式指定-未通过用户故事，验收标准，测试或其他任何方式指定。在某种程度上，它们是“角落情况”或错误处理情况。当遇到这些情况时，软件已经以特定的方式运行。 （这可能是通过显示一般性错误消息或沿某种通用解决方案进行的。）之所以存在这种情况，是因为该软件被设计为可容错的。
团队成员希望定义并锁定未指定的行为，因此它不会改变。如果确实发生了变化，尤其是情况变得更糟（例如，崩溃而不是显示一般错误消息），那么他们想抓住这一点。
但是他们建议通过编写与系统在极端情况下已经完成的工作相匹配的测试或验收标准来做到这一点。我的立场是，我们要保持稳定的任何当前未指定行为都应首先通过新的用户故事定义，而不是通过验收标准或测试来定义。用scrum / TFS记录和锁定现有软件中尚未发生的行为的正确方法是什么（最好以最少的努力）？
答案 0 :(得分：-1)
这是系统用户将从中受益的东西，因此，请按照用户案例进行操作：
作为用户，我希望产品稳定，并且在发生特定行为时不会崩溃，以便拥有良好的用户体验
要满足这个用户的故事，您可能会编写一项技术任务，以完成与现有边缘情况完全匹配的测试。
为什么要使其成为用户故事？好吧，这个工作项目将需要与其他待办事项进行优先排序，包括新功能。通过创建用户故事，我们允许使用标准Scrum积压方法对其进行优先级排序。