4. 我們如何產生sprint計畫
Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
Sprint規劃是非常重要的會議, 應該算是Scrum中最重要活動(當然啦, 這是我個人的意見). 執行不好的sprint規劃會議, 將會毀掉整個spint.
Sprint規劃會議的目的, 是要給團隊足夠的資訊, 好讓他們能在之後幾個星期內, 能不受干擾地工作; 同時也是給產品負責人能對此有充分的信心,
好吧! 你可能會說這樣還是相當模糊. 其實, Sprint規劃會議會產生出一些有用的成果
# Sprint的目標
# 團隊成員的名單(如果他們不是100%投入, 則需要列出他們投入的程度)
# Sprint backlog (也就是在sprint中所包含的故事列表)
# 事前訂好的展示時間
# 對於Scrum的每日會議, 事前訂好舉行的時間和地點
為什麼產品負責人需要參加?
有時候產品負責人不願意花數個小時, 和團隊一起討論sprint的規劃. "同事們, 我已經列出我所想要的, 我沒有時間一直呆在你們sprint規劃的會議中", 這是相當嚴重的問題.
為什麼整個團隊和產品負責人都需要參加sprint規劃會議, 原因是因為每個故事包含三項變數, 彼此之間都有高度的關連.
範圍(scope)和重要性(importance)是由產品負責人決定的. 但是估算是由團隊決定的. 在Sprint規劃會議期間, 經由團隊和產品負責人面對面討論, 這三個變數才能逐漸調整到理想的結果.
一般來說, 會議一開始, 產品負責人要簡述一下他對sprint和最重要的故事, 想要達成的目標是什麼. 接著, 要從最重要的故事開始, 團隊逐一討論和評估每個story. 在他們做這事情的時候, 他們必須對範圍(scope)提出重要的問題: "刪除使用者這個故事, 需不需要把所有使用者還沒處理處理完的交易也一並刪除?" 有時候答案可能會讓團隊很吃驚, 因此而讓他們調整他們的估算.
在某些狀況下, 對某個故事的時間估算, 可能不是產品負責人所期待的. 這可能會讓他調整這個故事的重要性, 或是改變故事的範圍, 因此而導致一連串的重新估算.
像這樣直接合作的形式是Srcum的基本, 事實上也是敏捷軟體開發的基礎.
如果產品負責人堅持他並沒有時間去參加Sprint規劃會議, 那該怎麼辦? 我通常會根據這樣的順序, 嘗試以下的策略:
# 嘗試幫助產品負責人了解到為什麼他的直接參與是非常關鍵, 希望能夠改變他的心意
# 嘗試讓團隊中某個成員, 志願在會議過程中, 扮演產品負責人的代理人. 然後告訴產品負責人: "因為你不能參與我們的會議, 我們會讓Jeff在這裡當你的代理人. 在會議中, 他會被充分授權, 去修改故事的優先順序和範圍. 我會建議你和他在會議之前, 儘可能讓你們的想法一致. 如果你不喜歡Jeff當你的代理人, 你可以換其他人, 只要這個人可以全程參加我們的會議就可以
# 試著說服管理團隊指派一個新的產品負責人
# 在產品負責人找到時間來參加會議之前, 會先暫緩sprint開始的時間. 同時, 拒絕承諾任何交付項目. 讓團隊每天都可以做他們最想要做的事情
為什麼品質是不可被談判的
在上面那個三角形中, 我刻意忽略了第四個變數: 品質
我企圖去把品質區分成內部品質和外部品質
# 外部品質是系統的使用者可以感覺到的, 一個緩慢和不直覺的使用者介面, 便是一個很明顯的例子
# 內部品質是指一般使用者看到不的問題, 但是它會深深影響到系統的可維護性. 像系統設計的一致性, 測試涵蓋度, 程式的可讀性和refactoring等等
一般說來, 若是一個系統內部品質很高, 仍然有可能會外部品質還是很差. 但是若是內部品質差的系統, 很少會有很好的外部品質. 試想, 在鬆軟的沙灘上, 如何建立堅固精緻的大樓.
我把外部品質也視為範圍的一部份. 有時在商業的考量下, 可能會發布一版, 它的使用介面比較簡陋, 並且反應速度也比較慢. 不過隨後發行一版比較乾淨的版本. 我會把這些做或不做的決定權留給產品負責人, 畢竟他是負責決定範圍的人.
然而, 內部品質就沒有得談了, 不管在怎樣的狀況, 團隊都要維護系統的品質, 這是無庸置疑的, 沒有可以討價還價的, 現在如此, 未來如此, 從來都是如此.
(好吧, 差不多是直到永遠)
所以我們如何區分哪些是內部品質, 哪些是外部品質的問題呢?
假如說, 產品負責人說: "我尊重妳們所估算的6個故事點數, 但是如果你們能花點心思, 你們一定找到依些快速解(quick-fix)的方法, 來節省一半的時間"
哈! 他想把內部品質當作一個變數. 你會想說我怎麼會知道呢? 因為他要我們縮短所評估出來的時間, 可是卻沒有要對減少要做的範圍這件事情來"買單". 所謂"快速解"這件事會敲響你的腦中警鐘
為什麼我們不允許這樣做?
我的經驗告訴我, 犧牲內部品質是一個很糟, 很糟的想法. 所省下來的時間, 在之後的日子會不斷為它付出代價. 一旦我們允許這樣做, 後面就很難恢復品質了
相反地, 我會試圖把話題回到範圍上面來, "既然你覺得早一點達到這個功能是很重要的, 我們能不能縮小這個範圍, 好讓我們能縮短實作時間? 或者我們可以簡化錯誤處理的的方式, 讓完整的錯誤處理方式變成另一個故事, 讓我們之後再去處理它? 或是我們降低其它故事的優先順序, 讓我們先集中精神處理這一個?"
一旦產品負責人學到內部品質是不能被討價還價的, 那對於其他變數, 反而他將會處理的很好
永無止境的sprint規劃會議....
在Sprint規劃會議中, 最困難的事情是:
(1) 人們不認為他們會花這麼多時間
(2) ...但是他們會的!
Scrum中每件事情都是有時間框的(time-boxed). 我喜歡簡單, 一致的規則. 我們試圖去堅守它.
如果sprint規劃會議時間快要用完, 但是仍然沒有sprint的目標或是backlog產生, 那要怎麼辦呢? 我們要打斷它嗎? 還是要延長一個小時嗎? 或是準時結束明天再繼續?
這種事常常一而再發生, 特別是新上手的團隊. 那你會怎麼做? 我也不知道. 但是我們的作法是什麼呢? 嗯....好的, 通常我會直接打斷它, 結束它. 讓這個sprint去承受這個沒有結果的事情. 更具體一點, 我會告訴團隊和產品負責人: "會議會在十分鐘後結束, 我們還沒有一個真正的sprint計畫. 我們是要照已經有結論的部份先作, 還是要明天早上8點, 再來個4小時的sprint規劃會議?" 你猜他們會怎麼回答... :o)
我也嘗試讓會議繼續下去, 但是通常還是沒有完成什麼事情, 因為大家都太累了. 如果他們在2~8小時內(不管你的時間長度是多少)沒有產生還可以的sprint計畫, 即使再一小時他們也不會有結果. 隔天再另外安排一個會議, 或許是一個還不錯的主意. 但是大家已經失去耐心, 只想開始這個sprint, 不想再花另外的時間去做歸劃.
所以我會打斷它. 是的, 這個sprint中, 大家會承受這個問題. 但是, 正面來說, 團隊學到非常寶貴的經驗, 下次會讓sprint規劃會議更有效率. 此外, 或許他們之前覺得你訂下的會議時間過長, 這時候大家將比較不會去抵制.
學習去遵守你的時間框(time-boxed), 並且學習設定合理的時間框長度. 那對會議長度和sprint長度的設定也有幫助.
Sprint規劃會議的議程
對於sprint規劃會議, 若是有事前制定好的時間表, 可以減少違反時間框(time box)的風險
這裡有一個我們用的典型的時間表:
Sprint規劃會議: 13:00-17:00 (每個小時休息10分鐘)
# 13:00 – 13:30. 產品負責人會介紹sprint的目標和簡述產品的backlog. 訂定要展示的地點和時間.
# 13:30 – 15:00. 團隊評估所需時間, 必要時, 進一步拆解backlog項目. 有需要的話, 產品負責人也更新重要性(importance)欄位的估算. 所有項目都被釐清. 對於所有有高重
要性的項目, "如何展示"的欄位都需要被填寫.
# 15:00 – 16:00. 團隊選擇哪些故事要被放入這次sprint當中. 並計算團隊的速度, 來檢查工作分派的狀況
# 16:00 – 17:00. 為了每日scrum會議, 安排固定的時間和地點. 並進一步把故事拆解成工作項目.
這個時間表並不是要完全固定不變, Scrum master可以根據會議的進程, 來延長或是縮短某個子項目的時間
留言列表
