他山之石——來自生產製造業的啟示

軟體開發業的人常喜歡用生產製造業來比喻軟體開發業的事情。由於對生產製造業的不熟悉，而是根據臆斷和推測來進行的比喻，常常出現錯誤的結論。為此本文特地就生產製造業的情況和軟體行業的類似於不同進行說明。

1. Working Cell
      提起生產製造業，第一印象往往都是生產線。但是生產線已經是在軟體業出現之前的事情，如今的生產製造業早已經不是以前那種生產線的時代了。生產製造業以前是採用生產線的方式進行生產，生產線把生產工序分成各個階段（熟悉吧？），每個階段生產的產物都是下個階段的輸入。

     生產製造業目前採用的方法叫做Working Cell。Working Cell是把生產人員分成各個工作小組，每個小組負責原來生產線的所有步驟。這麼做的主要目的是為了能夠避免由於生產線的某個環節出錯而導致整個生產線的等待。如果某個工作小組出錯了，不會導致整個生產線的停止。

    軟體行業早期也是類比了生產線的方式，把軟體的生產過程分成多個工序：需求分析、概要設計、詳細設計、編碼、單元測試、整合測試、系統測試....和生產線方式一樣，某個環節出現延誤則後續環節需要全部延誤。這就是軟體生產中總是發生延期的原因。和Working Cell一樣，軟體生產的時候如果採用迭代方式進行開發，則不會由於某個環節的延誤而導致其他環節的延誤，這也是為什麼敏捷開發可以“保證交付”的原因。

2. Cross functional team
      為了能夠實現Working Cell需要技術上的支援。技術工人從單一職責的車工鉗工等變成具備多種技能的工人，否則他們無法操作各種機器和進行各種加工工作。這種由多種技能的工人組成的團隊叫做Cross functional team。

      在軟體開發過程中有一種做法：把軟體功能分成各個層。
      一種常見的分法：UI層需要Javascript則由前端工程師完成，DB層由SQL專家完成，業務層由Java工程師完成。於是所有人都不熟悉軟體的整體結構。由於每個人都只注重自己的部分，導致整個軟體開發的時候各個人只關心自己的代碼而失去整體觀，乃至於很常見的一種情況是軟體開發都完成了，還不知道這個軟體是幹什麼用的。另外一個問題是：軟體開發人員經過一個項目之後技能上也沒有什麼成長。

　　在軟體開發過程當中，如果也採用Cross functional team，那麼情況就不同了。
　　首先，通過每個人對每種技術都要時間這種情況來說，每個人在每種技能上都會得到提升。不必過於擔心由於不夠深入瞭解某種技術而帶來的開發效率上的損失，因為從長遠利益上來說，技術人員在技術上的提升會對開發效率有大幅度改善。

3.Stop the line

     當生產線出現問題的時候，工人伸手拉一下生產線上的拉繩，生產線就立即停止。因為現在生產線上採用了高度的自動化。產品在不停的生產出來。但是當生產線出現問題的時候，如果不儘快停止生產線，那將會不停的生產不合格產品。當生產線停下來，發生問題的原因被清除以後，生產線就可以繼續生產合格的產品了。

     軟體開發何嘗不是如此呢？軟體開發過程中，直到測試為止，軟體的品質並不清楚。這就好像在生產線上不停的生產不合格的零件一樣，最終將品質把關交給了測試環節。

     軟體開發如何建立Stop the line機制呢？測試先行。當出現問題的時候禁止簽入代碼，直到問題被徹底解決為止。

     關於這個我將在《你不知道的組態管理》中詳細講解。

 4.5S

    5S是工廠管理方式的一個重要環節，它是確保產品品質的一個重要方式。
5S分別是：
    Seiri        （整理）
    Seiton     （整頓）
    Seiso      （清掃）
    Seiketsu （清潔）
    Seitsuke （素質）

    很多軟體企業也在實行5S，他們規定員工必須整理案頭，使之符合5S的要求。但是軟體開發人員更應該將其程式碼程式庫進行5S。很多無經驗的項目中，軟體的組態管理一塌糊塗。代碼到處亂放（若干個版本或者分支並存），文檔沒有歸類，常常這裡和那裡都分不清，代碼中到處殘留垃圾檔案以及垃圾代碼，代碼的簽入簽出隨意性很強，許可權胡亂分配。等等問題很多。儘管案頭很乾淨，這樣的企業也無法說其做到了5S。

　　程式碼程式庫裡應該管什麼，應該怎麼管，分支、標籤應該如何用，什麼時間應該簽入，怎麼才可以簽出。關於這個我將在《你不知道的組態管理》中詳細講解。   

最後特意向大家推薦《豐田生產方式》。