Background

過去傳統的工程開發，專案一般是將需要交付的範圍和內容在前期完成限定。換句話說，在一個專案開始的時候詳細明確了開發的需求，專案管理者和實施者需要在時間和各類資源上做調配，來獲得一個完美的結果。

作為一個年輕的品牌，誕生於一個不斷變化的時代！變化對於每一個置身於這個時代的組織和個人來說，都是一個不可忽視的因素。你可能聽過這個詞， VUCA （ Volatility Uncertainty Complexity Ambiguity ） 它表示的是事物存在的環境具有波動性，不確定性，複雜性和模糊性。因為外部變化太多太快，如果無法透過內部的快速響應去適應外部的變化，設計產品也好，執行的專案也好，最終很可能得到一個相對糟糕的結果。由此想到，當前整個產品開發過程的控制方法，是否能對一系列的開發的活動做比較好的把控？

NPDS（ New Product Development System）

NPDS 是吉利汽車正向開發所採用的整車開發體系模型，覆蓋整車專案管理，機械結構，功能特性，子系統，電子軟體零部件等一系列研發活動。此類流程的淵源是基於上世紀70年代系統開發生命週期模型。它們經常被用於 等大型工程專案和複雜系統開發的場景中。舉幾個這類模型比較明顯的特點。由於流程中各個活動和目標有明確的階段性，每當需要進入到下個階段時，往往需要經過所謂的 （連結參考 Project Management Institute 的定義）。按照專案管理方法論，Gates Review的目標是要幫助定位識別會使專案失敗的兩大原因，即專案範圍的變化和風險點。邏輯上看似乎沒有問題。

然而，GATE的開啟和關閉仍舊是由人來判斷的，人的能力和知識儲備水平是不一樣的。往往會發生過了GATE，但是其中需要排查的風險並未發現出來。流程本身也不能保證工作內容的質量符合預期。最嚴重的痛點是，每個階段需要很長的時間收集整理處理資訊，整個專案的時間週期會拉的非常長，從而引入更多的不確定性。人們也常常把這種方法論稱作瀑布式的開發方式，見下方圖例為一軟體開發相關的通用步驟。

 

圖一.瀑布式的開發方式舉例：需求->分析->設計-> 程式碼-> 測試-> 部署, 有的也會包含後續的維護部分

---

 

Agile - a short introduction

敏捷開發思維登場！簡單介紹一下敏捷開發的歷史：上世紀90年代，在美國矽谷的一些工程師在一起討論為什麼軟體工程交付和質量變得越來越差，有什麼樣的方法可以改變這樣的現狀？在這樣的背景下面，2001年，倡導輕量化和更多迭代開發方法的思想領袖們，聚集在了美國猶他州的雪鳥小鎮。雖然大家所提出的方法各不相同，但是與會者一致認為這些方法所遵循的共同價值和信仰，最終提出了具有轉折性意義的“敏捷軟體開發宣言”。 如下圖內容所示

 

圖二.敏捷宣言建立的價值觀 來源： agilemanifesto.org

翻譯過來就是：個體的互動高於流程和工具，工作的軟體高於詳盡的文件，客戶合作高於合同談判，響應變化高於遵循計劃，也就是說盡管右項有價值，我們更重視左項的價值。 由此為基礎，由Scaled Agile, Inc 進一步發展出來的整套SAFe（Scaled Agile Framework）原則概述如下

#1 - Take an economic view

採取經濟視角

#2 - Apply systems thinking

運用系統思考

#3 - Assume variability; preserve options

假設變異性;保留可選專案

#4 - Build incrementally with fast, integrated learning cycles

透過快速整合學習環進行增量式構建，

#5 - Base milestones on objective evaluation of working systems

基於對可工作系統的客觀評估設立里程碑

#6 - Visualize and limit WIP, reduce batch sizes, and manage queue lengths

視覺化和限制在製品，減少批次規模，管理佇列長度

#7 - Apply cadence, synchronize with cross-domain planning

