文章目录1. Scrum 官方核心 Artifacts必须有2. 常见辅助文档Supporting Documents大多数 Scrum 团队都会有项目启动与整体层面需求与设计层面轻量迭代测试与质量层面过程与会议文档轻量记录发布与维护层面其他常用实际最佳实践国外 Scrum 团队常见做法在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和适应AdaptationProduct 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 BacklogSprint 待办列表当前 Sprint迭代选中的 Product Backlog Items 实现这些项的具体任务计划。团队在 Sprint PlanningSprint 计划会议中共同创建每天在 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 DocumentationSwagger / OpenAPI自动生成最好。UI/UX Mockups / WireframesFigma、Sketch 等工具链接到故事中。测试与质量层面Test Cases / Acceptance Tests通常作为 User Story 的 Acceptance Criteria 的一部分或放在测试工具TestRail、Jira Xray中。Definition of Done (DoD)如上所述。过程与会议文档轻量记录Sprint GoalSprint 目标每个 Sprint 开头定义的一句话目标。Retrospective Notes回顾会议记录What went well / What didn’t / Action items放在 Confluence 或团队 Wiki。Meeting NotesSprint 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/PDFJira或 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 中几乎没有厚重的SRSSoftware Requirements Specification或SDDSystem Design Document取而代之的是细粒度的 User Stories 设计决策记录。文档量远少于 Waterfall但沟通和协作更多会议 工具透明。如果你是小型团队10人可能只需要Product Backlog Sprint Backlog DoD Release Notes 简单 Wiki就够了。如果是中大型团队或企业项目会增加 Roadmap、ADR、架构图、用户手册等。建议从Product Vision Product Backlog DoD开始逐步补充其他。团队一起在 Retrospective 中讨论“哪些文档对我们有价值哪些是浪费”持续优化。