如果你的目标是每个冲刺的潜在的可交付软件,他们说,在Scrum中,或者更好的是一个潜在的解决方案每次迭代中我们说纪律敏捷交付(爸爸),那么你需要保持你的交付文档同步与您的软件/解决方案——换句话说,写在整个项目中持续交付文档。图1中概述了该策略。您的另一种选择是将可交付文档的最后定稿留到项目的末尾，以便稍后进行文档化。

图1所示。通过SDLC -文档持续策略编制文档。

我一直在使用术语“可交付文档”，但这意味着什么呢?可交付文档是作为整体解决方案的一部分交付给涉众的文档。当然，这在不同的项目中会有所不同，但是可交付的文档通常包括用户手册、培训材料、操作手册、支持手册和系统概述。它通常不包括需求规范或设计规范，当然，除非在法规情况下需要这样的文档，或者在合同谈判中需要作为合同的一部分。当然，对于所有这些工件，我强烈建议遵循敏捷文档的最佳实践。

下面是一些很好的启发式方法，可以有效地持续记录:

1. 等待信息稳定下来。在您完成大部分开发工作之后编写文档，换句话说，在迭代的末尾。如果您记录的信息还不稳定，就会冒着必须重新编写文档的风险。
2. 在长迭代的迭代过程中编写文档。对于“长”迭代，比如四周或更长时间，您有足够的时间来稳定信息，从而在迭代期间捕获信息。
3. 用短迭代编写以下迭代的文档。对于“短”迭代，即两周或更短的迭代，信息不太可能及时稳定下来，以便您完成文档。为了尽可能保持效率，您应该考虑在迭代N+1期间为迭代N编写可交付的文档。对于中等长度的迭代(两到四周)，您将需要进行试验，以确定哪种方法更适合您。

注意，使用这种实践，许多团队将在迭代的done定义中包含关于更新可交付文档的标准。换句话说，文档成为确定工作项(例如用户故事或缺陷报告)是否已完全实现的验收标准的一部分。这反映了在软件之上解决方案的有纪律的敏捷交付(DAD)哲学。

这种做法的风险概况

通过在整个项目中不断编写可交付的文档，您可以解决以下风险:

1. 交付的风险。通过与解决方案的其余部分同步编写文档，您知道您有足够的文档来支持到目前为止构建的内容。这意味着您的解决方案实际上可能在每次迭代结束时交付。
2. 准确的风险。因为完成工作和记录工作之间的反馈周期很短，所以更有可能记住需要捕捉的关键细节。

然而，这种做法可能增加三种风险:

1. 财务风险。因为需求可能在整个项目中不断发展，所以您需要更新可交付的文档来反映这些变化。从敏捷的角度来看，通过不断地记录文档，您实际上是在“长途旅行”。
2. 进度风险。编写和维护这个文档需要花费时间和精力，并且由于需求的不断变化而导致的文档的任何返工都会影响您的进度，因为需要返工。
3. 准确的风险。遗憾的是，不断地编写文档要比不断地编写文档容易得多。通常情况下，敏捷团队会推迟编写文档，直到他们有时间这样做，实际上是向文档后期实践而不是这个实践迈进。

原文：http://agilemodeling.com/essays/documentContinuously.htm

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】