敏捷并不等于不要文档，而是强调刚刚够用的文档。测试报告的压力可以用自动化测试与探索性测试来分摊，需求文档则用用户故事做条目化管理，字数可能略多，但整理和书写速度会明显更快。
很多从传统项目转到敏捷团队的伙伴都会遇到同一个纠结：迭代节奏变快了，每个版本的需求和测试报告都要做，感觉文档量反而更大了。这个问题在敏捷落地初期非常典型，本质上是旧的文档习惯还没有换挡到敏捷的节奏。下面把测试报告与需求文档两条线拆开来看。
一、为什么敏捷会让人感觉文档变多了
传统项目的文档往往集中在启动和收尾阶段，一次写完；而敏捷是每个迭代都产出可交付的增量，于是需求条目、验收标准、测试记录会跟着迭代不断累积。感觉上文档变多，实际上是文档从一次性大块产出，变成了小步、多次的持续产出。
- 迭代越多，回归测试覆盖的累积范围越大，手工回归的量随之上升；
- 需求以用户故事为单位持续补充，条目数量自然增加；
- 但敏捷用用户故事这类直观表达，让想法能被快速写出来，单条编写速度更快。
二、测试报告怎么减负
基于覆盖率的传统测试策略很难在敏捷中长期支撑，因为每个迭代都会带来新内容，回归量会持续膨胀。可行的做法主要有两条：
- 自动化测试：让自动化用例与代码开发配套推进，把重复性回归交给机器，手工测试量就能明显下降；
- 探索性测试：用新的探索性测试策略替代一部分原有的手工回归，把人的时间投到更有价值的验证场景上。
三、需求文档怎么减负
需求文档的量确实需要交代清楚：就字数总量而言，敏捷不一定比传统方式少，甚至可能更多。但可以乐观地说，字数会多一些，写起来反而更快。敏捷采用用户故事这样的直观表达方式，能把脑海里想到的东西快速落到纸面。
核心工具就是用户故事与敏捷故事。通过故事把工作逐条包装和管理，它既能成为 WBS 的基石，又能直接承载项目管理的抓手——在传统项目里，WBS 和管理动作往往是两套东西，而在敏捷里这两者可以合二为一。
| 关注点 | 传统做法 | 敏捷做法 |
|---|---|---|
| 需求表达 | 大篇幅需求规格说明 | 用户故事 + 验收标准，条目化 |
| 测试策略 | 基于覆盖率的手工回归 | 自动化测试 + 探索性测试 |
| 文档节奏 | 阶段性集中产出 | 随迭代小步持续产出 |
| 管理与分解 | WBS 与项目管理动作分离 | 故事即抓手，WBS 与管理合二为一 |
敏捷文档与交付管理，可以系统学
艾威培训源于美国，2000 年进入中国，2003 年成为 PMI 全球注册教育机构（R.E.P. 编号 1887）。围绕 PMI 认证体系，艾威为敏捷教练、Scrum Master、产品负责人和研发项目经理提供 PMI-ACP 等敏捷方向的系统学习支持，课程覆盖敏捷思维、团队领导力、产品需求管理与增量交付等核心领域。英文主体 Avtech Technology Inc 可在美国 PMI Authorized Training Partner Directory 查询。
四、常见问题
敏捷文档与交付，学明白才做得轻松
如果你正被迭代文档、测试报告和需求条目压得喘不过气，系统掌握敏捷的思维与工具，往往比加班硬扛更有效。
艾威 PMI-ACP 课程：4 天 28 学时，覆盖敏捷思维、领导力、产品与交付四大领域。
