關於 Navya
Navya 專注於自動駕駛系統的開發，該公司成立於 2014，總部位於法國里昂，在法國和美國的多個據點擁有超過 280 名員工 (其中 140 人為工程師和技術專家)。Navya 是全球第一家推出商用自動駕駛接駁車的公司。該公司於 2015 年 9 月推出首款無人駕駛的全自動 AUTONOM® 電動接駁車，做為首末端客運解決方案。
問題：敏捷開發與 ISO 26262 合規
Navya 於 2018 年初面臨的主要挑戰，是如何在組織快速成長之際，有效管理日益複雜的產品開發流程。他們需要一種方法來平衡敏捷的靈活性和 V 模型的剛性，同時確保遵循安全法規。
公司當時仍處於創業階段：開發團隊尚未建立產品規格管理系統，且即使已進入開發階段，需求仍尚未確立。軟體團隊雖採用敏捷式流程，卻任由各個團隊管理自己的待處理項目。團隊之間協調不足，沒有可遵循的程序，也無法全面掌握開發進度。這些問題勢必會與行動產業功能安全嚴格的監管要求產生衝突。
改用 Codebeamer 之前，Navya 的開發團隊使用一組混合式的工具，這點與許多公司的做法類似。他們使用 Git 進行編碼版本控制，並搭配使用手動更新的試算表、Jira 和持續擴充的文件存放庫，追蹤開發活動的最新進度。
隨著 Navya 團隊規模擴大，產品複雜度急劇上升，幾近失控。該團隊意識到，這種情況可能會嚴重影響開發效率。Navya 團隊並未坐視不管，任由情況惡化到足以影響營運的程度，而是及時意識到需要在方法上做出調整。
自駕技術開發的安全性及法規遵循要求
Navya 開發了一款具有多個安全關鍵子系統的自動駕駛產品。由於監管機構制定自駕系統法規的速度落後於產品開發商，ISO 26262 仍是 Navya 為確保功能安全方面必須遵循的最重要監管要求。
從流程觀點來看，開發團隊會先根據產品使用案例，進行概括性的風險分析。接著再將分析結果劃分為不同層級的系統需求，並分配至所需的子系統和元件。為了驗證功能及非功能性需求，團隊會先進行功能或模擬層級的測試，也就是在受控環境中測試軟體系統的壓力耐受度，然後在代表性環境中進行系統層級的測試。
一旦通過了所有這些測試之後，產品就得到驗證並可以部署。即便如此，Navya 團隊仍會先進行規模較小且較受控的部署，且僅針對少數客戶進行。等到這次部署成功後，才會為整個車隊全面部署新開發的解決方案。
評估 ALM 工具要考慮靈活性
2018 年 7 月，Navya 啟動了選擇應用程式生命週期管理解決方案的採購流程。由於對正規化開發流程的需求日益增長，搜尋工作進行得相當快速。為了做出明智的決定，團隊分析了多款工具的功能，並開始與多家供應商洽談。
在評估期間，Navya 團隊主要考量的因素包括：
- 能夠自訂各類物件，並在它們之間建立連結，以實現端對端可追溯性
- 在快速發展、創新、敏捷的環境中易於使用
- 支援協同合作，並能讓使用者在工具內互動
- 靈活性，以及發展和調整系統以支援持續改進的能力
- 易於設定，因為隨著處理的改進，團隊的需求會不斷變化
- 最佳投資報酬率的定價模式
Navya 的開發團隊在建構 ALM 環境時，採用了與軟體開發類似的敏捷式方法。他們希望按部就班地進行，在選購過程中遵循基本敏捷模式，以確保他們選擇的解決方案能夠滿足不斷變化的需求。該團隊希望透過持續改善工作環境來實現最高效率。因此，Navya 將靈活性列為關鍵需求：他們最終選擇的工具，必須能夠適應並支援百分之百的敏捷思維模式。
評估階段結束後，Navya 的候選名單只剩下幾項最終入圍的工具，包括 Siemens Polarion 在內。最終，該公司對靈活性的迫切需求，讓 Codebeamer 雀屏中選。
Navya 於 2018 年 8 月購買了少量授權，隨後又逐步增加了授權數量。到了 2019 年，Navya 已擁有 120 名 Codebeamer 使用者，並計劃在隔年將使用人數增加至 200 名。
自主推行與培訓
Navya 之前並沒有大規模推行開發工具的經驗，而且 Navya 產品開發主管 表示，他們並未預料到 Codebeamer 會如此成功，且需求量持續增加。整體而言，Navya 報告顯示該工具導入迅速，且幾乎不需要投入精力訓練使用者。
最初的目標是使用該平台進行軟體程式錯誤管理，但很快就擴展到軟體團隊的使用者故事和史詩級任務 (epic) 管理。出乎意料的是，自 Navya 使用該系統以來，硬體團隊也開始採用這項工具。
使用 Codebeamer 一段時間後，產品團隊自然而然地將其擴大應用於硬體開發領域。管理階層起初面臨一些阻力，因為硬體工程師將該平台視為純軟體工具。然而，Codebeamer 在管理硬體問題和降低複雜度方面的優勢很快就變得顯而易見，也因此贏得了硬體團隊的認可。
在培訓方面，Navya 採用了混合式方法：雖然有正式的培訓計畫，但更鼓勵工程師自行「摸索」這項工具。當他們發現設定 Codebeamer 竟如此簡單時，Navya 決定將管理權限分配給多個團隊，以自然而然地擴大這項工具的應用範圍。
事實證明，這種方法有利也有弊：一方面，工程師確實逐漸精通該平台的使用與設定方法；但另一方面，Navya 開發團隊也累積了大量缺乏維護且無法互通的異質物件。為了解決這個問題，他們成立了一個專責團隊，負責維護平台使用規範、精簡物件數量，並將物件重新整合至一個共用架構之下。
整合式 ALM 的好處
Navya 改用 Codebeamer 後，最顯著的效益是流程變得更加透明、清晰且一致。
採用 Codebeamer 之前，Navya 的各個團隊各自獨立進行產品各項功能的相關任務。由於活動可見度有限，因此很難從系統層級的觀點，協助各個團隊應對複雜度挑戰。
使用 Codebeamer 後，他們便能全面洞察從需求到驗證階段的所有開發活動，並識別各類產出物之間的連結。他們可以輕鬆追蹤相依性，並藉助通用原則建立標準化的編碼品質規範。團隊可以輕鬆監控進度和各種高階指標，以評估重點領域。這有助於找出問題領域，進而推動持續改善。
ALM 讓 Navya 在合規性方面的開發工作更加順暢，從高階需求、有機架構到最終測試，所有環節都建立了可追溯的連結。這讓 Navya 的團隊能夠更有效地執行必要的驗證步驟及合規檢查。改用 Codebeamer 之前，這些流程缺乏專門的工具支援；Navya 報告指出，該公司團隊的效率因為使用此平台而有所提升。
考量該平台的靈活性及其帶來的所有好處，不難理解 Navya 為何正在探索在組織內部應用 Codebeamer 的創新方法：