首先，如果客户或产品负责人要求进行文档编制（并愿意付费），您可以制作文档并保持敏捷性。

增量和迭代地编写文档，就像编写代码一样。测试一些，编写一些，然后编写一些文档。

我看到三种方法来做这件事：要么在任务评估中包括撰写文档所需的时间，创建专门的文档任务，或者有文档积压项/故事。

文档故事的风险在于它们可能会在实施之后很长一段时间才被计划，因此我不建议这样做。

文档任务具有在迭代计划中可见的优势，因此不应被遗忘或忽视。

敏捷并不意味着“没有规格书”。它意味着早期和经常性的测试和发布（但不一定是到生产环境）。

Scrum中的积压是“规格”。如果你没有实际编写和管理特性清单，你将会丢失特性，并且你永远无法确定产品何时发布(因为你不知道你在哪里，还剩多少工作量需要完成)。特性清单必须由某人管理。最简单的方法是编写产品应该做什么的一切(你可以在措辞和定义上变得非常复杂)，并跟踪已完成和未完成的内容。否则你怎么分配开发人员的工作并向“管理层”报告状态呢？

我对这个问题进行了很多思考 - 我们在一个Scrum环境下工作，我们最终遇到了组织文档的困难。

我目前正打算使用维基文档，虽然现在时间还很早，不知道它是否能通过长期测试。

基本上，工作流程如下：

1. Stories come up in the backlog
2. Story gets picked up by a programmer
3. Programmer does the code, and in the DoD (Definition of Done), also has to write some tests against the new functionnality, and has to edit the wiki to add a page for the new functionnality.

维基百科是使用mediawiki模板进行组织的，这些模板基本上是灵感来自mediawiki扩展文档页面，包含功能名称、引入版本和任何有用的信息。该模板还添加了图标以区分不同类型的功能（及其状态）。

在一天结束时，维基有一个巨大的优势，即让您添加文档页面而不必担心在哪里或如何放置它，但显然您需要有人前来组织混乱。

无论你使用什么工具，要记住的重要事情是，开发人员应该在开发完成后立即编写一些文档（包括技术方面）-而不是之前，也不是几个月后...

In my view the functional specification is necessary depending on how involved is the tech team with the product and how senior is the team. If the tech team is involved in the product definition you ll definitely need less documentation because there will be less room for assumptions. If you have a team of engineers that are juniors you need a stronger documentation or else things will not be done the way they were defined in the end of the sprints.
Also be aware that remote teams need more documentation in the form of functional specs due to the natural barrier of not being close to the stakeholders and product visionaries. Having upfront functional specs is a feature of agile. I saw a lot of tech teams where the tasks where solely described by a user story and quite often I saw those teams failing to achieve the releases and meeting the stakeholder s expectations.

这个主题非常广泛，有很多观点，但在我看来，这可以归结为开发人员不应该猜测需求。

实际上，我相信结果的成功和质量与开发人员需要做出的猜测/假设数量成反比。我认为，灵活性随着某些事情的具体规定而增加，因为您将少犯错误，并花费更少的时间纠正这些错误。

如果创建功能规范是合同的必要条件，您应该非常谨慎地考虑其中的内容。如果您未能按照功能规范中所承诺的交付工作，可能会被拒绝付款。

很不幸的是，如果您采用这个过程，您不会保持非常灵活。客户是否真的希望将应用程序重写为相同的功能？如果是，那为什么还要重写呢？我相信有一些功能从未被使用过。

我不会费心去记录旧版本。你已经有了参考，就是应用程序本身。软件中没有歧义。

文档编写不是反对敏捷主义的。没有为客户优先考虑，获取反馈而进行设计才是反对敏捷主义的。敏捷的重要方面之一是获取客户认可。如果他们不相信，那么项目将比应该的更难。

正如已经指出的那样，敏捷并不意味着几乎没有文档 - “以可工作的软件为优先，胜过全面的文档”。

我处理文档的方法就是将所有的事情都考虑成文档的一部分（包括代码和单元测试等技术规范）。因此，对于描述业务/用户需求的故事（或使用其他机制分配工作）应该详细到团队可以估算完成工作的程度；否则，它就是不完整和模糊的。此外，我在自己的实践中做的事情是，如果这个故事（或其他）估计需要超过一天的工作时间才能被团队定义为“完成”，那么它最好被拆分（这种原子化再编译最终会导致相当广泛的文档，但是不像不这样做那样假设许多未知变量 - 并且可以引导相当有趣的重用和模式发现）。

使用BDD风格需求的示例：

Given I am working on a document
When I select "Save As..."
Then a menu should appear allowing me to choose a name, 
and a file type, 
and a location in the file system,
and a file should be created in the file system

我们可能需要/想要添加UI元素来完成此任务，如菜单项、故事板、键盘快捷键等，以此来描述（我们可能有多种变体的“保存文件”主题）。等等。

所有这些相关的物品都可以附加到基础故事/需求上，以实现更完整的文档。但是，只将您实际实施的那些故事添加到您的软件网络版本的文档中。

这里的事情有点颠倒了，变得更加“敏捷”了。在开发期间以及之后，重新审查已记录的需求并添加团队所做的更改/修改/改进（无需仅通过文档CCB）。能够在不通过所有审查委员会等程序或在开发期间发现文档某些方面不完整时，编辑/更新文档和相关资产，使我们能够适应未知情况 - 因此，敏捷。

这份文档应该具有某种形式的版本控制或历史记录，使我们能描述我们所期望的系统，同时也能描述实际实施的系统 - 注意到有关文档作为“已完成定义”的一部分的另一个答案/建议（这也是我所做的）。 （维基对此很好;然而，一个完全集成的概念更加理想 - 例如，能够将票关联到衍生版本的文件中是不错的。）

从某种程度上来说，提前创建详尽的文档，并且在开发过程中和/或开发刚刚结束时无法进行修改，这将使你无法灵活 - 无法快速适应未知情况。然而，参考《领先的精益软件开发》一书中提到的，如果政策不允许正确使用某些实践/流程，那么无论你说自己是精益（或Scrum、敏捷），都没有什么用。

确保不过度详尽的方法之一是只在需要时写出所需要的内容（类似的概念也存在于开发中）。另一个方法是让所有人都明白你不需要一开始就尝试弄清楚所有的问题（从瀑布模型到敏捷模型的最大转变）—我们将记录每一个想法，它可能会出现，也可能不会出现在发布中。最后，弃用（并删除）任何不再适用的内容... 我记得有一次看到一个系统的文档，但是当我审查这个系统时，一半的文档并不适用于这个系统了。

既然你已经有了描述产品功能的文件，我会把它作为初始的任务清单，将工作划分成按优先级从高到低的多个小块。然后在每个迭代中处理一组小块。简而言之，使用Scrum方法，以您的初始文件作为任务清单。

我不会在未完成这项优先工作之前直接进入实施阶段。这不需要很多写作，而更需要引用您想解决的部分。

我不会事先记录整个事情。

此外，你还将直接与你正在处理的平台相关的一些任务，这些任务需要被捕捉并添加到冲刺积压工作列表中。

同样，您可能会在几次迭代后意识到您不想实施所有的要求。

敏捷开发在敏捷特征列表、产品待办事项清单，甚至到Sprint的任务待办事项清单中都有功能规格文件。它们没有被称作文件并不意味着它们不重要。与瀑布模型的功能规格文件的区别是什么呢？... 敏捷开发的功能规格文件只包含所需的内容，因此内容较少，还记得“完整文档之上，更注重工作软件”的原则吗？