進度條

融會貫通看板後,就試著進入敏捷式開發管理"Scrum"的世界吧

終於輪到大名鼎鼎的Scrum介紹文了,你準備好了嗎?

作者: Vincent Ke 更新日期:

上一篇:光了解看板(Kanban)方法還不夠,不如用Trello提升你的工作效率吧

 

在過去如大型建設等硬體工程上,例如以室內裝修為案例,在交屋驗收前,若是專案設計需要變動,除了最後交屋的時間會延宕之外,更常會遇到的是如隔間要打掉重作、已經鋪好的地板要挖起來變成大里石,選定好的材料要全部更換....等等硬體成本的浪費。

 

而在軟體開發的角度上,因為專案變動的需求影響到的硬體成本,較過去其他傳統專案較少,因此在執行專案的過程中,很常會遇到在交付前的需求變更。而為了因應這樣的狀態和需求,在「以變為不變」的管理方式中,如何有效管理自己團隊的節奏來因應這些需求,更是敏捷式開發「Agile 」的核心概念。

 

在上一篇的看板管理方法中,想必大家應該都對視覺化的管理和改善有了初步的認識,但看板的管理概念較為廣泛,多數用來記錄及管理這些從需求出發的Idea,到產出成功能和產品間所有的活動與歷程,重心會偏向在工作流程的追蹤和改善。

 

 

而若是今天收斂到需求的開發上來說,會不會有其他的武功更值得我們參考或使用,若是作過專案的朋友們,相信在有限的時間內對產品作收斂是相當困難的,一來是要挑戰團隊間的資源規劃、二來是必須應付業主的需求,這時候也許看板的範疇在管理上就會顯得較不受用。這時候我們會為各位介紹另外一種管理方式「Scrum」。

 

和看板概念非常類似,一樣是透過視覺化來追縱團隊進度的管理,但方法卻大為不同了,有聽過Scrum的朋友對下面這張圖一定很不陌生

 

資料來源:http://scrumprimer.org/anime

 

Scrum的特色在透過每一個固定週期的Sprint去和業主(或是PM、老闆..等),針對現在作的功能作交付驗收的動作,在作出來功能不符合想像(或是需求)可以快速修正,這樣的概念上看似簡單,但與看板最大不同的是Scrum導入了制度、權重以及角色的概念,接下來會先針對名詞來作介紹:

 

1. Development Team(即Dev Team,可以稱作開發團):也就是主要著手開發的任務團隊,人數可以約6人左右,建議是可以叫一份大PIZZA可以一人分到一片的人數為上限,除了各司其職之外,更要相互支援,是一個生死與共的團隊。

 

2. Product Owner(PO,類似PM的角色,專職的產品負責人):產品的重要核心,決定每一次開發權重的角色,也是需要和所有的專案利害關係人(steakholder)斡旋的要角,基本上可以稱作是PM無誤了。

 

3. ScrumMaster(SM,類似教練的角色):在Scrum的各流各派中,有人認為她是Team leader的角色,也有人認為他也是PM的角色,但總之他所要專注的事情為維繫Scrum的制度運行,確保團隊在Scrum的範疇裡繼續Run,例如常常會遇到一些老闆不必要的會議或是強加的需求,SM就有責任維繫團隊的規則和產出去進行協調,通常包含了以上三者就是一個Scrum Team了!

 

4. Steakholder(專案的利害關係人):可以是你的老闆,也可以是你的業主,通常有能力決定產品走向和需求的人,會出嘴的都可以稱作Steakholder

 

 

資料來源:http://www.agilenutshell.com/scrum

 

5.Sprint:定期產出的週期,1-4週

 

6.Product > Feature(功能卡) > Task : 這是一種將產品由大到小的拆解,例如我們的產品是要建置一個咖啡店官網,我們可以想像她是張Product大卡片,其中Feature就可以是一個中型的卡片來包含了官網具備的功能,例如產品介紹、分店位置、現上點餐..等等。而Task就是以技術為單為最小的拆解囉,也是我們在跑Scrum裡最重要的視覺化物件,通常Feature的寫法可以透過前面介紹過的User Story來作撰寫會比較恰當。

 

 

