[Day01] Scrum 30天學習日誌 - 傳統瀑布式開發
===

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

## 瀑布式開發

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

但正因為清楚、固定的階段劃分，若是要回到上個階段做更改或修正都有一定的難度，而每個階段之間產生的大量資料，也提升了工作量；由於只有最後才能看到開發的成果，大大的增加了開發風險，且不適應用戶需求的變化。因此，經常遇到以下的問題：
1. 版本發布所需時間越來越長
2. 無法按時發布
3. 版本發布的最後階段，軟體達到穩定狀態所需的時間越來越長
4. 制定計畫的時機太長，但計畫卻不夠準確
5. 在版本發布中期很難做修改
6. 品質惡化
7. 「死亡行軍^[死亡行軍(Death March)：被迫行軍的戰俘或被驅逐出境的人們，通常會因刻意的過勞或遭受虐待而無法跟上隊伍，此情況可能持續到整個隊伍的人們都死亡。在此意指即便一個專案註定要失敗，或團隊成員已過度疲勞，該專案的成员仍需被迫按照上級的指示繼續此專案。詳情請參見WIKI。]」損傷士氣

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

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

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

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

---

## 小結
擬定計畫是有用的，但是盲目跟隨計畫是不聰明的。簡單介紹了瀑布式開發和相關案例，明天將繼續介紹敏捷式開發，並對兩者做一點比較。