敏捷开发需求文档_需求的长期，敏捷文档

敏捷开发需求文档

In my training courses, we discuss many topics. Including: how do you document requirements in the long term, in an agile environment?

在我的培训课程中，我们讨论了许多主题。 包括：如何在敏捷环境中长期记录需求？

Documentation is stored knowledge. As things are forgotten, its value increases over time. That’s why I think the question of long-term documentation is interesting.

文档是存储的知识。 随着事物的遗忘，它的价值会随着时间而增加。 这就是为什么我认为长期记录问题很有趣。

I’d like to start with two options for long-term documentation that  don’t make sense in an agile environment. Then I’d like to point out  sensible options. Each with advantages and disadvantages.

我想从长期文档的两个选项开始，这些选项在敏捷环境中没有意义。 然后，我想指出一些明智的选择。 每种都有优点和缺点。

不是有用的选项：详细的前期规范 (Not a useful option: Detailed up-front specification)

It does not make sense to specify all requirements in detail in  advance. In a complex environment, there are frequent changes.  Requirements are re-prioritized. This is one of the advantages of agile development. Some requirements are considered, but never implemented. Or not as planned, because you gain new knowledge during development.

事先详细指定所有要求没有意义。 在复杂的环境中，经常进行更改。 需求被重新排序。 这是敏捷开发的优势之一。 考虑了一些要求，但从未实施。 是否按计划进行，因为您在开发过程中会获得新知识。

Discussion and documentation of a requirement costs time. If the requirement is not implemented as documented, it was a waste of time.  Time that is urgently needed in development.

讨论和记录需求会花费时间。 如果未按文档要求实施要求，那将是浪费时间。 开发中迫切需要的时间。

也不是一个有用的选择：积压 (Not a useful option either: The backlog)

Let’s say you start to work in an agile way. Maybe you think: there  isn‘t any detailed specification. But a backlog. Let’s use it to document the requirements on a long-term basis.

假设您开始以敏捷的方式工作。 也许您认为：没有任何详细的规范。 但是积压。 让我们用它来长期记录需求。

But a backlog serves the future, not the past. It’s more like a to-do list. What do we implement next? The backlog isn't a sensible option for long-term documentation. It doesn’t document what has already been implemented.

但是，积压的订单是为未来而不是过去服务的。 它更像是一个待办事项清单。 接下来我们要实现什么？ 对于长期文档而言，积压不是明智的选择。 它没有记录已实施的内容。

选项1：实施后存档用户故事