敏捷开发过程需要文档工作吗？

通过确立一个共同的目标，保持流畅的沟通，从而同步思想，这一点对于敏捷开发团队来说十分重要，它是成功和效率的根本保证。但是可能开发团队的成员分属不同部门，甚至分布在世界各地，由于地域、时区或文化背景的差异，使得面对面进行交流的这种沟通方式变得困难。并且很多时候我们需要用文字材料来记录沟通结果（例如交换的意见信息或者详细计划信息等），所以无论当面交流，或者远程电话，完全摒弃文本的听说式交流方式难以满足敏捷开发的沟通需求。

敏捷开发过程的文档资料可以用于：对团队讨论结束的事项 / 决议 / 代办工作进行总结和提醒；对于产品设计和架构 / 功能点的多少与范畴进行规范；记录测试用例，测试的架构，测试的范围等测试信息；提交客户所要求的文档，和用户手册等。如果没有借助文档的帮助，想要完成这些任务，将会非常困难。

所以即使在敏捷开发中，我们强调产品产出，也并不意味着完全放弃在文档工作中的投入。投入的多少是量的问题，是否投入就是质的问题，就如同我们强调团队合作并不意味着我们放弃独立工作，所以我们应在明确质的前提下，把握好量。不得不说，传统开发文档带来的好处我们有目共睹，所以我们应该继承传统，开拓创新，设计适合敏捷开发自身特点的文档工作解决方案。

综上所述，敏捷开发过程中仍然需要文档工作，只是与传统开发文档工作相比，我们需要有自己的特点。

敏捷开发过程的文档工作有哪些特点？

在传统开发过程中，人们通过交付各种文档来获得价值。但实际上这样做的结果仅仅是撰写了产品的附加件而已，对于产品本身的交付没有太大的帮助。如果我们结合文档工作的成本因素来综合考评，就会发现这些文档的性价比很低。它们形式严格，内容丰富，但是显得过于臃肿，将来会被束之高阁。

对比传统开发过程，敏捷开发要体现敏捷性。开发过程不再通过交付各种文档来获得价值，价值的获得在于产品的交付。因此文档工作的核心目的从获得价值，转变为协助沟通，于是我们的文档不再需要大型的导航，不再需要冗余的内容，而只需包含我们需要的信息即可。同时站在客户的角度上考虑，假设他们花了 10 万元购买一款软件，当我们告诉他们其中有 3 万元花在文档工作上，我相信他们会很难接受。客户们更情愿通过削减文档工作的成本，使更多的资源节省出来，投入在产品交付过程中。

所有的这些转变使得敏捷开发文档，具有了新的特点：形式简洁，内容突出，低成本。

为了做到降低文档工作的成本，我们可以从两点下功夫：一方面改变文档自身内容形式，另一方面转变文档管理方式。

改变文档内容形式：轻量级文档。
为了节省成本，我们不再事先编写大量的相关文档去记录随时变化的信息，取而代之的做法是缩减文档数量，只生产一些必要的文档资料，并且我们精简这些文档内容。一段注释 , 一张流程图 , 一张照片等，与那些将来束之高阁做足表面功夫的文档相比，这种形式更加简练，内容更加突出的轻量级文档，更适合敏捷开发过程。

转变文档管理方式：轻量级生成
能否有一种方式，使我们只做少量的操作，而将大量的文档的管理工作交给计算机去做，从而节省人力资本？答案是肯定的，轻量级生成文档，就是一个不错的解决方案。这一方案将会在下一段落进行详细描述。

轻量级生成文档

轻量级文档，轻量级生成，即是通过优化文档的更新方式，使文档更新工作变得智能化、自动化。这种解决方案的目标就是把文档的组织和更新工作交给软件系统，从而降低人工成本，节省资源。如何实现呢 ?

请考虑这样一个情形。假设我们现在需要一组测试用例文档，那么很可能我们得到的文档差别很大，有的内容详细，有的内容简略，有的字体大，有的字体小，有的使用文字，有的使用图表，有的有页眉页脚，有的有大型导航。我们真正关注的是文档的内容，可是如此风格迥异的文档会为有效信息的提取造成困难。如何解决这个问题？

通过研究我们发现，文档之间存在一定的相似性，譬如一些文档来源于相同的数据源，文档内容的组织方式固定不变，文档的格式确定等等。于是我们提出一个想法，对于具有相似性的文档，不妨通过一个模板来统一生成。该模板规定了以下内容：从哪些数据源中取数据，从数据中提取哪些内容，这些内容如何排版，生成怎样格式的文档。通过模板的使用，可以圈定文档内容的范围，文档内容的层次，以及文档的风格，避免了内容的丢失及格式的混乱，并且通过这种方案我们能实现生成文档自动化。所需要做的，是抽象出文档的共性来构造一系列模板，然后通过模板的套用来生成文档，类似于活字印刷术。一次构造，多次使用，从而使文档更新流程化，便捷化，达到轻量级的效果。

