在正式介紹Scrum之前，先來簡單認識傳統的瀑布式開發和逐漸興起的敏捷式開發。

瀑布式開發

無論是商業組織、政府機構，還是非營利組織，都可能需要透過開發、訂製和使用軟體來創造價值。傳統的「瀑布式開發」使用預測性的設計流程，像瀑布一樣從上往下，建立嚴謹、標準的開發程序，清楚的階段劃分，易於分工及責任歸屬。

但正因為清楚、固定的階段劃分，若是要回到上個階段做更改或修正都有一定的難度，而每個階段之間產生的大量資料，也提升了工作量；由於只有最後才能看到開發的成果，大大的增加了開發風險，且不適應用戶需求的變化。因此，經常遇到以下的問題：

1. 版本發布所需時間越來越長
2. 無法按時發布
3. 版本發布的最後階段，軟體達到穩定狀態所需的時間越來越長
4. 制定計畫的時機太長，但計畫卻不夠準確
5. 在版本發布中期很難做修改
6. 品質惡化
7. 「死亡行軍」損傷士氣

並不是認為瀑布式流程一定不好，只是較適用於擁有某些特定的條件下，進而取得成功，然而，在軟體開發這個環境，這些只是特例而並非常態。何謂特定的條件？當已經建立了完整的願景，而其中的要求已經定義，同時也策畫出詳細的計畫，此時就可以使用瀑布式計畫。但是，只要與原始目標、需求或是計畫略有偏差，失去控制和可預測性，就會帶來巨大的風險。

Stacey Graph

Stacey Graph是用來評估共作中的確定性和可預測性的有效工具。他能衡量不同維度工作的確定性和不可預見性，並標示出工作範圍。這3個維度分別是需求(Requirements)、技術(Technology)和人(People)，如下圖所示。

簡單來說，瀑布式開發適用於沒有任何變動或不確定性，而且技術與願景又能夠完全一致且確定的組織。

FBI的Sentinel專案

FBI在2006年3月展開的Sentinel專案，初期便是使用瀑布式開發，最初的預算是4.51億美元，預期在2009年12月完工。然而到了2010年3月，FBI已經花費了總預算中的4.05億美元，卻只完成了一半的工作。2010年，他們改變了Sentinel的開發流程，導入了敏捷開發和Scrum，最終在2012年7月完成了全部的部署。

小結

擬定計畫是有用的，但是盲目跟隨計畫是不聰明的。簡單介紹了瀑布式開發和相關案例，明天將繼續介紹敏捷式開發，之後還會再對兩種開發方法做簡單的比較。

本文同時發布於HackMD：https://hackmd.io/okFWzu3vQkqNeT327q2c_g