軟體開發中的準時化生產

作者 路寧

準時化生產（Just In Time）是精益生產（Lean Production）和豐田生產系統（Toyota Production System）中的概念，早在1936年便被豐田汽車的創始人豐田喜一郎所提出，它強調在合適的時間生產合適數量的滿足客戶需求的產品。這充分體現了從客戶價值出發組織生產運營系統的觀點，是一種先進的生產方式，為包括豐田、戴爾等眾多世界級企業的成功奠定了基礎。

軟體開發組織從一開始就在向製造業借鑑和學習，並形成了各種不同的開發方法。敏捷開發與準時化生產中的很多觀點和實踐是一致的，精益思想作為精益生產背後的指導思想也正在積極地影響著軟體開發領域，向其中不斷注入創新與活力。

一. 準時化生產與大規模生產

豐田在接到客戶訂單後3天時間內就可以生產出滿足客戶需求的汽車。戴爾在接到客戶訂單後4天內就可完成組裝生產並將電腦送到客戶手中。也許有另外一家利用經 銷商分銷的電腦生產廠家3天就可以調貨到客戶手中，但有多少有價值的生產活動是發生在這3天中呢？如果計入該廠家持有的電腦元部件發生貶值的成本、廠家為 其產品降價給經銷商存貨帶來損失而進行的補償成本（價格保護成本）、退貨成本、產品淘汰成本和存貨持有成本等（這些成本最終都要客戶買單），可想而知客戶 為此這次採購最終付出的代價。

很多采用大規模生產方式的企業也都聲稱自己能夠“及時”地回應客戶，但做法卻是保持超量庫存。這種策略風險很大，因為這樣並非真正回應客戶需求，反而會增加庫存成本，減弱了企業對市場的敏感性，隱藏了企業內部各種問題並帶來庫存淘汰的風險。

準時化生產強調零庫存，通過減少各個環節的庫存，將浪費暴露出來，並通過持續地消除浪費，消除各個工序之間的等待，使得產生價值的活動能夠連續流動起來，在儘量短的時間內開始交付產品。
大規模生產方式根據加工的步驟來劃分部門並儘量優化部門的生產能力。它通過將半成品大批量地在部門間傳遞最終完成產品的生產。它與準時化生產是對立的，它們的區別並不在於生產的量，而在於生產的方式。

敏捷開發類似準時化生產，而瀑布式開發則像是大規模生產方式，不難看出它們向不同的工業生產思想借鑑和學習的影子。

二. 庫存與交付

庫存就是指部分完成的工作，廣義上講就是指已經開始但尚未給客戶創造價值的全部工作。我們可以認為，尚未被開發過程驗證的設計工作是庫存；沒有被提交的程式碼是庫存；已經“做完了”，但還沒有通過驗收的開發工作，包括相關聯的分析和設計工作都是庫存；庫存說明了什麼叫“完成”，只有將庫存交付出去，並得到了肯定的反饋才能叫“完成”。沒有後續步驟的反饋，更進一步講，沒有終端使用者的反饋就說自己的工作已經完成了只能被認為是一種假象和誤導。

嚴格地講，軟體開發中的庫存量是一次交付中的全部工作量。 這可能是1個月的工作量，也可能是半年，甚至是一年的工作量。減少庫存可以有效降低因持有大量未交付工作所帶來的各種風險。減少庫存還便於強化開發過程中 各個角色的“使用者價值意識”，使每項工作都以使用者可識別的價值為目標。可以設想一下，如果在一個星期之內就能完成從對某項功能的分析到向使用者演示該功能的 過程，那麼使各個角色圍繞這一使用者價值展開工作也就變得很現實了；而如果要半年或一年後使用者才能看到可以執行的功能的話，強呼叫戶價值意識只能是一句空話。

頻繁交付是減少庫存的有效方法，以使用者可識別功能為單位的迭代式開發是實現頻繁交付的必要手段。交付週期縮短的極限就是“每次提交程式碼都產生交付就緒的軟體”，這就是零庫存。像很多精益生產中的概念一樣，絕對的零庫存是做不到的，因為每次提交程式碼後或許會產生可以執行的軟體，但距離可交付的狀態很可能還有段距離，可是這不影響我們以此作為持續改進的目標。

真的有必要這麼頻繁的交付嗎？這取決於客戶的要求。只是有些客戶還沒有意識到頻繁交付不僅是一個合理的要求， 而且很可能是對客戶和開發團隊雙方都有利的一件事情，這涉及到了合同、專案型別、軟體商業價值的積累、開發模式和部署等議題，值得單獨撰文探討。這裡想要 表明的是，即使由於種種原因客戶只需要每半年交付一次，我們在內部開發時也要模擬頻繁的交付過程，減少庫存，強化使用者價值意識。

