[專案管理] Scrum 是什麼?－老實念佛，以戒為師

網路文章

Scrum在台灣可能很多人都沒聽過,但在國外,這可是已推行了十年以上的專案管理方法,也是屬於敏捷式開發(Agile)的流程,和傳統的專案管理方式差異點之一在於有雙重回饋機制以及類似於一層一層疊加上去完成的需求(iteration),和不同於舊有的分工模式,以下可以來好好討論這些差異是什麼呢~

簡單而言,Scrum可以分成這四個步驟: 預估(story point)、實作(sprint)、監控(daily scrum)和修正(retrospective meeting)

角色

在說明Scrum前,可以先了解和Scrum相關的靈魂人物有哪些?可以分成兩大類,一類是主要角色,包含Product Owner(PO)&Scrum Master(SM)&Team Member;另一類是輔助角色,包含stakeholders&manager,和這專案有利害相關的人都可包含在這其中~

Product Owner:PO這角色最為吃重,負責專案的成敗,案子的好壞必須承擔在PO身上,並且充當客戶的代表人,要向開發團隊說明客戶的需求並釐清需求內容,並轉換成一項一項的to-do list,以便team member可以把任務領回家作,且負責盯緊整個專案進度~

Scrum Master: 幫助團隊可以依循著Scrum的精神開發,而且要能確認Scrum的活動都有在正確的路上執行,有點像是團隊的秘書兼顧問角色~

Team member: 當然就是負責開發的人啦,選進來的成員最好能有多項技能,可以負責cover其他成員,如會UI程式的人也能會些美工設計,會寫資料庫的也能會些UI開發,這樣不僅可互相支援之外,在下一階段的story point也能更快達成共識~

從這圖可以清楚說明這些關係~

Activity

在開始專案的第一天,通常都會舉行Sprint planning meeting,這會議有點類似kick off meeting,但更強調的點在PO和Team member間的需求釐清,在這會議結束後,必須要達成幾項共識:1.挑選這個 sprint 所要開發的需求(stories) 2.逐一將stories 細分為更細的 task(施工項目),並且估算完成每一個 task 所需的時間,用story point來使大夥對於每項task所需花費的時間和困難度達成共識~因此最後產出的Spring Backlog即可作為team member的施工藍圖~

在建立Spring Backlog後也會經常在每一次的sprint中撥出5%~10%的時間來檢視Spring Backlog裡所有的story有無修正或新增~

在專案開始之後,PO會訂定每日的戰鬥會議Daily Scrum,會作為戰鬥會議的主因是只開15~20分鐘,全程站立的效果更有助於會議的加速進行,而在會議中,要討論的就是讓組員報告,並且利用Burndown Chart(燃盡圖)來控制目前工作進度是否有照著合適的規律進行著,報告內容不外乎:

(1) 昨日作了什麼?

(2) 今天準備要作什麼?

(3) 有沒有任何問題要提出或討論?

接下來就是會進入完整的開發週期,這裡將每一cycle稱之為Sprint,一般是2周為一個sprint cycle,週期不宜調整,固定是最佳的~~

當開發一個階段後會有所謂的雛型產品產生,也是為了能在最後完成前能讓客戶看一下產品是否符合他們期望,因此在sprint結束後會舉辦一個Sprint review meeting,參加對象至少要有PO(可作為客戶代表人)和SM,developer也可展示產品給PO看,確認這些story有作到當初討論的需求,如果有更進階的想法也可在此時提出~

最後完成整個專案後,PO會召開一個Sprint retrospective meeting,主要是真對這次專案的進行,提出Good(作的好的)及Could be better(待改善)的項目以作為下一次專案的改善目標~

這樣表示看起來更好理解了XD

Artifact

簡單說明一下Story是什麼?Story就像是一個完整的testcase,會有一個End to End的劇情上演的,而作出來的產品要能讓劇情順利演完,如果將story切割之後可以分成好多個task項目,這些tsak就能讓developer分別完成,像是UI設計&資料庫建置&完成使用者手冊&testcase等等都是呢!!

另外Burndown chart的應用,如果是task的應用,會在Sprint review meeting後將所有storys的tasks施工總時數加總統計一下,在每一次的daily scrum中成員會報告完成哪些task,將完成的task時數加總一下,再用總預估工時扣除完成時數,藉以每一次都能有個點,最後連線起來就能和一開始預估的斜線比對,在預估比對斜線之上就知道delay了,該改善了(理論上在 sprint 最後一天剩下未完成的工作時間應該是 0)~~

Daily Scrum&Burndown Chart