Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
交錯的每日會議
如果你在單一產品中有許多scrum團隊, 而且他們都在同一時間招開每日scrum會議, 你將會有很大的問題. 產品負責人(和我像這樣好管閒事)每天只能參加某個
團隊的每日會議.
所以我們要求團隊避免在相同時間去招開每日會議
以上是一個開會時程的範例, 我們招開每日會議在不同的房間, 而不是在團隊的房間. 會議通常是15分鐘, 但是每個團隊在每個房間都有保留30分鐘, 如果他們需要多一點時間.
這方法相當有用的, 理由有二.
1. 像產品負責人或是我自己, 在早晨會去參加所有每日會議. 沒有比這更好的方法,可讓你清楚知道每個sprint的進度, 以及關鍵的風險是什麼.
2. 團隊可以參加其他團隊的每日會議, 這通常不太常發生. 不過當有兩個團隊在類似的環境下工作, 有些成員會造訪其他團隊的每日的scrum會議, 以保持同步.
這方法的缺點是團隊的自由度變小 - 他們不能選擇任何他們喜歡的時間來舉行每日會議. 不過這還沒變成是我們問題
救火團隊
我們曾經遇到一個狀況, 一個很大的產品無法採用scrum, 因為他們花太多時間在救火. 也就是修復之前貿然出貨的系統所產生的錯誤. 這真的惡性循環, 他們忙於救火, 所以他們沒有時間主動去做些事情, 來預防火災(像是, 改進設計, 自動化測試, 建立監控工具與警報工具).
我們藉由建立一個專門的救火團隊, 和專門的scrum團隊, 來解決這個問題
Scrum團隊的工作是(帶著產品負責人的祝福)試圖去有效率地穩定系統, 預防事情惡化.
救火團隊(事實上我們叫它"支援團隊")有兩項工作.
1) 救火
2) 保護scrum 團隊免於各式各樣的干擾, 包括擋掉那些不知從哪裡來的, 任意功能的請求
救火團隊可放在最靠近們邊的地方, scrum團隊可以放在房間的最裡面. 所以救火團隊可以物理上保護scrum團隊, 免於著急的銷售人員或是生氣的客戶的干擾.
在兩邊都會安插資深的開發人員, 所以某一個團隊不會太依賴另一團隊的核心人員
基本上, 它是去解決scrum自我驅動問題的一種嘗試. 如果團隊一次無法有機會規劃超過一天的工作, 那要如何開始進行scrum呢? 我們曾經提過這樣的解法: 我們的策略是把它拆成兩個群組.
這方法運作的非常好. 因為scrum團隊有空間讓大家工作的很積極, 所以他們最後能穩定系統. 在這期間, 救火團隊完全地放棄事先規劃的念頭, 他們只是根據外面的需求來反應運作, 單單只修復下一個出現的問題
當然啦, scrum團隊也不是完全不被干擾. 救火團隊經常會請scrum團隊的關鍵人員來幫忙, 或最糟時, 需要整個團隊的幫忙.
但不管如何, 在幾個月後, 系統已經足夠穩定, 所以我們可以解散救火團隊, 並建立額外的scrum團隊. 救火隊員會很高興把壓扁的頭盔放在一旁, 然後加入scrum團隊中.
是否要拆解產品backlog
假設你有一個產品和兩個scrum團隊. 那應該有多少產品backlog? 多少的產品負責人呢? 我們為此曾經評估過三個模型. 選擇結果將會對sprint規劃會議如何被實行, 有很大的影響.
策略1: 一個產品負責人, 一個backlog
這裡有一個"只能有一個"的模型. 是我們最推薦的模型
這個模型的優點是, 你讓團隊根據產品負責人目前的最高優先順序, 來管理他們自己. 產品負責人只著重於他所需要的, 讓團隊決定如何拆解工作.
更具體一點, 這裡有個團隊sprint規劃會議如何運作的方式:
Sprint規劃會議在外面的會議中心舉行
在會議開始之前, 產品負責人指定一面牆, 當作"產品backlog的牆壁", 並且把故事放上去(用索引卡的方式), 依照相對的優先順序來排序. 他會放到直到牆壁被擺滿為止, 通常會比一個sprint要做的項目還要多.
每個scrum團隊選擇一面空的牆, 並且貼上自己團隊的名字. 這是他們的"團隊牆壁". 每個團隊會從產品backlog的牆壁拿取一些故事, 把這些索引卡貼到他們自己團隊的牆壁.
下面這張照片可以用來說明, 黃色箭頭表示故事的索引卡, 如何從產品backlog牆壁移到團隊牆壁的過程.
在會議的過程中, 產品負責人和團隊對於索引卡進行討價還價, 把他們在團隊間移動, 移上移下來調整優先順序, 或是把它們拆解成更小的項目, 等等. 再經過一小時左右, 每個團隊在他們的團隊牆壁上, 有第一個sprint backlog的候選版本. 隨後團隊獨立工作, 進行時間估算和把故事拆解成任務.
這會相當混亂吵雜, 和令人筋疲力盡, 但是效果不錯, 有趣, 和可以相互聯誼交流的. 當時間到時, 所有團隊通常已得到足夠的訊息, 讓他們可以開始下個sprint.
策略 2: 一個產品負責人, 多個backlog
在這個策略中, 產品負責人維護多個產品的backlog, 每個團隊對應一個. 我們沒有真的試過這個方法, 但是我們差點這樣做. 如果第一個方法失敗時, 基本上這是我們的備援計畫.
這個策略的缺點是, 產品負責人需要分配故事給團隊, 這件事情可能團隊自己做會比較好.
策略 3: 多個產品負責人, 每個人負責一個backlog
這個和第二個策略有點像, 每個團隊有一個產品backlog, 但是每個團隊也只有一個產品負責人
我們並沒有用這個方法, 可能也永遠不會使用
如果兩個產品backlog包含相同的程式碼, 將會造成兩個產品負責人之間嚴重的衝突
如果兩個產品backlog能分開程式碼, 這樣做和把產品拆成兩個子產品獨自運作並沒有兩樣. 這意味著我們回到了每個產品一個團隊的解決方案, 這將非常輕鬆和容易.
程式碼分支
當多個團隊同時在相同的程式碼上工作, 我們不可避免地, 必須利用SCM(軟體建構管理工具)來處理程式碼的分支. 有很多書籍或是文章在教你如何處理, 多個人在相同的程式碼上工作, 所以這裡我不再多談任何細節. 我沒有任何新的東西或是革命性的見解, 但是, 我將總結到目前為止, 我們團隊所學到的一些最重要的經驗.
# 應該要嚴格保持mainline(或是trunk)在一致的狀態. 這意味著最起碼, 每件事應該要被編譯, 所有的單元測試要被通過. 在每個時間點, 應該都可以產生一個可運作的發佈版本. 最好這個持續建構的系統在每天晚上可以進行建購, 並自動部署到測試環境中.
# 每個發佈都打上標記. 無論你何時發佈到驗收測試環境或是到產品環境, 要確認在你的manline中打上版本的標記, 用來準確辨識什麼東西被發佈. 這意味在未來任何時間, 你可以退回到之前某個時間點, 建立一個可維護的分支.
# 僅在需要的時候才建立新的分支. 這裡有一個好的規則: 當你在不違反codeline的政策下, 是無法使用現存的codeline, 這時候就可以分支一個新的codeline. 當有疑問時, 就不分支. 為什麼? 因為每次分支, 將導致複雜度和管理成本增加.
# 使用分支主要是為了切割不同的生命週期. 你可能會或可能不會, 決定每個scrum團隊能在他們自己的codeline進行編碼. 但是如果你把短程的修復和長程的改變放在同一個codeline, 你將會發現,那是非常困難去發佈短程的修復.
# 經常同步. 如果你在分支上工作, 每當你某些事情可以建構, 要記得同步回mainline. 每天當你要開始工作時, 把mainline的程式同步到分支上去. 所以你的分支才能及時, 以反映其他團隊的改變. 如果因為合併的痛苦, 導致你接受先不合併, 不過越等下去將會使這狀況越來越糟糕.
多個團隊的回顧會議
當有多個團隊在同一個產品中, 我們要如何做sprint回顧會議呢?
在sprint展示一結束後, 大家鼓掌, 每個團隊走回去他們自己的房間, 或是辦公室外某個舒服的地方. 他們進行回顧會議的方式, 和我之前在"我們如何進行sprint回顧會議"所描述沒有太大的不同.
在sprint規畫會議期間(因為我們已經同步每個產品的sprint, 所以所有團隊都參加), 第一件事情我們從每個團隊中找出一個發言人, 站起來簡述她們回顧會議中所得到的重要結論. 每個團隊花5分鐘. 然後我們有10-20分鐘的開放討論. 之後休息一下, 再開始真正的sprint規劃會議.
對於多個團隊的狀況, 我們還沒試過其他方法, 目前這方法已經足夠了. 不過最大的缺點是, 在sprint回顧會議後, 及sprint規劃會議前, 沒有任何鬆弛的時間. (請看"sprint之間的休息時間")
對於只有單一團隊的產品, 我們在sprint規劃會議中, 沒有需要做任何回顧的總結. 沒有必要是因為每個人都實際出席了回顧會議.
上一篇: Scrum and XP的實戰經驗 Ch15 (3)
留言列表
