序
建構軟體並非易事。雖然一開始就想好要做什麼，但真的開始動工後，可能中途需求就改變了，還會 出現各種新的要求。建構軟體可能會花很長的時間，甚至會造成失去其原本意義，而花費了龐大費 用，得到的成品也不見得能達到期望。
在建構軟體時，真正重要的是什麼？就是實際使用軟體成品解決客戶和使用者的問題，賺取回報，也就是取得實際成果。建構軟體本身不是目的，而是取得成果的手段。因此，需要弄清楚為何要建構軟體，並時常確認目前所為是否真能達成其效果。在此過程中，如果想到了比先前更好的點子，那就接受並改變建構的東西，這樣做能將成果最大化。
什麼是敏捷開發？
那麼，為了達成目的並最大化成果，該怎麼進行呢？可以採用以下的方式。
● 所有相關人員彼此合作實現目標
● 分段實作產品，而不是所有功能同時完成，從早期就提供能正常運作的軟體，並持續反覆評估
● 持續從使用者或相關人員獲得回饋，並調整計劃
這種開發過程稱為敏捷開發。這個詞是在2001 年誕生的。為了解決傳統開發過程的繁重問題，經過各種試誤以及各種討論，有群人發現他們的基本想法有許多共通之處，提出了敏捷軟體開發宣言。換句話說，敏捷開發並不是指任何單一的開發方法，而是指類似的開發方法的共通價值觀與行為原則，而且有許多不同方法體現這些原則。主要的方法是Scrum、極限程式設計（Extreme Programming）和看板（Kanban）。各種敏捷開發方法的共通點是以「一切都無法事先準確預測及計劃」為前提。在傳統開發方法中，所有需求都是事先收集的，並估計所需時間、人力，以及成本。
而在敏捷開發中，是先決定在專案上要花的時間及人數，在其範圍內，從最重要的需求開始打造產品（產品是指敏捷開發的實際產品，主要指軟體，也包括必要的文件）。亦即會從重要、高風險的需求開始進行，其他放在後面，從而最大化成果。
什麼是Scrum？
如上所述，Scrum 是敏捷開發方法之一。
Scrum由Jeff Sutherland和Ken Schwaber在1990年代創立，是將野中郁次郎與竹內弘高在1986 年發表於《哈佛商業評論》之文章「新新產品開發遊戲」的內容，應用在軟體開發上，而Scrum這個名稱也是來自該文章。Scrum 具有以下特點。
● 依照價值、風險或必要程度，對需求進行排序，並依此順序建構產品，以達成成果最大化
● 在Scrum中進行作業時，將時間切分成固定且短的區間，固定的時間區間稱為時間盒
● 時常釐清目前狀況和問題，即所謂的透明
● 定期檢查進度，確認所製作的產品是否能得到預期的結果，以及工作方式是否存在問題，即所謂的檢驗
● 如果做法有問題，或是有能做得更好的方法，我們就改變做法，即所謂的調適
Scrum 適合處理未知多於已知的複雜問題，它由一套最基本的規則組成：五種事件（event，會議等）、三種角色（role，人的角色）和三個產出物（artifact）。因為只有最低限度的規則，所以我們必須自己找出如何應用這些規則。此外還要根據自己的情況，決定Scrum 中未定義部分的做法，像是如何撰寫程式碼，如何測試，這些都是建構產品所需的。因此它也可以說是一種架構（framework）。
Scrum的規則定義在《Scrum 指南》，第一版於2010 年發布，此後每隔1～2年就會有修訂內容，可以說《Scrum 指南》自己也是以反覆的檢驗和調適來更新的。本書以《Scrum 指南》2017年版為基礎進行解說，這是撰寫本書時的最新版本，而指南也仍會修訂，所以請視需要查詢最新版本
