在 Agile/Scrum 项目中，文档理念遵循 敏捷宣言：“ Working software over comprehensive documentation”（可工作的软件胜过全面的文档）。因此，文档强调 轻量（lightweight）、迭代更新（living documents）、足够就好（just enough），而不是像传统瀑布模型那样一次性写出巨型规格书。

Scrum 官方（Scrum Guide）只要求 3 个核心 Artifacts（工件），这些是必须维护的“文档”形式。其余文档都是 supporting documentation（辅助文档），根据团队规模、项目复杂度、合规要求（如金融/医疗项目）或客户需求灵活决定。国外成熟 Scrum 团队常用 Jira（管理 Backlog 和任务）+ Confluence / Notion / GitHub Wiki（写详细文档）+ Markdown（代码仓库内）组合。

1. Scrum 官方核心 Artifacts（必须有）

这些是 Scrum 框架明确要求的，提供透明度（Transparency）、检查（Inspection）和适应（Adaptation）：

• Product Backlog（产品待办列表）
  整个产品所有功能的有序列表（通常在 Jira 中维护）。包含 Epics（史诗）、User Stories（用户故事）、Bugs（缺陷）、Technical Debt（技术债） 等。
  由 Product Owner（产品负责人）负责维护和优先级排序。
  每个 User Story 典型格式：
  As a [用户角色]，I want [功能] so that [业务价值]
  后面附带 Acceptance Criteria（验收标准）（常用 Gherkin 格式：Given-When-Then）。

• Sprint Backlog（Sprint 待办列表）
  当前 Sprint（迭代）选中的 Product Backlog Items + 实现这些项的具体任务计划。
  团队在 Sprint Planning（Sprint 计划会议）中共同创建，每天在 Daily Scrum 中更新。

• Increment（增量） + Definition of Done (DoD, 定义完成)
  每个 Sprint 结束时交付的可工作、可潜在发布的产品增量。
  DoD 是一个共享的检查清单（例如：代码写完、单元测试通过、代码审查通过、集成测试通过、文档更新、部署到 staging 等）。它不是单独文档，但常作为 Confluence 页面或团队 Wiki 维护，确保每个 Increment 都满足质量标准。

2. 常见辅助文档（Supporting Documents，大多数 Scrum 团队都会有）

这些不是 Scrum 强制要求，但实际项目中非常实用，按项目阶段/用途分类：

项目启动与整体层面

• Product Vision（产品愿景）：一句话或短段描述产品最终目标和为什么要做（常放在 Confluence 项目首页）。
• Product Roadmap（产品路线图）：中长期规划（3-6-12 个月），展示主要 Epic 和发布计划。常用工具：Jira Advanced Roadmaps、Aha!、Productboard 或 Confluence。
• Project Charter / Team Charter（项目/团队章程）：团队角色分工、沟通规则、工具栈、Definition of Done 等（轻量版，一页纸即可）。

需求与设计层面（轻量迭代）

• User Stories + Acceptance Criteria（已在 Product Backlog 中）。
• Epic Documentation：大型功能的故事地图（Story Map）或简单说明。
• Technical Specification / Design Docs（技术规格/设计文档）：只在需要时写，例如复杂架构决策。用 ADR (Architecture Decision Records) 格式记录“为什么选择这个方案”（非常推荐，轻量且实用）。
• API Documentation：Swagger / OpenAPI（自动生成最好）。
• UI/UX Mockups / Wireframes：Figma、Sketch 等工具链接到故事中。

测试与质量层面

• Test Cases / Acceptance Tests：通常作为 User Story 的 Acceptance Criteria 的一部分，或放在测试工具（TestRail、Jira Xray）中。
• Definition of Done (DoD)：如上所述。

过程与会议文档（轻量记录）

• Sprint Goal（Sprint 目标）：每个 Sprint 开头定义的一句话目标。
• Retrospective Notes（回顾会议记录）：What went well / What didn’t / Action items（放在 Confluence 或团队 Wiki）。
• Meeting Notes：Sprint Planning、Review、Daily Scrum 的关键决策（不需要每次都写长文档，关键点即可）。
• Burndown / Burnup Chart、Velocity Report（燃尽图、速度报告）：Jira 自动生成，不需要手动文档。

发布与维护层面

• Release Notes / Changelog（发布说明）：每次发布时更新，列出新功能、修复、已知问题（可从 Jira 自动生成）。
• User Documentation / Help Docs（用户手册）：针对最终用户的操作指南、FAQ（常放在 Notion、ReadTheDocs 或产品内帮助系统）。
• Deployment / Runbook（部署手册 / 运维手册）：CI/CD 流程、配置说明、故障排除（尤其对运维团队重要）。
• Architecture / System Overview（架构概览）：高层架构图（C4 Model 等），保持更新。

其他常用

• Risk Register / Impediment Log（风险/障碍日志）：在 Jira 中作为单独 Issue 类型或 Confluence 页面。
• Lessons Learned（经验教训）：项目或大版本结束时总结。
• Team Wiki / Handbook（团队知识库）：编码规范、开发环境搭建、Onboarding（新人引导）等。

实际最佳实践（国外 Scrum 团队常见做法）

• 核心在工具而非 Word/PDF：

  • Jira（或 Azure DevOps、ClickUp）：管理所有 Backlog、Stories、Tasks、Reports。
  • Confluence / Notion：写详细说明、决策、架构图、Retros。
  • GitHub / GitLab Wiki + README：代码层面文档。
  • 自动生成：API docs、Changelog、测试报告尽量自动化，减少手动维护。

• 文档原则：

  • Just Enough：只写当前需要的，避免未来可能用不上的内容。
  • Living Documents：随时更新，随故事或 Sprint 一起维护。
  • 可追溯：User Story 链接到设计、测试、代码（Jira + Confluence 链接很方便）。
  • 面向受众：开发者看技术细节，用户看操作手册，利益相关者看 Roadmap。
  • 大型/合规项目会额外增加 Security Docs、Compliance Docs、Data Privacy 等。

• 与传统项目的区别：

  • Scrum 中几乎没有厚重的 SRS（Software Requirements Specification） 或 SDD（System Design Document），取而代之的是细粒度的 User Stories + 设计决策记录。
  • 文档量远少于 Waterfall，但沟通和协作更多（会议 + 工具透明）。

如果你是小型团队（<10人），可能只需要 Product Backlog + Sprint Backlog + DoD + Release Notes + 简单 Wiki 就够了。
如果是中大型团队或企业项目，会增加 Roadmap、ADR、架构图、用户手册等。

建议：
从 Product Vision + Product Backlog + DoD 开始，逐步补充其他。团队一起在 Retrospective 中讨论“哪些文档对我们有价值，哪些是浪费”，持续优化。