規(guī)模化敏捷框架在ISO 26262標(biāo)準(zhǔn)下的應(yīng)用

在ISO26262標(biāo)準(zhǔn)下，傳統(tǒng)的敏捷方法在實(shí)際應(yīng)用中往往面臨一些挑戰(zhàn)。由于ISO26262對(duì)功能安全有嚴(yán)格的流程和文檔要求，普通敏捷的靈活性和輕量級(jí)特性有時(shí)難以滿足這些需求。例如，“敏捷強(qiáng)調(diào)‘可用的軟件勝過詳盡的文檔’”，但I(xiàn)SO26262要求詳盡的危害分析、安全需求追溯和驗(yàn)證證據(jù)，這導(dǎo)致團(tuán)隊(duì)在敏捷迭代中難以保持合規(guī)性。此外，敏捷的自組織特性有時(shí)難以確保安全關(guān)鍵任務(wù)得到足夠重視，會(huì)出現(xiàn)多個(gè)團(tuán)隊(duì)之間責(zé)任邊界模糊、無法同步節(jié)奏、加大溝通成本的情況。

基于此，經(jīng)過調(diào)研，可以借鑒規(guī)?；艚菘蚣艿乃枷脒M(jìn)行滿足ISO 26262的業(yè)務(wù)敏捷研發(fā)。下文以SAFe框架為例，講述如何在規(guī)?；艚菘蚣軆?nèi)進(jìn)行研發(fā)。

SAFe概念闡述

SAFe（Scaled Agile framework，規(guī)模化敏捷框架）是一種用于大規(guī)模敏捷開發(fā)的實(shí)踐框架，旨在幫助企業(yè)在團(tuán)隊(duì)、項(xiàng)目組合和整個(gè)組織層級(jí)協(xié)調(diào)敏捷實(shí)踐。它整合了精益、敏捷和DevOps原則，通過定義角色、事件、工件和指導(dǎo)方針，支持多團(tuán)隊(duì)協(xié)作與價(jià)值交付。SAFe強(qiáng)調(diào)對(duì)齊、透明和持續(xù)改進(jìn)，適用于復(fù)雜軟件或系統(tǒng)開發(fā)場(chǎng)景。其最新版本（如6.0）注重業(yè)務(wù)敏捷性和數(shù)字化轉(zhuǎn)型。

SAFe框架分為四個(gè)層級(jí)，Portfolio（投資組合）層負(fù)責(zé)戰(zhàn)略規(guī)劃和資金分配，確保企業(yè)投資與戰(zhàn)略目標(biāo)一致，主要活動(dòng)包括制定戰(zhàn)略主題、管理投資組合看板、協(xié)調(diào)史詩(shī)和解決方案。

Solution Train（解決方案火車）層專注于開發(fā)和交付大型復(fù)雜解決方案，通常涉及多個(gè)ART和供應(yīng)商，主要活動(dòng)包括協(xié)調(diào)解決方案意圖、管理解決方案看板、組織解決方案演示和PI規(guī)劃。

Agile Release Train（敏捷發(fā)布火車，ART）是由多個(gè)敏捷團(tuán)隊(duì)組成的長(zhǎng)期跨職能團(tuán)隊(duì)，負(fù)責(zé)持續(xù)交付價(jià)值，主要活動(dòng)包括PI規(guī)劃、系統(tǒng)演示、檢視和調(diào)整工作坊以及同步迭代執(zhí)行。

Team（團(tuán)隊(duì)）層是SAFe的基本執(zhí)行單元，通常由5-9名成員組成，負(fù)責(zé)迭代交付可工作的增量，主要活動(dòng)包括迭代計(jì)劃、每日站會(huì)、迭代評(píng)審和迭代回顧。

1?投資組合層Portfolio的戰(zhàn)略規(guī)劃

