Scrum 是什麼(4):Product Backlog
source link: https://teddy-chen-tw.blogspot.com/2012/01/scrum-4.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Scrum 是什麼(4):Product Backlog
January 03 08:46~10:35
前情題要:
前幾集介紹了 Scrum 雙回饋機制與 Scrum 的內涵,包含角色、產出物與活動,這一集依照順序應該要提到當鄉民們要在專案中開始採用 Scrum 時,要如何開始第一個 sprint。不過 Teddy 之前已經先偷跑談過這個問題了,請參考「萬事起頭難:如何開始第一個 Sprint?」與「Iteration 0 要幹麼?」,所以本集 Teddy 就來談一下 product Backlog。
先幫鄉民們複習一下 product backlog:
所有關於此專案或是產品的 stories 就稱為 product backlog,放在 product backlog 裡面的項目(稱為PBI,Product Backlog Item)要經過「排序」,比較重要,比較優先要施工的項目放在前面。鄉民們可以直接用 excel 來紀錄 product backlog,當然也可以用支援 Scrum 的軟體系統(例如免費的 ezScrum)甚至是一般的文字檔來管理 product backlog。
3 年多前 Teddy 開始採用 Scrum 的時候,從網路上面下載了一個 excel 檔案可以用來管理 product backlog。由於時間久遠當初下載的連結 Teddy 老早就忘了,Teddy 把這個檔案放到 Dropbox 的 public folder 如果鄉民需要的可以從「這裡下載」。
把這個 ProductBacklog.xls 檔案打開之後,切換到 Backlog 這個頁面,會看到這個 product backlog 目前有三個 stories。這算是一個典型的 product backlog 格式,Teddy 稍微解釋一下每一個欄位的意義。
- ID:流水號,沒什麼特別的意義。
- Imp:重要性(importance)是一個整數值,用來排序 stories 之用。基本上越重要的 stories 會先被選出來施工。這個重要性的數值其實只是用來排列 story 的順序(order)之用,把不同 story 的重要性拿來比較是沒有意義的。例如,一個重要性為 80 的 story 並不表示它比一個重要性為 40 的 story 還要「重要兩倍」。這個觀念有時候對於剛開始採用 Scrum 的團隊會造成混淆而經常卡在如何設定重要性上面(這個重要性只能由 Product Owner 來決定)。為了避免混淆,後來新版的 Scrum 好像把這個欄位改稱做 Order(Teddy 還沒有時間去仔細研究一下改版後的 Scrum...XD)。Teddy 自己的作法是,如果最近 2-4 個 sprints 內可能施工的 stories,就把他們的重要性設在 99 - 70 這個範圍之內,如果是 2-4 個 sprints 之後但是半年之內可能會施工的 stories,則全部設定為 60。其他剩下的 stories 可能是還沒想清楚的需求(很模糊的需求與概念),或是一些閒雜人等對於軟體的「幻想 願望」,那麼重要性就全部都設成 40。反正每一個 sprint 還有一個 product backlog refinement meeting 可以去持續調整 product backlog 的內容。當然,平常 Product Owner 閒閒沒事的時候也要經常去耕耘 product backlog,畢竟整個產品(軟體)開發的方向(需求順序)都要依靠 product backlog 來決定啊。
- Name:Story 的名字。不過這個 ProductBacklog.xls 檔案裡面的例子寫得不好,story name 應該就是一個句子,類似 As a user, I can do something so that I can achieve xxx(身為使用者,我可以做某件事情以達成某項目標)。
- Notes:備註欄位,由於 story name 只是一個簡短的句子,在備註欄位中可以註明其他需求項目作為 sprint planning meeting 時與團隊成員討論需求時的「小抄」(提醒之用)。
- How to test (How to demo):該 story 的驗收條件,有的人把這個欄位寫成 how to test 也有人寫成 how to demo。這個欄位滿重要的,因為有了這個欄位開發人員才知道說這個 story 的「最小完工要求「」,而與測試人員(如果很幸運的團隊裡面有這樣的人力配置的話...XD)也才知道要如何驗收這個 story (最小驗收條件)。最後,sprint demo meeting 時就依照這個欄位所敘述的方式來展示每一個完成的 story。
- Estimate:Story point 的估計值。關於估算 story point 的問題請參考「如何估算 story point?」與「Story point 為何沒有單位:相對論篇」。
打好 stories 之後,每個 sprint planning meeting 時,就可以把該 sprint 預計施工的 stories 印出來。這個 ProductBacklog.xls 檔案裡面有 Excel 巨集程式,可以產生如下圖所示的 story cards。一張 A4 紙剛好可以列印兩個 stories,再用刀片割開就 OK 了,還算滿方便的。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK