用Scrum開始敏捷開發

由Jeff Sutherland 和Ken Schwaber在1990年代創立的Scrum，是將野中郁次郎與竹內弘高在1986年發表於《哈佛商業評論》的文章「新新產品開發遊戲」（The New New Product Development Game）的內容，應用在軟體開發上，而Scrum這個名稱也是來自該文章。Scrum具有以下特點：

依照價值、風險或必要程度，對需求進行排序，並依此順序建構產品，以達成成果最大化

在Scrum中進行作業時，將時間切分成固定且短的區間，固定的時間區間稱為時間盒（timebox）

時常釐清目前狀況和問題，即所謂的透明（transparency）

定期檢查進度，確認所製作的產品是否能得到預期的結果，以及工作方式是否存在問題，即所謂的檢驗（inspection）

如果做法有問題，或是有能做得更好的方法，我們就改變做法，即所謂的調適（adaptation）

Scrum適合處理未知多於已知的複雜問題，它由一套最基本的規則組成：5種事件（event，會議等）、3種角色（role，人的角色）和3個產出物（artifact）。因為只有最低限度的規則，所以我們必須自己找出如何應用這些規則。此外還要根據自己的情況，決定Scrum中未定義部分的做法，譬如如何撰寫程式碼，如何測試，這些都是建構產品所需的。因此它也可以說是一種架構（framework）。

對功能和要求進行排序

在Scrum中，我們會列出產品所需的功能、需求、請求、修正等項目，建立一個稱為產品待辦清單（product backlog）的列表，依序排列。每個產品只能有一個待辦清單，其中的項目是依照這些項目帶來的價值、風險和必要性排序的。

待辦清單中的每個項目都有唯一順序，開發時會依序從前面的項目開始，因此順序越高，內容就越具體而詳細。此外，還要對每個項目（特別是排比較前面的）進行估算（estimation）以用於計劃。估算通常是基於工作量的相對值，而非時間或金額等絕對值。

產品待辦清單並不是建立然後排序就算完成了。需求不斷變化，新的需求也不斷冒出，實作順序也會根據情況改變。因此產品待辦清單必須在整個產品建構過程中，時時更新，保持最新狀態。

產品待辦清單的項目沒有特定的寫法，不過通常是用使用者故事（User Story）的形式來寫。

誰是產品的負責人？

負責管理產品待辦清單的人被稱為產品負責人（PO, Product Owner）。

產品負責人是對產品負責的人，每項產品都會有一位（不是合議制的委員會），負責利用開發團隊最大化產品帶來的價值，儘管產品負責人可與開發團隊一起建立及更新產品待辦清單，但最終的責任還是在產品負責人身上。

產品負責人的決定不應輕易被其他人推翻，產品負責人自己做出決定，並對結果負責。

開發能用的產品

第二個角色是開發團隊，主要責任是根據產品負責人所建立的產品待辦清單，依其項目順序進行開發。

一個開發團隊通常由3～9人組成，若少於3人，因為彼此互動較少，主要是依賴個人的技能，所以團隊一同開發所帶來的效果較少。而人數在10人以上時，則會因為溝通成本增加而造成開發效率低落，因此一般會拆分團隊以保持適當規模。

開發團隊必須能完成產品建構所需的所有工作，例如開發團隊要能分析需求、設計、撰寫程式、架設伺服器、測試，以及撰寫文件，這就是所謂的跨職能團隊（cross-functional team），裡面不會再分成特定的小組，像是「需求分析小組」或「測試小組」。團隊中每位成員可能會做不同的事情，或者有能力差別，但在工作過程中，最好是每個人都盡可能地能做多種事情。

在開發團隊中，不會有基於職位或技能的特定頭銜或角色。開發團隊內部的工作進行方式，是由成員之間共識決的，而非受到外部指示該如何進行。整個開發團隊作為一個整體，對自己的工作負責，這就是所謂的自我組織（selforganization）。用這種方式能讓開發團隊發揮主體性，團隊的能力也會不斷提高。

切成期間並重複

Scrum將時間切分為最長一個月的固定期間，周而復始地進行開發。這個固定期間稱為Sprint（「衝刺」的意思）。

在這期間內，開發團隊會進行各種工作來完成產品待辦清單上的項目，包括規劃、設計、開發和測試。

這種固定期間的反覆進行能帶來節奏感，讓團隊專注於開發工作，掌握整體目標進度，更能應對風險。

即使在Sprint最後一天還有工作沒完成，也會結束Sprint，不再延長。Sprint的期間該設定多長，是根據產品規模、開發團隊人數和成熟度，以及業務狀況決定的，一般是以週為單位，短則1週，長則4 週。若因情況變化導致Sprint的工作失去意義，那麼只有產品負責人能決定是否提前終止Sprint。

