從專案到產品：生產線類比的終結

譯者：無敵哥

原文地址: https://www.tasktop.com/blog/end-manufacturing-line-analogy/ 本文翻譯僅供學習交流之用。

原文作者 Mik Kersten 出版了《Project to Product》

本系列共四篇文章，分別是

• 01 從專案到產品：軟體需要從物理產品交付中學到什麼？|IDCF（點選檢視）
• 02 從專案到產品：生產線類比的終結|IDCF
• 03 從專案到產品：到底是什麼應該流經軟體價值流？|IDCF
• 04 從專案到產品：軟體時代需要價值流架構師|IDCF

我最近參觀了寶馬集團在萊比錫的工廠。我的目標是和寶馬集團的 IT 領導人一起頭腦風暴，探討如何將生產線與軟體生命週期無縫整合在一起。我也有興趣瞭解更多關於寶馬如何處理汽車生產，因為我正在為我即將出版的新書《Project to Product》定義流框架。參觀包括沿著工廠的生產線走10公里，工廠領導解釋每個涉及汽車生產的系統、流程和工具。那次訪問比我讀過的所有關於精益流程的書籍更深刻地影響了我對精益生產的理解。

該工廠是一個令人難以置信的設施，在技術和可持續性方面領先於業界，每70秒生產一輛寶馬1系或2系汽車。它還擁有令人驚訝的創新型 i3和 i8生產線。走進中央大樓(參見圖1) ，你會有一種觀看星際飛船建造設施的感覺，同時也會有一種大型科技創業公司的感覺。開放式辦公室位於生產線露天部分的下方，生產線將汽車從汽車修理車間移動到工廠的瓶頸地帶，然後再移動到裝配大樓。

圖1: 寶馬集團萊比錫工廠的中央樞紐大樓。該工廠每70秒生產一輛寶馬1系或2系汽車。(來源: 寶馬集團，經許可使用。)

當我向工廠領導層提出數以百計的問題時，我的大腦急速地想把汽車和軟體的製造方式進行比較。機器人和人類協同工作的結合，讓我們得以窺見未來人類技能將如何與人工智慧和自動化相結合。但給我印象最深的是工廠的架構，它展示了任何軟體架構師都會羨慕的優雅和模組化。

在圖2中，裝配線的關鍵階段清晰可見，五個“手指”的“指關節”向右生長。每個手指都是生產線架構中的關鍵固定點，隨著製造步驟的增加，以及技術和客戶需求的演進，建築向外逐步擴充套件。我從來沒有想到我與軟體架構聯絡在一起的原則會以如此物理的、不朽的形式出現。

圖2: 寶馬集團萊比錫工廠的無人機照片。生產線的關鍵階段清晰可見，五個“手指”的“指關節”從工廠中間向右生長。(來源: 寶馬集團，經許可使用。)

訪問結束後的幾個月裡，我一直在思考如何將工廠的製造性創新，應用到軟體，重新思考該如何構建。 

• 我們如何模擬返工區域提供的視覺化？ 
• 我們如何像萊比錫工廠那樣將我們的軟體架構與價值流結合起來，從建築的結構到每個階段和工具的放置？ 
• 我們如何將自動化和人類工作無縫地結合起來？ 
• 而且，最重要的是，我們如何使軟體過程的關鍵瓶頸像工廠那樣讓我們的員工看得見？

然後我和 Tasktop 的產品開發副總裁 Nicole Bryan 進行了長時間的交談，她讓我確信我的想法是錯誤的。

軟體開發不是一個製造過程

萊比錫工廠最令人印象深刻的事情之一是大規模實施準時生產（Just In Time）。更有趣的是，這些汽車是按順序生產的: 汽車從生產線上下來的順序與客戶訂單進來的順序相同。許多階段都令人印象深刻，但當看到端到端過程中的最佳化時，令人興奮不已。

拉動的概念是任何精益系統的核心。對於製造業來說，“拉”是物理部件的客戶訂單序列。在寶馬集團，小部件（widgets）是滿足市場需求的汽車。以“純粹的駕駛樂趣”滿足客戶，這個短語張貼在整個工廠，以便讓工作人員看到。如果更多的1系列比2系列汽車取悅使用者，更多的1系列汽車下線，生產線的工具和流程適應新的需求。

當我走在工廠的地板上時，我腦海中的禪意心印（Zen koan ，譯者注：查了一下，這是一個佛教用語，禪宗的心印是“如人飲水，冷暖自知”的不可思議禪境）正試圖弄清楚，在一個模糊的軟體交付過程中這些“流動單元”是什麼。從寶馬集團對“純粹的駕駛樂趣”的強調中獲得靈感，我們可能會得出這樣的結論: 這些流動單元應該是讓我們的終端使用者感到高興的東西。然而，我們知道，隨著壓縮打包（Zip）和燒錄CD的日子遠離我們，開發人員不會因為一次又一次地釋出同樣的軟體而感到高興。