準 時化生產在交付上也會有類似的問題。豐田公司每週到供應商處取一次貨，但卻要求供應商每2個小時就要將一定量的成品從總裝區運送到裝貨區（很多供貨商第一 次聽到這個要求時都難以理解），這就是兩階段庫存，是均衡化生產的一個實踐，目的是為了做好發貨準備的同時實現虛擬客戶，模擬每2個小時提出需求拉動整個生產的過程，使每個生產環節能夠感受到自己的工作是如何配合上下游的工序迅速實現使用者需求的。敏捷開發雖說可能僅需要每幾個月才交付一次，但在內部也通過 迭代實現了模擬客戶頻繁提出需求的過程。每一次迭代都模擬了一次客戶提出需求並最終驗收的全過程。重點是要儘量按照交付的標準來要求迭代，即使使用者不需要 我們真正去交付。

維持頻繁交付、減少庫存還有一個重要的作用就是迫使問題和浪費從隱藏狀態浮現出來。比如程式碼的簡單性， 很難想象複雜難懂的程式碼能支援頻繁交付。當程式碼中有很多重複的邏輯，或是實現過於複雜時，程式碼的質量就可能很差，並且增加新功能也會變的十分困難，這使得 團隊難以實現短期交付的目標。可見，在頻繁交付的環境下，程式碼中的複雜性更易形成明顯的阻礙，迫使我們及時發現和處理這些問題。如果交付週期很長，這些問 題就不那麼明顯了。

均衡化生產是準時化生產的一個重要概念，它強調每個生產單元每天生產每種型號的產品，而不是像大規模 生產方式那樣集中力量生產完某一型號的產品後再去生產下一個型號的產品。這個近乎瘋狂的觀點有效地減少了庫存，增加了靈活性，提升了交付能力。為了儘快交 付一個使用者故事，減少庫存，敏捷開發弱化了各個階段，也打破了軟體模組的所有權。一個開發人員在一天中可能擔當了分析、設計、編碼和測試等多個角色，並可 能觸動了客戶端、伺服器端以及資料庫等多個模組。

準時化生產環境中，當生產流程穩定，平安無事的時候，團隊可能會通過調 離10%的人員，或是調整節拍時間（生產一件產品需要的工時數，後面會有介紹）來迫使現有流程出現混亂，讓以前不顯眼的問題暴露出來，讓很少量的庫存也成 為阻礙迅速流動的障礙。團隊會解決這些暴露出來的問題和浪費，持續地改進工作流程。為了消除浪費，任何事情都可以改變，即使這會觸及到已經成文的規定或是 根深蒂固的觀念。

三. 拉動生產與看板

準 時化生產採用“拉動”的方式傳遞資訊和生產指令，它替換了傳統的通過物料資源計劃系統（Material Resource Planning）向各單位傳送資訊和生產指令的“推動”方式。拉動生產強調前一道工序僅在後一道工序提出要求時才開始生產，以此類推，最後一道工序是客 戶。可見，在拉動的過程中，資訊流動的路徑是從客戶開始的，經過後道工序到達前道工序。“看板”作為拉動生產的一個重要工具，記錄了客戶的需求或是後一道 工序對前一道工序的生產需求，它經常被拿來與敏捷開發中的使用者故事卡做比較。

在敏捷開發中，客戶藉助使用者故事在一個迭代 的過程中將軟體價值小批量地從團隊中拉動出來。典型的開發過程是以這樣的順序進行的：發現新需求 - 使用者故事卡 - 使用者驗收測試 - 單元測試 - 開發，這就是測試驅動開發的過程。故事卡是第一道看板，在開發過程中，看板是以測試的形式存在的，只有在建立了看板，也就是在看到失敗的測試的時候才開始 編碼。軟體中的看板是可執行的，當所有驗收測試執行通過後，使用者故事也就做完了。敏捷開發綜合運用增量式需求探索、使用者故事、測試驅動開發以及演進式設計 等技術，確保客戶可以將軟體功能一個一個地從團隊中拉動出來。

瀑布式開發採用“推動”的策略，依賴集中的分析和任務分 配，並通過執行已經制定的計劃，將“部分完成的工作”在部門之間批量地進行傳遞來達到目標。這種資訊流動方式容易牽一髮而動全身，最終會導致決策的行政化。而拉動過程的資訊鏈是鬆散的，它更注重實質的流程而非形式，員工清楚自己工作的目標（可識別的客戶價值），因此可以自己決定很多事情，便於形成自發性 的系統。

