在 LeSS 中的 Scrum 團隊, 嚴格來說就是一個 feature team. 這個團隊中會包含完成事情所需的人. 這些成員被稱之為團隊成員, 不會特別去說你是開發人員或是你是測試人員. Feature team 會鼓勵你學習多點技能, 不限制於你原先擅長的部分. 讓大家有機會在非專長的地方, 也可以幫助別人完成工作.

和 Feature Team 相反的, 就是 Component Team. 這是傳統組織的組成單元, 這個團隊的組成, 是為了要處理產品或是系統某個元件. 在以前的想法, 認為這樣算是專業分工, 專職處理會比較有效率.

由下圖可知. Feature Team 的成員可以處理大多的 component, 所以當他們接到一個 Product Backlog Item 要做時, 他們會自己去處理後面相關用到的 component. 而 Component Team 則不一樣, 當某個 Product Backlog Item 要被處理了, 如果這個 Product Backlog Item會用到 3 個 component, 這 3 個 component 對應的 component team 就要聚在一起合作, 來討論如何完成這個 Product Backlog Item.

圖片來源: https://less.works/less/structure/feature-teams

在 LeSS 中所以建議的 Scrum 團隊, 是 Feature Team 形式, 而非 Component Team. 這是為什麼呢? 主要是認為 Component Team 會有以下問題. 後面我們將會逐一加以說明.

• 導致循序開發的模式與心態
• 限制學習
• 可以做事情先做, 不是有價值的先做
• 導致有”假造的工作”
• 一直在成長的開發人員數目
• 讓規劃和同步變得複雜
• 導致較差的程式碼和不良的設計
• 延遲功能的交付

(1) 導致循序開發的模式與心態

當團隊是 Component Team 形式, 代表這些團隊只懂某個或是某些 component. 為了要能讓這些 Component Team 能夠做事, 我們需要先將需求分析和設計過, 知道哪些部分要給哪些 Component Team 做, 這樣我們才能通知他們來做事.

這樣就代表你的開發流程是有順序性的, 需要有人幫忙先做需求的分析設計, 否則 Component Team 是無法開工的. 並且 Component Team 各自做完後, 還需要整合測試, 以確保做出來東西合起來是滿足需求的, 否則也無法就直接上 production. 這樣的開發是快不起來的.

(2) 限制學習

因為 Component Team 專門負責某些 Component 的開發與維護, 所以他們擅長的部分就是那些 Component. 因此對於別的團隊的 Component 就不熟悉. 如果臨時有 case 進來, 但是不是自己負責的 Component, 他們就不懂無法幫忙. 另外, 如果要做系統效能優化, 或是找出系統某部分的瓶頸, 也因只懂局部, 而無法參與討論, 更不用說給出什麼好的建言.

(3) 可以做的事情先做, 不是有價值的先做

在 Product Backlog 種中的每個 Item, 會用到的 component 都不同, 有可能高價值的 Product Backlog Item 沒用到某些 component, 但是在中間或是低價值的 Product Backlog Item 才有用到某個 component, 例如下圖中的 component C. 這時候 Component Team C 他們在做的事情, 只跟功能 8 有關. 但是功能 8 是目前最有價值的是嗎? 從圖中看起來不是, 因此 Component Team C 只是在做他能先做的事, 而非最有價值的事.

(4) 導致有”假造的工作”

當這個迭代在進行時, 因為剛好要開發的需求, 都用不到那個 Component, 那個 Component Team 便沒工作做.

這時候會怎樣呢? 有些團隊會去做 refactoring, 把之前的技術債給還了, 這還算不錯. 有些團隊可能會重寫某部分, 或者是找找別的事情做. 總之, 就不能讓團隊閒著, 避免讓老闆覺得你們團隊沒有用. 反正就是裝忙.

但是, 不管你是在忙什麼, 只要這些東西無法給客戶帶來價值, 這些事情再有意義, 大多都是種浪費. 或許當下你不承認, 或者是不認為, 但是長久後回來看沒價值居多.

(5) 一直在成長的開發人員數目

在每次版本時, 所要用到的 component 不同, 傳統組織遇到這間事情, 通常就是看哪個 component 用得多, 就把人力投入到那個 Component Team 中.

如下圖所示, 在 Release 1 中, 因為用到 component A 比較多, 所以就給團隊 A 較多的人力. 可是等到 Release 2 時, 這時候用到 component B 比較多, 所以要給團隊 B 較多的人力. 通常我們並不是從其他團隊中調度人力, 而是給團隊 B 更多 headcount, 因為其他團隊的老闆不願意放人, 或者是其他團隊的人員沒有相關能力, 或是不願意學習.

可是, 這樣循環下去, 你就會發現公司的人數越來越多, 可是公司的產能並沒有太大改變.

(6) 讓規劃和同步變得複雜

正如 (1) 所說, 需要先規劃好每個 Component Team要做什麼, 這樣 Component Team 才知道要做什麼. 然後 Component Team 做完後, 要一起整合起來已確認是否真的可動. 因此, 這些都需要有人去協調. Component Team越多, 或者是要處理的需求越多, 導致你整個開發過程變得很複雜.

(7) 導致較差的程式碼和不良的設計

讓我們來看看下面這張圖, 這是從Craig Larman 和 Bas Vodde 的 Feature Teams 一文中提到. 當 Component Team 越多後, 會越不容易在一起交流, 導致你不知道對方在做什麼. 當你不知道對方在做什麼, 自然就可能重複製造類似的功能代碼. 當功能相同, 但程式碼不盡相同越多, 導致你需要越多人維護. 所以這樣的循環不斷發生和加強後, 程式碼越來越大, 越來越不容易維護, 寫出爛 code 的機會就越多.

https://www.craiglarman.com/content/feature-teams/feature-teams.htm

(8) 延遲功能的交付

如下表所示, 迭代 1 你在開發需求 1 和需求 2, 需求 1 會用到 Component A 和 Component B, 需求 2 會用到 Component A 和 Component C. 這代表 團隊 A 會同時間要處理需求 1 和 需求 2. 當時間有限的狀況下, 團隊 A 往往只能救一個, 優先極高的先救, 所以在迭代 1 時, 只能完成 需求 1, 而需求 2 需要被延遲到迭代 2 中才能完成.

由上述這些原因看來, 不難想像 LeSS 為什麼偏好 Scrum 團隊需要是 Feature Team, 這樣才能避免上述狀況, 加速需求的開發, 以及增加產品整體品質.