在日常辅导团队的过程中有一个问题是大家问的比较多，直观上理解有些困难，更别说实际的使用。“敏捷需要文档吗？”这个问题，在一个组织对于不同的角色，同一个角色但不同开发背景的人，答案都不一样。这篇文章想由浅入深的对敏捷开发需要的文档进行讨论。
简单的答案是“需要”。
敏捷开发和瀑布流程对文档的要求
我们知道敏捷开发和瀑布流程在开发周期时间上明显不同，一个是迭代开发，迭代周期（1～4周），一个是阶段-门限开发，周期（1～n月），在交付一个可运行的小功能上两种开发方式需要的时间明显不同。敏捷只需要几周，瀑布则需要按月来交付。这个周期时间的不同会导致在文档上花的时间的不同。
如上图我们说敏捷开发是轻文档，而瀑布是重文档式的流程。
重量级文档流程
先来说重量级文档，在瀑布流程下，我们被要求从商业分析，市场分析，产品需求收集，产品设计，开发分析，开发，UT，测试，集成测试，系统测试，到发布这些阶段，对应于商业需求文档（BRD）， 市场需求文档（MRD），产品需求文档（PRD），概要设计（HLS），详细设计（LLS），测试策略，测试计划，测试用例，测试报告，整个开发流程大概需要这些文档。Winston W. Royce(瀑布流程发明者，1970年发表）认为开发流程和制造业的流程相似，如果在每个阶段我们都做好充分的分析设计，那么整个项目最终是不会有很大偏差的。 到这里我们要回答两个问题：
- 这个理论正确吗？
- 1970发明的方法还适用于现在的市场环境，商业环境和研发技术吗？
这个理论正确吗？在不考虑任何成本的情况下，花更多的时间在每个阶段可以提升每个阶段的正确性。在后续任何阶段发现错误，都可以回到最初的阶段。比如在测试阶段发现前面有个功能的设计错误了，那么完全可以回到产品需求收集阶段进行修改，同时进行相应文档变更，PRD，HLS，LLS，测试用例变更。那么这个理论正确吗？在不考虑任何成本的情况下，这个理论可行。但如果考虑成本呢？
我们在一个产品或项目构建的早期，能想清楚所有要解决的用户问题，所有的功能，所有的技术依赖吗？ 经验说明根本不可能，不然变更控制委员会(CCB)设立来做什么？就是变更太多控制不住，需要一群人来控制。
我们的业务，领域知识是随着产品不断的开发过程中，不断学习获得的，如果前期在缺乏大量产品知识的时候，我们要进行大量的需求设计，这时期会产生大量的低质量需求，大量错误的假设导致后期的返工。
1970发明的方法还适用于现在的市场环境，商业环境和研发技术吗？
大家回想一下1970年代的产品与技术,那个时候以科研系统为主流，unix系统在那时诞生，使用汇编和C语言为主要编程语言。那个时候市场竞争并不激烈，计算机还没有用于个人。所以在70年代左右开发的系统复杂，昂贵，而且没有多少市场竞争，开发一套系统往往耗时几年。这个时候开发一套系统成本很高，周期很长，使用重文档的流程开发，产生的浪费，往往被高成本，长时间的交付掩盖住了。
到了现在个人市场，商业市场都有了长足的发展，交付周期被缩短到了几周，甚至于每天上线多次。重文档的流程弊端凸显，要么根本就无法完成这些文档，要么对文档进行大量的裁剪，要么文档落后代码几公里再也无法同步。在快速高效的开发流程里写出这些高质量的文档变得不可能，也不必要，因为这些文档从一开始价值就不高。重文档流程的组织在商业交付上越来越慢，最后深陷泥潭，被新型的独角兽企业一遍又一遍的冲击，最后不得不转型开发流程寻求突破。
敏捷开发中的文档
敏捷文化在90年代后期开始逐渐重塑了整个软件行业。以重视反馈，减少浪费，团队协作为核心，整个开发文档也遵循其核心价值。
那么在敏捷中我们怎么写文档，才能高效，高质量，低成本的完成我们的交付呢？
关于需求文档：
之前说到在前期业务人员，市场人员，产品经理会输出BRD，MRD，PRD，这些文档的目的和价值是什么呢？
这些文档的核心目的是帮助组织的业务目标和产品对齐，在敏捷里面不仅希望目标对齐，同时还希望最大化使用这些文档，通过这些文档实现以下目的：
- 业务目标和产品目标对齐
- 理解的一致性
- 文档和代码保持一致
- 自动化验收系统
这样可以最大化的提升文档的价值，文档用于业务人员，产品经理，开发人员，测试人员理解一致，文档和代码始终一致可以实时反应代码情况，同时文档又用于产品交付的自动化验收。
用户故事
敏捷里面提倡使用用户故事来描述需求，通过用户故事团队随时讨论，澄清需求，同时通过用户故事的验收标准（AC），帮助开发团队各角色明确需求的验收范围。 通过用户故事的INVEST原则，帮助我们提高交付效率，理解需求价值。
用户故事的INVEST原则
实例化需求
敏捷里面提出了实例化需求的一组模式，帮助达到上述的目标，在实例化需求里面提倡：
- 产品要从商业目标去得到需求的范围，要理解需求背后的"why"“who”，理解商业用户期望的结果是什么
- 需求是协作产生的，通过工作坊商业干系人，领域专家，开发团队一起完成需求的梳理和澄清
- 使用实例来描述需求，开发团队和商业用户一起识别系统的关键实例
- 精炼实例，实例需要呈现用户的需要，避免过多的实现细节
- 实例化需求实现自动化验收
前面几点还是比较容易理解，主要第5点很多产品经理觉得不可思议了，我写的需求还可以变为自动化验收测试系统？是的，现在有很多支持实例化需求的平台,如： Concordion,FitNesse.
Concordion实例化需求：
自动化验收框架：
这里不具体讲解实例化需求验收部分，这个以后专题讲解。
关于设计文档：
说了需求部分，那么开发设计部分呢？以前的HLS，LLS怎么更有价值，减少浪费呢？
敏捷里面认为：
- 代码的设计体现在代码自动化测试里面，这样代码的设计通过自动化测试代码实现，这时测试代码和实现代码保持一致，通过测试反应方法设计意图，反应功能设计的意图。
- 领域模型，领域的知识用领域模型反映，通过领域模型实现开发人员和领域专家理解一致性
- 通过富文本注释实现，代码不仅要自注释，而且通过图文并茂的富文本注释体现设计思路
关于测试文档：
在测试方面，提倡代码质量集体负责，测试人员并不是最后的守门员，而是作为测试专家，把测试方面的技能传递给开发人员，让开发人员对自己的功能充分测试，并完成自动化单元测试，自动化验收测试。最后测试文档变成了一个一个的自动化测试用例代码。
总结：
在如今要求高效率，高质量快速交付的环境下，敏捷的轻量级文档流程，并不是真的“轻”了，而是聚焦于消灭成本高，浪费高，价值低的文档，通过自动化的方式提升文档的价值。作为产品，开发，测试的人员更需要锻炼基本功，提升整个交付过程的效率和质量。