通常我們在大規模使用 scrum 時, 會利用 scrum of scrums 來處理多個團隊之間同步資訊的問題.
什麼是 scrum of scrums 呢? 當你有很多人時, 根據 scrum 的經驗, 大約每個團隊的人數是 7 +/- 2 人, 因此會把一個很大的團隊, 拆解成多個小小的團隊 (或者是 feature team).
然後這些小團隊彼此之間若是要溝通時, 便會派出代表來進行討論, 這些代表通常是能夠解決這次討論問題的人.
如果這些代表的人數, 加起來遠超過7 +/- 2 人, 則表示這些代表的人, 需要再分成幾個小團隊, 這時候就是第二層的小團隊. 因為 scrum 認為團隊人數不要太大才會有效率.
那這些第二層的小團隊彼此之間要如何同步訊息呢? 同樣地, 也是要由每個第二層的小團隊, 指定出代表的人, 來參加討論的會議. 因此就會生成第三層的團隊.
如果第三層的團隊人數太多, 也要分成小團隊, 所以就這樣著上述方式, 一直遞迴下去來形成 scrum 小團隊來溝通.
這樣做會有什麼問題呢?
1. 只著重于最急的事情:
每次聚會時, 在大多數狀況下, 都是處理最急的事情, 可是對於中期規劃, 或是未來 2-3 個iteration 後, 小團隊之間的整合, 容易被忽略掉.
2. 容易變成只是狀態報告
就如每日立會(Daily Standup Meeting)一樣, 這種會議最容易會變成是在報告各自的狀態, 但是其實最重要的事, 是要說出哪些事情會影響別人, 或者哪些事情需要別人幫忙.
3. 不容易了解全貌
在大部份的狀況下, 參加這些 scrum of scrums 只是來自部分團隊, 大家可能只了解跟自己的一部份, 無法對於整體狀況有全盤的了解, 所以可能會做出局部最佳化的決策, 這會是 scrum of scrums 最大的問題.
不過, 幸好這種狀況不易發生, 因為台灣不會有這麼大的團隊, 並且還採用 scrum 的開發方法 XDDD
全站熱搜
留言列表
