在ISO26262标准下传统的敏捷方法在实际应用中往往面临一些挑战。由于ISO26262对功能安全有严格的流程和文档要求普通敏捷的灵活性和轻量级特性有时难以满足这些需求。例如“敏捷强调‘可用的软件胜过详尽的文档’”但ISO26262要求详尽的危害分析、安全需求追溯和验证证据这导致团队在敏捷迭代中难以保持合规性。此外敏捷的自组织特性有时难以确保安全关键任务得到足够重视会出现多个团队之间责任边界模糊、无法同步节奏、加大沟通成本的情况。基于此经过调研可以借鉴规模化敏捷框架的思想进行满足ISO 26262的业务敏捷研发。下文以SAFe框架为例讲述如何在规模化敏捷框架内进行研发。SAFe概念阐述在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.2The 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、供应商及客户确保战略目标与执行的一致性。相比单一ARTSolution Train的活动更强调跨价值链的集成与治理解决方案PI规划会将多个ARTs和供应商对齐到统一的增量目标通过解决方案演示展示跨ART集成的成果而解决方案系统团队则负责解决系统级架构与合规性问题。解决方案同步会议定期协调依赖关系和风险解决方案检视与适应IA工作坊则推动规模化改进。这些活动通过更高层级的透明性和同步节奏确保大型解决方案在技术、业务和运营层面的整体协调避免局部优化带来的碎片化风险。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.2The 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的检视与调整IA研讨会。IA是定期进行反思、收集数据、解决问题并采取行动的固定机制包含三个部分PI系统演示、用于审查指标和趋势的定量测量以及回顾与问题解决研讨会。PI系统演示包含合规工作成果可能包括为更好支持自动化测试和合规而进行的基础设施建设、重要评审或审计的结果与反馈以及里程碑合规事件如飞行测试的结果。定性测量通过数据趋势展示产品认证和发布的进展合规指标可能包括需求覆盖率、测试代码覆盖率和同行评审结果的当前状态。SAFe还提供若干相关质量指标——缺陷数量、测试总量、自动化测试百分比等。以精益-敏捷思维评估每个增量期间的指标。毕竟目标不仅是满足每个增量的合规要求更要理解项目如何朝着整体合规目标推进并识别需要关注的问题领域。从这个角度看这些指标的趋势数据通常比单个PI边界点的数据更具参考价值。最后回顾与问题解决研讨会涵盖合规活动中的关注点项目是否充分满足合规目标指标趋势是否表明解决方案能达到认证所需的里程碑确保合规的政策或程序是否阻碍了开发流程通过这些问题的探讨团队可以制定潜在改进方案在下一个PI中探索优化合规实践。通过上述元素不同团队间实现对齐和可持续交付解决了合规团队和研发测试团队或者多个研发团队之间无法有效对齐的问题。vavo zhu| 作者胡冲 | 审核一个人想不如一群人聊填写表单进 SASETECH 技术社群和作者、和同行直接对话吧
