瀑布（ Waterfall ）模型的一些关键符号是参考相关的论文，工件和过程。从Lean中汲取灵感，敏捷将许多文书工作视为“浪费”，并消除这些“浪费”以简化开发过程。
许多项目经理可以轻松理解瀑布阶段如何转换为冲刺阶段 – 完成相同的工作;只是以不同的方式呈现。另一方面，消除此类文档比较困难，因为它突出了一种完全不同的功能方法。它需要放弃控制权，接受不确定性，并使交付团队能够即时做出选择。
传统的文档存档方法正受到挑战
瀑布技术投入了大量的精力来定义项目要求和描述解决方案。当要求是完全明确的，并且我们确信任何内容都不会改变已记录和基线的内容时，此过程是有效的。然而，大多数公司在过去几十年的经验已经证明，情况几乎从来都不是这样。在当今的环境中，变化速度如此之快，以至于当我们完成文档阶段时，客户的需求已经发生了重大变化。
敏捷的重点是把事情做好，同时也为利益相关者提供价值。它的设计初心是为了避免在范围外工作和不直接为客户带来价值的活动。
瀑布式与敏捷文档
每个组织都有不同的文档，甚至可能因项目而异。以下是瀑布式和敏捷项目中常见文档实践的示例：
| 瀑布 | 敏捷 |
|---|---|
| 大多数情况下，需要文件。在文书工作完成之前，不会有任何进展。 | 只掌握足够的文档就可以开始工作。 |
| 文件经过彻底的审查程序，并且必须得到各方的授权。 | 没有正式的审查和批准程序，项目经理做出绝大多数决定。 |
| 必须使用标准化模板。 | 没有明确的文档模板;相反，采用最佳实践。 |
| 在各个阶段都需要各种论文，包括项目章程，愿景声明，业务需求文档，功能和非功能需求，高级设计（HLD）和低级设计（LLD）文档等。 | 只需要在下一个冲刺期间提供计划所需的文档。 |
| 文档更改很困难，因为所有论文都是相互关联的。 | 文档更改要简单得多。 |
| 需要一个系统或程序来管理大量文档。 | 由于文档很小，因此易于处理。 |
文档案例
瀑布式鼓励更严格的文档方法，这看似不必要。但是，在我们将其作为“浪费”丢弃之前，请考虑以下具有强大的文档实践的优点。
战略思维的可能性
那些没有计划的人可能会经历失败。文档迫使项目经理坐下来思考问题，以得出最佳答案。人们经常误解软件在大量文档之上的功能软件的敏捷价值，并认为文档是没必要的。然后，他们匆匆忙忙地进入市场，对讲机产品副总裁保罗·亚当斯（Paul Adams）将这一策略描述为“把东西摆放出来，后期再考虑是否备受人们喜爱”。设计解决方案、制定策略和考虑行动可以节省时间，并审查每个想到的功能想法，从而提供价值。
用户体验和功能一致性
当组织从几个创始人发展到数百或数千人时，许多不同的团队开始从事相同或相关的产品。A团队可能认为他们的工作与B团队的工作无关，但对于最终消费者来说，这都是相同的产品。拥有关于用户体验和功能级别的清晰文档，而不是跨职能团队各做各的，可以防止用户流失。
文档可以转换为用户指南
瀑布式花了很多时间解释解决方案以及如何使用它们。为前端开发人员提供高保真设计图像。与从一开始就创建这些材料相比，把这些材料转换为内部或外部用户手册所需的工作量更少。
敏捷如何减少对文档的需求
员工流动率是其中一个公司强制提供文档的原因。经理们担心，当员工离职并雇用新员工来取代他们时，机构知识会随着员工离去而消失。他们如何知道公司已经实施了哪些措施以及工作方式的？他们需要多长时间才能赶上？现在的团队是否有资源来指导新的团队成员？
强大的文档将迅速使主要独立工作的新员工跟上进度。但是，敏捷通过使用协作工具降低了对文档的需求，这些工具也减少了入职时间。以下是敏捷如何减少文档需求的一些示例。
产品团队和敏捷团队成员之间的定期互动
敏捷宣言将“个人和关系置于程序和技术之上”。由于需求在整个项目中不断变化，新想法不断涌现，因此敏捷可直接从源头提供证实，而不是依赖于需要定期更新的书面工件。
梳理和规划任务
积压工作梳理和冲刺计划将功能划分为清晰、可实现的组件，这些组件易于理解，并且可以单独处理。这使得新员工即使无法完全理解整个项目的整体情况下能够在早期提高工作效率。
用户故事有助于处理文档
简单结构的用户情景使项目经理能够把最低限度的需求记录下来，从而在所有团队成员之间达成共识。即使用户情景未包含在冲刺计划中，也不至于浪费这些文档。当用户故事经历冲刺时，内容会被填充，并用其他信息如线框图、设计、验收标准等进行扩充。这种技术可帮助产生非正式的文档，这些文档适合在开发阶段时准备。
不再需要代码文档
结对编程和代码审查等技术提供了在整个团队中传播技术知识的机会，特别是向新团队成员传播技术知识。持续的反馈可产生共识，这些共识也可以适应不断变化的条件，而不是被隐藏在某个地方的论文中。
敏捷仪式
每日会议，冲刺审查和回顾提供了解决问题和亲自做出决定的充分机会，而不是依赖于电子邮件和文书工作。由于所有仪式有一个有限期限，这保证了只有最关键的信息被优先考虑，而不是浪费时间记录所有不太可能需要的内容。
上述所有内容都降低了文书工作并分辨了项目目标的优先级，同时保证不会因缺少文档而真正丢失任何内容。
混合文档方法
即使在敏捷环境中，一些企业也希望保留一些文档。因为每个项目都是多样化的，并且有一定的处理方式，所以敏捷不是规范性的。
以下是如何将敏捷与耗时的文档方法一并使用的一些实例。
将 UML 和敏捷结合在一起
考虑采用标准建模语言来描述系统，例如统一建模语言（UML），它非常有条理并包含指定的实体。这有助于保持信息的基本性并专注于所需的内容，同时确保尽可能少地使用书面语言。像StarUML和 Draw.io 等工具非常有用。
代码文档生成器
另一种方法是使用详细信息、方法详细信息、参数用法、依赖项等中包含更有条理和描述性的注释，使代码更易于理解。有各种文档生成器的程序可以自动从源代码创建可用文档。它们从一般语言到编程语言都有所不同。
详细设计和用户体验文档
通过线框图、模型、用户流程图、序列图和其他可视化辅助工具定义需求可简化项目流程，并使技术团队清楚地了解必须构建的内容。为不同程度的文档提供详细说明是绝佳方法。对于这些工作，有几种线框图和UX工具可供选择。
文档由项目管理工具自动化
更高级的项目管理和相关技术（如 JIRA、Confluence、Asana和Basecamp）使您能够集中所有与项目相关的信息。可以连接、标记、存储任务并将其分配给各个团队成员，然后他们可以提供备注并报告任何问题。所有这些活动，以及改变这些工具的能力，都可以创造大量不费时的文档。
此外，传统上，因为有报告义务所以一定会有对部分文件的需求。利益相关方希望了解团队绩效或其他相关指标。使用项目管理软件，可以轻松实现自动化的自定义仪表板和可视化，这些仪表板和可视化可提供项目进度并连接到产品内部的相关材料。
文档管理需要精细的平衡
敏捷宣言的作者指出，“比起详细文档他们更喜欢功能软件”。然而，他们也指出，“尽管身边的东西是有价值的，但往往人们更看重别的物品。敏捷不主张删除所有文档，因为有些文档显然是有价值的;相反，它主张专注于功能软件，并根据项目条件添加重要文档，同时不会减慢开发进度。
项目经理必须使用更少的时间在文档上和使用更多的时间在交付功能软件之间取得平衡，并找出达到长期成功所需要的文档。
