Feature Team or Component Team?

Feb. 02 22:11~22:51

 

有一次上Scrum課程的時候，一位學員A問了一個關於敏捷開發團隊組成的問題。

學員：你說要組織cross-functional team（feature team）而不要組織component team（functional team），可是我們公司之前有一個專案，前端有網頁、iOS、Android等不同平台，負責開發這些產品的團隊是採用cross-functional team，但後端共用的平台我們則是採用component team的方式。這麼做的原因是因為如果後端平台不集中控管而是交由三個前端團隊自行開發，可能會造成後端系統無法整合的問題。

Teddy：你們這樣分工運作順利嗎？

學員A：嗯，如果從「平台一致性」的角度來看，這麼做是很好，為整個後端平台統一交由一個團隊來負責。問題出現在三個前端平台與後端團隊的溝通上，因為後端平台的需求不是end-to-end story，而是從API/Service的角度出發。加上同時要應付三個不同團隊的需求，因此在工作安排上經常有等待的浪費出現。

Teddy：你覺得你們的後台系統有可能採用逐步成長的開發模式嗎？

學員A：什麼是逐步成長的開發模式？

Teddy：就是不要有單獨的後台component team，整個後台的功能是藉由前端三個團隊在逐一完成每一個end-to-end story的過程中慢慢長出來。

學員A：依我們的情況，可能有技術上的困難。而且我們會擔心三個團隊做出重複的後台功能。

***

看到這裡，鄉民們覺得學員A的公司在開發後台系統的時候採用component team的做法是否合適呢？Teddy在〈Scrum框架下的跨界開發(4):分組方式〉介紹過7種不同的分組方式，Teddy認為學員A的公司將後台開發獨立成一個component team也並無不妥，只要他們有辦法妥善解決前端團隊與後端團隊的分工與溝通問題，將後台開發工作集中處理的確可以省去很多問題。但如果前台與後台溝通的問題大於後台集中開發所帶來的利益時，這時候也許可以考慮將後台團隊打散到三個前台團隊之中。

***

工程就是一種取捨的決定，有時候很難斷言A方案就一定比B方法要來的好。身為一位工程師，至少要負責將各種方案的利弊得失想清楚，以便確定自己是在「有意識」的情況下做出決定，而不是因為「別人說好」你也跟著說好。

***

友藏內心獨白：對得起良心就好。