舊版
首頁 | Scrum流程 | ezScrum工具 | 最佳實務 | 近期活動 | 課程消息 | 關於我們 |

A Simple Intro of Scrum

一個精簡的敏捷(agile)方法,主張以若干個固定長度期程(sprint),進行開發工作,每ㄧ期程結束時需展示完成的功能。Scrum透過控管需求、投入資源,並持續檢視成果,使團隊的開發活動變得透明而可控。

下圖說明整個方法的過程,含各個角色的責任與產出物。Scrum將軟體開發相關人員分為四種角色:顧客(stakeholder)產品擁有者(product owner)Scrum隊長 (Scrum master)、與Scrum隊員 (Scrum team member)。顧客對應用領域擁有某種願景(vision),而產品擁有者則負責定義出實現該願景的產品的需求,包括功能需求與品質特性。當需求被定義的相當完整之後,Scrum團隊即可開始進行開發的活動。在Scrum中,這些需求稱為故事(story),被放在產品待辦目錄(product backlog)中。

整個開發時程將依據團隊的選擇,分為若干個次固定期間的衝刺(sprint),期間長度通常介於2~4週之間。每一個衝刺開始前,由產品擁有者與Scrum團隊會同召開一個衝刺規劃會議(sprint planning),自產品待辦目錄中選擇若干個故事,由Scrum團隊一起將選中的每一個故事分割成為數個工作(task),將之紀錄於該次衝刺的待辦目錄(sprint backlog)之中。通常sprint planning的長度以每次不超過4小時為原則。這些工作將由scrum隊員領取並在該次衝刺中完成。在當次衝刺即將結束前,由Scrum團隊對產品擁有者展演已完成的功能及品質特性 (sprint demo)

每一個衝刺的最後一項活動為回顧(sprint retrospective),由隊長主持檢討該次衝刺的好的(good)與待改進事項(improvements)。如此週而復始,直到專案結束或完成所有故事。

Scrum中的估算、規劃、度量

採用Scrum的專案中最常被問的問題為:「身為產品擁有者,你如何確認Scrum團隊開發的進度能確保在專案期限內完成所有故事?身為scrum隊員,你如何估算一個故事需要多少個工作量?」Scrum回答這些問題的方式如下:先定義估算工作量的度量(metrics),在sprint planning中進行工作量估計,在工作中蒐集實際發生的度量值,然後以統計圖顯示進度。

一個故事的工作量以故事點(story point)為單位計算,一個故事點相當於一個人天,即一個人於每個8小時的工作天所能完成的工作量。原則上,一次衝刺可完成的故事數由團隊產能與故事工作量決定;該二項數據之估計均發生於sprint planning會議中。

假設團隊有4人,週期為二週,因此最大工作能量為5x2x4=40個故事點。然而,以最大工作能量為基礎領取故事並不合理,通常軟體開發人員在工作轉換之間需要一些額外的時間,或者有其他雜務需要處理。後者雖應盡力避免 – 此為scrum隊長的重要職責之一,即確保隊員可免受擾於與專案無關的事務 – 但實質上很可能無法完全避免。Scrum引進一個參數反映隊員專注程度,稱為專注因數(focus factor)。如團隊無已知專注因素,一般而言可自訂起始值,並逐次依實況修正。在納入專注因素0.7後,上例中之團隊工作能量為10x4x0.7 = 28個故事點。假設領取總值26點的故事,而實際完成24點,則此個sprint的實際專注因素為24/40 = 0.6。只要蒐集足夠多個sprint之後,團隊即可建立其專注因素。

知道此次衝刺Scrum團隊的工作能量後,即可知道要領取幾個工作。作法為由團隊對選定的故事進行分割,切成若干task,再由所有團員估算每一個task所需點數。進行估算時,合法的點數為0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100。估計過程中隊員可討論,但需各自估計。如個別估計點數相近,代表大家對估算具有共識,該工作之估算即視為完成。如差距過大,則由隊員解釋其估算的原則並討論之。隨後再次估計與出牌,過程重覆至共識形成為止。待每一個工作估算完成後,加總值即為該故事的估算點數。

Scrum的控制與調適

Scrum的每日會議(daily scrum)為流程中主要的控制與調適機制。該會議於每上班日定時召開(如上午9:30),為時15分鐘。隊員站成一圓圈,逐次做三項發言:昨天完成工作為何?今天準備做的工作為何?遭遇困難為何?每日會議結束後,隊長將可獲知最新的工作完成資訊,並據以繪製故事與工作的完成進度圖(burndown chart),如下圖所示:

在表達「昨天完成工作為何?」時,隊員同時在團隊的工作版(task board)完成必要的工作狀態修改(含完成日期),並將之移至已完成區(Done);在表達「今天準備做的工作為何?」時,自待領區(Not Checked Out)取出工作,並標上自己的姓名(或代號)與領取日期,並將工作移至領出區(Checked Out)。如下圖所示:

隊員在sprint中遭遇的困難,可能導致減損生產力。這些困難應在Daily Scrum中被報告,隊長鬚加以記錄,並設法為隊員排除該項困難。

Scrum的sprint planning為Product Owner因應需求變動的控制與調適機制。在Scrum中,story為可交付項目的最小單位。一般而言,為避免對Scrum團隊產生過大的干擾,product owner應只在sprint planning中做此項調整。這使Product owner與Scrum團隊間的權責劃分變的清楚而容易:Product owner可以專注在需求上,而不需管技術面如何實現;團隊在完成一個故事的過程中亦不會遭受不必要的干擾。然而,在極端的情形下,亦有可能需要在半途中砍掉已規劃的故事,並以unplanned story的形式追加亟須儘早完成的故事。Sprint demo依據story中的how to demo情節進行驗收。

Scrum可擴充性

前述流程適用於個別專案團隊,但由於產品通常涵蓋硬體、driver、作業系統與應用等層,一個應用Scrum的模式如下:除在各子層個別執行Scrum之外,另在產品層次執行top level Scrum,目的為掌握各子層的Scrum活動。產品層Scrum參加對象為產品計畫的PM (擔任Scrum master)與各子層Scrum隊長 (擔任隊員),參與產品層的sprint planning meeting與sprint demo。產品層sprint planning會議在子層sprint planning會議前召開,目的為讓各個子層帶回產品層的sprint backlog,作為子計畫選story進入sprint backlog的參考依據之一。最後,release plan由產品層統一規劃訂定,並由子層共同遵循。

技術面

Scrum並未規範如何進行技術面的工作。這跟過去以技術歷程為中心的流程(如waterfall)相當不同。一般而言,一個sprint所需做的事情含分析、架構與細部設計、撰寫程式碼、測試整合等工作都需要完成。由於Scrum並未規範將隊員如一般做法(如Unified Process)分為分析師、設計師、程式員、測試員等角色進行分工,因此,sprint planning中,story的分割就顯得非常重要。在另一方面,如果團隊過去習慣由不同專責人員組成,則隊長在規劃流程作法時,必須加以考慮。

就技術面而言,Scrum隊長應具備良好的分析、架構、設計、審查(review)、除錯能力。在隊員遭遇設計與程式困難時,scrum master可利用各種方法,如設計檢閱(design review)、程式碼檢閱(code review)等方式協助隊員解決問題,並在過程中進行教導(mentoring),逐步提升隊員的技術能力。

   
計畫贊助: 執行單位: 友站連結:
Copyright © 2011-2015 ezScrum. All rights reserved.