在SAFe框架中管理符合ISO26262標(biāo)準(zhǔn)的項(xiàng)目時(shí)，Portfolio層需要將ISO26262的功能安全要求融入戰(zhàn)略規(guī)劃和治理流程，確保整個(gè)組織的敏捷交付體系符合該標(biāo)準(zhǔn)的系統(tǒng)性安全要求。

1.1 功能安全戰(zhàn)略與投資主題對(duì)齊

Portfolio層需定義與功能安全相關(guān)的投資主題（Investment Themes），確保資源分配支持ISO26262的合規(guī)目標(biāo)。依據(jù)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層塑造文化，并定下戰(zhàn)略主題（Strategic Themes），通過價(jià)值流（Value Streams）和戰(zhàn)略主題將功能安全目標(biāo)分解到具體項(xiàng)目群（Programs）和團(tuán)隊(duì)（Teams）。

1.2 安全文化與管理承諾

SAFe強(qiáng)調(diào)高層管理對(duì)功能安全的支持。Portfolio層需建立精益-敏捷領(lǐng)導(dǎo)力，推動(dòng)安全文化。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的投資組合層通過精益預(yù)算（Lean Budgets）和治理看板（Portfolio Kanban）確保安全相關(guān)舉措獲得資金支持。

1.3 功能安全目標(biāo)分解與合規(guī)性管理

Portfolio層需將ISO26262的功能安全需求（FSRs, Functional Safety Requirements）映射到SAFe的史詩(shī)（Epics）和使能項(xiàng)（Enablers）。

SAFe的投資組合看板（Portfolio Kanban）可用于跟蹤安全相關(guān)史詩(shī)，確保其優(yōu)先級(jí)符合ISO26262的安全完整性等級(jí)（ASIL）要求。

1.4 供應(yīng)商與合規(guī)性治理

若Portfolio涉及外部供應(yīng)商，需確保其符合ISO26262-8:2018第5條對(duì)分布式開發(fā)的要求：

"Responsibilities are agreed between the customer and the suppliers for the concept,

development, production, operation, service and decommissioning phases of the safety lifecycle."

SAFe的供應(yīng)商協(xié)作實(shí)踐可用于協(xié)調(diào)安全需求，并通過合規(guī)性看板（Compliance Kanban）跟蹤供應(yīng)商交付物的安全驗(yàn)證狀態(tài)。

SAFe 可通過Lean Portfolio Management (LPM)與功能安全策略集成，在Portfolio Kanban中引入Enabler Epics用于實(shí)施功能安全能力。

SAFe通過價(jià)值流（Value Streams）和戰(zhàn)略主題（Strategic Themes）將功能安全目標(biāo)分解到具體項(xiàng)目群（Programs）和團(tuán)隊(duì)（Teams）。

2?在解決方案火車Solution Train進(jìn)行系統(tǒng)級(jí)安全分析與技術(shù)協(xié)調(diào)

解決方案火車（Solution Train）作為規(guī)模化敏捷（SAFe）框架中最高層的協(xié)作單元，專注于復(fù)雜解決方案的端到端交付，其活動(dòng)設(shè)計(jì)用于協(xié)調(diào)多個(gè)敏捷發(fā)布火車（ARTs）、供應(yīng)商及客戶，確保戰(zhàn)略目標(biāo)與執(zhí)行的一致性。相比單一ART，Solution Train的活動(dòng)更強(qiáng)調(diào)跨價(jià)值鏈的集成與治理，解決方案PI規(guī)劃會(huì)將多個(gè)ARTs和供應(yīng)商對(duì)齊到統(tǒng)一的增量目標(biāo)，通過解決方案演示展示跨ART集成的成果，而解決方案系統(tǒng)團(tuán)隊(duì)則負(fù)責(zé)解決系統(tǒng)級(jí)架構(gòu)與合規(guī)性問題。解決方案同步會(huì)議定期協(xié)調(diào)依賴關(guān)系和風(fēng)險(xiǎn)，解決方案檢視與適應(yīng)（I&A）工作坊則推動(dòng)規(guī)模化改進(jìn)。這些活動(dòng)通過更高層級(jí)的透明性和同步節(jié)奏，確保大型解決方案在技術(shù)、業(yè)務(wù)和運(yùn)營(yíng)層面的整體協(xié)調(diào)，避免局部?jī)?yōu)化帶來的碎片化風(fēng)險(xiǎn)。

