在正式介紹Scrum之前,先來簡單認識傳統的瀑布式開發和逐漸興起的敏捷式開發。
無論是商業組織、政府機構,還是非營利組織,都可能需要透過開發、訂製和使用軟體來創造價值。傳統的「瀑布式開發」使用預測性的設計流程,像瀑布一樣從上往下,建立嚴謹、標準的開發程序,清楚的階段劃分,易於分工及責任歸屬。
但正因為清楚、固定的階段劃分,若是要回到上個階段做更改或修正都有一定的難度,而每個階段之間產生的大量資料,也提升了工作量;由於只有最後才能看到開發的成果,大大的增加了開發風險,且不適應用戶需求的變化。因此,經常遇到以下的問題:
並不是認為瀑布式流程一定不好,只是較適用於擁有某些特定的條件下,進而取得成功,然而,在軟體開發這個環境,這些只是特例而並非常態。何謂特定的條件?當已經建立了完整的願景,而其中的要求已經定義,同時也策畫出詳細的計畫,此時就可以使用瀑布式計畫。但是,只要與原始目標、需求或是計畫略有偏差,失去控制和可預測性,就會帶來巨大的風險。
Stacey Graph是用來評估共作中的確定性和可預測性的有效工具。他能衡量不同維度工作的確定性和不可預見性,並標示出工作範圍。這3個維度分別是需求(Requirements)、技術(Technology)和人(People),如下圖所示。
簡單來說,瀑布式開發適用於沒有任何變動或不確定性,而且技術與願景又能夠完全一致且確定的組織。
FBI在2006年3月展開的Sentinel專案,初期便是使用瀑布式開發,最初的預算是4.51億美元,預期在2009年12月完工。然而到了2010年3月,FBI已經花費了總預算中的4.05億美元,卻只完成了一半的工作。2010年,他們改變了Sentinel的開發流程,導入了敏捷開發和Scrum,最終在2012年7月完成了全部的部署。
擬定計畫是有用的,但是盲目跟隨計畫是不聰明的。簡單介紹了瀑布式開發和相關案例,明天將繼續介紹敏捷式開發,之後還會再對兩種開發方法做簡單的比較。
本文同時發布於HackMD:https://hackmd.io/okFWzu3vQkqNeT327q2c_g