應用節奏，透過跨領域設計進行同步

#8 - Unlock the intrinsic motivation of knowledge workers

釋放知識工作者的內在動力

#9 - Decentralize decision-making

去中心化的決策

#10 - Organize around value

圍繞價值鏈組織活動（後續的版本新增）

 

介紹了那麼多，敏捷的優勢到底在哪裡呢？透過以下兩個圖，粗略的對敏捷開發和傳統的瀑布式開發做一個對比，圖中紅色曲線是傳統的工作方式，藍綠色代表的是敏捷的工作方式，橫軸是時間線，縱軸相對關係的比較示意，沒有絕對的數值。

左邊圖裡面所描述的是，傳統的開發中，在前期設立好的開發的範圍，與客戶商議的需要交付的功能清單，會因為資源或技術成熟度等因素的影響，使得實際交付變得困難。特別是臨近專案交付時間點，與之前的承諾會有很大的出入。而敏捷開發是一個增量的變化，在前期保證可交付少量但是可以工作的功能。哪怕這些內容並不是非常完美，至少在整個框架內的這部分已提交內容可以被終端客戶使用並接受檢查的。後續的交付是在之前的基礎上疊加，完善甚至超出客戶的期望。

 

 

圖三.傳統和敏捷開發的優缺點舉例

右邊圖中，更多的是從整合測試的角度和發現問題的數量來比較。在傳統的開發過程當中，往往會忽略前期的，特別是在一個複雜的系統內跨部門之間的聯合測試。傳統專案直到後期才開展的大跨度的整合工作，有很大失敗的風險。敏捷的方式引入持續整合和測試的概念，保證全鏈路新開發出來的相關部分都能儘早被對應的測試覆蓋。每次控制的變化的數量，保證始終有軟體在開發，整合測試，初期客戶驗證等不同階段進行的活動。相比而言，傳統的工作方式這些步驟會存在於不同的GATE後，無法得到小步快跑的效果。

---

Case study

著名的諮詢公司 研究了全球企業級的敏捷實踐推廣, 從中分析的由此轉變得到影響。包含了總共有22個組織的6大部分，得到的結論敏捷的優勢主要表現在三個方面

改善客戶滿意度增長10%-30%

員工滿意度增加20%-30%

組織執行效力改善30%-50%

最終得到財務表現提升20%-30%的結果

 

圖四.資料來源麥肯錫研究

做為大部分工程人員，可能無法經常得到第一線接觸客戶的聲音和反饋。這容易引發一些問題，比如忽視開發的最終目的是讓產品能夠經過生產加工流通到終端客戶並滿足客戶的某些需求。一味的從技術角度，無視客戶的真實需求，堆砌各種功能，最後與初衷背道而馳。敏捷開發的宣言和原則的內容都很好的傾斜到對客戶的期望滿足上。

當今，各個科技型公司的最有價值的部分往往是組成這個公司的人才。對於知識勞動者，比如軟體開發工程人員的管理和培養，需要區別於傳統流水線上的工人。是否能夠更好的激發他們的主動熱情，往往是一個企業文化優劣的評判標準。鼓勵主動思考總結，引領創新的工作氛圍也是敏捷開發過程中強調的內容。

組織的上下協同，效率優先的做事方式是精益生產與敏捷開發中對工作流和價值流的追求的目標。對得到上述的調查結果沒有驚奇！如果公司上下都切實踐行了敏捷方法論，得到以上結果的甚至應該是理所當然的。

WHY？ WHY？ WHY？

 

如果敏捷開發優勢這麼明顯...

為什麼還要把兩種開發方式結合起來呢？

不能直接全面替換掉原有的流程嗎？

敏捷開發和NPDS能共存嗎？

......

