自2001年敏捷宣言发布以来，关于敏捷开发的核心原则一直是业界讨论的热点。其中，关于前期文档化方法的价值、所需文档的数量以及交付的工件等问题，一直存在着健康而有益的辩论。敏捷宣言指出，尽管文档（右侧）有其价值，但更重视的是工作软件（左侧）。那么，文档的价值何在，又需要多少文档才足够呢？
这个问题的答案实际上与文档本身关系不大。真正的问题在于，为了有效地沟通功能和技术设计，需要向团队内外的利益相关者提供多少信息。这些利益相关者包括业务、基础设施、运营、安全、风险、架构、合规和质量保证等。
那么，应该如何与这些利益相关者共享设计信息呢？生产代码是系统构建方式的最准确表示。对于开发者来说，代码是现成的，易于理解。然而，随着团队数量的增加，代码库的复杂性增加，遗留问题累积，目标受众从开发者转变为技术性较低的利益相关者，使用代码作为沟通工具变得重复、缓慢，并且需要开发者不断地在代码和利益相关者之间“解释”。这种开销占用了开发者的生产力，并影响了开发速度。
例如，一位售前解决方案架构师提到：“最近需要了解一个现有的B2B网络集成是如何实现的，以便能与新客户达成一致。没有文档，答案藏在代码中，需要开发者去调查。这需要在待办事项列表中添加一个用户故事，将其优先安排到下一个冲刺中，最后几乎在两周后得到了所需的信息。”
随着产品开发团队数量和代码行数的增加，这种效应会加剧。随着更多利益相关者的加入，直接沟通的难度越来越大（可以观看有关此主题的）。
为了避免这种情况，需要一定程度的文档来弥合代码和利益相关者之间的差距。简洁的基线功能和设计文档，描述应用程序的现有状态是关键。可以通过历史版本回顾过去的状态，通过战术待办事项列表驱动的过渡到基线，或者通过战略路线图来更好地表达未来的状态，这些路线图可以创建、修改或弃用服务或功能。
与其争论是否需要文档，不如将精力投入到如何更有效地进行文档化上。生产更准确文档的工具和技术正在成熟。值得一看的例子包括Swagger、Gherkin、Mermaid和Plant UML。
组织因素的考虑：
可能会影响产生的文档水平的各种因素，例如：