一些应用开发人员和软件质量测试专业人士，认为敏捷软件文档实际上不存在，或者敏捷开发方法需要我们把注意力从文档上转移。这是真的吗？

　　最近，我与一个敏捷团队一起工作，创建一个高度监控的产品，此产品对验证和确认文档有严格的需求。他们打电话给我，问我，“我们怎么做？我们不打算在敏捷中做文档。”这是不切实际的！

　　问题不是是否建档的问题。有两个问题：对于你的项目来说，哪一个是最有的文档，以及什么时候是最佳时机不产生它。

　　文档有两种类型：流程和产品文档。“流程”描述了工作过程或在发现和交付过程中你使用的移交信息。对于分布式团队有不同领域的专家是最有价值的，或者当你需要验证的证据时。

　　“产品”文档对于产品的销售、服务和使用来说，都是高价值的财产。这里，通常越少越好。识别客户，关注他们的使用需求——验证分析、最终用户,、安装程序、帮助咨询的技术人员等等。探索用户的观点和需求，来定义最小效用和可用的文档。

　　我所提到的客户，他们构建实验的、救生医疗设备作为医院教学与研究的一部分，他们需要脚本，来使用样本进行验证学习，来测试产品概念本身。因为人们会现场执行样本，我们设计了一个精简的列表小册子，对功能进行了简要的介绍。这就足够了，且容易生产。团队也可以使用它来教导新的团队成员。

　　现在我们来看看时间设置。团队包括产品小组在内，都需要问一问，“在我们创建产品组成部分的同时，交付文档好吗，还是推迟一下在产品发布之前，建立一个更大的文档好呢？” 这是两个元模式。

　　考虑一下需求的波动。就如我们医疗设备客户，设备用在医院的病患身上，做为一种实验，所以规格就会常常变化。对每次迭代建档可能是浪费时间，因此在实现阶段，他们只在产品发布之前建档。

　　在其它情况下，当在需求已广为人知的时候，越早建档越有意义。你可以为产品块，定义部分验收标准——一个用例、功能、最小可市场化特征等等。

　　文档是为了方便知道的传递，因此，你希望所建的文档，能越来越接近你所创建产品的时间。而且文档尽量的小，但却足够服务于用户。