敏捷开发与文档：互补还是互斥？

如果敏捷是反文档的，为什么会发布一个宣言？

• 个人和交互高于过程和工具
• 工作软件胜过全面的文档
• 客户协作高于合同谈判
• 响应变化而不是遵循计划

即便如此，业内对敏捷开发方法的误解和困惑仍然存在。“over”被“instead of”所取代，原本《敏捷宣言》的意图是“最好把更多的注意力放在软件上，而不是把时间花在过于详细的前期文档上”，现在似乎变成了“让我们完全抛弃文档，并希望我们记住讨论的所有事情。”

一、敏捷神话：“文档并不重要”

二、投资敏捷文档的原因

• 项目的利益相关者需要它。从根本上来说，创建文档是一个业务决策，团队将利益相关者的资源投入到文档开发中，因此他们应该对是否以这种方式花费他们的钱有发言权。
• 支持与外部团队的沟通。开发团队总是位于同一地点是不可能的，并且让利益相关者随时待命也是不可行的。共享文档通常是与偶尔的面对面讨论、电话会议、电子邮件和协作工具相结合的解决方案的一部分。
• 也不可能总是让项目涉众随时待命。共享文档通常与偶尔的面对面讨论、电话会议、电子邮件和协作工具结合在一起，是解决方案的一部分。
• 支持组织记忆。敏捷建模的原则之一是“实现下一个努力是你的次要目标”，这意味着与“工作软件是你的首要目标”的原则相平衡。这意味着，团队在开发软件时，还需要开发使用、操作、支持和维护软件所需的支持文档。
• 把事情想清楚。把想法写在纸上的行为可以帮助自己巩固它们，并发现自己思维方式中的问题。那些在脑海中看起来清晰而直接的东西，往往会被证明是非常复杂的，所以可以先把它写下来。

三、如何在敏捷中编写文档

1.敏捷文档的4条原则

• 敏捷中的文档是“可变的”，需要整个团队协同维护。为了充分利用我们在文档上投入的时间，我们可以遵循一些简单的原则：
• 确保它总是“刚刚好”。请记住，创建的任何文档都必须在之后进行维护。如果文档简单、不复杂、不太详细，就更容易理解和更新。
• 用“just in time”来写。在记录之前先耐心等待——这是避免积累错误和过时信息的最好方法。在需要的时候再生成文档，而不是在需要之前生成。
• 将文档放在一个容易获取的地方。文档只有在可访问的情况下才有用，将产品文档存储在团队成员可以轻松找到的地方。
• 与团队合作。在敏捷团队中维护文档是一个协作过程，应该鼓励每个团队成员对此做出贡献。

2.何时记录

3.记录什么

• 敏捷文档中可能用到的文档示例包括案例研究、图表、表格和站点地图。以下是在项目过程中会考虑创建的一些文档：
• 产品愿景：它是对产品核心的描述，是对当前的成本估算、预期收益、风险、人员配备估算和计划里程碑的总结。这一文档的要求是：保持简短，直切要点。
• 项目概述：这是与项目相关的关键信息的总结，例如主要用户联系方式、技术和用于构建系统的工具等。将其作为团队新成员的起点，并在整个开发过程中对其进行维护。
• 设计决策：这是团队在整个项目中做出的与设计和架构相关的关键决策的概述。
• 操作文档：这通常是对系统所涉及的依赖项的描述，以及对备份过程的参考、故障排除指南等。运营部门可能会有此类文档的标准格式。
• 需求文档：它是对系统功能的概述，包括用例、用户故事或基本用户界面原型等。旨在将需求捕获为可执行规范。
• 支持文档：这包括专门为支持人员提供的培训材料、故障排除指南等。与运营部门一样，支持团队可能有标准模板或示例来使用。
• 系统文档：提供系统的概述，包括技术体系结构、业务体系结构和其他高级需求。系统文档有助于确保关键信息的留存。
• 用户文档：它包括用户参考手册和支持指南。这一文档的要求是保持简单、易懂。如果需要采用大量的培训来教会用户如何使用该产品，那么解决方案文档的设计就是有缺陷的。

四、结论