第二章 組織團隊
摘錄至 軟體專其中一個重要挑戰, 是如何把人們拆解適當大小的團隊, 並且讓這些團隊能合作得很好
當人數到達60 人時, 我們面臨了溝通和合作的困難, 這是典型團隊太大的問題. 很幸運地, 我們都在同一個地方工作, 最多花30 秒走路的距離就能找到彼此. 因此我們很容易實驗要如何組織團隊. 事實上, 組成適當團隊可能是這個專案最重要成功的因素.
以下是我們的團隊結構:
我們有五個團隊. 有些成員是在這些團隊以外, 負責一些特殊事務和協調的事情. 這些人像是project manager, project admin, configuration manager, performance test expert, development manager, coach等等.
1. 一個需求團隊 2. 三個feature team
Lean from the Trenches - managing large-scale projects with kanban, Henrik Kniberg
Chapter 2 Structuring the Teams
- 它基本上是一個virtual team, 所以並沒有和團隊坐在一起, 但是會坐在附近, 讓團隊成員可以方便找得到.
- 有些需求分析師在隸屬於某個feature team, 他會幫忙團隊釐清需求問題
- 有些需求分析師是著重在大方向, 也就是它並不隸屬於某個feature team. 他會幫忙處理high level的feature areas
- 剩下的需求分析師可能會依狀況, 來幫忙前面兩項的事情
- 基本上它們是Scrum團隊, 也就是要在同一地方工作, 跨職務, 自我組織, 能處理一個功能中所有的開發和測試工作.
3. 一個system test team
- 它基本上是一個virtual team.
- 有些測試人員在隸屬於某個feature team, 他會幫忙團隊對於feature level來進行測試和除錯
- 有些測試人員是著重在大方向. 他會對要release的版本, 進行high level的system tests, 整合測試.
- 剩下的測試人員可能會依狀況, 來幫忙前面兩項的事情
以前我們都是依職務來分團隊, 像是需求分析團隊, 開發團隊, 測試團隊等等. 因此會導致有以下問題: 現在這樣的作法, 讓feature team是跨職務, 人數較少, 比較好溝通. 並且著重於要交付的feature. 並且也有人可以去看大方向的部分. 兼顧了短期和長期的考量.
1. 當人越多時, 需要和其他團隊溝通的複雜度增加
2. 團隊之間只會想用文件來溝通, 而忘記多交談, 並且容易指責彼此
3. 每個團隊只會想要把他們團隊的事情先做好, 而不是去交付一個客戶要的功能.
留言列表