2.1 系統(tǒng)級(jí)安全需求分解與分配

Solution Train需將ISO26262的技術(shù)安全需求和功能安全需求分解到各ART和子系統(tǒng)，確?？勺匪菪浴?/span>

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."，

即規(guī)定了技術(shù)安全要求應(yīng)依據(jù)功能安全概念及項(xiàng)目的系統(tǒng)架構(gòu)設(shè)計(jì)進(jìn)行規(guī)定。

Solution Train的解決方案意圖（Solution Intent）需記錄安全需求、ASIL等級(jí)分配及安全分析。通過模型基系統(tǒng)工程（MBSE）和需求可追溯性矩陣確保需求一致性。

2.2 安全生命周期與敏捷節(jié)奏對(duì)齊

Solution Train需將ISO26262的V模型活動(dòng)嵌入敏捷開發(fā)節(jié)奏。

應(yīng)按照ISO26262-2:2018 第6.4.6.6條要求定義安全活動(dòng)。

在SAFe實(shí)踐中，每8到12周完成一個(gè)系統(tǒng)增量迭代（Program increment，下稱PI迭代），需對(duì)應(yīng)ISO26262階段評(píng)審，通過解決方案看板（Solution Kanban）跟蹤安全關(guān)鍵任務(wù)。

2.3 Safety Case的持續(xù)演進(jìn)

Solution Train需在每次PI迭代中更新安全案例，證明系統(tǒng)始終符合ASIL目標(biāo)。

引用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的持續(xù)合規(guī)性實(shí)踐可通過自動(dòng)化工具生成Safety Case片段，并在解決方案團(tuán)隊(duì)的監(jiān)督下整合。

在SAFe的Solution Train層管理ISO26262項(xiàng)目，核心是通過需求分解、跨ART協(xié)同、安全生命周期對(duì)齊、安全案例演進(jìn)、供應(yīng)商管理及故障驗(yàn)證，確保規(guī)?；艚蓍_發(fā)不妥協(xié)于功能安全。SAFe的解決方案意圖、PI節(jié)奏和持續(xù)合規(guī)性是核心實(shí)踐，而ISO26262的ASIL等級(jí)、安全案例和V模型要求構(gòu)成驗(yàn)證基準(zhǔn)。

兩者結(jié)合的關(guān)鍵是：在敏捷迭代中“內(nèi)建安全”（Build Safety In），而非事后合規(guī)。

3?應(yīng)用Agile Release Train (ART)進(jìn)行持續(xù)

交付

ART是由多個(gè)團(tuán)隊(duì)組成的敏捷開發(fā)“列車”，圍繞一個(gè)共同目標(biāo)協(xié)同開發(fā)一個(gè)可交付解決方案。ART通過固定節(jié)奏的PI迭代規(guī)劃、跨團(tuán)隊(duì)同步會(huì)議和系統(tǒng)演示等活動(dòng)，將多個(gè)敏捷團(tuán)隊(duì)的工作整合為一個(gè)統(tǒng)一的交付節(jié)奏，確保所有團(tuán)隊(duì)朝著共同的業(yè)務(wù)目標(biāo)前進(jìn)。

在功能安全管理中，ART負(fù)責(zé)：

? 分解系統(tǒng)安全需求為軟件或硬件安全需求；

? 管理ASIL等級(jí)對(duì)應(yīng)的開發(fā)措施；

