1913 年，美利堅工業之神——亨利福特，發明了世界上第一條流水線，汽車工業從此進入了大規模生產的時代。豐田公司提出的豐田生產系統（Toyota Production System）又為汽車工業帶來了很多先進的生產和管理理念。
先進的生產和管理理念是一個行業從小作坊走向規模化的必經之路，軟體工業雖然誕生較晚，但是發展卻非常迅速，這也同樣得益於軟體工業開發和管理理念的發展。這其中就從汽車工業吸收了很多成熟的理念。
下面，就讓我們通過這張出自 Toggle 的漫畫，來了解軟體開發模式的變遷史。
總覽
這張圖片從上向下，五個房間，分別是瀑布模型（waterfall），敏捷開發（agile），看板（KANBAN），SCRUM 和精益軟體開發（lean）。
除了瀑布模型這間小屋和其他小屋有著明顯的界限之外，其他幾種模型就像一個四合院，有著不可分割的關係，這也恰好表明，瀑布模式和敏捷開發模式是軟體工業先後經歷的兩個階段，而 KANBAN，SCRUM 和 LEAN 則是敏捷運動的產物。
OK，客官裡邊請，讓我們進第一個屋子看看。
Old Days——瀑布式軟體開發
所謂瀑布模型，就是說，軟體開發是按照一定順序展開的（傳統線性生產流程 : Traditional,linear production flow）。就像汽車生產的流水線一樣，每個部門各司其責，工作按照順序展開，交付件單通道線性流動。你看這幅圖，總體上就分為：需求 → 設計 → 製造 → 測試，四個階段。
在這個系統中，客戶被排除在生產系統之外（圍牆是密閉不透明的），它們只能從需求的介面人那裡向系統輸入需求（Client places order）。正因如此，客戶無法理解生產所需的費用以及為什麼交付總是會延期，因此，也難免會鬧出下面這樣的笑話：
客戶希望你造一輛汽車，卻只願意支付一輛自行車的開發成本。
需求接納後進入到設計階段：
設計定型後，進入製造階段：
線上性的生產系統中，或者說在瀑布開發模式中，需求和設計是不可以進行修改的。工人被安排在製造系統中一個個工位上，每個人僅負責一個部件的生產和裝配，就像這位盤腿坐著的“I know HTML”大哥一樣，HTML 開發者只需要負責 HTML 的開發而無需，也不應該關心軟體的其他部分。
喂喂喂，這位老鐵，不上班玩什麼球啊？哎，您也別怪他，畢竟交付件（整車/軟體）還沒有完成開發，測試工作自然無法開展，當然得等著咯。這也是瀑布模型最大的弊端，下游工作的開展嚴格依賴於上游交付件的完成情況，這無疑是一種浪費，在爭分奪秒的軟體開發過程中，你能忍受這種浪費嗎？
汽車完成生產和測試之後，一次性交付到客戶手中，完成客戶的全部需求。
走進新時代——敏捷開發模式
敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態
有點書面是吧，其實很簡單，敏捷開發的一個前提假設是：使用者不可能在產品開發之前，設計之初就完整、明確的提出需求。期望使用者在開發過程中不變更需求是不現實的。使用者在開發前提出的需求，可能並不是它們最終希望得到的。
在敏捷開發中，客戶會參與到軟體開發的整個流程中。整個開發過程不再是一堵不透風的牆，透明是關鍵（TRANSPARENCY IS KEY），但是，隨著越來越多的使用者參與進來，越來越多的問題也暴露出來了，越來越多不著調的需求也會被提出。
敏捷開發的另一個重要概念就是迭代，所謂迭代，就是不斷對產品進行細微的、漸進式的改進（Small incremental changes）。
“先給您上個小號的尾翼，用著好我再給您換個大的~”
在敏捷開發中，生產不再是線性的，開發的同時還會進行測試工作，所有人都在同時工作。尷尬等待的日子一去不復返咯~
利用敏捷模式開發出的產品，相較於傳統的軟體交付方式，一個顯著的特點是能夠及時響應客戶需求的變更，不斷適應新的趨勢。
這不，隔壁老王喜當爹了，之前定的法拉利顯得有點不穩重，寶寶也沒地方坐。我們的產品經理和開發人員快速響應，轎跑變商務也不是什麼大問題~~ 當然，為誰辛苦為誰忙，客戶爸爸們一定要買單呀！
什麼？您問第一稿方案是什麼樣的？去翻垃圾桶吧！ 
一股來自東方的神祕力量——看板
相信各位也注意到了，相對於瀑布模式的井井有條，敏捷開發在靈活的同時，也帶來了一定程度的混亂。
就在這個節骨眼上，還得請這位來自東方的神祕人物——豐田看板大師（KANBAN SENSEI）給你點撥點撥。
KANBAN，不是漢語拼音，更不是英文縮寫，它來自日語“看板”，カンバン的羅馬拼寫：Kanban。它正是豐田生產系統的一個重要概念：
看板管理，常作“Kanban管理”，是豐田生產模式中的重要概念，指為了達到及時生產（JIT）方式控制現場生產流程的工具。及時生產方式中的拉式（Pull）生產系統可以使資訊的流程縮短，並配合定量、固定裝貨容器等方式，而使生產過程中的物料流動順暢。
KANBAN要求把開發中的任務，以 TODO List 的方式表現出來：
形式可以是即時貼，也可以是視覺化軟體等等。
在製造業中，看板也是非常重要的管理方法。也有將其稱為目視化管理的。
SCRUM 又是什麼？
Scrum原始含義是指英式橄欖球次要犯規時在犯規地點對陣爭球。爭球雙方各有8個隊員參與，各方出3名前鋒隊員，並肩各站成一橫排，面對面躬身互相頂肩，中間形成一條通道，其他隊員分別站在後面，後排隊員用肩頂住前鋒隊員的臀部，組成3、2、3或3、4、1陣形。然後，由犯規隊的對方隊員在對陣一側1碼外，用雙手低手將球拋入通道，不得有利於本隊。當球拋入通道時，前排的3對前鋒隊員互相抗擠，爭相踢球給本方前衛或後衛隊員，前衛和後衛隊員必須等候前鋒將球踢回後，方可移動
在敏捷開發領域，SCRUM是一種迭代式增量軟體開發過程，它包括了一些預定義的角色：
- 產品負責人 Product Owner
產品負責人負責維護訂單
- Scrum主管 Scrum Master
SCURM Master 對整個SCRUM 過程負責，不惜一切代價（AT ANY COST），保證團隊的工作時間和計劃。
- 開發團隊 Team
在 SCRUM 過程中，開發團隊通常會進行衝刺 （Sprint），一個衝刺週期的長度通常是2-4周。
在這個衝刺過程中，開發小組專注於完成一組訂單項的開發。比如：製造一個發動機 
對於KANBAN 和 SCRUM，有人說 KANBAN vs SCRUM，也有人說 KANBAN+SCRUM，究竟誰是誰非，我看只有適合自己團隊的才是最好的，畢竟方法和流程是為業務服務的。就這篇漫畫來看，SCRUM + KANBAN 是兩個避免混亂的好方法。
來來來，兄弟們，我們來開一個關於減少站會的站會~~
精益軟體開發
第二次世界大戰結束後，豐田公司前社長豐田英二曾經去美國汽車城底特律對福特生產線進行了考察，儘管福特高效的大規模生產線給他造成了很大的衝擊，豐田英二還是非常理智的認識到了當時日本製造業所面臨的困難。經濟蕭條，資源短缺，小批量差異化的需求使他不能盲目的引進這種大規模的生產方式，隨後豐田公司發明並實踐了一系列的管理和生產方法，這些方法在後來被統稱為精益生產和管理方式（lean）
精益生產的思想， 簡單來說就是Just In Time（JIT），也就是說，只在必要的時候，按照需求的量，僅生產必要的產品，杜絕浪費。
Eric Ries曾在《精益創業實戰》中提出MVP（minimum viable product）概念，意即“最簡可行產品”——用最快、最簡明的方式建立一個可用的產品原型，這個原型要表達出你產品最終想要的效果，然後通過迭代來完善細節。
精益軟體開發不再像傳統的軟體開發一樣，耗時幾年才向客戶交付完整的軟體。取而代之的是，優先建立一個最簡可用的原型產品投放市場或交付到客戶手中。
一輛最簡可用的汽車是什麼樣子的呢？不就是四個輪子、一個方向盤、一個座椅然後一起裝在底盤上麼。能開、能停、能轉彎不就是汽車嘛。讓客戶先享受到產品帶來的收益是最重要的。
BUT!!!
你看，這裡還有一位失落的大叔
儘管MPV 的概念聽上去是如此的簡單，可是實施起來卻沒有那麼容易。
因為在設計產品原型的過程中，很多設計師是這麼做的：把他們認為的產品應當具備的功能羅列出來，然後一一排除，排定優先順序，決定哪個功能要在最初的版本中出現，而哪個可以靠後一些。但設計師們往往無法真的只把最必要的功能留在初級版本中——因為誘惑太多。設計師們總希望把很cool、很有驚喜的小細節帶給使用者來博取讚歎，但從全域性來看，其實把某些功能刻意強加進產品，是會削弱產品整體流暢性的。Mr Jamie曾在其部落格中把這種心理表現稱作“藝術家心結”。
所有不必的東西（ALL NON-ESSENTIALS ARE THROWN OUT）都不能應用到當前的最小可用產品。你說，藝術家們得多傷心啊（愁的鬍子都長一臉了）
此外，儘早交付產品給客戶或部署到生產環境，也促進了 DevOps，持續整合（CI），生產環境測試（testing in production）等實踐的發展。儘早交付產品，儘早從使用者獲取反饋，不論是好的還是壞的，促使問題儘早暴露，儘早修復，持續整合，持續改進。
眼尖的童鞋，估計早就看到了桌子上有一隻程式設計師的好朋友 —— 小黃鴨。你還不知道小黃鴨？那你該看看這篇文章：《小黃鴨除錯法，每個程式設計師都要知道的》。
結束語
實際工作中的軟體開發和管理模式，往往並不能純粹的歸類於以上某種型別。即使是相同的開發模型，在不同的團隊中也往往會根據實際情況進行變化和改進，留言告訴我們你所在的公司是如何進行軟體開發的吧~
此外，如果你對我的解析有不同的看法，或者你在圖中看出了新的內涵，也歡迎在評論中互動！
擴充套件閱讀
- [1] kanban vs scrum vs agile
- [2] Scrum vs. 看板，還是Scrum + 看板？
- [3] 精益軟體開發
- [4] 使用 DevOps 進行精益軟體開發
- [5] 豐田生產系統
打賞支援我寫出更多好文章，謝謝！
打賞作者
打賞支援我寫出更多好文章，謝謝！
任選一種支付方式
