敏捷方法的成功密技(八):Scrum 的衝刺時間長短怎麼訂?

敏捷方法的成功密技(八):Scrum 的衝刺時間長短怎麼訂?
(Photo by Jonathan Chng from Unsplash
 
一個衝刺(Sprint)的時間長短到底應該是多少才是最好的呢?如果衝刺的時間設定得太長,那麼,應變的彈性就會變得比較小,而如果衝刺的時間設定得太短,那麼,又容易讓開發團隊能產出的成果出問題。怎麼說呢?
 

衝刺時間長好,還是短好?

 
因為所有被選進衝刺內實做的用戶故事,在衝刺期間內將都會被鎖定,不能任意更改,以讓開發團隊聚焦、計速、守承諾,所以,衝刺的時間如果設定得太長,就會讓用戶故事的「變更」這件事情,變得比較沒有彈性,必須等到衝刺結束之後,才能夠進行討論和修改。
 
可是如果衝刺的時間設定得太短,就很可能會讓產出的成果功能很有限,也很容易讓開發團隊因為一些意外狀況而導致時間不足,倉促犧牲測試的完整度、DoD(Definition of Done)的檢驗,囫圇吞棗地釋出(release)一個不完善的成果。
 
這樣的結果,勢必會產生大量的 bug,而這些 bug 也就勢必會影響到下一個衝刺的進行,犧牲掉下一個衝刺的部分開發時間!因為,不解決一些 show stoppers(或 gating issues)的話,已經在客戶端試用中,或是已經部份對外開放,上線營運的服務,就會停擺,甚至招致致命性的損失,包括實質的營收,以及無形的商譽損失!
 

誰來做衝刺時間最終的裁決?

 
除了時間長短的議題之外,那到底衝刺的時間長短,應該由誰來決定比較好、比較合適呢?
 
聰明的你一定想到了,答案當然是整個團隊一起決定(廢話XD)!因為,Scrum 方法的精神就是著重團隊的自我管理啊!
 
問題是,人多嘴雜,大家的想法、意見、初衷、角度都不相同,要達成一致的共識,其實也沒有這麼簡單。比方說,PO(產品負責人)可能希望一個衝刺的時間可以短一些,那麼,他/她就可以比較頻繁地檢驗開發團隊的產出、跟客戶溝通最新的進度等。然而,開發團隊卻不一定這麼認為。開發團隊可能希望,一個衝刺的時間最好長一些,這樣他們就可以把功能做完整一些、測試做完整一些、這樣交出去的成果也會完善一些。
 
這個時候,你也許已經意識到了,沒錯,是 Scrum Master 該跳出來的時候了!
 
Scrum Master 是引導開發團隊,朝高效產出的方向去發展的那個人,當團隊進入冗長、無法達成一致共識的時候,Scrum Master 應該要有 guts 做決定,讓團隊能擺脫內耗,繼續快速前進。當然,說明這樣決定的理由,取得團隊的諒解,是必要的動作!
 
其實,我們也不需要過於擔心這樣的事會常常發生。因為,如果您的 Scrum 開發團隊連這麼小的決策都會爭論不休,那麼,未來整個產品的開發過程勢必會很堪慮,您可能得考慮調整一下團隊的組成份子了!
 
您也許會問,我們人就這些,根本也沒得換,難道就沒有其他更好的方式了嗎?答案是,當然有的!
 

決定衝刺時間更好的方法

 
對於不是首次導入 Scrum 的組織而言,您一定有過去的經驗和紀錄可以參考。
 
當然,過去那個 Scrum 團隊成員的組成、能力的差異、產品的技術難度、時程緊繃的程度等,皆與現在即將要進行的 Scrum 也許會有些不同。把這些因素考慮進來之後,通常決定現在這個 Scrum 的衝刺時間週期,也就不是什麼大不了的難事了。比較難的是,如果您的組織是首次導入 Scrum ,根本就沒有歷史資料可以參考,那該怎麼辦?
 
其實,回到我們想導入 Scrum 的初衷,事情也就不這麼難決定了。
 
既然我們在講 Scrum,是要利用它的「敏捷」精神,那麼,為什麼我們在決定衝刺的時間週期的時候,我們不可以也用敏捷的精神來試試,看看各種不同長度的衝刺時間,對整個團隊和產品的屬性是否合適呢?
 
一個簡單又可行的方法是這樣做的。
 
因為大家對 Scrum 還不熟悉,團隊成員之間的默契也還沒有建立起來,我們大可以先設定兩週為一個衝刺的週期。這樣的時間不至於過短,也不至於過長。等團隊運作過2、3個衝刺(約莫一至兩個月左右),團隊開始對於 Scrum 的流程和合作模式有了一定程度的熟悉和掌握之後,再調整衝刺的週期為固定的時間長度。
 
經過這樣的測試,團隊也許會繼續維持衝刺週期為2週,也許就調整改為3或4週了。但重點是,從此就得固定下來,在接下來的產品開發過程當中,不能再繼續做變動。
 

一切都是為了有掌握

 
不能一直變動的理由很簡單。一直變動的衝刺週期,無法讓人產生節奏感,團隊將無法抓到團隊的開發速度感、節奏感。這樣就很容易會讓團隊像是在大霧中開車一樣,沒有方向感,甚至是產生恐懼感,對團隊自己的開發速度掌握沒有信心,進而削弱團隊的士氣和熱情。
 
衝刺時間不超過四週的理由,就是要為無可避免的「變更」保留即時的彈性,也避免團隊發生「學生效應」(您的暑假作業都何時做?)。而衝刺時間不低於一週的理由更簡單,因為很難有東西可以產出啊!
 
依 Scrum 的定義,Scrum Master 無疑是整個 Scrum 流程的管控者。既然是流程的管控者,當然就包含衝刺的時間週期的制定。所以,如果上述方法都還沒法讓衝刺的時間週期定下來,Scrum Master,您就獨裁決定吧!
 
原文轉貼自:威廉網紙原文連結
本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
盧鄭麟 William Lu

盧老師曾任HTC軟體專案經理團隊主管,掌管上百個智慧型手機軟體專案(包含全球首款WiMAX 4G手機),總出貨量超過 1,500 萬支。亦曾於趨勢科技、友立資訊、華康科技、文生真空科技等企業擔任研發部門主管、產品經理,以及總經理室協理等職務,領導軟體研發團隊與管理專案之實務經歷超過20年。 盧老師在教學上善於利用遊戲化教學,將真實情境轉換為模擬個案,引導學員透過動手實作來學習管理知識。授課經驗包含兩岸多家知名企業,例如台達電子、華碩電腦、揚智科技(台北/上海/珠海)、久元電子、飛宏科技、宜鼎國際、精技電腦、震旦集團、南僑集團 (上海)、杏輝醫藥集團、新北市政府等。