Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
訂定sprint的長度
Sprint規劃會議的其中一個產出, 就是定出sprint展示的時間. 這意味你必須決定sprint的長度
所以sprint的長度要多長比較好?
好的, 短的sprint會比較好. 它可以讓公司更敏捷, 也就是說方便於改變方向. 短的sprint = 短的回饋週期 = 更頻繁的交付 = 更頻繁的客戶回饋 = 在錯誤的方向上不會花太多時間 = 學習和改進的更快速 好處多多
但是, 長的sprint也不錯. 團隊能有更有時間累積能量, 更多空間去解決問題, 進而達成sprint的目標. 不會被一堆sprint規劃會議或展示等等, 忙得不可開交.
(譯注: 每次的sprint會有一些基本消費額的活動, 像是sprint規劃會議, 展示等. 越多次sprint也代表越多次的sprint規劃會議, 展示等等, 有些團隊會認為這些活動浪費不少時間)
一般說來, 產品負責人喜歡短的sprint, 而程式設計師喜歡長的sprint. 所以sprint的長度是可以討論的. 我們實驗了許多次, 最後總結我們最喜歡的長度: 3個星期. 大部分我們的團隊(但不是全部)sprint長度都是三週. 對我們來說, 它短的讓我們有足夠的敏捷性; 也長的足夠讓我們完成在sprint中, 所要完成的事情和所要解決的問題.
我們得到一個結論: 在剛開始時, 就要做sprint 長度的實驗. 不要浪費太多時間去做分析, 先選一個還不錯的長度, 做個一兩個sprint, 然後再調整長度.
不過, 一旦你已經決定哪個長度最適合你. 之後就要長時間堅持住. 經過幾個月後的實驗, 我們發現三個禮拜很好, 所以我們用3週, 進行了一段時間.
有時候可能會感覺有點長, 有時候可能會感覺有點短. 不過只要保持住相同的時間, 就會變成大家共同的心跳節奏, 會覺得很舒服. 並且對於發布日期(release date)不會有任何爭論, 每個人都知道每三週會有一個發布.
定義Sprint的目標
定義Sprint的目標, 這是每次都要做的事情. 在sprint規劃會議中的某個時間點, 當我問"這次sprint的目標是什麼?", 大家都會一臉茫然的看著我, 產品負責人也會皺起眉頭, 開始搔著下巴.
基於某種原因, 要訂出sprint的目標是件很困難的事. 但是我發現是值得去把它找出來. 半吊子的目標也比沒有好. 這個目標可能是"賺更多的錢", 或是"完成前三件重要的故事",
或是"打動CEO", 或是"把系統做的很好, 可以作為是Beta的版本給使用者使用", 甚至是"增加基本後台系統的支援"等等. 重要的是, 它必須用商業的用詞來表示, 而不是用技術的用語來表示. 這意味著需要連團隊以外的人都能了解.
Sprint的目標需要來回答這個基本的問題: "為什麼要進行這個sprint? 為什麼我們不去放假呢?" 為了要能拐騙產品負責人說出sprint的目標, 其中一種方法就是問他這個問題.
Sprint的目標應該是尚未達成的. "打動CEO"可能是不錯的目標, 但如果他已經留下深刻的印象, 在這種狀況下, 即使大家回家休息, sprint的目標仍然可以達成.
在sprint規劃過程中, 或許所訂出的sprint的目標看起很愚蠢, 或是很作做. 但是當大家開始對於他們該做什麼感到困惑時, 它經常會被拿出來提醒大家. 如果你有很多Scrum的團隊(想我們一樣), 可以把所有團隊的目標列在一個wiki的網頁上(或是其他系統), 並且把它放在一個明顯的地方, 讓公司內所有人(不只是高階主管)知道公司在做什麼, 以及為什麼要做.
決定在這次sprint要做哪些故事
在sprint規劃會議中, 一個主要的活動是決定哪些故事要在這個sprint中完成. 更具體的說, 哪些產品backlog中的故事要被放到sprint backlog中.
看一下上面那個圖, 每個長方形代表一個故事, 並且依重要性排序. 最重要的故事是放在最上面. 每個長方形的大小代表故事的大小(也就是故事時間點數的估算). 藍色括號的高度代表團隊評估的速度, 也就是團隊認為多少故事點數, 他們可以下一個sprint中完成.
在右邊的sprint backlog, 是產品backlog的一個故事快照(snapshot). 它代表團隊承諾要在這次sprint中, 所要完成的故事列表.
是團隊決定多少故事要在這個sprint中被完成, 而不是產品負責人或是其他人所決定的
這會引起兩個問題
1. 團隊如何決定哪些故事要被放到這次sprint中?
2. 產品負責人如何影響他們的決定?
我先回答第二個問題
產品負責人如何能影響哪些故事要放在這次sprint中?
在sprint規劃會議中, 假設我們遇到以下狀況
產品負責人很失望, 故事D沒有被排入這次的sprint中. 那在sprint規劃會議中他能做什麼?
有一個選擇是他能重新設定優先順序. 假如他賦予故事D較高的優先順序, 那團隊就不得不把它先加入sprint中 (在這裡需要把故事C給丟掉)
第二的選擇是他可以改變換範圍. 縮小故事A的範圍, 直到團隊認為故事D可以放到這個sprint為止
第三的選擇是他可以拆解故事. 產品負責人可能可以決定故事A中某些部分不重要, 所以把故事A分成故事A1和A2, 並且賦予不同的重要程度.
就如你所看到的, 雖然產品負責人在正常的狀況下不能控制團隊所評估出來的速度, 但是他還是有很多方法, 可以影響哪些故事要放到sprint裡面.
留言列表
