碁峰資訊

由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、雲端計算。

熱門新聞

Advertisement