第二章    組織團隊

摘錄至
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 2 Structuring the Teams

軟體專其中一個重要挑戰, 是如何把人們拆解適當大小的團隊, 並且讓這些團隊能合作得很好

當人數到達60 人時, 我們面臨了溝通和合作的困難, 這是典型團隊太大的問題. 很幸運地, 我們都在同一個地方工作, 最多花30 秒走路的距離就能找到彼此. 因此我們很容易實驗要如何組織團隊. 事實上, 組成適當團隊可能是這個專案最重要成功的因素.

以下是我們的團隊結構:

我們有五個團隊. 有些成員是在這些團隊以外, 負責一些特殊事務和協調的事情. 這些人像是project manager, project admin, configuration manager, performance test expert, development manager, coach等等.

1.      一個需求團隊 
-          它基本上是一個virtual team, 所以並沒有和團隊坐在一起, 但是會坐在附近, 讓團隊成員可以方便找得到
-          有些需求分析師在隸屬於某個feature team, 他會幫忙團隊釐清需求問題 
-          有些需求分析師是著重在大方向, 也就是它並不隸屬於某個feature team. 他會幫忙處理high levelfeature areas
-          剩下的需求分析師可能會依狀況, 來幫忙前面兩項的事情

2.      三個feature team 
-          基本上它們是Scrum團隊, 也就是要在同一地方工作, 跨職務, 自我組織, 能處理一個功能中所有的開發和測試工作 

3.      一個system test team

-          它基本上是一個virtual team.

-          有些測試人員在隸屬於某個feature team, 他會幫忙團隊對於feature level來進行測試和除錯

-          有些測試人員是著重在大方向. 他會對要release的版本, 進行high levelsystem tests, 整合測試.

-          剩下的測試人員可能會依狀況, 來幫忙前面兩項的事情

以前我們都是依職務來分團隊, 像是需求分析團隊, 開發團隊, 測試團隊等等. 因此會導致有以下問題
1.      當人越多時, 需要和其他團隊溝通的複雜度增加
2.      團隊之間只會想用文件來溝通, 而忘記多交談, 並且容易指責彼此 
3.      每個團隊只會想要把他們團隊的事情先做好, 而不是去交付一個客戶要的功能.

現在這樣的作法, feature team是跨職務, 人數較少, 比較好溝通. 並且著重於要交付的feature. 並且也有人可以去看大方向的部分. 兼顧了短期和長期的考量.

 


    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()