| 介绍一下我的朋友Jane和John。 John是一家大型公司的长期分析师，负责捕获新的软件产品及现有软件产品的需求。他用SRS（软件需求规格说明书）记录所有客户对正在开发或维护的特定产品的需求。 Jane是同一家公司的开发人员。她通常接收John的软件需求规格说明书（SRS），而后开始对要实现的内容进行技术分析和设计。完成分析之后，她就开始写代码实现。  我的这两个朋友John和Jane的需求文档和设计文档都需要经过审批；对于John来讲，把需求文档发给Jane之前需要经过审批，而对Jane来讲，则是在开始写代码之前要经过审批。 最近，John和Jane所在的公司采用了敏捷方法来作项目管理和软件研发，这使得他们的工作方式发生了改变。不需要制定大量的前期需求和设计，需求说明书和开发都被切成了小块的信息，摒弃了使用多年的大篇幅文档。开发人员的开发方式也发生了变化，鼓励像实现之前先做测试设计和用较长的名字来命名函数等这样的做法。 不出所料，John和Jane提出了一大堆的问题：
在过去十年中，敏捷方法在项目管理和软件开发中的应用经历了迅速发展的阶段，并预计将持续地增长。在向敏捷过渡的过程中，看似宽松的开发方式完全不同，做事不再那么传统，为此，世界各地的许多人都会和John、Jane一样抛出如上同样的问题。 当公司开始过渡到敏捷理念的过程中，一些工作方式的差异都与文档有关。 本文将重点讲述为什么、什么时候、如何以及在哪里编制技术和功能文档。 文档编制与敏捷理念敏捷宣言中宣称的价值观是： 个体和互动 高于 流程和工具 尽管提到了文档，但敏捷原则在如何编制文档方面并没有给出任何刚性的指导原则。 因此，在敏捷管理的项目中我们应该期待产出什么样的文档呢？ 敏捷理念背后的原则是，强调为客户实现价值。这就意味着我们应该把产品开发的时间花在能够为客户带来价值的那部分，避免在几乎没有什么价值的任务上浪费时间。该原则也同样适用于文档的编制。 在传统的瀑布方式中，文档是一个预定义的阶段，它需要花费大量的时间。过渡到敏捷则意味着我们必须重新思考编写文档的方式，以避免把时间浪费在价值具有争议的交付成果上。 这是否意味着我们不需要编制任何文档呢？其实不是这样的。 另一个敏捷原则是适应变化。那就意味着我们不能提前做太多的计划，因为事情在项目进行中会有所变化。所以，我们永远专注的是适时的计划。这一条也同样适用于文档。为了避免浪费时间，我们应该只在需要文档时才去编写它。 但是，我们如何知道它何时需要呢？ 真的需要文档吗？-为什么需要文档如果你来自瀑布的领域，那么很自然就会带过来定义大量文档的习惯，但这样会导致：
为了避免这个情况，有一些指导方针帮助我们决定是否真的需要编制文档。 为避免在文档上浪费时间，向每个相关的人问如下问题：
决定是否需要文档的一个关键因素是，只定义正好够用的文档。在干系人真正需要的和完整的内容之间寻找平衡点。不多不少，恰到好处。 何时，在哪，编制什么文档对为什么编制文档和编制多少文档达成共识之后，在开始编制之前还需要定义要编制什么样的文档。 什么样的文档根据文档的目标受众来编制相应的文档。教程？培训材料？维护支持文档？业务规则文档？还是系统描述文档？ 在项目的每一阶段规定需要什么样的技术文档和功能文档，从而来确定编制什么文档：
|