精益思想是讓客戶從生產者那裡獲取價值。因此，軟體中的小部件應該是流向客戶的業務價值單位，產生某種愉悅、無煩惱和收入的組合。這些“流動條目”（Flow Items）的完整定義在 《Project to Product 》中有所涉及; 可以把它們看做新新增的特性、待修復的缺陷、需解決的技術債務和安全漏洞，以及客戶希望拉動的類似業務價值單元。然而，這些流動單元中沒有兩個是相同的。

這裡我們看到了一個核心差異。汽車製造廠的目標是以最高的速度、可靠性和質量，以不同的配置生產出相同的小部件，而軟體開發組織則生產出每個功能都不同的小部件。決定這些功能應該是什麼樣子的工作，類似於寶馬集團對下一輛汽車的設計工作。在高效率的軟體商店裡，這種情況每週或每小時發生一次，而不是每年一次。

• 如果您的輸入受到限制，並希望生產高質量的小部件，那麼您最好的選擇是，建立一個完全線性的批處理風格的流程，最終的例子是汽車生產線。 
• 但是如果你每次都要製作一個不同的小部件，並且定義這個小部件的大小和形狀是一個創造性的過程，那麼線性過程就是一個錯誤和誤導性的模型。

錯誤心智模式的陷阱

作為科學家、工程師和技術專家，我們透過把複雜的問題簡化為簡單的問題，從而做得很好。但是，回顧一下我們在過去改進大規模軟體交付的嘗試中，所採取的一些錯誤步驟。

• 瀑布開發在理論上看起來很棒，因為它使軟體交付中連線所有利益干係人的複雜性，轉變成線性的。

• 敏捷開發拯救了這個問題，但是它過於簡化了交付視角，將上游或下游的利益相關者排除在外，比如業務分析師和運營人員。

• DevOps 透過包含運維、自動化和部署過程的可重複性來解決這個問題。但是我現在擔心，由於過分關注線性過程，而不是 DevOps 的端到端流程和反饋原則，組織將會犯類似的錯誤，採用過於狹隘和過於線性的DevOps 觀點。

以自動的、可重複的方式應對頻繁釋出的能力，可以成為 DevOps 轉型的一個很好的起點。但這只是最佳化端到端軟體價值流的一小步。《限制理論》（theory of constraints）告訴我們，只投資於價值流中的一個部分不會產生結果，除非這個部分是瓶頸。但是我們怎麼知道這是瓶頸呢？更重要的是，如果我們是在一個非線性過程中尋找一個線性瓶頸呢!!

軟體開發包括一系列類似製造的過程。單獨來看，每個都可以被認為是批次流，其中自動化和可重複性決定成功與否。例如，在20世紀70年代，我們掌握了軟體彙編，使用編譯器和 GNU Make 之類的系統，為構建非常大的程式碼庫提供了批次式的可重複性。在接下來的十年裡，GUI 生成器和程式碼生成成為了自動化手段，我們現在在構建Mobile UI時認為這是理所當然的。現在，我們正處於掌握程式碼部署、釋出和效能管理的過程中，使頻繁釋出成為一個可靠和安全的過程。

然而，這些都只是端到端軟體價值流的單個構建塊，類似於成型、焊接和組裝汽車的各個階段的機器人。但是在軟體方面，這些不同的階段並不足以組合起來形成簡單的單向批次生產流程。

從線性批處理到價值流網路

從核心關鍵點來看，端到端軟體生命週期是一個向終端使用者提供價值的業務流程。因此，詹姆斯 · 沃馬克和丹尼爾 · 瓊斯在他們的《精益思想》一書中總結的精益思想5個原則非常適用:

• 精確地定義具體產品的價值
• 確定每個產品的價值流
• 使價值流不受干擾
• 讓客戶從生產者那裡獲得價值
• 追求完美

當我們將流程從裝配線轉移到網路時，許多精益理念都是相關的，比如小批次和單件流，以儘量減少正在進行的工作。然而，為了避免過度使用製造業的類比(或者更糟，繼續沿著錯誤的心智模型的道路前進) ，我們必須更清楚地界定管理迭代式、基於網路的軟體開發價值流與管理線性製造價值流之間的關鍵區別:

