敏捷文档：平衡速度和知识保留

与其生成相关的各种文档、工件和过程是瀑布模型的一些主要符号。 借用精益，敏捷将大量文档视为需要根除的“浪费”，以简化开发生命周期。

对于许多项目经理来说，理解瀑布阶段如何转变为冲刺并不是一件容易的事——完成了同样的工作； 它只是以不同的方式组织。 然而，删除大多数文档是一种难以下咽的药丸，因为它强调了一种完全不同的工作方式。 它需要放松控制的缰绳，拥抱未知，并授权交付团队当场做出决定。

传统的文档记录方法正在受到挑战

在瀑布方法中，大量时间用于记录项目需求和详细说明解决方案。 当需求完全明确并且我们确信捕获和基线化的内容不会发生任何变化时，此过程才有效。 然而，大多数公司在过去几十年的经验表明，这几乎不是真的。 在当今世界，变化的速度如此之快，以至于当我们完成文档阶段时，客户的需求发生了很大变化。

敏捷的重点是完成工作并为利益相关者增加价值。 它的构建方式是，该模型不鼓励在外围设备和不会直接和立即为客户增加价值的活动上工作。

瀑布与敏捷中的文档

每家公司都有不同级别的文档，即使在项目级别上也可能有所不同。 但这是瀑布和敏捷项目中典型的文档程序的样子：

文档案例

Waterfall 提倡对文档采取更严格的方法，这似乎有些过分。 但在我们将其视为“浪费”之前，有几个好处是拥有强大的文档程序。

战略思维的机会

那些没有计划的人，计划失败。 文档迫使项目经理坐下来思考问题，然后提出最佳解决方案。 人们有时会误解工作软件相对于综合文档的敏捷价值意味着不需要文档。 然后他们冲向市场，对讲机产品副总裁 Paul Adams 将这一举动描述为向墙上扔东西，看看有什么东西能粘住。 设计解决方案、制定计划、考虑行动——这些活动通过节省时间来创造价值，而不是开发想到的每一个功能想法。

用户体验和功能一致性

随着公司从几个创始人发展到成百上千名员工，许多不同的团队开始研究相同或相关的产品。 团队 A 可能认为他们正在做的事情与团队 B 正在做的事情无关，但对于最终用户来说，它们都是同一个产品。 与跨职能团队做自己的事情不同，关于用户体验和功能级别的清晰文档可以避免脱节的用户流程。

文档可以转换为用户指南

在 Waterfall 中，大量时间用于详细说明解决方案以及如何使用它们。 为前端开发人员创建高保真设计图片。 与从头开始创建它们相比，所有这些资产转换为内部或外部用户指南所需的工作更少。

敏捷如何减少文档需求

反复出现作为强制文件的借口的一个因素是员工流动率。 当人们离开并有新人加入以取代他们时，经理们担心会失去机构知识。 他们如何知道已经实施了什么以及它是如何工作的？ 他们需要多长时间才能赶上？ 当前团队是否有足够的带宽来接待新的团队成员？

希望好的文档能让大部分独立工作的新员工快速上手。 然而，敏捷本质上通过协作技术减少了对文档的需求，同时减少了入职时间。 以下是敏捷减少文档需求的几种方法。

产品团队和敏捷团队成员之间的定期互动

敏捷宣言提倡“个人和互动优于流程和工具”。 由于需求在项目期间往往会发生变化并且会出现新的想法，因此敏捷确保直接从源头澄清需求，而不是依赖于需要不断更新的书面工件。

梳理和计划划分任务

待办事项梳理和冲刺计划将功能分解为易于理解且可以独立工作的具体、可实施的部分。 这为新员工创造了一个机会，让他们能够在早期提高工作效率，同时还没有完全了解整个项目的大局。

用户故事提供有效的文档

用户故事的简单格式允许项目经理捕捉最低限度的要求，从而在所有团队成员之间建立共同的理解。 即使用户故事没有进入 sprint，创建此文档工件的浪费也非常低。 随着用户故事进入 sprint，它们可以被充实并补充其他所需的信息，例如线框、设计、验收标准等。这个过程提供了非常有效的文档交付，它是高度一次性的，并且在最合适的开发阶段生成。

减少对代码文档的需求

结对编程和代码审查等技术为在整个团队中传播技术知识创造了持续的机会，尤其是向新的团队成员。 不断的反馈导致了共同的理解，这种理解也具有适应新环境的灵活性，而不是在某个地方的文档中很快变得过时。

敏捷仪式

每日站会、冲刺评审和回顾会创造大量机会来解决问题并面对面做出决策，而不是依赖电子邮件和文档。 所有仪式的有限时间范围确保只有最重要的信息被优先考虑，而不是花时间记录一切，即使它可能永远不会被使用。

以上所有直接或间接地减少了文档并优先考虑项目目标的交付，同时确保没有任何东西因缺乏文档而真正丢失。

文档的混合方法

一些公司仍然喜欢有一些文档，即使在敏捷环境中也是如此。 敏捷不是规定性的，因为每个项目都是不同的，并且有一组独特的情况需要解决。

下面是一些示例，说明如何将敏捷与更耗时的文档方法相结合。

结合 UML 和敏捷

考虑使用标准建模语言，例如统一建模语言 (UML)，这种语言非常结构化并定义了实体来可视化系统。 这有助于保持内容非常简单并专注于需要的内容，并确保最少使用书面语言。 StarUML 和 Draw.io 等工具都是方便的选择。

代码文档生成器

另一种方法是通过在类细节、方法细节、参数使用、依赖关系等中引入更多结构化和详细的注释来确保代码更具可读性。 有许多工具可以自动化从源代码生成有用文档的过程，它们被称为文档生成器。 它们的范围从通用到特定于编程语言的。

详细设计和用户体验文档

使用线框图、模型、用户流程图、序列图等定义需求有助于简化项目流程，并使技术团队清楚地了解需要开发的内容。 设计文档是拥有不同级别的更严格文档的好方法。 这些任务有多种线框图和 UX 工具可供选择。

项目管理工具 自动化文档

更强大的项目管理和相关工具（如 JIRA、Confluence、Asana 和 Basecamp）提供了一种将所有项目相关信息保存在一个地方的方法。 任务可以链接、标记、嵌套和分配给不同的团队成员，然后他们可以发表评论并报告任何问题。 所有这些操作，以及适应这些工具的灵活性，可以轻松创建大量文档。

此外，从历史上看，部分文档需求源于报告要求。 利益相关者希望获得团队绩效或其他相关指标。 项目管理工具可以轻松实现自定义仪表板和视图的自动化，这些仪表板和视图反映了项目进度并链接回工具内的相关文档。

文档管理是一种平衡行为

敏捷宣言的创建者写道，他们重视“工作软件胜过全面的文档”。 然而，他们还添加了一项免责声明，“虽然右边的项目有价值，但 [他们] 更重视左边的项目。” 敏捷并不建议删除所有文档，因为某些文档显然提供了价值； 它只是建议优先考虑工作软件，并根据项目情况仅在必要时添加文档，并且不会严重阻碍开发进度。

项目经理必须在花更少的时间在文档上和花更多的时间在交付工作软件和实际找出某种形式的文档对于长期成功所必需的地方之间取得平衡。