序
建構軟體並非易事。雖然一開始就想好要做什麼,但真的開始動工後,可能中途需求就改變了,還會 出現各種新的要求。建構軟體可能會花很長的時間,甚至會造成失去其原本意義,而花費了龐大費 用,得到的成品也不見得能達到期望。
在建構軟體時,真正重要的是什麼?就是實際使用軟體成品解決客戶和使用者的問題,賺取回報,也就是取得實際成果。建構軟體本身不是目的,而是取得成果的手段。因此,需要弄清楚為何要建構軟體,並時常確認目前所為是否真能達成其效果。在此過程中,如果想到了比先前更好的點子,那就接受並改變建構的東西,這樣做能將成果最大化。
什麼是敏捷開發?
那麼,為了達成目的並最大化成果,該怎麼進行呢?可以採用以下的方式。
● 所有相關人員彼此合作實現目標
● 分段實作產品,而不是所有功能同時完成,從早期就提供能正常運作的軟體,並持續反覆評估
● 持續從使用者或相關人員獲得回饋,並調整計劃
這種開發過程稱為敏捷開發。這個詞是在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年版為基礎進行解說,這是撰寫本書時的最新版本,而指南也仍會修訂,所以請視需要查詢最新版本