Scrum and XP的實戰經驗 Ch4 (2) @ David Ko的學習之旅

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中.