用 Kanban + Scrum 支援大型專案(2)：分組方式

Nov. 12 10:25~11:45

 

Teddy在《用 Kanban + Scrum 支援大型專案》介紹了如何利用專案看板來擴展Scrum團隊以便支援大型專案的概念，今天續攤繼續介紹《Lean from the Trenches: Managing Large-Scale Projects with Kanban》這本書中提到的大型敏捷團隊分組模式。

在上一集中Teddy只提到如果團隊人數很多（數十人），則可以將5-9人分一小組來進行專案開發，但問題是：要如何分組？幾十個人的專案，需求要如何分析？功能要如何開發？測試要如何進行？以Scrum的角度來看，專案（產品）的需求是由Product Owner（PO，產品擁有者）來定義的，但是幾十人的專案，需求大小與複雜度有一定的規模，僅僅只是依靠一個PO似乎不容易把需求弄清楚。此外，當若干個開發團隊同時間一起施工（開發軟體）的時候，如果團隊成員對於需求有疑問，大家都要找這個PO，那PO不是分身乏術，忙死了。

測試也是一個難題，傳統上測試位於整個開發流程的後端，等開發人員把做好的軟體一次交付給測試團隊的時候，開發人員此時通常沒啥事可做，但是測試人員卻是忙得要死（反之亦然）。在敏捷開發方法中，要如何解決這個問題，特別是在團隊人數比較多的情況下，要如何避免在專案後期才跑出一大堆測試的工作出來？

上圖是書中介紹的分組模式，和Teddy之前的經驗很類似，只不過Teddy之前團隊的規模比較小 。圖中央的三個團隊稱之為「功能團隊」（feature team，請參考《Scrum框架下的跨界開發(4):分組方式》），主要是負責開發（實作功能）的團隊。圖中用虛線圈起來的兩個團隊，分別是「需求分析團隊」與「系統測試團隊」。這兩個團隊稱之為「虛擬團隊」（virtual team）。

***

需求分析團隊

• 團隊成員並不像實際團隊（上圖中的功能團隊）需要坐在一起工作，而是分散在專案中各個需要需求分析師的地方。
• 有些分析師會跟功能團隊在一起以便回答開發人員的問題（有點類似PO的角色）。
• 有些分析師是負責整個專案的「big picture」（綜觀全局），這些人並不屬於任何的功能團隊，而是專注在分析整體專案功能模組上面。
• 有些分析師則是依據實際需要有時與功能團隊一起開發，有時則回頭關注整體的專案功能。
  

如果鄉民們還記得Teddy之前寫過的「Scrum框架下的跨界開發」系列文章中提到UX/UI設計師與團隊合作的模式，在這裡也可以把UX/UI設計師歸類在需求分析團隊，協助PO（需求分析師）在分析需求時同時考慮使用流程或是使用者體驗這類的問題。

系統測試團隊

• 系統測試團隊的特性與需求分析團隊類似，團隊成員並不像實際團隊需要坐在一起工作，而是分散在各個功能團隊之中，負責協助執行測試工作。
• 有些測試工程師會跟功能團隊在一起，協助功能測試與除錯。
• 有些測試工程師則是負責整個專案的「big picture」，這些測試工程師不屬於任何的功能團隊，而是負責整合測試與系統測試。
• 有些測試工程師則是依據實際需要有時與功能團隊一起開發，有時則回頭關注整體專案的整合與系統測試工作。

***

鄉民甲：圖中還有一群人（綠色的人形圖示）並沒有包含在上述任何一個團隊之中，這些人是做什麼的？

Teddy：這些人主要在負責協調或是特殊專長的工作。例如，專案經理、建構工程師、敏捷顧問、技術文件工程師等等。如果鄉民們的團隊夠大的話，這些人也有可能單獨被抽離出來變成一個團隊，例如《Scrum框架下的跨界開發(4):分組方式》中所提到的，在大型專案中，有可能會有一個獨立的「整合團隊」（integration team）負責建構管理與持續整合的工作。

***

結合《Lean from the Trenches: Managing Large-Scale Projects with Kanban》與《Agile Game Development with Scrum》這兩本書所介紹的分組模式，應該可以應付絕大多數的大型敏捷專案需求。

***

友藏內心獨白：人先找來再說啦 。