• 可變性。對製造業而言，什麼將出現在生產線的末端，有一個固定的、定義良好的變化集，而新的軟體功能是開放式的。製造業需要最小化可變性; 軟體開發需要擁抱可變性。
• 可重複性。製造是關於最大化相同部件的生產能力; 軟體是關於最大化驅動創新的迭代和反饋迴圈。在目前，我們在軟體交付的每個階段，都在追求可重複性，比如可靠的自動部署，但是我們應嘗試更多地最佳化流和反饋，而不是可重複性。
• 規劃頻率。汽車是在瀑布式跨越年的週期內進行前期設計，現代軟體組織通常使用兩週的 sprint 節奏來規劃交付。這意味著我們必須為頻繁的計劃和變化，來設計我們的價值流。
• 創造力。製造過程旨在實現最高可行的自動化水平，這是透過從生產過程中移除任何創造性和不確定性的工作來實現的，創造性的工作轉移到定義和調整生產過程本身。而我們在軟體交付過程中，看到了一些這樣的例子：例如，定義從規劃到部署的價值流可能比編寫新特性更具技術挑戰性。同時，在自動化方面，即使人工智慧即將取得重大進展，我們仍將在軟體價值流的每一步需要創造性的工作和協作。
• 視覺化。軟體之所以如此有趣，是因為它不受物理製造的限制，這使得它具有無限的可塑性。這意味著，能夠以一個戲劇性的節奏適應一個市場的需求。然而，物理位元的缺乏，使得流和產出物的視覺化，成為一個非常有趣的挑戰；相比之下，在汽車製造廠，這是非常明確的。正如我們必須發明顯微鏡，來理解肉眼看不到的物理世界的內部運作一樣，我們現在需要一套新的工具來理解和管理無形的軟體價值流。

如果你接受軟體價值流會形成網路，這和飛機交通相類似，我們也必須考慮是什麼造就了健壯、高效的網路，從路線最佳化到流量控制。例如，為了最佳化網路，我們必須考慮以下幾點:

• 吞吐量。我們可以用吞吐量來衡量一個網路的有效性----例如，某些路線可以運送多少乘客。在一個 IT 組織中，我們應該在哪些方面進行投資，以獲得總體吞吐量的最大增長？
• 延遲。線上性流程中，延遲很容易處理，但是在前端和後端團隊都必須協作才能實現一個特性的場景中，情況又如何呢？外包到遙遠的時區會增加延遲嗎？我們如何衡量總體網路延遲和端到端的前置時間，以及上市時間？
• 彈性。一個健壯的網路可以讓在一個節點不工作的情況下，讓流動保持不變。這與失敗的產品或無法償還的技術債務有什麼關係？

最後，梅特卡夫定律（Metcalfe’s law）告訴我們，網路的價值隨著其連通性而增長。如果我們的價值流網路連通性不足，那麼最佳化任何特定階段還有意義嗎？例如，假設運維人員和服務檯（Helpdesk）工作人員之間沒有正式的反饋迴圈，他們使用的是 IT 服務管理工具，如 ServiceNow; 開發人員使用的是敏捷工具，如 Jira 和 Microsoft Project 中的規劃釋出。在這種情況下，投資數百萬美元到持續交付能產生任何可衡量的商業效益嗎？當一家公司的市場競爭力岌岌可危時，對這些問題的一般性答案是不夠的。我們需要一個更健壯的軟體價值流網路模型，這是從專案到產品的一個關鍵主題。

當我走出萊比錫的工廠時，我的觀點被寶馬集團已經達到的獨創性、創新性和管理成熟度所改變。現在是我們打下基礎和建立新的心智模型的時候了，這些心智模型將使我們達到這種精確性、完美性和流程性，以衡量軟體是如何構建的。如果我們繼續把軟體交付視為一個線性的製造過程，我們就會停留在飛行前的時代。

注：本文的一個版本最初發表在2017年11月 / 12月出版的 IEEE 軟體(版權 IEEE，2017)。“生產線類比的終結” ，軟體 IEEE，卷。34，no. 6，pp. 89-93,2017.11-原文

這裡擷取一張原文作者 Mik Kersten 一次演講的照片，可以對比一下汽車生產與企業IT研發的區別。

這是一系列來自於Mik的部落格，這些核心內容可以認為是 《Project To Product》的起源。對Mik來說，從專案到產品，是一個20年的旅程，開始於作為一個開源開發者的十年學習，並將這些學習應用到他過去十年與 不同行業IT 領導者的合作中。這些帖子代表了他一路上最有趣的學習和合作歷程。這些文章最初發表在 IEEE 軟體雜誌的“ On DevOps”專欄中，目標讀者是對軟體體系結構進化感興趣的讀者。