Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC IEEE 26515解决了现代软件工程中最具挑战性的问题之一:如何在需求快速演变、发布频繁且传统文档流程通常被视为过于缓慢和僵化的敏捷开发环境中开发高质量的用户文档。该标准提供了一个框架,用于调整用户文档开发以适应敏捷方法论,同时保持用户期望的质量、完整性和可用性。
标准引入了文档待办列表的概念作为关键的规划工件。类似于Scrum中的产品待办列表,文档待办列表包含所有已知的文档工作项:需要编写的新主题、需要更新的现有主题、可用性改进、翻译请求以及技术债务项(如过时的截图或不完整的参考章节)。每个待办项都经过工作量估算,并根据用户价值、风险以及与软件开发待办项的依赖关系进行优先级排序。
文档工作项被集成到敏捷迭代周期中。在Scrum中,文档任务包含在冲刺规划中,文档团队参与每日站会和冲刺评审。标准强调文档应与软件一起增量开发——而不是在开发完成后的独立瀑布阶段。这意味着功能文档应在开发该功能的同一冲刺中开始编写、审查和完善,或最多落后一个冲刺。这种方法确保文档在软件发布时已准备就绪,消除了文档在产品发布后数周或数月才交付的常见问题。
| 敏捷实践 | 文档适配 | 频率 |
|---|---|---|
| 冲刺规划 | 为冲刺选择文档待办项 | 每个冲刺 |
| 每日站会 | 文档团队报告进度和障碍 | 每日 |
| 冲刺评审 | 向利益相关者展示完成的文档 | 每个冲刺 |
| 冲刺回顾 | 反思文档流程改进 | 每个冲刺 |
| 待办项细化 | 估算和排序文档项 | 持续进行 |
| 持续集成 | 自动文档构建、链接检查、风格检查 | 每次提交 |
标准描述了将文档作者集成到敏捷团队中的几种协作模式。嵌入式作者模式将技术文档作者直接置于开发团队内,参与所有团队仪式,并能够立即接触开发人员、产品负责人和不断演变的产品。专家团队模式维持一个独立的文档团队,通过定义的接口和服务级别协议与多个开发团队交互。混合模式结合了两者的元素,一些作者嵌入关键团队,而中央文档团队处理跨领域的问题,如风格指南、内容管理基础设施和专门的文档类型。
无论采用何种协作模式,标准都强调作者参与关键敏捷事件的重要性。作者应参加冲刺评审以查看可工作的软件并提供文档视角,参与待办项细化以确保文档需求被捕获为用户故事,并贡献于回顾会议以识别改进文档过程的机会。标准还强调结对写作的价值——一种技术文档作者和主题专家(通常是开发人员或产品负责人)实时协作创建文档的技术,结合了写作技能和产品专业知识。
标准涉及支持敏捷文档所需的技术基础设施。持续文档实践将持续集成和持续交付的原则扩展到文档领域。这包括从源代码自动构建文档(编译主题、生成导航结构、产生输出格式)、自动质量检查(拼写、语法、风格指南符合性、链接有效性、可访问性检查)、自动部署到预发布和生产环境,以及与软件构建流水线集成,使得每次提交时文档都随软件一起构建和测试。
工具考量包括文档源文件的版本控制(使用与软件相同的仓库或紧密关联的仓库)、支持模块化创作和内容重用的内容管理系统、文档的自动测试框架,以及支持实时反馈和评审周期的协作平台。标准强调文档工具应支持软件开发团队使用的相同分支、合并和发布管理工作流,使文档能够与软件发布同步发布。