请想象这样一个场景 : 一个项目开发会议将在十分钟后举行，在会议上大家会对开发进度，测试程度及客户满意度

问题进行相关讨论，因此我们需要为会议准备不同类型的文档，目前这些文档的相关资料存储在不同数据库的不同表中，还未经过整理，目标是十分钟之内把所有文档准备好，供与会人员参考，有办法完成这一艰巨的任务吗？答案是肯定的，使用 RPE 工具来进行基于模板的轻量级生成

借助 RPE 完成轻量级生成

Rational Publishing Engine（RPE）是基于这一文档策略的优秀文档生成工具，它适用于不同的数据源，能生成不同格式的文档，能把信息从数据格式中剥离出来，并为它们赋予新的数据格式，并且不受使用环境、数据源、以及数据生成格式等因素的制约，不需要安装 Microsoft Word 或其他任何第三方软件就可完成文档生成工作在文档生成过程中不会影响原始数据。

它由四部分组成：Document Studio 用于模板设计，Tool Integrations 用于 RPE 与其他软件的整合， Launcher 用于管理文档的生成，Web Service 提供 RPE 的 web 服务 , 从而用于减少客户端负载。

RPE 的结构如下图所示：

图 1. RPE 结构图

DocumentTemplate 定义了输入数据的结构，输出文档的内容结构以及输入输出之间的联系。

DocumentSpecification 负责 DocumentTemplate 与数据源的结合，定义了输出文档的格式。

RPE 的工作流：

首先 InputDrivers 模块从不同数据源中提取数据，然后数据进入 Core 模块，该模块通过调用 Document Specification 模块，将数据与模板进行匹配，通过模板抽取出数据且组织好输出格式后，Core 模块调用 OutputDrivers 模块，将文档输出。下面通过一个实例来演示 RPE 轻量级生成文档的过程。

RPE 使用实例

在这里我们使用 RPE 从 DOORS 中提取信息来生成轻量级文档。

图 2. 数据源、模板、结果图。

图 3. 数据源

图 4. 结果

生成文档的过程分两步，第一步使用 Document Studio 建模，第二步使用 Launcher 生成文档。

在 Document Studio 中建模。

Document Studio 工作区如下所示：

图 5. Document Studio 工作区

通过对模板部分的编辑，我们能规定从数据源中提取哪些数据，以及这些数据用怎样的形式来表现。在此我们为文档加入总标题，通过表格的形式来呈现数据。

图 6. 模板内容编辑区

除此之外我们还能通过模板的母版页面为文档配置页眉页脚等信息，如图。

图 7. 模板母版编辑区

模板编辑完成，保存即可。

使用 Launcher 来管理文档生成。

使用 Launcher 来配置文档需要三步：选择模板、配置文档输出格式以及选择数据源地址。

图 8. Launcher 配置图

保存 Launcher 中的文档配置信息，执行文档生成。

接下来 RPE 会通过模板自动从数据源抽取数据然后加以组织编排，生成文档。文档可以打开并且保存至本地，下图显示的是执行结果及其中 PDF 文档的内容：

图 9. 执行结果图

至此，建模及文档生成过程结束。如果以后想更新此类文档，只需使用 Launcher 打开文档配置信息，点击文档生成按钮，即可以"一键式"生成新的文档。

除此之外，RPE 还具有许多其他功能，例如一篇文档可以从多个数据源中提取数据，一篇文档可以使用多个模板来组织。

想要了解更多关于 RPE 的建模方法，请参考：

RPE Template Library

RPE 的另一个特性是它可以与 DOORS, RQM,RTC,RequisitePro,Rhapsody 等产品进行整合。使得 RPE 可以应用于敏捷开发周期的各个环节。

想要了解 RPE 与其他产品整合的相关信息，请参考：

IBM Publishing Engine 信息中心

总结

综上所述，在敏捷开发过程中，对于文档工作，我们需要一种与传统方式不同的解决方案。由此我们提出轻量级文档，轻量级生成这一主题。其中文档的轻量级生成工作可以借助 RPE 来完成。它的优势在于实时性（能即时抽取数据），自动化（数据组织自动化），快速（文档生成无需人工参与）以及易于维护（只需维护模板），它不仅能"一键式"生成文档，同时能和其他产品整合。这种做法克服了传统文档生成方式的不足，减少了文档工作的人工开销，提升了文档的精确性（数据无误）、规范性（格式严格）以及敏捷性（模板复用），更加适合敏捷开发过程的需要。