《硝煙中的Scrum和XP》第6章 我們怎樣編寫sprint backlog
- 2020 年 4 月 7 日
- 筆記
第6章 我們怎樣編寫sprint backlog
- ScrumMaster現在應該創建sprint backlog了。它應該在sprint計劃會議之後，第一次每日例會之前完成
sprint backlog的形式
- 是我們發現管理sprint backlog最有效的形式——掛在牆上的任務板！
- 注意——如果你用貼紙來記錄任務，別忘了用真正的膠帶把它們粘好，否則有一天你會發現所有的貼紙都在地上堆成一堆
任務板怎樣發揮作用
- 添加列這種類型的事情，「簡單性」會發揮極大的作用；所以除非不這樣做會付出極大代價，我才願意讓事情變得更加複雜
例1——首次每日Scrum之後 在首次每日例會之後，任務板可能會變成下圖這樣，「checked out」表示團隊今天將處理這些條目的工作。在大團隊中，有時某個任務會一直停留在"ckecked out"狀態，因為已經沒人記得是誰認領了這個任務。要是這種情況一再發生，他們就會在任務上加上標籤，記錄誰領了這個任務
例2——幾天以後 可以看到，我們已經完成了「DEPOSIT」這個故事（它已經被簽入了源程式碼倉庫，經過了測試、重構等等步驟）。「MIGRATION TOOL」只完成了一部分，"BACKOFFICE LOGIN"剛剛開始，"BACKOFFICE USER ADMIN"還沒有開始，還有3個未經計劃的條目，放在任務板的右下角，進行sprint回顧的時候應當記住這一點
燃盡圖如何發揮作用
- sprint的第一天，8月1號，團隊估算出剩下70個故事點要完成。這實際上就是整個sprint的估算生產率
- 在8月16號，團隊估算出還剩下15個故事點的任務要做。跟表示趨勢的虛線相對比，團隊的工作狀態還是差不多沿著正軌的。按照這個速度，他們能在sprint結束時完成所有任務
- 我們沒把周末放到表示時間的X軸上，因為很少有人會在周末幹活兒。我們曾經把周末也算了進來，但是這兩天的曲線是平的，看上去就像警告sprint出現了問題，這就讓人看著不爽了
任務板警示標記
- 在任務板上匆匆一瞥，就可以大致了解到sprint的進展狀態。ScrumMaster應當確保團隊會對下圖所示的這些警示標記做出反應
需要從sprint刪除一些backlog
需要添加一些backlog到sprint
sprint進度一半了，忽略高優先順序的事情
不在計劃的事情干擾了正常的sprint計劃
嘿，該怎樣進行跟蹤呢
- 在這種模型中，如果必須跟蹤的話，那我能提供的最佳方式，就是每天給任務板拍一張照片
天數估算vs.小時估算
- 大多數都是用小時而不是天數來估算時間。我們也這樣干過。我們的通用方程為1個有效的人-天=6個有效的人-小時
- 現在我們已經不這麼幹了，至少在大部分團隊中如此，原因如下
- 人-小時的粒度太細了，它會導致太多小到1-2個小時的任務出現，然後就會引發微觀管理
- 最後發現實際上每個人還是按照人-天的方式來思考，只是在填寫數據時把它乘6就得到了人-小時。「嗯……這個任務要花一天。哦對，我要寫小時數，那我就寫6小時好了」
- 兩種不同的單位會導致混亂。「這個估算的單位是啥？人-天還是人-小時？」
- 所以我們現在用人-天作為所有時間估算的基礎（雖然我們也稱之為故事點）。它的最小值 是0.5，也就是說小於0.5的任務要麼被移除，要麼跟其他任務合併，要麼就乾脆給它0.5的估算值 （稍稍超出估算不會帶來很大影響）
