導讀：瀑布模型、敏捷方法的對立統一從20世紀70年代就出現了，其實本質是從不同的角度、不同的粒度去對項目管理提出的方法論，都是實現目的的手段。站在今天，我們是否可以用一個新的名稱和模型來統一取代呢？
瀑布模型是將軟件生存週期的各項活動規定為按固定順序而連接的若干階段工作，形如瀑布流水，最終得到軟件產品。1970年温斯頓·羅伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被廣泛採用的軟件開發模型。
核心思想：
瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟件生命週期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。
瀑布模型有以下優點
1）為項目提供了按階段劃分的檢查點，或者叫做里程碑。
2）每個階段嚴格區分，前一個不完成不進行下一個，當前一完成後，您只需要去關注後續階段。
3）可在迭代模型中應用瀑布模型。增量迭代應用於瀑布模型。迭代1解決最大的問題。每次迭代產生一個可運行的版本,同時增加更多的功能。每次迭代必須經過質量和集成測試。
4）它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該模板下有一個共同的指導。
5）瀑布模型把開發人員定義為流水線上的工人。比較適合規模化、流程化的大項目，便於管理效率提升，充分降低人的因素，將人作為螺絲釘功能存在具備可替換性而不影響項目的推進。
瀑布模型有以下缺點
1）各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量。
2）由於開發模型是線性的，用户只有等到整個過程的末期才能見到開發成果，從而增加了開發風險。（變化的外部市場和用户在C端市場非常普遍，B端則相對穩定）
3）通過過多的強制完成日期和里程碑來跟蹤各個項目階段。
4）瀑布模型的突出缺點是不適應用户需求的變化。
瀑布模型有個重要前提是假設條件固定，按照既定的條件和目標往前推進直至標的；好處當然是程式化，管理效率高，減少了人的因素；缺點就是那個要命的前提假設。
2. 敏捷方法首先回答#敏捷#方法是不是什麼情況都適用？
答案當然是否定的，適用背景大概如下：
①新興市場、產品、行業，充滿X，很多都是未知的，你的產品不成熟、用户不成熟、市場也不成熟，都在認知成長過程中 ②產品生命週期短、需求變化快、不可控因素增多
所以，我們不得不保持以下原則：
- 你得用盡量小的腳步，這樣你才能靈活（想想凌波微步）即時調整方向；
- 你得以少為多，化繁為簡，也就是MVP最小可用單元，你想吃火鍋的時候或許1個饅頭也可以
- 你得明白唯一的不變就是變，擁抱變化（阿里巴巴價值觀中就有這麼重要的一條）
- 你得做這一步的時候想着下一步，或者説為了做下一步做了這一步（比如微信當年推出的打飛機遊戲，其實主要是為了讓你升級版本，用的連環套）
- 你得找槓桿大的feature，力求四兩撥千斤
- 你得時刻確保你的用户（直接用户、間接用户、支持性用户）想要，你是保持接觸的
對於兩種模型：
①瀑布模型像是一條直線，給定了初始方向和力，然後沿着線條往前單向推進，直奔原定的目標，如下圖（雖然很可能達到目標時候，目標已經沒有意義了，就好比你現在要潛心開發一個新汽車發動機可以提高很多燃油效率，但是顯然新能源的趨勢不可阻擋，你的產品面世之時，説不定汽油發動機都幾乎沒有市場了）
②敏捷方法像是一個螺旋線，每個小圈就是一次迭代過程，在朝着目標推進的過程中，採用了儘量小的渦旋前進模式，像是對每一個小成果的一次驗證，迭代-修正-迭代不斷往復推進，顯然對於多變的背景是更為適用的。如圖：
敏捷強調擁抱變化，瞬息萬變的時代，哪有不變的前提。就像最近的買菜大戰，誰想到前兩年還是小玩家先烈般的探索，倒下一批又一批，今年後半段大户就一併湧入了，大户也沒想到剛湧入國家調控就出了。
敏捷vs瀑布，下面這張流傳的圖片很形象的展示給了我們答案，嚴格的階段劃分+一始而終的前進，如果缺乏必要的中間驗證和接觸，後果是多麼的離譜……
瀑布和敏捷2個陣營還進行過大辯論，網絡上相關內容也是紛紛擾擾，到最後的結果也是你中有我我中有你，各有優劣。
假如提出1個新的模型方法，是不是就可以完美解決了呢？
二、流體模型一個兼具瀑布模型和敏捷方法於一體的模型設想，這個靈感來源於大學時候流體力學那門學科。
我們先從流體力學的角度展開，如上圖，湍流和層流都是流體的一種流動狀態：
- 【瀑布狀態】當流速很小時，流體分層流動，互不混合，稱為層流，也稱為穩流或片流；
- 【混沌狀態】逐漸增加流速，流體的流線開始出現波浪狀的擺動，擺動的頻率及振幅隨流速的增加而增加，此種流況稱為過渡流；
- 【敏捷狀態】當流速增加到很大時，流線不再清楚可辨，在流場中有許多小漩渦，層流被破壞，相鄰流層間不但有滑動，還有混合，從而形成湍流，又稱為亂流、紊流或擾流。
流體模型——正是基於瀑布和敏捷的兩種理念的交融：
①瀑布狀態（層流狀態）
如同流體模型中的層流狀態，這時候流速很小，也就是外界環境相對穩定不存在多變的條件、複雜的背景。整個產品開發和項目管理流程按照有序的狀態和嚴格的先後次序進行流水線開發及管理。
②轉換條件（過渡區）
隨着外界複雜性，變化速度的加快，層流形式（即瀑布模型）不再能夠適應環境。在產品和項目的場景中，外部條件包含：市場的變化、用户需求的變化、政策及經濟環境變化、競品市場變化；內部條件有：戰略方向調整、團隊變動等。致使若繼續一味按照層流即瀑布模型會背離環境變化，導致最終偏離目標。
③敏捷狀態（湍流狀態）
轉換條件發生，模型自動轉換為湍流狀態，也就是敏捷中的小步快跑、不斷迭代、擁抱變化。
1）湍流狀態特徵
下面聊一下流體模型中轉換為湍流狀態後的特徵表現：
湍流基本特徵是流體微團運動的隨機性。湍流微團不僅有橫向脈動，而且有相對於流體總運動的反向運動，因而流體微團的軌跡極其紊亂，隨時間變化很快。湍流中最重要的現象是由這種隨機運動引起的動量、熱量和質量的傳遞，其傳遞速率比層流高好幾個數量級。
——引自湍流的物理學釋義
2）湍流特徵和敏捷不謀而合
- 湍流的軌跡紊亂，隨時間變化快——正是敏捷強調的擁抱變化，變化因素具有相通性質，看似有序的世界和環境，不過是無序的一種特徵值體現；
- 湍流有相對流體總運動的反向運動——敏捷中最小成本驗證，可以視作如此的案例。每一次驗證時一種嘗試，可能正確可能方向錯誤導致失敗，正如流體模型中湍流狀態時無序甚至和總方向相反的亂流一般；
- 湍流引起的動量熱量和質量傳遞速率比層流高好幾個量級——敏捷在不斷的找支點、放槓桿，迭代之間可以獨立且存在依託，所產生的價值槓桿對於與層流（瀑布模型）的一始而終，是不可比擬的，對於標的達成的撬動能力更是不可言喻。
流體模型，正是描述同一種流體即同一個組織在產品和項目的實現過程中，當面臨不同的外部和內部條件變化，有層流狀態（瀑布狀態）和湍流（敏捷狀態）的銜接切換，中間過渡區的存在，有瀑布和敏捷的相互結合，從而達到目的。
實際工作中，有時即便是在適用瀑布模型的項目中，也難免的採用到敏捷的方法作為支撐，比如：關鍵時期高頻的信息觸碰、外部條件的監控等；而敏捷項目中又何嘗不存在瀑布的影子，你的需求管理流程等都又是瀑布的做法；現實中已經很難再將瀑布和敏捷完全區分，共生或許已經是常態，只是存在一個“過渡區”讓二者可以自由的銜切。
4. 流體模型中將弊端也一併展示對於一種流體，在外部條件引起湍流後，一方面它強化了動量、熱量、質量傳遞和反應過程；另一方面極大地增加摩擦阻力和能量損耗。
這在組織和項目中何嘗不是呢，當我們進入敏捷狀態之後，面臨的變化、不斷迭代、時刻專注、保持接觸等，一方面會極大的促進組織活力、產品成長，激活產品生命週期曲線；另一方面，不得不承認這種節奏對精力的消耗，是所有人有目共睹的，快速的人員迭代在組織中也是常態；同時，這種狀態下各個小組或產品項目未達成自己的目標，會產生並行情況，比如在職能線的模式中，不同的產品項目就會產生較大的阻力而不得不在產品評審中殺的你死我活。
三、結語我們在不斷的探索中會走過的路有很多：一個需求的生老病死，一個項目的開始完成，一個產品的生老病死，一個組織的生老病死……
但方法終歸不是目的，它只是我們實現目的的手段，手段的目的又是為了給使用者提供更有力的抓手（溝通、協作、管理）。
本文由 @Kris_3ᶻᶻᶻ 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CCO協議