存档场景和重新审视故事

Question

在一个庞大而复杂的应用程序上工作，我想知道我们应该在哪里以及是否应该存储方案来记录软件的工作原理。

当我们讨论现有功能的问题时，我们很难看到我们已经完成的工作，并且很难回顾使用诸如 TFS 之类的Scrum工具。我们有一些测试，但产品所有者看不到这些测试。
我们是否应该寻找一些大量的故事/情景列表，修改/更新我们去的时候或者这不敏捷。

除了代码，一些单元测试，一些测试用例和一些过时的用户指南之外，我们没有关于软件如何工作的记录。

Answer 1

我们倾向于使用我们的自动验收测试来记录这一点。当我们处理用户故事时，我们还开发了自动化测试，这是我们的“完成定义”的一部分。

我们使用SpecFlow进行测试，这些编写为Given，When，Then，易于阅读和理解的场景，可以与产品所有者共享。

这些测试增加了很多价值，因为它们是我们的自动回归套件，因此回归测试更快更容易，但随着我们开发新故事时它们不断更新，它们也充当了系统工作方式的文档。

您可能会发现查看一些示例规范的博客很有用，这实际上就是我们要做的事情。

我过去认为有用的一些链接是：

http://www.thoughtworks.com/insights/blog/specification-example

http://martinfowler.com/bliki/SpecificationByExample.html

Answer 2

除了测试之外，我们还使用Wiki作为文档。特别是REST API记录了请求/响应示例以及其他软件行为（长时间讨论的结果，难以记住的东西）。

Answer 3

由于您希望能够对正在运行的软件所做的事情的描述进行匹配，因此您应该将其与版本控制一起放在版本控制中。从docs /目录开始，然后根据需要添加详细信息。我经常这样做，它只是有效。如果您想使这个Web服务，然后在某个地方设置一个Web服务器，每隔一段时间检查一次文档，并将文档根目录指向工作副本docs /目录。