7.Product Backlog(產品需求清單):完成產品需要的清單

 

8.Sprint Backlog(Sprint清單):每周Sprint要完成的事情,這中間PO要決定完成的先後順序,所以保持頭腦清醒很重要的!

 

接下來在流程的部分作介紹,每一項專案下來之後PO會先和Steakholder談好了產品和功能的UserStory(kick-off meeting),也就是有了Feature的UserStory之後,就可以透過Scrum Planning meeting來作切分,主要是挑選在這次的Sprint要完成的項目,並把他切割成Task。

 

另外最重要的一點是把透過團隊共識,把每一個UserStory切出StoryPoint,點數可以使用天數來作評估比較具體,例如作出線上點餐需要8天,那其中每一個Task如加入購物車、結帳、建立商品清單..等等這些項目,也必須切割出StoryPoint,當然總合不能超過8點。

 

每一張Task的卡片上都必須記載著人名、點數後,最後把這一次Sprint要開發的Task蒐集貼在ScrumBoard板上,就可以開始進行開發作業囉,建議一張Feature不要超過13點,若是超過表示他還可以在細切。

 

接下來他的ScrumBoard就比較簡單,只有Undo(待做),Doing(正在作)和Done(作完),當從Undo移動到 Doing的時候記得一定要確認卡片上有沒有填寫名字,也就是一定要有人認養才可以移動到Doing,接下來就是每天記錄與扣點的動作,當扣成0表示該功能已經完成,而移動到Done前PO一定也要完成驗收才可以移動。

 

 

 

接下來的流程就是每天透過Daily Scrum Meeting,讓團隊的人來講解昨天作了什麼,今天要作什麼,有沒有遇到什麼困難,並且規定在meeting前,每個人要針對有記載自己名字的卡片(也就是負責的開發功能)去作扣點,例如分店地圖位置功能為八點的話,就代表團隊有共識這功能八天可以開發完成,而負責的人就必須依照自己實際的開發進度來作扣點,最後PO要針對這些總扣點的點數去化作Burndown chart。

 

如上圖,首先橫軸是這次Sprint的天數,縱軸是點數,假設我們一周擁有五個工作天,團隊有六人,所以一個Sprint如果是3周的話,就會有5x6x3=90點,這時候我們就會有一個比較的基準,若是這一個Sprint切出來的點數為120點,表示120/3(周)在除以5天,就可以知道一天至少要扣掉八點,才有辦法把這些點數燃燒為0(但團隊只有六個人...所以表示這樣有超出負荷的嫌疑,以此類推),所以透過每天的Meeting,很容易就可以追蹤這次的開發進度是否有落後的趨勢,若每天都忠實記錄開發扣點的狀況的話,可以明顯的看到若是線的走勢漂浮在基準線上方的話,那開發的進度就會有風險產生囉。

 

另外透過每一次的Sprint結束後,就可以去和Steakholder進行確認,也就是階段階段驗收的方式,來確保開發主軸沒有偏離,並帶給團隊中快速從經驗學習反應和自我管理。

 

而在每一次Sprint結束前,到下一次Planning meeting前,團隊也必須開啟一次review回顧會議,來檢討這個Sprint的狀況,確保未來不再發生。

 

與看板最大的不同,看版本身是透過WIP來限制階段的作業量,Scrum是透過一個固定的週期來限制開發的需求量,而看板本身視覺化的是工作流程。Scrum視覺化的是在風險評估的部分,使用上各有千秋,就看每個團隊的考量來作選擇囉。

 

小編目前也是先針對Scrum的概念去進行初步的講解,之後有機會會在跟各位討論兩種管理方法上的差異,以及針對Scrum可以使用的線上管理工具"Atlassian JIRA"

 

下一篇:就決定用JIRA來磨練看板與Scrum的實戰演練吧!


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