敏思 Agile 文档
5.00/5 (3投票s)
关于在采用敏捷方法进行软件开发时，需要多少文档的持续讨论。
引言
敏捷宣言（发表于 2001 年）指出“可工作的软件胜过详尽的文档”。 自那时起，敏捷的核心原则一直是健康辩论的主题。 有理由质疑前期文档方法、所需文档数量以及交付的工件的价值。
敏捷宣言还指出，虽然右侧的项目（文档）具有价值，但我们更重视左侧的项目（可工作的软件）。 那么，文档的价值是什么，以及多少文档才足够？
讨论
答案与文档本身关系不大。 真正的问题是，为了有效地沟通功能和技术设计，需要向团队内部和外部的利益相关者提供多少信息。 这些利益相关者包括业务、基础设施、运维、安全、风险、架构、合规性和质量保证。
那么应该如何与这些利益相关者共享设计信息？ 生产代码是系统构建方式的最准确的体现。 对于开发人员来说，代码是现成的并且易于理解的。 然而，随着越来越多的团队加入，代码库的复杂性增加，遗留系统不断积累，目标受众从开发人员转向不太技术化的利益相关者，使用代码作为沟通工具会变得重复、缓慢，并且需要开发人员不断地“解释”代码与利益相关者之间的关系。 这种开销会占用开发人员的生产力并影响速度。
一个例子是
“最近，我需要了解现有的 B2B Web 集成是如何实现的，以便我们可以与新客户达成类似的协议。 没有文档，答案在于代码中，需要开发人员进行调查。 这需要将一个用户故事添加到积压工作中，将其优先安排到下一个 sprint 中，最终我几乎在两周后才获得了所需的信息。” – 预售解决方案架构师。
随着参与产品开发的团队数量和代码行数的增加，这种影响会加剧。 直接沟通的扩展变得越来越困难，因为添加了更多的利益相关者（请参阅这个主题的一个很好的视频）。
为了避免这种情况，需要一定程度的文档来弥合代码与利益相关者之间的差距。 简洁的基础功能和设计文档，描述应用程序现有的“如是”状态至关重要。 可以通过历史版本查看过去的状态，并通过战术积压驱动的基线过渡或战略路线图来更好地阐明未来的状态，这些路线图可以创建、修改或弃用服务或功能。
与其争论是否需要文档，不如将精力花在探索如何更有效地编写文档上。 产生更准确文档的工具和技术正在成熟。 值得关注的例子包括 Swagger、Gherkin、Mermaid 和 Plant UML。
需要考虑的组织因素
各种因素可能会影响您生成的文档级别，例如：
- 软件的复杂性
- 开发类型 - 您是构建一次性解决方案、产品还是平台
- 团队和利益相关者的地理分布
- 参与开发的团队数量
- 每个团队的人数
- 利益相关者的数量
链接
以下是 Code Project 上关于敏捷的一些文章
历史
- 版本 1.0 - 提交
- 版本 1.1 - 细微的格式更改