前面提到了節拍時間（Takt Time），它等於可用工作時間除以客戶需求數量，是生產一件產品需要的工時數。節拍時間確定了每一工位的工作節奏，超過和不足都不合適。比如，按照客戶 的需求，1天要生產80件產品，每天8小時工作時間，那麼每6分鐘就應該生產出一件成品。生產速度是屬於整個團隊的，它建立在完成的成品數量之上，沒有必 要去考核每一個工位的加工速度，因為這個對整體沒有意義，每個工位的加工速度都由節拍時間來決定。繼續上面的例子，如果一件成品需要2個某一型號的零件， 則該型號零件的節拍時間就是3分鐘（6分鐘/2），快了會產生多餘的庫存，慢了會影響成品的速度，因此重點不在於優化對這一零件的生產，而是使成品的生產 速度剛好滿足客戶的需求。

準時化生產強調在節拍時間到來的時候看是否生產了一個合格的成品，而不是如傳統生產方式那樣強 調某個工位有沒有按照工單上的要求加工完至少200個零件，越多越好。同樣，敏捷注重穩定的開發節奏。開發的速度屬於整個團隊，它建立在完成的使用者故事數 之上，強調持續、穩定地完成一個個對使用者有價值的，經過整合的可用功能，而不是看是否做完了全部的設計工作，或是試圖測量開發人員每天編寫了多少行程式碼、 測試人員測了多少個Bug。如果那樣做就像是在傳統大規模生產方式下測量工人在工位上加工了多少零件是一樣的，是區域性優化而非著眼全域性優化整體。

四. 內建質量（Build Quality In）

準時化生產與“有人工參與的自動化（Autonomation）”並稱為豐田生產方式的兩大支柱，前者著重強調如何讓有價值的步驟迅速流動起來，實現快速交付；而後者強調在第一時間、第一現場發現缺陷，分析根本原因並徹底解決問題，以此實現零缺陷的目標。

“ 有人工參與的自動化”認為質量產生於工序中，而非依賴後期檢測，並認為後期檢測是一種浪費。工人被授權在出現問題的時候停止生產線，分析和解決問題，同時 廣泛應用自動化的檢測裝置在生產線上及時發現加工中的缺陷。操作員不能將本工序的缺陷傳遞到下一個工序，他們要清楚質量的含義，而且有能力驗證它。如果暫 時不能取消後期檢測，那麼檢測人員與加工工人應在一起工作，第一時間實施檢測，而非像大規模生產方式那樣將他們分到兩個不同的部門。

軟體的質量產生於分析、設計和編碼的過程中，而非依賴後期人工測試。人 工測試固然暫時不可缺少，但敏捷開發更強調儘可能將重複的測試過程自動化，並通過自動化驗收測試和單元測試的形式整合到開發過程中，頻繁地執行，及時發現 錯誤。測試驅動開發的意義在於它改變了設計和編碼的過程，向其中注入了質量。現在，質量是整個團隊共同的任務而非只是QA才關心的事情，團隊中的每位成員 都需要了解質量的含義並具有共同的質量意識。

大規模生產與準時化生產在如何保證質量上有不同的認識，這裡有一個有趣的比 較：一家德國汽車廠以生產高質量汽車聞名，在它生產線的末端停著很多汽車，大批工人在那裡檢測並修理遇到的問題。該工廠把生產一輛汽車超過1/4的工時花 費在這個階段上，他們認為這是工廠對質量承諾的最佳詮釋。而同時期豐田公司僅用了這家德國工廠1/3的工時就能生產同等品質的汽車，生產線末端被設計為僅 能停放2量汽車，也看不到大量工人維修的場景。豐田正是通過“有人工參與的自動化”技術高效地保證了質量。

可見，質量主要不在於你投入了多少人組建了一個多麼大的後期測試隊伍，而在於測試的時機和方式，等所有功能都做完了再測試就太晚了。我們或許可以通過大量後期測試的投入得到較好的軟體“外部質量”，但很可能早已錯失了通過改進設計提升軟體“內部質量”的時機。糟糕的內部質量在你為軟體增加新功能時會暴露無疑。

準 時化生產要求產品設計人員要走出辦公室，到車間和工人們一起解決問題。發生問題時優先考慮通過改進產品設計和工具設計從源頭上避免缺陷再次出現。這與傳統 管理方式很不同，那時設計被認為是高階別的工作，需要坐在辦公室裡，認真地繪製圖紙。軟體開發中的分析設計，編碼和測試也需要密切配合，及時反饋，發現問 題，然後從根本上解決問題。而不是像瀑布方式那樣，分清階段，採用扔磚過牆的方式將問題傳遞到下一個部門。

五. 現場管理與勞動力授權