ART可在PI Planning期間將功能安全作為主題軌道（Theme）進(jìn)行規(guī)劃，同時(shí)通過使能特性（Enabler Features）引導(dǎo)驗(yàn)證測(cè)試（如ASIL C的MC/DC覆蓋測(cè)試）及形式化建模等安全工作。使能特性是ART 待辦列表中幫助項(xiàng)目進(jìn)行完善的特性。

在SAFe框架的ART層管理符合ISO26262標(biāo)準(zhǔn)的項(xiàng)目時(shí)，需要將功能安全要求無縫集成到敏捷交付流程中，確保每個(gè)PI迭代的增量都能滿足ASIL等級(jí)要求。以下是關(guān)鍵工作內(nèi)容：

3.1 安全需求分解與團(tuán)隊(duì)待辦列表管理

ART需將Solution Train下發(fā)的技術(shù)安全需求（TSRs）拆分為團(tuán)隊(duì)級(jí)可執(zhí)行任務(wù)，并納入團(tuán)隊(duì)待辦列表。

SAFe的項(xiàng)目群待辦列表（Program Backlog）需標(biāo)記ASIL等級(jí)，并通過需求分解將其轉(zhuǎn)化為用戶故事。

3.2 安全關(guān)鍵任務(wù)的迭代規(guī)劃與執(zhí)行

ART在PI規(guī)劃和迭代中需優(yōu)先處理安全關(guān)鍵任務(wù)，確保其不受其他需求變更影響。

ART的迭代計(jì)劃會(huì)議需為安全任務(wù)預(yù)留專用容量并使用使能項(xiàng)（Enablers）跟蹤技術(shù)債務(wù)。

3.3 持續(xù)安全測(cè)試與驗(yàn)證

ART需在每次迭代中執(zhí)行符合ISO26262-6:2018 第9條的測(cè)試活動(dòng)。

可以利用SAFe的持續(xù)集成（CI）流水線集成安全測(cè)試，以便管理內(nèi)建質(zhì)量。 

3.4 安全評(píng)審與審計(jì)

ART需在PI系統(tǒng)演示中展示安全需求實(shí)現(xiàn)情況，并接受獨(dú)立評(píng)審。

SAFe的質(zhì)量門禁需包含ISO26262檢查項(xiàng)并由系統(tǒng)團(tuán)隊(duì)在PI邊界前完成驗(yàn)證。

3.5 變更管理與安全影響分析

在敏捷發(fā)布火車（ART）中進(jìn)行變更管理，相比普通敏捷團(tuán)隊(duì)，能夠更好地平衡規(guī)模化交付的穩(wěn)定性和敏捷響應(yīng)能力。普通敏捷團(tuán)隊(duì)的變更通常由產(chǎn)品負(fù)責(zé)人和開發(fā)團(tuán)隊(duì)直接決定，靈活性高但影響范圍有限，容易因跨團(tuán)隊(duì)依賴不足而導(dǎo)致協(xié)調(diào)問題。而ART通過結(jié)構(gòu)化的流程，確保變更在規(guī)模化環(huán)境中得到系統(tǒng)化評(píng)估和優(yōu)先級(jí)排序。緊急變更可以通過快速通道處理，但需經(jīng)過ART層面的影響分析，避免單團(tuán)隊(duì)決策引發(fā)的連鎖風(fēng)險(xiǎn)。

