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

上一篇：光了解看板(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粉絲團按讚喔!!