DMA01
敏捷式開發 vs 瀑布式開發

敏捷式開發 vs 瀑布式開發

Scrum/Waterfall comparison

寓意科技

藉由本章節,你會學到: (1) 什麼是敏捷開發、 (2) 敏捷式開發與瀑布式開發的比較、 (3) 敏捷開發的適用性。

---

敏捷開發已經刮起炫風一陣子,或許不乏聽到你身邊的朋友說:「我老闆說要跑 Scrum。」或是你自身就經歷過老闆這麼說:「我們要跑敏捷開發,敏捷就是快!我們快還要更快!」。甚至在提到敏捷開發的同時,也會相較傳統我們最常聽到的瀑布式開發。那麼,什麼是敏捷式開發?跟瀑布式開發又有什麼樣的不同?

敏捷式開發 vs 瀑布式開發

瀑布式開發是一個傳統的項目管理方法,在瀑布式開發中會經歷幾個階段:從一開始的需求分析設計,全數確認完成以後就會將相關的文件交付給開發單位進行開發,開發完成以後,再將文件與開發出來的產品交付給測試,測試完成以後進行線上佈署,最後就是後續的維護服務,具有順序步驟且無迭代。在瀑布式開發模式中,認為需要將專案的需求、目標、範疇和時程等部分都制定的非常清楚後,才能夠足夠進行相關的風險評估,好開始進行這個專案。

俗話說按圖施工保證成功,但是事實總是事與願違,尤其在開發中可能會有其他意料之外的事情發生;或者好不容易花了一年半載完成的專案,卻發現市場已經變了(當初我的專題就是遇到這樣的狀況,專題開始的時候根本沒有所謂的 android,但是在專題發表的時候,那時是android 崛起大約半年,就被老師詢問:「你們為什麼要做一個不入流的產品?」),更或者專案做到一半要求變更,於是又重新從跑了前面所有流程,並且再次重新畫押。於是,就出生了另外一種開發模式。

敏捷式開發主要精神就是在於「快速迭代」,如果專案的時間是一年,那麼他不會在一年後才有成果、產品的交付,而是會訂一個短週期,通常會訂在 1週 到 4週之間。團隊需要在每個短週期中交付出一個可被使用的產品,進而去推進去市場或是交付到顧客手中做驗證,得到回饋後再進行下一次的迭代改進。其中有幾個代表性的方法,像是Scrum、Kanban Method 或是 Lean 等,都是基於敏捷原則的框架或是方法。

 

於是同樣一年的時間下,使用敏捷式方法期間可能就已經迭代了三次產品,而使用瀑布式開發方式的團隊需要到最後一刻才會有產品上市被驗證。

什麼時候選擇什麼方式?

敏捷式開發方法並不是唯一解,瀑布式開發並不是一無是處,敏捷式開發的出現,不如說是提供一個可以解決問題不同的方法,最重要的是依照專案的特性去找出適合的方案。

那我們應該要如何判斷此時使用什麼樣的方法更好呢?這時候你可以參考 Stacey Matrix 來做判斷。原始的 Stacey Matrix 其中是使用 Agreement(共識度) 和 Certainty(確定性) 兩個維度,定義了Simple(簡單) Complicated(繁雜) Complex(複雜) 和Chaotic(混亂) 4個區域,是用來幫助公司評估決策的複雜度。


 

我們將維度做一個轉換,把Y軸的 Agreement 換成軟體開發中的 Requirement 需求內容,如果需求的內容是所有人都非常清楚,而且對於目標也是有一致性的認同,那麼就會越靠近初始軸;把X軸的 Certainty 換成我們對於技術的掌握程度,如果對專案中所使用的技術知識是非常充足的,那麼也就最靠近初始軸,反之亦然。

這時候我們來看這四個區塊

Simple(簡單) :目標清楚,技術清楚,這種流程固定方法固定沒有變化的專案,適用瀑布式開發。

Complicated(繁雜) :如果需求有點不明確,但技術難度不高,此時不管是瀑布式或是敏捷式方法都適用;如果處在需求算是明確,但是技術部分具有不確定性時,就建議採用敏捷方法。

Complex(複雜) :不僅需求不明確,甚至也存在技術上的複雜程度,為了要降低不確定性,此時建議採用敏捷方法,並推薦使用 Scrum,藉由每個週期的快速迭代,持續產出來實驗效果。

Chaotic(混亂) :這是一個很糟糕的處境,需求十分不明確,技術的採用也具備高度不確定性,專案具有高度的風險,此時建議採用敏捷方法,並且推薦使用 Kanban Method,在這個方法中,強調項目需要持續產出,流程中不斷流動,可以藉由找出瓶頸逐步找出更明確的方向。

瀑布式開發方法,在開始任何工作之前必須進行大規模的前期計劃。如果在所有目標和步驟都非常明確的情況下,使用瀑布式開發會與使用敏捷式開發得到一樣的結果,更甚至因為一開始就有明確的任務排序和優化資源分配,還更優於敏捷式開發模式。

而敏捷式開發方法,對於需求和技術使用上有不確定的因素存在時最適合使用。因為藉由敏捷式開發的特性,先以最小的範圍去作出一個可交付的項目,逐步逐步的修正,使得原本模糊的方向,逐漸清晰,在成員不斷密切調適協作下,來完成專案項目。

結論:使用敏捷開發並不等於快速

是的,並不是像老闆說的「用了敏捷專案就會變快」,不如說持續使用敏捷式開發後,團隊對於需求的變化、突發的狀況,會更有彈性的去調整,如果你的專案符合 VUCA (Volatility 易變性、Uncertainty 不確定性、Complexity 複雜性、Ambiguity 模糊性),基本上就會建議你採用敏捷式開發,如果你的專案是屬於從前面就可以看到後面的類型,那麼使用瀑布式開發是沒有問題的。

 

這堂課結束了,那麼請你思考兩個問題:

  1. 現在公司的運作模式是使用哪一種呢?那你也認同嗎?還是覺得更適合哪一種模式呢?

  2. 你覺得你每一天,是使用敏捷式生活還是使用瀑布式生活?為什麼呢?


 

寓意科技
寓意科技

寓意科技提供專業的及系統資訊科技管理顧問服務,協助企業規劃並完成軟體建置

fable寓意科技官方網站:https://www.fable.com.tw/

fable寓意科技 Medium:https://medium.com/@fableltd

淺談線框圖(Wireframe)
嚴格來說,真正製作完成的 Wireframe 是一種描述產品規格的技術文件,Wireframe 告訴團隊的設計師與工程師們如何執行計畫,讓專案的開發者們能夠確認規格流程、判斷難易度、評估所需時程等訊息。
Project delivery
Step 1:Go to market plan, Step 2:User onboarding flow, Step 3:Deployment plan
遠端(距)工作的風險與挑戰
對於一個遠端工作者來說,主要會遇到的風險有 1.個人品牌/信任問題 2.管理成本(個人/企業) 3.資訊落差/溝通成本 4.資安風險 5.結果就是一切