3.6 文档与变更
正如Martin对那种什么文档也不写就自称为敏捷的善意批评，敏捷过程对文档的态度只是一种思想的转变，而非重型的过程控制要求。敏捷方法需要两种类型的文档，它们分别是需求文档和设计文档，而其它所有类型的文档都是选择性的。对于需求文档，在敏捷方法中，往往会在某次迭代之中进行。它经常先于其他开发过程，但也要到开发过程的迭代开始的时候才在内容上达到完整。对于暂时不做的开发，就不会做细部特征的定义，以免浪费。撰写文档，其实是一件颇耗精力的事情，所以选择做什么样的文档需要有一种“投资回报”的考虑。
传统的大量正式文档，规格严整而厚重，但在项目的中后期却往往不能保持同步（现状、文档之间以及与软件系统），难以维护和跟踪，生产和维护成本也很高。这些文档除表明需求本身外，更多地是一种管理控制的角色，比如，对于变更。
敏捷过程并不是由文档主导、支撑和控制变更。如《敏捷宣言》中所透露的“响应变化胜过遵循计划” ，对于变更，敏捷过程是一个态度的转变。变更除过软件工程组织或者PMI等定义大部分类似于由“工作缺陷”引起的以外，在现代信息化竞争时代，它往往意味着商机。当然，对于这种商机的“欢迎”，企业需要商务模式的准备，否则将极易陷入“需求黑洞”之中。
3.7 敏捷需求分析小结
综合以上的陈述，对敏捷需求分析归纳如下表（角色职责的变化也是一种重要的对比，请参见表1，此处不赘言）：
| 角度 | 传统需求分析 | 敏捷需求分析 |
| 需求分析时机 | 更多地集中在项目早期 | 近乎均匀地贯穿于项目的整个生命周期 |
| 需求划分单位 | 基于功能分解，划分模块或子系统，一个模块或子系统的颗粒度通常较大 | 基于能否独立业务价值，切割成一个个用户故事，一个故事有时会跨越传统的模块或子系统边界；用户故事是小粒度的，可测试的，可见的，并且是有价值 |
| 需求细化过程 | 一步到位，可供开发人员设计开发 | 逐步细化，仅就下一个迭代需要实现的部分进行详细分析 |
| 需求文档要求 | 正式文档，往往有明确的格式要求。既作为设计开发人员必须严格遵守的规约，也作为向客户提交的必备产出物之一。难维护，难验证（跟踪），很多产出物最终难以被阅读。 | 非正式文档。仅仅是辅助开发团队与客户沟通，不作为规约，也不作为必备产出物。更多强调通过自动化功能测试用例来跟踪系统需求。（对于组织过程资产管理要求，可以在此基础上形成可阅读可理解的轻型文档）。 |
| 需求文档同步 | 项目中后期一般都处于不同步状态 | 即时的同步 |
| 需求传递过程 | 单向的陈述与记录，文档传导（线性的传递，误导放大，缓慢） | 聚议，共同参与，业务场景与用户故事，及时的非正式沟通 |
| 应对需求变更 | 有严格的控制流程，视变更为风险 | 视变更为必然或预期中的事情 |
表2：敏捷需求分析的特征对比
