Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29110-4-3：非常小实体——敏捷扩展profile
系统和软件工程——面向VSE profile的敏捷扩展
将敏捷实践与VSE Profile框架集成
ISO/IEC 29110-4-3是标准VSE profile框架的敏捷扩展，明确将敏捷实践和工件映射到ISO/IEC 29110-5中定义的过程结果。该扩展是为了响应敏捷方法在小型软件组织中的广泛采用而开发的，旨在协调敏捷灵活性与过程成熟度要求。本标准并未将敏捷和过程标准视为矛盾的方法，而是展示了Scrum事件、看板、极限编程（XP）实践和其他敏捷技术如何满足传统计划驱动方法所解决的相同过程结果。
敏捷扩展并未创建独立的过程框架——它将敏捷实践映射到现有的VSE profile结果上。这意味着使用Scrum的VSE可以通过将Sprint规划映射到项目规划结果、Sprint评审映射到验证结果、已完成定义（Definition of Done）映射到质量保证结果来证明符合ISO/IEC 29110 Basic profile的要求。
该扩展涵盖三个profile级别：Entry（Profile 1）、Basic（Profile 2）和Intermediate（Profile 3）。对于每个profile，标准提供了一个敏捷映射表，将过程结果与特定的敏捷实践进行交叉引用。例如，在Entry profile级别，软件实施结果”开发并测试软件组件”映射到测试驱动开发（TDD）和持续集成实践。在Basic profile级别，配置管理结果与自动化构建流水线和版本控制工作流程保持一致。
| VSE过程结果 | 敏捷实践映射 | 敏捷工件 | 验证方法 |
|---|---|---|---|
| 建立项目计划 | Sprint规划、发布规划 | 产品Backlog、Sprint Backlog | Backlog细化会议、规划扑克结果 |
| 定义需求 | 用户故事、故事地图 | 用户故事库、验收标准 | 故事点估算、就绪定义 |
| 实施软件组件 | TDD、结对编程、持续集成 | 测试套件、CI流水线配置 | 构建状态、测试覆盖率报告、结对轮换日志 |
| 管理配置 | 分支策略、CI/CD流水线 | 版本控制仓库、部署脚本 | 拉取请求历史、自动部署记录 |
| 执行质量保证 | 已完成定义、Sprint评审、回顾 | DoD检查表、评审会议记录、行动项 | Sprint燃尽图、速度趋势、缺陷逃逸率 |
| 执行验证与确认 | 自动化测试、验收测试、演示 | 测试自动化框架、演示录制 | 通过/失败率、用户验收签字 |
工程洞察：采用敏捷扩展的VSE报告称，在相同profile级别内，新功能上市时间比传统计划驱动方法快40%。关键推动因素是文档前置时间的减少——验收标准和自动化测试报告等敏捷工件同时作为工程交付物和合规证据的双重用途。
实际实施策略
对于从临时开发过渡到采用敏捷实践的形式化profile的VSE，以下实施路线图在现场研究中被证明是有效的。首先，建立产品负责人（Product Owner）角色（映射到标准中的客户/利益相关者职责），并定义简单的就绪定义和已完成定义——仅这两个检查表就覆盖了Basic profile中几乎所有的质量保证结果。其次，实施两级规划结构：发布规划（每2-3个月）用于与组织目标保持战略一致，Sprint规划（每1-2周）用于运营层面的项目管理。
一个常见的误解：敏捷扩展并不意味着”无需文档”。标准仍然要求过程执行的证据。区别在于证据采用敏捷兼容的形式——一个维护良好的、包含验收标准的产品Backlog既充当需求规范又充当项目跟踪工件。风险在于将敏捷的非正式性视为完全跳过过程结果的许可证，这违背了采用标准的初衷。
该扩展还解决了随着VSE增长而扩展敏捷实践的具体挑战。一个5人团队可能使用带有共享看板和每日站会的简单看板方法，而一个有多个团队的20人VSE可能需要Scrum-of-Scrums、组合backlog管理和协调发布规划。Profile结构自然地适应这种扩展：Entry profile支持单团队看板/Scrum，Basic profile增加跨团队协调，Intermediate profile引入组织级过程指标和多团队回顾。
关键风险：在未对敏捷方法和ISO/IEC 29110框架进行充分培训的情况下采用敏捷扩展，经常导致”Scrum-but”场景——团队挑选敏捷仪式而未实现底层过程结果。在开始实施之前，必须对敏捷实践与VSE profile结果之间的映射进行强制培训。组织应为每个关键角色预算至少40小时的培训时间。
常见问题
问：VSE能否同时声称符合ISO/IEC 29110 Basic profile和Scrum？
答：可以。敏捷扩展正是为这种双重合规性而设计的。当团队正确运行Scrum仪式并维护映射表中列出的敏捷工件时，他们自然满足了Basic profile的过程结果。无需额外的文档超出敏捷团队自然产生的文档。
答：可以。敏捷扩展正是为这种双重合规性而设计的。当团队正确运行Scrum仪式并维护映射表中列出的敏捷工件时，他们自然满足了Basic profile的过程结果。无需额外的文档超出敏捷团队自然产生的文档。
问：敏捷扩展是否支持没有固定sprint的纯看板团队？
答：当然。该扩展在敏捷范围内是与方法无关的。看板团队将流指标（周期时间、在制品限制、累积流图）映射到测量和过程控制结果。关键在于证明过程结果已实现——节奏（基于sprint与基于流）是灵活的。
答：当然。该扩展在敏捷范围内是与方法无关的。看板团队将流指标（周期时间、在制品限制、累积流图）映射到测量和过程控制结果。关键在于证明过程结果已实现——节奏（基于sprint与基于流）是灵活的。
问：敏捷扩展如何处理分布式的VSE团队？
答：标准认可分布式团队是常见的VSE现实情况。敏捷扩展将分布式协作工具（例如数字看板、通过Slack/Teams进行的异步站会、通过VS Code Live Share进行的远程结对编程）映射到沟通和协调结果。关键要求仍然是这些实践产生可审计的证据。
答：标准认可分布式团队是常见的VSE现实情况。敏捷扩展将分布式协作工具（例如数字看板、通过Slack/Teams进行的异步站会、通过VS Code Live Share进行的远程结对编程）映射到沟通和协调结果。关键要求仍然是这些实践产生可审计的证据。
问：从无过程到使用敏捷扩展的Entry profile的推荐过渡路径是什么？
答：从仅三项实践开始：(1)可视化任务板（物理或数字），(2)每日15分钟站会，(3)简单的已完成定义检查表。运行4-6周直至成为习惯，然后增加Sprint规划和评审周期。这种渐进方法具有最高的持续采用成功率（超过80%）。
答：从仅三项实践开始：(1)可视化任务板（物理或数字），(2)每日15分钟站会，(3)简单的已完成定义检查表。运行4-6周直至成为习惯，然后增加Sprint规划和评审周期。这种渐进方法具有最高的持续采用成功率（超过80%）。
