不是。敏捷不要求每个迭代额外产出文档，迭代产出物只与蕞终可交付成果相关；软件开发场景以可运行的软件为主，文档不会因此增加，整理的工作量通常反而更少。
很多团队在转向敏捷时都会担心：短迭代意味着频繁交付，是不是每一轮都要写一堆文档？这其实是把敏捷的"迭代交付"与"文档产出"混为一谈了。敏捷调整的是交付节奏与协作方式，并不要求增加文档。下面从产出物定义、文档工作量和工具选择三个角度，说清楚敏捷到底要不要写文档。
一、敏捷迭代到底要不要产出文档？
敏捷要求的是每个迭代产出与蕞终成果相关的可用产物，而不是一份固定的文档清单。
- 如果是软件开发项目，迭代真正需要的产物是可运行的软件，而不是成套的纸面文档；
- 如果是非软件项目，迭代产物就等同于你原本工作要交付的成果，敏捷不要求额外的产物；
- 敏捷只要求你在每个迭代把原本要做的产物做出来，因此不会因为采用敏捷而增加任何文档。
换句话说，文档整理的工作量不会更大，往往只会更少。
二、为什么敏捷不要求"额外的文档"？
早期极限编程（XP）实践对文档存在过误解，一度被简单理解成"不要文档"。随着实践成熟，业界形成了更清晰的做法：需要保留的不是厚重的文档形式，而是能被团队持续复用、自动沉淀的信息。
敏捷强调可交付价值与快速反馈，因此文档的作用被重新定位为：
- 支撑团队沟通与知识共享，而不是留档应付检查；
- 随迭代持续更新，而不是一次性写完就锁死；
- 优先服务当前迭代的交付，而不是追求篇幅完整。
三、不同项目类型，迭代产物怎么对应？
| 项目类型 | 迭代核心产物 | 文档工作量 |
|---|---|---|
| 软件开发 | 可运行的软件、可交付增量 | 不额外增加，通常更少 |
| 产品 / 需求类 | 用户故事、待办事项、验收标准 | 按原本产出即可 |
| 非软件类项目 | 与原有工作一致的交付成果 | 不额外增加 |
四、用对协同工具，文档整理反而更省力
要让文档"自然沉淀"而不成为负担，关键在于使用支持在线协作与版本控制的工具。如今规模化敏捷组织普遍采用 Wiki 类协同平台，例如 Confluence、SharePoint、Azure DevOps 等内嵌的文档工具，让成员随时编辑、自动积累、自动版本控制。
相比之下，单机版的 Word、PowerPoint、Excel 在协作效率上明显偏低，文档容易散落、版本混乱。越来越多实施规模化敏捷的组织，正在把文档工作迁移到线上多人协同工具，让文档整理更高效、更易追溯。
不过，想让敏捷真正落到团队协作中，光有工具还不够，系统的敏捷方法论学习同样重要。
艾威的 PMI-ACP 课程，帮你把敏捷思维学透
艾威培训源于美国，2000 年进入中国，2003 年成为 PMI 全球注册教育机构（R.E.P. 编号 1887），长期深耕 PMI 项目管理与敏捷人才培养。PMI-ACP 课程基于官方《敏捷实践指南》，覆盖思维、领导力、产品、交付四大考核领域，并系统讲解 Scrum、看板、精益、极限编程（XP）、测试驱动开发（TDD）等多种敏捷实践。
课程结合真实敏捷场景，帮助学员理解"每个迭代要什么产物、怎么协作、如何持续交付价值"，而不只是背知识点。
五、关于敏捷文档的常见问题
把敏捷思维用到你的团队里
从"要不要写文档"到"如何持续交付价值"，敏捷的核心是让团队更快、更稳地交付可用成果。
先做一次敏捷学习路径评估，看看 PMI-ACP 是否适合你。