實施準時化生產的企業認為管理資訊和生產資料不應僅儲存在電腦中或是高階經理的辦公桌裡，它們中的絕大部分資訊都不值得保密，反而應該公開出來發揮其本身應該發揮的作用。

準時化生產的工廠強調視覺化的現場管理，你可以通過簡單的觀察在5分鐘內瞭解生產現場狀態，瞭解到各小組要滿足的生產需求，生產進度和人員安排等等，而這些 都不需要動用計算機或詢問任何人。工廠廣泛運用看板、資訊提示板、改進提示版、大螢幕、訊號燈和各種標記線等方式將重要的資訊展示在辦公環境中，並授權一 線小組，維護和利用這些資訊，安排生產，做決策，解決遇到的問題。

勞動力授權就是將決定權交給那些最熟悉某種特定情況的 人，放權各個小組組織生產。小組的成員一般來自傳統企業的各個部門，共同完成具體的任務，強調敞開式辦公，配合視覺化的現場管理實現充分的溝通。這樣的小 組有助於拆除分隔各部門之間的壁壘。大家還要改變觀念，由主管吩咐做什麼轉化為小組決定做什 麼，這包括安排人員，進行改進活動，甚至包括當出現質量問題時派人拜訪客戶等等。

敏捷開發中採用幾乎一樣的方式組織開發 團隊，並授權團隊成員自我管理和決策。敏捷開發和前述的工廠一樣，利用各種視覺化方法將反映專案狀態的資訊展示出來，典型做法包括使用使用者故事卡牆和 Burn Down/Up 圖，還可能會用大螢幕或訊號燈來揭示持續整合的狀態。開放的辦公環境更利於交流，大家也更容易“嗅”到團隊中的小問題，並在問題出現時能及時主動地提供 導和幫助。

價值產生於生產現場，現場是發現和解決問題的地方也是瞭解生產現狀的最佳場所。精益生產強調“現場態度”，不要聽報告，到現場去了解情況，管理人員走出辦公室，到現場去解決問題。

軟體開發中的現場指：

• 人
• 工作環境，包括辦公環境和各種不同用途的機器裝置等
• 所有工作產出物，包括程式碼，文件，任務跟蹤系統和配置資訊等

我們要問問，這個現場是否整齊清潔，是否有沒用的東西，有用的東西是否簡單明確地存放到了唯一的位置，團隊成員是否清楚什麼時候需要什麼東西，到哪裡找？這些問題不僅要用來問辦公環境和機器裝置，更重要的是用來問問所有的產出物，尤其是程式碼庫。

敏 捷開發強調同樣的現場態度，報告離現場遠了一些，並不一定能反映出專案的真實現狀，也未必會幫助你發現和解決問題。如果懂開發，就去看看程式碼，或與程式設計師 結對開發一會；不懂得話可以和QA結對真正使用一下團隊開發的軟體，或者和需求分析人員一同分析一個新需求。這些都會讓你得到的資訊更接近專案的真實狀 態。

敏捷開發強調共享現場，而不是各自維護自己的一塊。它通過結對和頻繁地更換結對來培養每個人對現場的整體認識，為平時的決策打下基礎。團隊內部的技術討論也建立在對現場的充分認識上，避免空洞的建議。

六. 小結

綜上，準時化生產的思想強調在軟體開發過程中進行頻繁的交付，以此減少庫存，暴露並消除浪費的步驟，加快價值的流動；它強調通過客戶來拉動開發過程，確保每 一時刻團隊成員都在圍繞客戶認為最重要的軟體功能展開工作；它強調在第一時間、第一現場發現問題，並從根本上解決問題，以此將質量內建在分析、設計和開發 的過程中；它強調將與專案相關的所有人組成高度授權的團隊，通過視覺化地向團隊成員全面展示專案資訊來支援自我決策。準時化生產的思想還告訴我們，當改進 流程和實踐時，要以快速交付和高質量為目標，而成本則要端到端地考量，低成本往往是實現快速交付與高質量的自然結果。

前面提到了準時化生產和精益生產中的一些觀點和實踐，這些也僅涵蓋了其一小部分內容。還有很多其它有趣的觀點和實踐，比如持續改進、單件流、5S、全面生產維護、標準化和快速換模等等，它們對軟體開發也頗有啟發意義。

希望軟體從業者能虛心地向製造業中的先進思想學習，不要因為軟體開發中包含了更多的智力活動就過早地持懷疑態度。重要的是製造業和軟體開發行業都面臨著一些類似的問題，我們希望瞭解精益生產解決這些問題的方法，有選擇地學習和借鑑它的思路，鞏固和發展軟體開發實踐。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-374456/，如需轉載，請註明出處，否則將追究法律責任。