Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
15. 我們怎樣處理多個Scrum團隊
當你有許多Scrum的團隊工作在同一個產品時, 許多事情會變得比較困難. 這問題是眾所周知的, 和Scum實際上沒有太多關係. 更多的開發人員 = 更複雜的狀況
我們(和以前一樣)遭遇過這種狀況. 最多的時候, 我們大約有40個人在做同一個產品
主要的問題是
# 要建立多少團隊
# 要如何分配人員到團隊當中
要建立多少團隊
如果處理多個scrum團隊是這麼困難, 我們為什麼要這麼做呢? 為什麼不把所有人都放到同一個團隊中呢?
我們曾經有的最大scru,團隊大約是11個人. 它是可以動的, 但是無法運作的很好. 每日scrum會議往往會拖超過去15分鐘. 團隊成員不知道其他成員在做什麼, 所以有點混亂. Scrum master很難讓其他成員都朝著相同目標前進, 也不容易找到時間去解決所有回報的問題.
另外一個方法是把它拆成兩個團隊, 但會比較好嗎? 不一定.
如果團隊對scrum很有經驗並且也很適應, 可以用邏輯的方式將產品規劃藍圖, 切割成兩個不同的行動路線, 並且這兩個行動路線不會使用到相同的程式碼. 那我會說把它分成兩個團隊是件好的主意. 否則我會考慮把它合成一個團隊, 不管大的團隊會有怎樣的缺點.
我的經驗是, 寧可團隊數量較少, 但是人數較多. 若是團隊個數多, 但人數少, 容易相互干擾. 因此要成立小團隊, 必須確保他們不會相互干擾.
虛擬團隊
對於"大團隊"與"很多團隊"之間的權衡, 你怎麼知道您做出了正確的, 或是錯誤的決定?
如果你一直打開眼睛和耳朵, 你可能會注意到"虛擬團隊"的形式
範例 1: 你選擇大的團隊. 但是在sprint過程中, 你查看誰和誰在講話時, 你注意到團隊有效地自行分成兩個小團隊
範例 2: 你選擇成立三個小團隊. 但是在sprint過程中, 你查看誰和誰在講話時, 你注意到團隊1和團隊2會一直在交談, 而團隊3工作上比較孤立.
所以, 這代表什麼意思? 是你團隊切割策略不正確嗎? 如果不正確，虛擬團隊似乎是永久不變. 如果正確, 虛擬團隊似乎是暫時的.
讓我們再看一次範例 1. 如果兩個虛擬子團隊一直在改變(也就是, 大家在虛擬子團隊間移動), 那你可以決定把他們放到同一個scrum團隊. 如果兩個虛擬子團隊, 在整個sprint過程中都待在相同的地方, 你可以在下一個sprint中, 把他們拆解成兩個真正的scrum團隊.
現在再看看範例 2. 如果團隊1和團隊2在整個sprint中都一直在交談(不是和團隊 3), 你可能在下一個sprint中, 要去把團隊1和團隊2結合成一個團隊. 如果在sprint前半段, 團隊1和團隊2一直在交談; 在sprint後半段, 團隊1和團隊3則一直在交談, 你可以考慮把三個團隊變成一個, 或是還是保留原先三個團隊. 把這個問題帶到回顧會議中, 讓團隊自己決定.
團隊切割,是scrum其中一個困難的部份. 不要想太多, 或是花太多精力去最佳化. 先做實驗, 對虛擬團隊保持觀察, 確認你在回顧會議中, 有足夠的時間去討論這類議題. 遲早你會根據你的狀況, 發現最佳的解決方案. 最重要的事情是團隊會覺得舒適, 不會常常互相干擾到.
最佳的團隊大小
在大部分我所讀過的書中, 都宣稱最佳團隊的大小是大約5-9人
到目前為止, 我所觀察的團隊來說, 我同意這個說法. 不過我會建議3-8人. 事實上, 我相信值得花些代價, 去達到這樣的團隊大小.
假設你有一個團隊是10個人. 考慮把兩個最弱的成員趕出去吧. 哦, 我真的有那樣說嗎?
假設你有兩個產品, 每個產品都有一個3個人的團隊, 兩個都進行的很緩慢. 把它變成一個6個人的團隊去負責兩個產品, 或許是個好主意. 在這個情況, 讓其中一個產品負責人離開(或是給他顧問之類的角色)
假設你有一個12個人的團隊, 因為程式碼處於很糟糕的狀況, 沒有方法讓兩個不同的團隊, 獨立在上面工作. 所以需要認真投入新入去改進這些程式碼(而不是建立新功能), 直到你可以拆解他們為止. 這投資很快你就可以得到回報.
是否要同步多個sprint?
假設你有三個scrum團隊, 都為同一個產品工作. 他們的sprint應該要被同步嗎? 也就是, 開始和結束都相同嗎? 或是他們應該重疊嗎?
我們一開始的方法是有重疊的sprints(因為各自時間考量的關係)
聽起來不錯. 在任何一個時間點上, 會一個正在進行的sprint要結束, 或是一個新的sprint正要開始. 產品負責人的工作量, 隨著時間的演進, 將會均勻地分佈各個sprint中. 系統將會持續不斷地被發佈, 每一週都有展示, 哈利路亞!!
耶, 我知道你要說什麼, 但是那時候聽起來是蠻有說服力的
我們之前開始一直是這樣做, 直到有一天我有機會和Ken Schwaber對談時(在我scrum認證時). 他指出這是一個不好的主意, 比較好的方法是去同步sprints. 我已經不記得他確切的理由, 但是在幾次討論後, 我被說服了.
這是我們後來使用的解決方案, 之後沒有覺得後悔或不好. 我永遠不會知道, 是否重疊的sprint終究會失敗. 但是我認為會如此. 同步sprints會有以下的好處:
# 這裡自然有時間去重新組織團隊 - 在sprint之間的時間! 在重疊的sprint中, 沒有任何方法可以重新組織團隊, 而不干擾到某一個正在進行sprint的團隊.
# 所有的團隊可以在同一個sprint中, 朝向相同目標努力, 可以一起做sprint規劃會議, 導致團隊間會有較好的協同合作
# 較少的管理花費, 也就是, 較少的sprint規劃會議, sprint展示, 和發佈.
下一頁: Scrum and XP的實戰經驗 Ch15(2)(http://www.wretch.cc/blog/kojenchieh/15285551)
留言列表
