Specialization and Generalization in Teams
http://www.scrumalliance.org/articles/324-specialization-and-generalization-in-teams
Specialization and Generalization in Teams
http://www.scrumalliance.org/articles/324-specialization-and-generalization-in-teams
在一個專案中, 你可能分成很多小組去做開發. 多個小組會需要把他們寫完的程式放進 soruce control system, 或是從 soruce control system 把程式整合到他們手頭上的程式裡.
這時候你會遇到的問題是, 太多人 check-in 程式碼, 導致系統的穩定度變得很差, 甚至沒有任何build是可以運作的.
Scaling Lean & Agile Development, Craig Larman and Bas Vodde, Chapter 7 Feature Teams
http://www.infoq.com/resource/articles/scaling-lean-agile-feature-teams/en/resources/feature%20teams_%20infoq_%20final.pdf
Feature Crews: kanban systems for software engineering in the large
http://leansoftwareengineering.com/2009/04/07/feature-crews/
在 Feature crew中, 有一個難題是程式碼共享的問題. 當很多feature crew要同時修改同一份程式碼時, 要如何維持其正確性, 並且也要兼顧效率. Corey Ladas在他的文章中分享他們如何處理這樣的事情.
在feature team中如何處理同時存取程式碼的問題
Scaling Lean & Agile Development, Craig Laman and BasVodde, Chapter 7 Feature teams
http://www.infoq.com/resource/articles/scaling-lean-agile-feature-teams/en/resources/feature%20teams_%20infoq_%20final.pdf
和component team比較起來, feature team有個重要不一樣的地方, 就是feature team可能會同時存取不同component的程式碼, 並且可能會有多個feature team會存取相同component的程式碼.
在1980年代, 版本控制的工具工具比較陽春, 大部分採取的是Pessimistic Locking or strict locking. 因此對於要同時存取程式把時, 效率會非常差. 因為當一個人lock後去修改, 另一個人是沒有機會再check-out去修改.
這樣會帶來一些壞處. 例如造成大家在分工時, 盡量都是一段程式碼只有一個人負責, 不要讓多個人同時去存取. 或者整合的時間點, 往往托的很久, 因為要等別人改好, unlock版本控制. 這些都是會造成等待, 時間的浪費, 以及每個component只有一個人負責的狀況.
Scaling Lean & Agile Development, Craig Laman and BasVodde, Chapter 7 Feature teams
http://www.infoq.com/resource/articles/scaling-lean-agile-feature-teams/en/resources/feature%20teams_%20infoq_%20final.pdf
通常在開發的時候, 一般的做法是將系統拆解成幾個component, 然後assign每個component的owner, 然後就開工了
Feature team的好處
Scaling Lean & Agile Development, Craig Laman and BasVodde, Chapter 7 Feature teams
http://www.infoq.com/resource/articles/scaling-lean-agile-feature-teams/en/resources/feature%20teams_%20infoq_%20final.pdf
雖然作者列出了不少好處(如下面所列), 但是我總結是因為feature team和其他團隊互動少, 所以沒有太多comminucation effort, 比較容易可以自行調整, 並且專注在自己所負責的feature上面
1. 增加有價值的產出
- 專心於交付對客戶或是市場最有價值的部分
Scaling Lean & Agile Development, Craig Laman and BasVodde, Chapter 7 Feature teams
Feature team 是 agile 一個很重要的做法, 藉由這樣的做法才能達到 scalable. 因此有需要對 feature team 加以研究一下.
Agile At Microsoft
摘錄至 How We Test Software At Microsoft
大部分的Agile專家建議, 一個agile團隊的大小最多不要超過10人. 因此在一個大公司中, 如何大的團隊做切割是一個很大的挑戰.
在微軟公司, 對於這件事情的解法是Feature Crew. 它們在一個product或是project中有很多feature crew.
- 組成
(1) 它由各個不同角色所組成: 經理(PM), 開發人員(Dev), 測試人員(Tes)