敏捷系列 | 我該如何選擇瀑布式開發或敏捷式開發？
瀑布式開發與敏捷開發其實都是一種軟體開發的精神，但我該如何選擇呢？
筆者最近暫別顧問業，加入一個正在實施敏捷開發流程的產品團隊，對於我來說算是一個新的挑戰，畢竟先前在擔任顧問時，在協助客戶導入Salesforce CRM、Automation Anywhere RPA等系統軟體時，比較偏向使用「瀑布式」的開發流程來推動專案的進行，因此剛好有這個機會能夠在工作上參與到目前科技業比較主流的軟體開發流程：「敏捷式專案管理」，算是一個滿新鮮的嘗試。
因此今天想與大家分享一個敏捷式的軟體開發流程是怎麼進行，以及想深入聊聊為何系統顧問大多是使用瀑布式的開發流程，而不是使用敏捷式的開發流程？
一、瀑布式開發的精神
以前在當顧問業當系統顧問時，常常會聽到「方法論」這個詞，若從字面上來看，方法論就一個：「做事情的方法」，例如當顧問在遇到不同類型的客戶專案時，就會採用不同的方法論來應對，也就能夠有效地制定後續專案實施步驟與執行內容，然後再搭配不同的實作工具，讓客戶的專案能夠有效率地推進，因此回到軟體開發中，瀑布式、敏捷式，還是Devops他們都是一種軟體開發中的方法論，也是一種代表軟體專案管理精神。
瀑布式開發的流程
瀑布式開發，顧名思義就是一種「由上至下」的流程，上圖是一張經典的瀑布式開發流程，我們可以從圖片中看到，瀑布式開發會歷經收集需求、需求分析、架構設計、確認開發規格、系統功能開發、功能測試、上線交付這幾個環節，每個環節都是環環相扣，上一個環節不能超車下一個環節，比如我做完需求分析後，就直接進如系統功能開發，這個在執行瀑布式開發的專案過程中是不被允許的。
瀑布式開發的痛點
也是因為瀑布式開發這種「Step by Step」的精神特性，會造成軟體開發一些麻煩，例如專案團隊可能會花過多的時間在執行步驟1～4的階段，也就是收集需求至確認開發規格的環節，我們都知道市場是處於一個隨時在變化的狀態，用戶的需求也會因應市場的變化而隨時調整，因此前兩週收集與分析好的用戶需求，不一定適用於後兩週的市場情況，因此在瀑布式開發的軟體專案過程中，常常會發生用戶需求沒有辦法確認的情況，造成無法執行下一階段系統開發功能的環節。
另一個瀑布式開發令人詬病的問題在於，客戶只會參與步驟1～4的階段，當下一次客戶重新參與專案時，會一直延遲到步驟7的環節，步驟5~6的階段基本上客戶是不會參與專案的執行，這部分是由專案的開發團隊來負責，因此這會冒出幾個問題，例如「開發完的需求，不能真正符合客戶的期待」，也就是開發團隊確實依這規格書實作出系統功能，但這並不是客戶所想要的，抑或是進入系統功能開發流程後，客戶又有新的需求，這時開發團隊接獲這個需求後，可能會把它併入下一個瀑布式開發的排程中，或者納入目前的開發流程中，執行「需求變更 (Change Request, CR)」流程，但一旦新需求被列入需求變更後，有可能會造成後續步驟6功能測試時間的延後，而導致步驟7正式上線部署的時間也會延宕。
瀑布式開發的優點
除了上述所描述的瀑布式開發幾個明顯的痛點外，其實還有很多問題，這邊就不多加贅述，也興趣的讀者可以自行深入研究，也因為瀑布式開發不太是適用於現在變化快速的軟體市場環境，因此才會有人提出了：「敏捷式開發」的概念。
在說明敏捷式開發的概念之前，讓我們為瀑布式開發平反一下，雖然他是一個非常制式化(Step by Step)的開發流程，但對於軟體專案的管理上還是有幾項優點，例如他非常適合和WBS管理工具做搭配，WBS的全名為Work Breakdown Structure ，中文翻譯為「工作分解結構法」，是一個將大的執行項目拆解成數個可執行步驟的方法，並從中可以很明確地掌握每個細部項目所要花費的開發人天(Man Day)的多少，有效地規劃與掌握我們的專案所要耗費的時程。
當我們能夠有效地使用WBS工具拆解瀑布式開發各個專案環節，並落成數個執行步驟後，就可以將他們畫成「甘特圖(Gantter)」，把我們的專案進行可視化處理，並且可以於圖中邊標記「里程碑(Milestone)」，讓我們清楚知道在個環節的截止日是什麼時候，有效地掌握並推進我們專案的進度與時程。
二、敏捷式開發的精神
從上述中我們可統整出瀑布式開發有二個關鍵問題：「客戶只會參與前期的需求訪談，不會參與功能開發環節」、「一個瀑布的運作時間過長，產品功能的迭代速度太慢」，前者導致開發團隊所做出來的產品功能不是客戶真正想要的，後者導致產品的功能無法因應變動快速的市場環境，因此Jeff Sutherland，Ken Schwaber等人就提出了敏捷式開發的概念。
敏捷式開發的精神強調「對話」與「迭代」的重要性，他們希望在執行敏捷開發的團隊中，客戶與工程師可以非常緊密的坐在一起工作，每天的站立會議能夠讓在敏捷團隊中的每一個了解目前的專案的現況以及面臨到的問題，使得團隊成員彼此間無時無刻都能保持良好的夠通，而迭代則是希望每次只做一點，不要向瀑布式開發那樣一定要把所有的需求都確認後，才可以執行開發，加快整個產品功能的迭代速度，可以隨時依照客戶需求與市場變化來做調整。
敏捷式開發的問題
雖然目前市場上敏捷開發儼然已經成為軟體開發的聖經，且坊間也有許多宣揚敏捷開發的好處，因此筆者在本篇就不針對敏捷式開發的優點多做撰述，倒是想和大家分享關於一些我觀察到敏捷式開發的問題，例如敏捷式開發發長強調迭代的重要性，但不同於瀑布式開發的視角，敏捷是開發並沒有一個明確的「專案完成日期」，也就無法清楚地跟客戶說：「嘿，我只要做完12的敏捷迭代，專案就算告一段落了！」，因為敏捷式的開發一旦啟動了就會一直持續下續，除非該產品已經認為沒有必要再持續投資資源，或許才會終止，此外我們也知道在軟體開發的世界中，因為市場會一直變化，客戶需求也會一直改變，只能透過不斷地修正產品功能，才能確保產品不會被市場淘汰。
總結來說，敏捷式開發跟瀑布式開發的精神：做完！(Get Things Done )，不太一樣
敏捷式開發更強調：做到好！(Do More Better)。
三、我該如何選擇瀑布式開發或敏捷開發？
我們從上兩個章節已經能夠分別掌握「瀑布式開發」與「敏捷式開發」兩種模式所要傳達的精神，前者的目標是希望透過Step by Step的方式，把事情完成，而後者的目標是希望透過迭代Iteration的方式持續地優化，然而我們接手一項軟體專案開發任務時，我該選擇要用哪一種開發方式比較好呢？
這邊提供給大家一個判斷參考基準：若這個軟體專案的是估算出一包具體的專案金額，例如250萬，且很明確知道這個專案會完成哪幾個環節後，算是達成目標並告一段落時，那你可以考慮採用瀑布式開發來管理你的軟體專案。
使用瀑布式開發的時機
舉個例子，以前學生時期上補習班的時候，你是不是會拿著一筆錢(具體的專案金額)給補習班，補習班在收到你的錢之後，就會安排一位老師給你，在上課時老師就會開始翻開課本教材，依照著課本教材的章節，從第一章一直教到最後一章，此外你也會很明確的知道，我要歷經3個月，完成21堂課程後這個課程才會結束（很明確知道這個專案會完成哪幾個環節後，算是達成目標並告一段落），從補習班的案例中我們可以知道他們是用瀑布式開發的方式來設計、開發與執行學生的補教課程。
這也說明了為什麼市場上的系統導入廠商，如ERP、CRM、物流系統等，大多會傾向採用瀑布式開發的軟體專案管理模式，而不是選擇使用更能夠有效因應市場變化，符合客戶需求的敏捷式開發來執行專案，原因在於系統導入廠商底是以「顧問在這個專案上，需要投入多少的小時才可以完成」來估算專案的金額，因此會有一個明確的專案完成時程，以及專案的執行步驟，就像補習班的課程一樣。
因此未來若遇到該專案是具有一個具體的專案金額，且有一個明確的專案目標（達成該目標後，該專案工作算是告一段落）與完成時間時，例如大部分的系統導入軟體專案，就可以採用瀑布式開發的模式來執行。
我該何解決瀑布式開發所遇到的問題
先前有提到，當一個軟體專案選擇採用瀑布式開發時，就會遇到產品功能無法真正滿足客戶需求等問題，然而這卻很常發生在一般的系統軟體專案導入案件中，因此我們可以嘗試地將系統導入專案拆解成「正式上線前」與「正式上線後」兩個區塊來審視這個問題。
在正式上線前由於我們有專案時程的壓力，為了能夠有效地掌握專案時程並堆動轉案進行，我們會採用瀑布式開發的方式，來確保我們的系統可以如期上線，由於導入顧問會與參與專案的IT人員進行技術轉移，這時你可以採用敏捷式的開發流程來持續優化你的系統功能產品。
如果你的專案角色是乙方，也就是提供顧問服務協助客戶導入系統軟體的那一方，可以採用顧客成功(Customer Sucess)的運作模式來，縮小系統正式上線後與真實需求之間的落差，並持續達成一致，已確保以瀑布式開發的軟體專案可以持續滿足客戶的需求與期待。
歡迎繼續服用下一篇敏捷系列文章：
感謝各位朋友的支持與鼓勵!
當你／妳閱讀完這篇文章後，請依喜歡與實用程度給我1–10個拍手。
讓我能了解各位朋友寶貴的回饋意見，撰寫更優質的內容分享給你/妳!
