敏捷or瀑布：你還在糾結嗎？

工程開發(fā)的本質與瀑布模型

自然界的系統(tǒng)大致可以分為兩種主要的類型，一種是自然形成的，一種是人工制造的。我們在這里只關注人工制造的系統(tǒng)。因為其涉及到工程開發(fā)，所以，可以將其稱為：工程系統(tǒng)（Engineering System）。工程系統(tǒng)實現(xiàn)的過程就是工程開發(fā)的過程。

所有的工程開發(fā)，起點都始于需求。無論是一部手機，還是一架飛機，甚至是一棟建筑，它們被開發(fā)出來的目的都是為了滿足某種需求。因為，如果這些系統(tǒng)不能滿足某種特定的需求，就不會有人去花費時間、金錢和體力去實現(xiàn)它。

當需求基本確定了之后，接下來要做的就是進行設計。此時需要做的是確定這個系統(tǒng)使用在什么樣的環(huán)境內，有哪些主要的組成部分（組件），它們之間是怎么連接（結構）的，需要滿足哪些標準（原則）等。這個相當于系統(tǒng)架構的設計，或者是系統(tǒng)的詳細設計。如果系統(tǒng)復雜到需要多個人參與設計，那么架構設計就是必不可少的。負責設計架構的人把系統(tǒng)分為多個子系統(tǒng)，并規(guī)定好每個子系統(tǒng)的邊界和接口等一系列要求，再由相應的人進行更詳細的設計。

設計完成之后，就是開始實現(xiàn)了。這個時候，施工隊入場了，不同的人負責不同的工作。對于電子產品來說，要有軟件、硬件工程師。對于建筑來說，需要泥瓦工、水電、油漆等工種。不論產品如何，這個階段大家都是按照上面的設計來進行實現(xiàn)。

施工完成后，需要做的是驗收。不管產品是哪一種，驗收都可以分為兩類：驗證（Verification）和確認（Validation）。驗證活動檢查的是產品是不是按照設計實現(xiàn)了，確認檢查的是產品是不是確實是用戶想要的。對于建筑物來說，設計的時候是10層樓，結果蓋成了9層樓，那么就是不合格的，因為不符合設計?？墒侨绻O計的時候就注明了每層樓高2米，而客戶需要的是3米的層高，那么即使驗證合格了，確認環(huán)節(jié)也不合格。

在驗收結束后，產品就可以交付給用戶使用了。在一段時間內，產品的提供方還需要持續(xù)的對產品進行維護，產品出了問題時，產品的提供方就需要及時給解決。這個過程相當于售后的質保。

以上的過程就可以采用瀑布模型（Waterfall Model）進行表示。

瀑布模型的發(fā)展經歷了幾個階段，1956年在一篇關于軟件開發(fā)的論文中首次提到。在接下來的幾十年里，它被不斷完善，最后被美國國防部采用，作為承包商需要遵循的標準。瀑布模型描述了一種按照一定順序處理開發(fā)過程步驟的方法。

瀑布模型中，所有的工作都是順序的，是一層層流下來的，像瀑布的水流一樣，是單向的。純粹的瀑布模型的本質是，在進入下一個步驟之前，必須完全完成本步驟的所有任務。看起來邏輯很通順，但實際應用的時候卻可能會遇到很多問題。因為，需求（Requirement）可能不全或有錯誤，設計（Design）的過程中可能會出錯，實現(xiàn)（Implementation）也可能會出錯，從而導致理想的瀑布模型會不適用于很多復雜的場景。如果完全按照這種模式開發(fā)，就可能出現(xiàn)不斷重啟所有環(huán)節(jié)的情況。

實際的開發(fā)過程中，往往很少完全按照瀑布模型開展，產品一般都要經歷多次迭代。我們所熟悉的水果手機也不是在一出現(xiàn)就這么NB的，而是從1,2,3,4……一代代發(fā)展而來的。

從上面的討論我們可以看出，所有的工程開發(fā)都是從需求開始的，要經歷需求-設計-實現(xiàn)-驗證-維護的階段。瀑布模型反映的就是這個本質。

敏捷開發(fā)

