6. 我們怎麼撰寫Sprint backlogs
你們已經走了這麼遠啊？ 喔，幹得好。
現在我們已經完成Sprint規劃會議，並告訴大家我們下一個閃閃發光的新Sprint是什麼。接著是時候，讓Scrum master建立Sprint backlog。當Sprint規劃會議結束後，和第一次每日會議前，並需要把Sprint backlog給建立完。
Sprint backlog的存放方式
我們曾經嘗試過用不同格式來保存Sprint backlog，像是Jira，Excel 和牆壁上的任務板(taskboard)。剛開始，我們主要是使用Excel，有很多公開的Excel模板，可以用來存放Sprint backlog，還包括可以自動產生的burn-down chart等等。我可以告訴你很多我們怎樣調整Excel為主的Sprint backlog。但是這裡我先不提，我也不會舉任何例子。
代替的，我將要詳細描述，我們發現存放Sprint backlog最有效率的方法 - 掛在牆上的任務板！
是的，實體牆壁為主的任務板（又叫做 Scrum 板）是我首選工具！它的效果是令人驚訝地強大。對於分散在各地的團隊，則是利用電子工具來提供 Scrum 板的概念，並且在各地都用一個大的螢幕來呈現。在每日會議時，每個人站在牆壁的螢幕前，利用 Skype （或是其他工具）來交談。
找一面尚未使用或是充滿了沒用訊息的大牆(像是公司的logo，舊日的圖表，或是醜陋的塗鴉)。把它清理乾淨(如果必要的，先請求許可這樣做)。貼上一張大的白紙(至少2 x 2 平方公尺，大的團隊可能需要3 x 2 平方公尺)，然後這樣做：
你當然可以使用白板，但是多少有點浪費。如果可能，把白板省下去劃設計的草圖，用沒有白板的牆壁來做任務板。
或者更好的是，把整面牆弄成白板, 這是一個值得的投資！
注意 - 如果你使用便利貼來記錄任務，不要忘記用真的膠帶把他們黏好，否則你有一天會發現，所有便利貼會掉在地板上，堆成一堆。
或者買一個超級黏的便利貼，稍微有點貴，但是他們不會容易掉下來！（不，我不是贊助者，真的）
如何讓任務板發揮作用
當然，你可以加上許多欄位，像是 "等待去做整合測試"，或是 "已取消"等等。但是，在你把事情變複雜之前，多想一下，這些增加的欄位是否真的需要？
我發現對於這類事情，簡單是極端有用的。所以當不做會真的很不好時，我才會增加這些額外的複雜度進來。
範例 1 – 在每日會議結束後
在每日會議結束後，任務板可能會變成這樣：
你可能會看到，有三個任務被放到"checked out"欄位中，也就是，團隊今天將會處理這些項目。
有時候，對於比較大的團隊，任務可能會一直停在"checked out"狀態中，因為已經沒有人記得，是誰要負責這個項目。如果這種狀況一再發生，他們通常會導入這樣的規則，在每個checked out的任務上，標上是誰負責這個項目。
現在幾乎所有團隊都使用替身。每個團隊成員挑選他們的替身（像是南方四賤客或是其他）, 印出來，把它們放在磁鐵上面。這是很棒的方式可以知道誰正在做什麼。並且，如果每個只有兩個磁鐵，間接限制同時處理的工作數目，和避免多工。 “真他媽的見鬼了，我用完了磁鐵！”是的，所以停止做新的任務，把正在做的任務給完成！
範例 2 – 在幾天之後
在幾天之後，任務板可能看起來像這樣：
你可以看到我們已經完成"deposit"這個故事(也就是，它已經被checked in到原始碼資料庫，被測試過，和重構過等等) 這migration tool只完成了一部份，"back office login"已經開始，"back office user admin"還沒開始。
你可以看到右下角，我們已經有三個未計畫到的項目。當你在進行Sprint回顧會議，它非常有用，可以幫助你記住有過這些事。
這裡有一個真實Sprint backlog的例子，這個例子已經接近Sprint的尾聲了。在Sprint的過程中，這個表變得有點亂，但是還好，因為這樣的時間不長。每次新的Sprint開始，我們會建立一個全新，乾淨的Sprint backlog。
燃燒圖如何運作
讓我們放大燃燒圖：
這張圖表可以告訴我們：
• 在Sprint的第一天 ，8月1日，團隊評估大約有70個故事點數的工作要完成。這就是實際上整個Sprint的估算速度。
• 在Sprint的第十六天，團隊評估大約剩15個故事點數的工作要完成。虛線顯示出他們目前進度大約是在控制中，也就是，以這樣的速度，他們在Sprint結束前，會完成每件事情。
我們沒有把週末放到X軸上，因為很少人會在週末工作。我們曾經把週末放進去，但這將使得燃燒圖看起來很奇怪，因為在週末都是平的，看起來會好像是一個危險的徵兆。
Scrum 最初是被設計給團隊進行一個月的 sprint，並且使用 Excel 來追蹤任務的。在那個情形下，對於我們怎麼做事，燃燒圖是一個非常有用的視覺化總結。現在，雖然，大部份的團隊採用較短的 sprint，並且有更好的視覺化 Scrum 板。因此, 他們越來越多人完全忽略了燃燒圖，因為只需要看一眼，他們就得到他們想要的。試著忽略燃燒圖，看看你會失去什麼！
任務板上的警訊
在任務板上快速瀏覽一下，應該就可以知道，目前Sprint進行的狀況如何。Scrum master要負責確認，團隊會對這些警訊採取行動：
嘿，要如何追蹤？！
在這種狀況下，如果你需要可追蹤性，我所能提供的最佳可追蹤性的方法，就是每天對任務板拍一張數位照片。我有時候這樣做，但是我從來沒有用到這些照片。
如果可追蹤性對你是非常重要，那任務板可能不適合你。
但是我會建議你去評估一下，詳細的Sprint可追蹤性，對你的實際的價值是什麼。一旦Sprint完成，可以運作的程式碼被交付，文件也被 checked in。那還有人會關心有多少故事，在Sprint的第五天被完成？ 又有誰會真的關心"為Deposit實作測試先行"這個故事，原先估算的時間是多少？
我仍然覺得可追溯性被過度高估，有些工具有提供這類型的資訊，但是基本上沒有人用它。你的程式碼版本控制系統，就可以提供大部份你需要的資訊。（真他媽的見鬼了？誰做了這個修改？！）。規定一些公約，像是增加故事 ID 到你提交的註解中，這樣在大多的狀況下，你就可以有足夠的可追溯性。
用天數來評估 vs. 用小時來評估
在大部分有關Scrum的書籍或是文章，你會看到任務大部分是用小時來做時間的評估的。我們曾經也這樣做過。我們一般的作法是： 一個有效的人天 = 大約是6個人時(man-hours)。
現在我們已經不這樣做，至少在我們大部分的團隊已經是這樣，原因如下：
• 人時的評估太過精細了，這會導致很多1~2小時的任務，因而引發微觀管理(micromanagement)。
• 通常結果證明是，人們的思考始以人天為單位，只是把它乘以6 得到了人時。"嗯……這個任務需要花大概一天。哦，我必須要寫小時數，那我寫6小時就好了"。
• 兩個不同單位會導致混亂，"這是使用人天，還是人時評估的呢？"。
所以我們現在使用人天，當做所有時間估算的單位(雖然我們叫它故事點數)。我們最小的值是0.5，也就是，只要任何任務小於0.5，要嘛不把它移掉，要不然就是把它和其它任務合在一起，或者就是給它0.5的估算值(稍微超過估算不會有太大的影響)。這樣比較單純，比較好。
可以更簡單：完全跳過任務評估！大部份的團隊最終將學習如何將工作拆解成，大約是一天或兩天的任務。如果你可以做到那樣，你不需要受到評估任務的干擾，可以排除很多浪費。燃燒圖仍然有用（如果你一定要的話）– 在那種狀況下，只要數有多少任務，而不用去加總時數。
全站熱搜
留言列表