頻繁地計劃

開始Sprint之前，要先計劃在Sprint中要做什麼（What）、如何做（How）。計劃是在Sprint計劃（Sprint Planning）這個事件確定的。如果是1 個月的Sprint，那麼Spring計劃會議所花的時間大約是8小時，如果Sprint期間較短，那麼計劃的時間也會比較短。

在Sprint計劃中，主要有兩個主題。

第一個主題是決定在一個Sprint要完成什麼。

首先產品負責人要釐清在這個Sprint想達成的目標，然後從產品待辦清單中，選擇在這個Sprint要完成的項目以達成目標，一般來說會選排在前面的項目。選擇的項目數量是根據每個項目的估算規模、開發團隊過去表現（稱為速率，velocity）、該次Sprint可用於工作的時間（稱為產能，capacity）進行初步的決定。

另外還會根據討論的內容簡單總結本次Sprint的目標，這稱為Sprint目標（Sprint Goal），能幫助開發團隊理解為何是從清單中選擇這些項目來進行開發。

若要像這樣從待辦清單頂部開始，依序討論項目並作為本次Sprint開發對象，就需要在Sprint計劃會議前，先對頂部的項目做好準備。準備內容各不相同，譬如將項目內容更加具體化、解決項目的疑點、訂定項目該完成什麼（驗收標準）、將項目切分成可處理的大小、進行估算等。這些活動被稱為產品待辦清單精煉（Backlog Refinement，通常簡稱為精煉，或稱為梳理）。

Scrum 並沒有定義何時及如何進行精煉，但應該保留充足時間進行，如果在Sprint開始前才準備可能會來不及，通常精煉所花時間在Sprint的10% 以內。接下來第二個主題是計劃開發團隊如何完成選定的項目，也就是對每一個項目擬出具體任務內容，制定工作計劃。選定的產品待辦清單項目以及工作列表，稱為Sprint待辦清單（Sprint Backlog）。待辦清單是開發團隊的工作計劃，可以在Sprint期間自由增減任務內容。一般會將各任務分割為可在一天內完成的規模。

如果在討論Sprint待辦清單之後，開發團隊認為主題1 所選的項目很難完成，那就得和產品負責人討論如何調整工作量，看是要將一部分項目拿掉，或是重新檢討工作計劃。

要注意的是，雖然開發團隊必須盡其所能完成Sprint計劃會議中討論的內容，但並不保證會完成計劃的所有內容。如果承諾完成所有工作，可能會導致若出現估計失誤、難度過高、出現意外等情況時，開發團隊需要長時間加班或省略必要工作，結果就是產品會出現各種問題。Sprint待辦清單的各個項目並沒有特定負責人，且在Sprint計劃時，也不必決定所有項目的負責人，可以在真正開始作業時，由實際進行的人自己從Sprint待辦清單中選擇項目。

完成每個Sprint

Scrum要的是在每個Sprint裡能進行評估的增量（Increment）。

增量是指過去累積的成果和目前Sprint中完成的待辦清單項目的成果總和，通常是提供能運作的軟體，必須在Sprint結束時完成，且能正常運作。因此產品負責人和開發團隊需要對「完成」有共通的標準，這就是所謂完成的定義（Definition of Done），開發團隊必須做出符合此定義的產品。

完成的定義也可以說是品質標準。可以在開發途中追加定義，但要注意若是在途中刪減定義，可能導致產品無法達成品質要求。（摘錄整理自《SCRUM BOOT CAMP》，碁峰資訊提供）

圖片來源_碁峰資訊

 書名  SCRUM BOOT CAMP｜23場工作現場的敏捷實戰演練

西村直人、永瀬美穂、吉羽龍太郎／著；游子賢／譯

碁峰資訊出版

定價：500元

 作者簡介 

西村直人

2005年開始實踐敏捷軟體開發。自從接觸極限程式設計以及在永和系統管理公司開發以來，抱持著「想增加更多優良團隊，讓大家能透過敏捷開發為公司業務做出貢獻」的想法在努力。

永瀨美穗 

株式会社アトラクタ（Attractor Inc.）創辦人兼品牌官／敏捷教練。在委託開發現場擔任軟體工程師，擔任組織管理者，導入並實踐敏捷。

吉羽龍太郎 

株式会社アトラクタ（Attractor Inc.）創辦人兼技術長／敏捷教練。從事顧問與培訓，主要領域為敏捷開發、DevOps、雲端計算。