開發(fā)背景下的敏捷（Agile）一詞最早出現(xiàn)在2001年的猶他州的雪鳥會議上。在這場傳奇性的會議上，一些軟件人士聚集在一起，討論軟件編程的革命性方法。雖然那時極限編程（與Scrum相當相似）已經建立，但許多人仍然對沉重的軟件開發(fā)過程和非常長的開發(fā)時間感到沮喪。復雜的系統(tǒng)如航天飛機的開發(fā)時間超過了20年。

猶他州的那些人創(chuàng)造了敏捷宣言 [ https://agilemanifesto.org/]，描述了敏捷開發(fā)的主要原則，但其根源可以追溯到20世紀60年代人們開始嘗試快速開發(fā)之時。Scrum這種最流行的敏捷方法之一，也是在1995年初開發(fā)的。

《敏捷宣言》描述了12條原則，如下：

• 客戶的滿意是最優(yōu)先的。
• 在整個開發(fā)周期中，需求可以被改變。
• 在較短的周期內頻繁地交付工作軟件。
• 開發(fā)人員和業(yè)務人員需要有很好的聯(lián)系。
• 能夠對開發(fā)人員產生信任和激勵的支持性環(huán)境是關鍵。
• 自組織的團隊是高質量的關鍵。
• 團隊本身定期反思改進自己。
• 面對面的會議和同地辦公始終是首選。
• 可以工作的軟件是衡量成功的主要標準。
• 卓越的技術和強大的設計是持續(xù)關注的焦點。
• 簡潔性是必不可少的。
• 可持續(xù)發(fā)展和持續(xù)的步伐是敏捷的本質。

敏捷是項目管理和開發(fā)過程的混合物。Scrum以及Kanban可以被認為是純粹的項目管理方法。其他的敏捷方法，如測試驅動開發(fā)、結對編程和持續(xù)集成，則是在軟件開發(fā)或是質量保證方面。

敏捷開發(fā)中，與軟件有關的和與人有關的主題被很好的整合了。這就是敏捷的關鍵因素之一：工程師和他們的合作是成功的關鍵。對于那些習慣于以孤立的方式工作而不合作的人來說，他們無法通過Scrum這樣的項目管理方式來管理。

敏捷開發(fā)方法的主要特點是通過小型團隊的合作來實現(xiàn)快速迭代。但仍然遵循著需求、設計、實現(xiàn)、驗證的流程，這一點與瀑布式并無不同。與瀑布式開發(fā)不同的是，它的每一輪迭代的周期要小得多，通常以周為單位。它們的創(chuàng)建是為了快速交付并從用戶或利益相關者那里獲得早期反饋。這樣做的好處是，產品能更快地到最終用戶手中，而且反饋也能更快地回到開發(fā)團隊中。團隊致力于根據(jù)反饋和優(yōu)先級迅速調整方向，所以上述所有問題都通過短的反饋周期和透明度來解決。最后，團隊致力于持續(xù)改進。每個沖刺結束時都有一個回顧會，每個人都有機會發(fā)言，討論下一輪可能進行的改進。

敏捷還是瀑布？

究竟應該采用哪種開發(fā)方式？這個問題就像一個人問：應該吃蔬菜還是肉呢？如果籠統(tǒng)的回答，就只能是：看情況了。

不同的公司、不同的項目有不同的特點和要求，無法一概而論。簡單而言，敏捷更適合那種需要不斷快速試錯的項目，而且對團隊能力的要求很高。當需求不清楚或實現(xiàn)方案不清楚的時候，采用敏捷方式可以快速交付原型產品，得到客戶的反饋，并能夠讓團隊聚焦在高優(yōu)先級的任務上，從而提升交付效率。

然而，對于那些需求清晰、團隊規(guī)模大的項目，敏捷則并不一定能夠發(fā)揮很好的作用。這種情況下，如果有很好的架構設計，每個模塊或子系統(tǒng)的接口、邊界和需求都清晰的時候，每個子團隊完全可以按部就班的開展工作，每個人都有明確的職責和角色，也無需每兩周就交付一個版本，只需要按照既定的里程碑工作即可。此時，傳統(tǒng)的類似瀑布式的開發(fā)可能更為合適。尤其是在那些增量型的項目中：很多人在一個平臺上修修補補，只要大家能夠各司其職，有人在統(tǒng)一管理也就沒有問題了。

敏捷在很大程度上還涉及團隊精神、團隊授權和合作。如果一個團隊中的氛圍不好，也沒有得到充分授權，那么采用敏捷也無法提升效率。另外，假如每個工程師都需要同時負責多個項目的事情，敏捷也沒有辦法開展起來。

在有些人的眼中，瀑布就代表著落后，敏捷就代表著先進，這個未免有失偏頗。如同青菜與肉、跑車與拖拉機一樣，沒有好壞，只有適合與否。而且，我還從沒有看到過那個項目是完全按照瀑布式開發(fā)的。所有的項目都是按照計劃在最終版發(fā)布前有多個過程版本發(fā)布的，這也就是說，實際工程開發(fā)中也是按照敏捷的思想在開展的，只不過形式不同，迭代的周期不同而已。

當你的軟件項目有幾十個開發(fā)人員，產品規(guī)模遠大于一個團隊所能開發(fā)的規(guī)模，而且還需要快速地進行交付，那該怎么辦？業(yè)界已經定義了一些方法來將Scrum擴展到更大的軟件產品。擴展的Scrum方法包括Nexus、LeSS（Large Scale Scrum）和SAFe?（Scaled Agile Framework）?；镜乃枷胧牵盒〉拈_發(fā)團隊向更高層次的團隊交付，以此類推，直到完整的產品完成?？赡苄枰恍┬碌囊?guī)則、工件、團隊和會議。

