规模化敏捷框架在ISO 26262标准下的应用
在ISO26262标准下，传统的敏捷方法在实际应用中往往面临一些挑战。由于ISO26262对功能安全有严格的流程和文档要求，普通敏捷的灵活性和轻量级特性有时难以满足这些需求。例如，“敏捷强调‘可用的软件胜过详尽的文档’”，但ISO26262要求详尽的危害分析、安全需求追溯和验证证据，这导致团队在敏捷迭代中难以保持合规性。此外，敏捷的自组织特性有时难以确保安全关键任务得到足够重视，会出现多个团队之间责任边界模糊、无法同步节奏、加大沟通成本的情况。
基于此，经过调研，可以借鉴规模化敏捷框架的思想进行满足ISO 26262的业务敏捷研发。下文以SAFe框架为例，讲述如何在规模化敏捷框架内进行研发。
SAFe概念阐述
SAFe（Scaled Agile framework，规模化敏捷框架）是一种用于大规模敏捷开发的实践框架，旨在帮助企业在团队、项目组合和整个组织层级协调敏捷实践。它整合了精益、敏捷和DevOps原则，通过定义角色、事件、工件和指导方针，支持多团队协作与价值交付。SAFe强调对齐、透明和持续改进，适用于复杂软件或系统开发场景。其最新版本（如6.0）注重业务敏捷性和数字化转型。
SAFe框架分为四个层级，Portfolio（投资组合）层负责战略规划和资金分配，确保企业投资与战略目标一致，主要活动包括制定战略主题、管理投资组合看板、协调史诗和解决方案。
Solution Train（解决方案火车）层专注于开发和交付大型复杂解决方案，通常涉及多个ART和供应商，主要活动包括协调解决方案意图、管理解决方案看板、组织解决方案演示和PI规划。
Agile Release Train（敏捷发布火车，ART）是由多个敏捷团队组成的长期跨职能团队，负责持续交付价值，主要活动包括PI规划、系统演示、检视和调整工作坊以及同步迭代执行。
Team（团队）层是SAFe的基本执行单元，通常由5-9名成员组成，负责迭代交付可工作的增量，主要活动包括迭代计划、每日站会、迭代评审和迭代回顾。
1►投资组合层Portfolio的战略规划
在SAFe框架中管理符合ISO26262标准的项目时，Portfolio层需要将ISO26262的功能安全要求融入战略规划和治理流程，确保整个组织的敏捷交付体系符合该标准的系统性安全要求。
1.1 功能安全战略与投资主题对齐
Portfolio层需定义与功能安全相关的投资主题（Investment Themes），确保资源分配支持ISO26262的合规目标。依据ISO26262-1:2018第5.4.2条：
" The organization shall create, foster, and sustain a safety culture that supports and encourages the effective achievement of functional safety."
Portfolio层塑造文化，并定下战略主题（Strategic Themes），通过价值流（Value Streams）和战略主题将功能安全目标分解到具体项目群（Programs）和团队（Teams）。
1.2 安全文化与管理承诺
SAFe强调高层管理对功能安全的支持。Portfolio层需建立精益-敏捷领导力，推动安全文化。ISO26262-2:2018第5.4.2.2：
The organization shall institute, execute and maintain organization-specific rules and processes to achieve and maintain functional safety and to comply with the requirements of the ISO 26262 series of standards.
SAFe的投资组合层通过精益预算（Lean Budgets）和治理看板（Portfolio Kanban）确保安全相关举措获得资金支持。
1.3 功能安全目标分解与合规性管理
Portfolio层需将ISO26262的功能安全需求（FSRs, Functional Safety Requirements）映射到SAFe的史诗（Epics）和使能项（Enablers）。
SAFe的投资组合看板（Portfolio Kanban）可用于跟踪安全相关史诗，确保其优先级符合ISO26262的安全完整性等级（ASIL）要求。
1.4 供应商与合规性治理
若Portfolio涉及外部供应商，需确保其符合ISO26262-8:2018第5条对分布式开发的要求：
"Responsibilities are agreed between the customer and the suppliers for the concept,
development, production, operation, service and decommissioning phases of the safety lifecycle."
SAFe的供应商协作实践可用于协调安全需求，并通过合规性看板（Compliance Kanban）跟踪供应商交付物的安全验证状态。
SAFe 可通过Lean Portfolio Management (LPM)与功能安全策略集成，在Portfolio Kanban中引入Enabler Epics用于实施功能安全能力。
SAFe通过价值流（Value Streams）和战略主题（Strategic Themes）将功能安全目标分解到具体项目群（Programs）和团队（Teams）。
2►在解决方案火车Solution Train进行系统级安全分析与技术协调
解决方案火车（Solution Train）作为规模化敏捷（SAFe）框架中最高层的协作单元，专注于复杂解决方案的端到端交付，其活动设计用于协调多个敏捷发布火车（ARTs）、供应商及客户，确保战略目标与执行的一致性。相比单一ART，Solution Train的活动更强调跨价值链的集成与治理，解决方案PI规划会将多个ARTs和供应商对齐到统一的增量目标，通过解决方案演示展示跨ART集成的成果，而解决方案系统团队则负责解决系统级架构与合规性问题。解决方案同步会议定期协调依赖关系和风险，解决方案检视与适应（I&A）工作坊则推动规模化改进。这些活动通过更高层级的透明性和同步节奏，确保大型解决方案在技术、业务和运营层面的整体协调，避免局部优化带来的碎片化风险。
2.1 系统级安全需求分解与分配
Solution Train需将ISO26262的技术安全需求和功能安全需求分解到各ART和子系统，确保可追溯性。
ISO26262-4:2018 第6.4.1.1条说：
"The technical safety requirements shall be specified in accordance with the functional safety concept and the system architectural design of the item."，
即规定了技术安全要求应依据功能安全概念及项目的系统架构设计进行规定。
Solution Train的解决方案意图（Solution Intent）需记录安全需求、ASIL等级分配及安全分析。通过模型基系统工程（MBSE）和需求可追溯性矩阵确保需求一致性。
2.2 安全生命周期与敏捷节奏对齐
Solution Train需将ISO26262的V模型活动嵌入敏捷开发节奏。
应按照ISO26262-2:2018 第6.4.6.6条要求定义安全活动。
在SAFe实践中，每8到12周完成一个系统增量迭代（Program increment，下称PI迭代），需对应ISO26262阶段评审，通过解决方案看板（Solution Kanban）跟踪安全关键任务。
2.3 Safety Case的持续演进
Solution Train需在每次PI迭代中更新安全案例，证明系统始终符合ASIL目标。
引用ISO26262-2:2018 第6.4.8.2：
"The safety case should progressively compile the work products that are generated during the safety lifecycle to support the safety argument."
SAFe的持续合规性实践可通过自动化工具生成Safety Case片段，并在解决方案团队的监督下整合。
在SAFe的Solution Train层管理ISO26262项目，核心是通过需求分解、跨ART协同、安全生命周期对齐、安全案例演进、供应商管理及故障验证，确保规模化敏捷开发不妥协于功能安全。SAFe的解决方案意图、PI节奏和持续合规性是核心实践，而ISO26262的ASIL等级、安全案例和V模型要求构成验证基准。
两者结合的关键是：在敏捷迭代中“内建安全”（Build Safety In），而非事后合规。
3►应用Agile Release Train (ART)进行持续
交付
ART是由多个团队组成的敏捷开发“列车”，围绕一个共同目标协同开发一个可交付解决方案。ART通过固定节奏的PI迭代规划、跨团队同步会议和系统演示等活动，将多个敏捷团队的工作整合为一个统一的交付节奏，确保所有团队朝着共同的业务目标前进。
在功能安全管理中，ART负责：
• 分解系统安全需求为软件或硬件安全需求；
• 管理ASIL等级对应的开发措施；
ART可在PI Planning期间将功能安全作为主题轨道（Theme）进行规划，同时通过使能特性（Enabler Features）引导验证测试（如ASIL C的MC/DC覆盖测试）及形式化建模等安全工作。使能特性是ART 待办列表中帮助项目进行完善的特性。
在SAFe框架的ART层管理符合ISO26262标准的项目时，需要将功能安全要求无缝集成到敏捷交付流程中，确保每个PI迭代的增量都能满足ASIL等级要求。以下是关键工作内容：
3.1 安全需求分解与团队待办列表管理
ART需将Solution Train下发的技术安全需求（TSRs）拆分为团队级可执行任务，并纳入团队待办列表。
SAFe的项目群待办列表（Program Backlog）需标记ASIL等级，并通过需求分解将其转化为用户故事。
3.2 安全关键任务的迭代规划与执行
ART在PI规划和迭代中需优先处理安全关键任务，确保其不受其他需求变更影响。
ART的迭代计划会议需为安全任务预留专用容量并使用使能项（Enablers）跟踪技术债务。
3.3 持续安全测试与验证
ART需在每次迭代中执行符合ISO26262-6:2018 第9条的测试活动。
可以利用SAFe的持续集成（CI）流水线集成安全测试，以便管理内建质量。
3.4 安全评审与审计
ART需在PI系统演示中展示安全需求实现情况，并接受独立评审。
SAFe的质量门禁需包含ISO26262检查项并由系统团队在PI边界前完成验证。
3.5 变更管理与安全影响分析
在敏捷发布火车（ART）中进行变更管理，相比普通敏捷团队，能够更好地平衡规模化交付的稳定性和敏捷响应能力。普通敏捷团队的变更通常由产品负责人和开发团队直接决定，灵活性高但影响范围有限，容易因跨团队依赖不足而导致协调问题。而ART通过结构化的流程，确保变更在规模化环境中得到系统化评估和优先级排序。紧急变更可以通过快速通道处理，但需经过ART层面的影响分析，避免单团队决策引发的连锁风险。
ART进行变更时，需要通过PI进行跨团队的对齐。需在需求变更时执行ISO26262-2:2018 第6.4.9.1(b)条要求的分析：
“a functional safety audit to judge the implementation of the processes required for functional safety”
在ISO 26262功能安全标准的约束下，敏捷发布火车（ART）需要通过结构化的安全生命周期管理，将敏捷实践与汽车安全合规性要求深度融合。ART需在保持敏捷迭代交付的同时，建立符合功能安全等级ASIL的流程框架，包括在PI规划阶段明确安全需求与验证目标，确保从架构设计到代码实现的系统化追溯。跨功能团队需协同安全专家开展危害分析（HARA）和安全概念设计，并将输出拆解为可迭代开发的安全用户故事，同时通过持续集成环境嵌入自动化安全测试（如静态分析、故障注入）。每个增量交付必须通过安全评审门禁，这种模式既保留了敏捷快速响应需求变化的优势，又通过嵌入式安全活动和自动化工具链，确保功能安全合规性不被敏捷交付节奏稀释。
4►组织Agile Team进行具体执行
Agile team是SAFe的执行层，通常由5~11人组成，负责开发具体功能或组件，采用Scrum或Kanban开展迭代。
在SAFe框架的Team层实施符合ISO26262标准的开发时，需将功能安全要求落地到日常开发实践中，确保代码级实现满足ASIL等级目标。
在功能安全中，团队要：
• 实施符合ASIL等级的设计规范；
• 编写可追溯的用户故事，并标明其安全关键性；
• 执行静态/动态分析与回归测试，形成Safety Case一部分。
SAFe团队可采用SAFe for Teams + TDD + BDD等实践模式，同时用Backlog item的标签进行分类管理。
4.1 安全需求的迭代实现与验证
团队需将ART分解的软件安全需求（SSRs）转化为可执行的用户故事和任务。
实践要点：
• 在迭代计划会议中将安全需求标记为高优先级
• 依据验收准则，编写安全测试用例
• 按照代码规范进行开发
4.2 团队需遵循编码规范要求：
实践要点：
• 在持续集成（CI）流水线中集成静态分析等工具，实时检测违反代码规范的代码
• 对ASIL C/D代码实施结对编程或代码评审
• 单元测试与故障注入测试
4.3安全相关工件的版本控制
团队需按ISO26262-8:2018 第7章的要求管理配置项。
实践要点：
• 在Git中为安全关键代码打标签
• 通过制品仓库存储经过安全验证的二进制文件
4.4 每日安全同步与障碍解决
团队需在每日站会中优先处理安全障碍
4.5 迭代评审与安全演示
团队应依据ISO26262-6:2018 第10条规定在迭代评审会议中需展示安全需求。
实践要点：
• 演示安全机制的实际运行（如故障注入后的优雅降级）
• 提供测试覆盖率报告作为安全案例输入
Team层实施ISO26262的关键是：
1. 需求双向可追溯：通过ATDD将安全需求链接至测试用例
2. 质量内建：在CI流水线中强制实施静态分析/单元测试
3. 安全文化：每日站会优先处理安全障碍
SAFe框架不仅适用于规模化敏捷开发，同样能有效支持ISO 26262标准下的安全关键系统研发。其分层治理结构和内置合规机制使其成为汽车功能安全开发的理想选择。
SAFe通过Portfolio层确保安全战略与业务目标一致，管理安全预算和史诗级需求；Solution Train协调跨团队安全关键系统开发，保证系统级安全需求完整实现；ART（敏捷发布火车）借助PI规划实现长期安全目标，支持V模型开发流程。
5►总结
该框架可完整管理安全需求、设计决策和验证证据，满足ISO 26262的严格可追溯性要求。同时，PI规划和系统演示等机制确保变更受控，使能项（Enablers）则专门用于管理安全技术债务。
SAFe强调的"内置质量"理念将安全文档作为正式交付物，通过持续集成/持续部署（CI/CD）结合自动化安全测试，在保持敏捷灵活性的同时满足功能安全标准要求。这种结构化敏捷方法使SAFe既能适应快速迭代，又能确保安全关键系统的可靠性和合规性。
需要注意的是，在实施SAFe的过程中，并不需要照搬整套框架，而是可以在保留其主要思想的情况下进行裁剪。只要保证在实施过程中关键过程得到保留：
敏捷发布火车：跨职能团队组成的长期协作单元，以固定节奏（PI周期）交付价值。
PI规划：每8-12周的全ART对齐会议，制定可执行的目标和计划。
迭代：固定时长（通常2周）的开发周期，包含计划、执行、评审和回顾。
团队级敏捷实践：Scrum或Kanban，每日站会、迭代评审和回顾会。
举一个实践中的典型例子：
合规要求进行设计评审并记录和解决所有行动项。"设计评审"作为一个使能者待办事项（Enabler backlog item）提供了评审的客观证据，其完成的定义（DoD）确保行动项被记录和解决。如果需要，行动项本身可以作为"使能者用户故事"（Enabler Stories）进行跟踪。法规还可能要求审查所有变更，这通过为所有用户故事（Stories）设置"同行评审"的DoD要求来实现。
SAFe频繁构建并演示集成解决方案，至少以迭代系统演示的频率进行。频繁构建和集成使得用户验收测试、客户和最终用户能够持续验证。每个迭代期间，系统演示提供客观证据，证明集成功能按预期运行，整个系统在满足质量和合规要求的前提下持续演进。
每个PI迭代除了完成研发工作外，还要预留时间用于集成和评估上个PI的成果，并收集指标以支持PI的检视与调整（I&A）研讨会。I&A是定期进行反思、收集数据、解决问题并采取行动的固定机制，包含三个部分：PI系统演示、用于审查指标和趋势的定量测量，以及回顾与问题解决研讨会。
PI系统演示包含合规工作成果，可能包括：为更好支持自动化测试和合规而进行的基础设施建设、重要评审或审计的结果与反馈，以及里程碑合规事件（如飞行测试）的结果。定性测量通过数据趋势展示产品认证和发布的进展，合规指标可能包括：需求覆盖率、测试代码覆盖率和同行评审结果的当前状态。SAFe还提供若干相关质量指标——缺陷数量、测试总量、自动化测试百分比等。
以精益-敏捷思维评估每个增量期间的指标。毕竟目标不仅是满足每个增量的合规要求，更要理解项目如何朝着整体合规目标推进，并识别需要关注的问题领域。从这个角度看，这些指标的趋势数据通常比单个PI边界点的数据更具参考价值。
最后，回顾与问题解决研讨会涵盖合规活动中的关注点：项目是否充分满足合规目标？指标趋势是否表明解决方案能达到认证所需的里程碑？确保合规的政策或程序是否阻碍了开发流程？通过这些问题的探讨，团队可以制定潜在改进方案，在下一个PI中探索优化合规实践。
通过上述元素，不同团队间实现对齐和可持续交付，解决了合规团队和研发测试团队或者多个研发团队之间无法有效对齐的问题。
vavo zhu| 作者
胡冲 | 审核
来源：sasetech
作者：vavo zhu
