Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
為什麼我們要導入"團隊領導"的角色
假設我們一個產品有三個團隊
那個標記P, 紅色的傢伙是產品負責人. 標記S, 黑色的傢伙是scrum master. 其餘的都是咕噥著...呃...尊敬的團隊成員
在這樣群星聚集的團隊中, 誰要決定哪些人應該在哪個團隊中? 產品負責人是誰? 這三個scrum master一起搞定嗎? 或是讓每個人選擇他要參加的團隊? 如果每個人都要待在團隊1要怎麼辦?(因為scrum master 1看起太帥了嗎?)
如果後來證明, 這確實是不可能有超過兩個以上的團隊, 並行處理這份的程式碼. 所以我們必須把3個6人的團隊, 轉變成2個9人的團隊. 意味著只要2個scrum master. 所以哪一個scrum master要被免除頭銜呢?
這在許多公司都是非常敏感的問題.
讓產品負責人去作人員的配置或重新分配, 是乎很誘人. 但是這不是產品負責人該做的事, 對吧? 產品負責人他是領域的專家, 可以告訴團隊他們應該朝哪個方向運行. 他不應該介入這些內部的細節. 尤其是他是"chicken"的話(如果你沒有聽過 chicken 和pag的隱喻, 可以google一下""chickens and pigS")
我們藉由導入"團隊領導"這個角色去解決問題. 你可能叫他"Scrum of Scrums master", "the boss" 或是 "main Scrum master"等等. 他不用去領導單一團隊, 不過他必須負責跨團隊的問題, 像是誰應該是團隊的scrum master, 人員應該如何被拆解到不同團隊中, 等等.
我們花了一段時間才為這個角色想出好的名稱. "團隊領導"已經是我們能想出最不糟糕的名稱.
這個解決方案運作的很好, 我向你大力推薦一下 (不管你決定要叫這個角色什麼)
我們如何配置人手到團隊中
當你有多個團隊在同一個產品工作時, 這裡有兩個普遍的策略, 來分配人員到團隊中.
# 讓某個指定的人來分配, 例如, 我前面所提到的"團隊領導", 產品負責人, 或是功能經理人(functional manager)(如果他參與的夠深入, 他就能做出正確的決定)
# 讓團隊以某種方式自己進行
我們嘗試過以上三種方法. 三種? 是的. 策略1 , 策略2, 和兩者的組合
我們發現兩者組合的結果最好.
在sprint規劃會議前, 團隊領導需要和產品負責人和所有scrum master一起開團隊配置會議. 我們討論上一個sprint, 並決定重新配制是否需要. 可能我們要整合兩個團隊, 或是把某些人從某個團隊移動到另一個團隊. 我們決定某些事情, 把它寫下來, 當做所提議的團隊配置, 並把它帶回到sprint規劃會議討論.
在sprint規劃會議中第一件事, 就是檢視產品backlog中, 最高優先順序的項目. 團隊領導可能會說:
"嗨, 各位, 在下一個sprint, 我們建議以下的團隊配置"
"就你們所看到的, 這樣意味我們從4個團隊減到3個團隊. 我們已經列出每個團隊中成員. 請大家聚在一起, 自己在牆上佔一塊區域"
(人們來回在房間內走動, 團隊領導耐心地等待. 過了一段時間, 這三組人馬, 每一個團隊站在一個空牆區域)
"目前這樣團隊的拆解只是開端! 它只是一個起點, 以節省大家的時間. 在sprint規劃會議的過程, 你可以自由地換到另一個團隊, 把你的團隊猜解成兩個, 或是和另一個團隊整合在一起, 或怎樣都可以. 根據產品負責人的優先順序,來當作處理事情的基本常識"
我們發現這樣處理效果最好. 一開始某種程度的中央集權控制, 之後再某種程度的個別最佳化
要不要有特別的團隊?
假設你的技術由三個主要元件所組成
並且假設你有15個人為這個產品工作, 所以你不想把他們都組成同一個團隊. 那你會怎樣組織你的團隊呢?
方法 1: 特定元件的團隊
有一個方法是建立特定元件的團隊, 像是"用戶端團隊", "伺服器端團隊", 和"資料庫團隊"
我們一開始這樣做, 不過運作的不是很好, 至少當大部分的故事包含許多元件時, 就不太好.
例如, 假設我們有一個故事叫"留言板, 使用者可以留下訊息給其他人". 這個留言板的功能包括更新用戶端使用者界面, 在伺服器端新增邏輯, 在資料庫內加些表格.
這意味著所有三個團隊 - 用戶端團隊, 伺服器端團隊, 和資料庫團隊 - 必須協同合作去完成這個故事. 並不是太好.
方法 2: 跨元件的團隊
第二個方法是建立一個跨元件的團隊, 也就是, 團隊不會被約束在任何特定的元件上面
如果你的許多故事都包含多個元件, 這種形式的團隊切割策略都可以運作的不錯. 每個團對可能實作一個完整的故事, 包含用戶端, 伺服器端, 以及資料庫端. 所以團隊可以運作地更獨立, 那是一件好事.
當我們實施scrum時, 其中第一件事就是把現存特定元件的團隊打散(方法 1), 並且建立跨元件的團隊(方法 2). 減少了像這種狀況的發生次數: "我們無法完成這個項目, 因為我們必須等待伺服器端的人完成"
然而, 當真的有強烈的需求時, 我們有時候也會成立臨時的特定元件的團隊
上一篇: Scrum and XP的實戰經驗 Ch15 (1)
下一篇: Scrum and XP的實戰經驗 Ch15 (3)
留言列表
