為什麼選擇 Scrum：定義過程與經驗過程

有些項目相當直接且相對可預測，可以應用合理的規劃和決策工具。其他更複雜或不可預測的項目需要更多依賴自組織和創新的不同方法。

由於三個因素的融合：人員、需求和技術，大多數軟件開發項目在本質上被認為是複雜且不可預測的。在過程控制模型和項目複雜性的背景下，可以更容易地理解用於交付和管理項目的各種方法。

定義的過程——傳統的計劃驅動方法

傳統上，一旦項目開始，就會創建一個需求包，然後“簽字”。項目經理假定此簽核會產生一組固定的需求，並且現在可以開始計劃。項目經理估計完成需求所需的時間並製定項目計劃。該計劃預測項目將在某個日期之前完成，並將該日期傳達給客戶。

這種方法的根本缺陷在於，驅動一切的計劃是基於這樣一種假設，即需求是固定的並且不會改變。經驗告訴我們，從來都不是這樣。需求永遠不會固定——它們總是在變化。當需求發生變化時，計劃受到影響；因此，完成日期也需要更改。不幸的是，在許多情況下，這是不可能的，團隊必須在他們承諾的日期之前交付。這是發生重大危機並且項目開始失控的時候。

經驗過程——敏捷價值驅動方法

價值驅動的敏捷方法基於 改變整個思維方式的經驗主義 。它從一開始就假設任何預先存在的需求都不是固定的，它們會改變。

敏捷思維還假設您必須在某個日期之前交付。這種方法固定了時間和資源，並使需求未確定。對我們來說，這種方法更接近於創建軟件的現實。現在，價值驅動的整個概念非常有意義。當您有固定的時間不確定是否可以交付所有需求時（因為它們會改變，因此完成它們所需的時間也會改變），自然的反應是優先考慮需求並首先完成那些為客戶增加最大價值的人。

您可能會想，“那些在交貨日期之前沒有完成的需求呢？” 這就是您使用價值驅動方法的原因。您承認並非所有要求都將在交貨日期之前完成。要問的重要問題是您是否已交付足夠的功能來支持為客戶提供價值的系統。

軟件項目的失敗率

Standish Group 最近發布了 2015  CHAOS 報告。CHAOS 報告自 1994 年以來每年都發布，是軟件開發行業狀況的快照。今年，該報告研究了全球 50,000 個項目，從微小的改進到大規模的系統重新設計實施。今年的報告包括對成功的增強定義，著眼於以前調查中涵蓋的一些其他因素。

結果表明，要從軟件開發項目中取得成功，仍有許多工作要做。該表總結了過去五年使用成功因素的新定義（按時、按預算並取得令人滿意的結果）的項目成果。

隨著近年來敏捷開發方法的採用，可以比較敏捷和傳統瀑布項目之間的項目成果。如下表所示，在所有項目規模中，敏捷方法都能帶來更多成功的項目和更少的徹底失敗

傳統方法的問題是什麼？

傳統的基於計劃的方法本身並沒有缺陷。它只是不適合當今的軟件行業。基於計劃的方法最初是基於傳統的項目管理概念，起源於建築行業。在建築行業，基於計劃的方法是合適的：作為要求的藍圖是固定的，並且在建造建築物時可能不會改變。您可以估計建造鋼柱、澆築混凝土等需要多長時間。

傳統的基於計劃的方法適用於建築行業但不適用於軟件行業的原因在於我們控制經驗系統（如軟件開發）和控制定義系統（如建築或製造）的方式不同）。下表顯示了定義過程的特徵與經驗過程的特徵之間的差異。

看完表格不難看出，軟件開發絕對是一個經驗過程，而不是一個定義的過程。問題是多年來我們一直將軟件開發視為一個已定義的過程——而這種方法行不通。

參考

1. Standish Group 2015 年混亂報告
2. 用一個不完美的詞變得敏捷 — Greg Smith 和 Ahmed Sidky

其他 Scrum 讀物

• 3 分鐘 Scrum
• Scrum 的 5 個價值觀是什麼？
• Scrum 的演變是什麼？
• 經典項目管理與敏捷項目管理
• 為什麼 Scrum 難以掌握？
• Scrum 中的速度是什麼？
• 什麼是敏捷？什麼是 Scrum？