在古老的汽車行業(yè)，雖然軟件越來越重要，但軟件不是汽車中的唯一組件，軟件還需要與硬件和機械相結合才能有用武之地，軟件的開發(fā)也要匹配整車開發(fā)的時間線和SOP節(jié)點的要求。

總結

1. 開發(fā)的本質都是要從需求開始，經歷需求-設計-實現(xiàn)-驗證-維護的階段。只不過不同的項目或不同的組織選擇了不同的迭代周期和開發(fā)方式。不同復雜度的產品經歷的迭代輪次不同，開發(fā)周期也不同，但目的都是相同的：滿足需求，交付系統(tǒng)！

2. 如果從大的時間尺度來看，所有被持續(xù)更新的工程系統(tǒng)都是逐漸增長起來的，這與敏捷的思想很接近。產品都是從簡單到復雜的，功能是逐漸增長的，大樓也是一層的蓋起來的，汽車在剛剛出現(xiàn)的時候與現(xiàn)在所看到的完全不同，Windows操作系統(tǒng)也是逐漸演進的，控制器的軟件也是演進而來的。

3. Kanban和Sprint等都是一種工具或方法，而工具和方法都必然有自己的適用范圍，在不同的情況下，要靈活使用，沒有萬能的工具。

4. 選擇敏捷還是瀑布，需要考慮的點很多，至少包括：團隊規(guī)模，項目規(guī)模，開發(fā)需求是否明確，人員能力，人員穩(wěn)定性，團隊氛圍，項目是否需要持續(xù)維護等。

5. 當需求明確，技術方案也明確，也就是比較簡單的時候，使用瀑布。當需求不明確或技術方案不明確，使用敏捷。

6. 敏捷的好處是減少試錯成本，快速交付，不斷優(yōu)化開發(fā)過程（資源、能力、流程等）。

7. 敏捷也是一種流程，而非沒有流程。

8. 敏捷與瀑布并非對立的，如同青菜與肉一樣，兩者的適度結合才能有更好地產出。敏捷是一種思想和意識，而非教條。

最后，想說的兩點是：

1.如果你的項目不是一錘子買賣，也就是還需要不斷迭代升級和維護，那么還是老老實實寫好文檔。這與敏捷還是瀑布無關，因為你的團隊不可能沒有人員變動，人員也不可能永遠都清楚地記得自己幾年前做了什么。

2.看清事物本質就不會迷茫，盲目的采用敏捷并不能保證效率一定高。瀑布還是敏捷，本質上都是一種方式，靈活的在不同的時期采用不同的方式才是明智之舉。固執(zhí)的認為某種方式可以普適于所有情況，就是守株待兔、刻舟求劍、枉曲直湊！