ART進(jìn)行變更時(shí)，需要通過PI進(jìn)行跨團(tuán)隊(duì)的對(duì)齊。需在需求變更時(shí)執(zhí)行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功能安全標(biāo)準(zhǔn)的約束下，敏捷發(fā)布火車（ART）需要通過結(jié)構(gòu)化的安全生命周期管理，將敏捷實(shí)踐與汽車安全合規(guī)性要求深度融合。ART需在保持敏捷迭代交付的同時(shí)，建立符合功能安全等級(jí)ASIL的流程框架，包括在PI規(guī)劃階段明確安全需求與驗(yàn)證目標(biāo)，確保從架構(gòu)設(shè)計(jì)到代碼實(shí)現(xiàn)的系統(tǒng)化追溯?？绻δ軋F(tuán)隊(duì)需協(xié)同安全專家開展危害分析（HARA）和安全概念設(shè)計(jì)，并將輸出拆解為可迭代開發(fā)的安全用戶故事，同時(shí)通過持續(xù)集成環(huán)境嵌入自動(dòng)化安全測(cè)試（如靜態(tài)分析、故障注入）。每個(gè)增量交付必須通過安全評(píng)審門禁，這種模式既保留了敏捷快速響應(yīng)需求變化的優(yōu)勢(shì)，又通過嵌入式安全活動(dòng)和自動(dòng)化工具鏈，確保功能安全合規(guī)性不被敏捷交付節(jié)奏稀釋。

4?組織Agile Team進(jìn)行具體執(zhí)行

Agile team是SAFe的執(zhí)行層，通常由5~11人組成，負(fù)責(zé)開發(fā)具體功能或組件，采用Scrum或Kanban開展迭代。

在SAFe框架的Team層實(shí)施符合ISO26262標(biāo)準(zhǔn)的開發(fā)時(shí)，需將功能安全要求落地到日常開發(fā)實(shí)踐中，確保代碼級(jí)實(shí)現(xiàn)滿足ASIL等級(jí)目標(biāo)。

在功能安全中，團(tuán)隊(duì)要：

? 實(shí)施符合ASIL等級(jí)的設(shè)計(jì)規(guī)范；

? 編寫可追溯的用戶故事，并標(biāo)明其安全關(guān)鍵性；

? 執(zhí)行靜態(tài)/動(dòng)態(tài)分析與回歸測(cè)試，形成Safety Case一部分。

SAFe團(tuán)隊(duì)可采用SAFe for Teams + TDD + BDD等實(shí)踐模式，同時(shí)用Backlog item的標(biāo)簽進(jìn)行分類管理。

4.1 安全需求的迭代實(shí)現(xiàn)與驗(yàn)證

團(tuán)隊(duì)需將ART分解的軟件安全需求（SSRs）轉(zhuǎn)化為可執(zhí)行的用戶故事和任務(wù)。

實(shí)踐要點(diǎn)：

? 在迭代計(jì)劃會(huì)議中將安全需求標(biāo)記為高優(yōu)先級(jí)

? 依據(jù)驗(yàn)收準(zhǔn)則，編寫安全測(cè)試用例

? 按照代碼規(guī)范進(jìn)行開發(fā)

4.2 團(tuán)隊(duì)需遵循編碼規(guī)范要求：

實(shí)踐要點(diǎn)：

? 在持續(xù)集成（CI）流水線中集成靜態(tài)分析等工具，實(shí)時(shí)檢測(cè)違反代碼規(guī)范的代碼

? 對(duì)ASIL C/D代碼實(shí)施結(jié)對(duì)編程或代碼評(píng)審

? 單元測(cè)試與故障注入測(cè)試

4.3安全相關(guān)工件的版本控制

團(tuán)隊(duì)需按ISO26262-8:2018 第7章的要求管理配置項(xiàng)。

實(shí)踐要點(diǎn)：

? 在Git中為安全關(guān)鍵代碼打標(biāo)簽

? 通過制品倉(cāng)庫(kù)存儲(chǔ)經(jīng)過安全驗(yàn)證的二進(jìn)制文件

4.4 每日安全同步與障礙解決

團(tuán)隊(duì)需在每日站會(huì)中優(yōu)先處理安全障礙

4.5 迭代評(píng)審與安全演示

團(tuán)隊(duì)?wèi)?yīng)依據(jù)ISO26262-6:2018 第10條規(guī)定在迭代評(píng)審會(huì)議中需展示安全需求。

實(shí)踐要點(diǎn)：