NPDS 的靈感來源於沃爾沃汽車的VPDS，或者某種意義上也是延續了福特汽車的GPDS。包含的內容是整合了一套完整的汽車產品所需要經歷的，從概念，工程，到生產製造和售後的產品生命週期管理方法；是許多或成功或失敗的專案活動經驗的總結而積累起來的管理方式；也是包含了無數各個領域的專業人士的意見的集合；更是一套符合法規合規的最佳實踐。 NPDS和VPDS在這些年，也在自我演進，尋求突破。從縮短開發週期，增強部門協同，減少開發人員負擔，提高靈活度等多個方面做了革新。敏捷的開發源於軟體工程的範疇。而汽車作為一種相當複雜的產品，除了軟體以外，存在大量其他需要考慮的部分。對於某些特殊場景，無法很好的適用。例如大部分公司會有一些開發流程外的輔助體系，比如財務對專案現金流的管理或對新工廠基建的投資，需要明確的專案節點來控制。一些重要的節點仍舊需要有一種能夠把包含軟體在內的工作與其他交付做一個同步配合的方式。例如配合造車計劃節點和上市的時間表。同時組織架構決定了我們需要一個頂層的框架來保證公司的整體方向一致。

事實的情況日新月異技術的，像軟體定義汽車的概念，汽車向消費品化和服務化的轉變，又需要大家來面對這一系列變化。我們要做的是取長補短，將兩者的優勢發揮到最大，而規避各自的弱點。NPDS與Agile的關係，做個簡單的類比就像是在軍事領域，不同層級的指揮官。在不同的高度需要有兩種不同策略來適應實際的需要。戰場上瞬息萬變，在一線作戰的單位需要有靈活的決策方式，而在整個戰局的把控和戰略層面需要有通盤考慮，整體步調協同。

Expected result

在推薦NPDS+Agile的管理方法時，期望得到的結果有以下這些方面，它們也是實施的目標：

• 面對本業務相關的客戶和利益相關者，將他們引入到開發中來
• 識別價值流，特別關注增值的部分
• 管理部門內外存在的依賴關係和時間線，提高效率
• 關注迭代，自省與進步的迴圈
• 兼顧多個整合路徑上自有路線和互相配合
• 實現自我管理的團隊模式，形成新的團隊文化

Summary

總結：我們的目標是仍舊需要NPDS！但要對NPDS進行改造，引入敏捷開發的思想，特別是電子和軟體相關的開發。而成功的關鍵是需要你與我的共同參與和努力！

本文的最後引用庫布勒羅斯改變曲線，給大家參考當一個組織在做某項變革的時候，組織的成員往往會遇到思想轉變的一個過程。其中，內部的員工對新的概念和方法有很多負面的情緒，或者不願意接受甚至牴觸新的工作流程，這些都是正常的反映。如下圖可以看到由灰色色塊與其他顏色的邊界組合而成的庫布勒羅斯曲線是一個底部彎曲的形狀。當外部發生劇裡變化時，有些人會一直徘徊在曲線的左邊部分掙扎；也有些人會不斷的努力突破自己，學習適應新的知識體系，往曲線的右邊部分衝刺。 如果是你，對於這個新的工作方式NPDS+Agile，會有怎麼樣的表現呢？

 

圖五.庫布勒羅斯改變曲線

細心的你是否發現本文的編排也是貫穿了敏捷的思維呢？非常感謝大家的時間！後續會有一系列的敏捷開發實踐與大家分享，如果喜歡本次推送的內容，請持續關注我們的渠道！

 

Reference

參考及延伸

https://rezaid.co.uk/agile-waterfall-software-development/

https://www.atlassian.com/blog/jira-align/agile-mindset-waterfall-projects

https://www.ekrfoundation.org/5-stages-of-grief/change-curve/

 

本文作者：極氪勞哥

 

---

文章結尾新增：
極氪汽車軟體及電子中心，秉承平等、多元、可持續的價值觀，對產品持續極致追求，為使用者提供用心體驗。從中央計算、智慧區域控制器、整車OTA、智慧車身控制、整車軟體等領域出發，打造行業頂級的電子電氣架構，為智慧電動車保駕護航。