Waterfall vs. Agile

在過去參與軟體專案的工作經驗中,最常看到的就是工程師抱怨需求一直改,PM抱怨schedule一直滑,老闆抱怨release一直給不出去。這過程中,我也一直沒想出更好的解決方式。
所以當我準備要放大假時,我規劃要從學習不同的軟體開發的思維下手,看看是否能找出一個具可行性的方式.今天就先從Waterfall Development 對比Agile Development下手吧!

。乘著瀑布一路往前衝

Waterfall Development 的觀念從1970年代開始,成為了軟體開發模型中的顯學,而在我經歷的公司中(電子業的軟體部門),這也幾乎是唯一的選項. Why? 留做最後再來解釋.

Waterfall Development模式是將軟體生命周期劃分為
user requirement->requirement analysis->high level design->detail design->implement->test->release->maintain
由上而下依序進行不回頭，如同瀑布落下一般。

Waterfall的立論基礎是在認為軟體開發是predictive,也就是在專案開始之際,我們可以列出且分析所有需求,接著定義所需的時間以及資源,剩下的就是發包開工,完工後拿著最初的需求定義來進行測試,最後開心release給客戶

不過實際進行過後,你一定會發現,現實不是那麼開心:

1. 因為初期的需求分析以及high level design主宰著產品最終的結果,因此需要時間產生大量的文件(CMMI的最愛!!),而通常老闆不太喜歡你花太多時間寫文件
2. 對於需求者而言,需等到過程的後段才能確認產品是否符合預期
3. 對於開發者而言,要等到開發後期的整合或測試階段才能發現初期設計的錯誤

當然,大家也不會傻傻的看著上述問題而不處理,所以通常你會看到在開發/測試/交付發現問題時,有人使出了盧山升龍霸逆瀑布而行,重新修改需求/設計/實作

但是這也就帶來另外的問題:
1. 既然規格隨時會改,那初期的需求分析就不用太追求完美
2. 專案過程中如果需求/設計文件要繼續更新,那就要花更多時間. 而我看到的現場是很多人就不更新文件了,修改的討論及細節就存在mail或會議紀錄中
3. 當waterfall不再是線性,那當初基於軟體predictive而定出來的schedule也就無法遵循
結果勒,老闆最後看到結果的是: 最初需求是錯的,最初設計是錯的,最初的schedule也是錯的

當然,也不是說waterfall的想法是錯的,只能說這模型應該是適用於其他的工程領域(例如建築),或者你能確保專案中不會有任何人(老闆,客戶,或者隔壁部門的老王)使出廬山升龍霸

。先不談廬山升龍霸,你聽過敏捷開發嗎?

這些年,Agile Development(敏捷開發)似乎跟著web/app開發的熱潮,成了軟體業的顯學,不過在我之前身處的台灣電子業,這倒是蠻少聽到有人談論.

其實這個概念是在2001的敏捷軟體開發宣言(Manifesto for Agile Software Development)中被定義出.我相信大家都懶得點連結(即使那已經是翻成中文的網頁了),所以幫忙貼下最重要的四個價值觀:
．個人與互動 重於 流程與工具
．可用的軟體 重於 詳盡的文件
．與客戶合作 重於 合約協商 
．回應變化   重於 遵循計劃
看完的工程師們,不要如獲至寶的趕著下結論: 大推, 搞這個就不用執行流程,不用寫文件,不用管spec,不用配合schedule啦!!!
別鬧了, 你以為是呆伯特嗎?
 
相對於Waterfall認為軟體開發是predictive, Agile認為軟體開發該是adaptive(重點在快速反應現實的變化)。以Agile的思維,不將重點放在描述專案最終的模樣,而是強調當專案的需求或者設計起了變化，團隊要能夠立刻作出反應。

不過如果你是老闆,你能接受一個半年一年的案子用agile這樣的精神進行嗎?好像有點難. 因此目前Agile的主流適用範圍看來是:短期(幾周或者幾個月)完成相對較小的project/task，配合儘快將盡量小的可用的功能作階段性整合或release，讓整個project/task在life cycle可以持續改善以及加強。

用個簡單的例子說明,如果客戶要你幫他畫一張油彩畫,你們必須溝通好構圖,配色,筆觸,確定後才開工,這基本上就是 Waterfall的方式,而風險就是你可能會把人家想要的蒙娜麗莎畫成小野麗莎. 而Agile的方式是完成初步溝通後,先用鉛筆畫出草稿給客戶看看,ok後再上色. 這樣如果客戶忽然覺得你想畫的蒙娜麗莎太有肉,你還是有機會改成小野麗莎.

Agile Development提出的只是精神,因應而生的做法就不少了:Scrum, XP, Kanban, lean.....(有興趣就看看wiki吧) 這表示接著我還有很多東西可以學習,未來也還有不少東西可以分享.
(驚覺, 為何我不在離職前,先凹到公司贊助我去上課後,再翹頭勒!!!扼腕!!)

。在台灣電子業做軟體的困境

如同我前面說的,過去十年我在電子業做軟體,看到的都是waterfall的開發方式,並沒有人想到軟體業正火紅的agile. Why?

最大的原因當然是電子業的專案中,硬體部分通常可以符合waterfall核心精神:predictive且不可逆,你想想,重洗全部的PCB要花多少錢啊!!更別論IC要ECO的成本有多高. 所以老闆的硬體思維中,waterfall相當合理啊!! 可是如果硬體真的出包了??好吧,軟體改設計或者規格,畢竟不用錢!
所以我前面提到不合理的軟體開發流程變形就這麼出現了,而電子業的軟體工程師繼續爆肝,繼續delay schedule.

這個困境有解嗎? 等我有答案又有機會實踐後,再來分享吧。