? 演示安全機(jī)制的實(shí)際運(yùn)行（如故障注入后的優(yōu)雅降級(jí)）

? 提供測(cè)試覆蓋率報(bào)告作為安全案例輸入

Team層實(shí)施ISO26262的關(guān)鍵是：

1. 需求雙向可追溯：通過ATDD將安全需求鏈接至測(cè)試用例

2. 質(zhì)量?jī)?nèi)建：在CI流水線中強(qiáng)制實(shí)施靜態(tài)分析/單元測(cè)試

3. 安全文化：每日站會(huì)優(yōu)先處理安全障礙

SAFe框架不僅適用于規(guī)?；艚蓍_發(fā)，同樣能有效支持ISO 26262標(biāo)準(zhǔn)下的安全關(guān)鍵系統(tǒng)研發(fā)。其分層治理結(jié)構(gòu)和內(nèi)置合規(guī)機(jī)制使其成為汽車功能安全開發(fā)的理想選擇。

SAFe通過Portfolio層確保安全戰(zhàn)略與業(yè)務(wù)目標(biāo)一致，管理安全預(yù)算和史詩(shī)級(jí)需求；Solution Train協(xié)調(diào)跨團(tuán)隊(duì)安全關(guān)鍵系統(tǒng)開發(fā)，保證系統(tǒng)級(jí)安全需求完整實(shí)現(xiàn)；ART（敏捷發(fā)布火車）借助PI規(guī)劃實(shí)現(xiàn)長(zhǎng)期安全目標(biāo)，支持V模型開發(fā)流程。

5?總結(jié)

該框架可完整管理安全需求、設(shè)計(jì)決策和驗(yàn)證證據(jù)，滿足ISO 26262的嚴(yán)格可追溯性要求。同時(shí)，PI規(guī)劃和系統(tǒng)演示等機(jī)制確保變更受控，使能項(xiàng)（Enablers）則專門用于管理安全技術(shù)債務(wù)。

SAFe強(qiáng)調(diào)的"內(nèi)置質(zhì)量"理念將安全文檔作為正式交付物，通過持續(xù)集成/持續(xù)部署（CI/CD）結(jié)合自動(dòng)化安全測(cè)試，在保持敏捷靈活性的同時(shí)滿足功能安全標(biāo)準(zhǔn)要求。這種結(jié)構(gòu)化敏捷方法使SAFe既能適應(yīng)快速迭代，又能確保安全關(guān)鍵系統(tǒng)的可靠性和合規(guī)性。

需要注意的是，在實(shí)施SAFe的過程中，并不需要照搬整套框架，而是可以在保留其主要思想的情況下進(jìn)行裁剪。只要保證在實(shí)施過程中關(guān)鍵過程得到保留：

敏捷發(fā)布火車：跨職能團(tuán)隊(duì)組成的長(zhǎng)期協(xié)作單元，以固定節(jié)奏（PI周期）交付價(jià)值。

PI規(guī)劃：每8-12周的全ART對(duì)齊會(huì)議，制定可執(zhí)行的目標(biāo)和計(jì)劃。

迭代：固定時(shí)長(zhǎng)（通常2周）的開發(fā)周期，包含計(jì)劃、執(zhí)行、評(píng)審和回顧。

團(tuán)隊(duì)級(jí)敏捷實(shí)踐：Scrum或Kanban，每日站會(huì)、迭代評(píng)審和回顧會(huì)。

舉一個(gè)實(shí)踐中的典型例子：

合規(guī)要求進(jìn)行設(shè)計(jì)評(píng)審并記錄和解決所有行動(dòng)項(xiàng)。"設(shè)計(jì)評(píng)審"作為一個(gè)使能者待辦事項(xiàng)（Enabler backlog item）提供了評(píng)審的客觀證據(jù)，其完成的定義（DoD）確保行動(dòng)項(xiàng)被記錄和解決。如果需要，行動(dòng)項(xiàng)本身可以作為"使能者用戶故事"（Enabler Stories）進(jìn)行跟蹤。法規(guī)還可能要求審查所有變更，這通過為所有用戶故事（Stories）設(shè)置"同行評(píng)審"的DoD要求來實(shí)現(xiàn)。

