编制路线图.docVIP

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