SAFe頻繁構(gòu)建并演示集成解決方案，至少以迭代系統(tǒng)演示的頻率進(jìn)行。頻繁構(gòu)建和集成使得用戶驗(yàn)收測(cè)試、客戶和最終用戶能夠持續(xù)驗(yàn)證。每個(gè)迭代期間，系統(tǒng)演示提供客觀證據(jù)，證明集成功能按預(yù)期運(yùn)行，整個(gè)系統(tǒng)在滿足質(zhì)量和合規(guī)要求的前提下持續(xù)演進(jìn)。

每個(gè)PI迭代除了完成研發(fā)工作外，還要預(yù)留時(shí)間用于集成和評(píng)估上個(gè)PI的成果，并收集指標(biāo)以支持PI的檢視與調(diào)整（I&A）研討會(huì)。I&A是定期進(jìn)行反思、收集數(shù)據(jù)、解決問題并采取行動(dòng)的固定機(jī)制，包含三個(gè)部分：PI系統(tǒng)演示、用于審查指標(biāo)和趨勢(shì)的定量測(cè)量，以及回顧與問題解決研討會(huì)。

PI系統(tǒng)演示包含合規(guī)工作成果，可能包括：為更好支持自動(dòng)化測(cè)試和合規(guī)而進(jìn)行的基礎(chǔ)設(shè)施建設(shè)、重要評(píng)審或?qū)徲?jì)的結(jié)果與反饋，以及里程碑合規(guī)事件（如飛行測(cè)試）的結(jié)果。定性測(cè)量通過數(shù)據(jù)趨勢(shì)展示產(chǎn)品認(rèn)證和發(fā)布的進(jìn)展，合規(guī)指標(biāo)可能包括：需求覆蓋率、測(cè)試代碼覆蓋率和同行評(píng)審結(jié)果的當(dāng)前狀態(tài)。SAFe還提供若干相關(guān)質(zhì)量指標(biāo)——缺陷數(shù)量、測(cè)試總量、自動(dòng)化測(cè)試百分比等。

以精益-敏捷思維評(píng)估每個(gè)增量期間的指標(biāo)。畢竟目標(biāo)不僅是滿足每個(gè)增量的合規(guī)要求，更要理解項(xiàng)目如何朝著整體合規(guī)目標(biāo)推進(jìn)，并識(shí)別需要關(guān)注的問題領(lǐng)域。從這個(gè)角度看，這些指標(biāo)的趨勢(shì)數(shù)據(jù)通常比單個(gè)PI邊界點(diǎn)的數(shù)據(jù)更具參考價(jià)值。

最后，回顧與問題解決研討會(huì)涵蓋合規(guī)活動(dòng)中的關(guān)注點(diǎn)：項(xiàng)目是否充分滿足合規(guī)目標(biāo)？指標(biāo)趨勢(shì)是否表明解決方案能達(dá)到認(rèn)證所需的里程碑？確保合規(guī)的政策或程序是否阻礙了開發(fā)流程？通過這些問題的探討，團(tuán)隊(duì)可以制定潛在改進(jìn)方案，在下一個(gè)PI中探索優(yōu)化合規(guī)實(shí)踐。

通過上述元素，不同團(tuán)隊(duì)間實(shí)現(xiàn)對(duì)齊和可持續(xù)交付，解決了合規(guī)團(tuán)隊(duì)和研發(fā)測(cè)試團(tuán)隊(duì)或者多個(gè)研發(fā)團(tuán)隊(duì)之間無法有效對(duì)齊的問題。

vavo zhu| 作者

胡沖 | 審核