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

 

螢幕快照 2015-05-18 下午11.28.24  

 

傳統 component team, 每個 component 是由團隊負責設計和維護. 在 feature team 時, 這樣的事情有些轉變, 因為 feature team 讓 component 的程式碼是大家共有的.

 

可是很多人, 包括我自己, 會認為這樣做會造成大災難, 因為誰也不知道別人改了甚麼, 是否能和自己的部分相配合. 因此 feature team 對 component 的作法需要加以改變, 以下是作者的作法:

 

1. Continuous Integation (CI)
當程式碼一有修改, 便立即執行測試來確認系統是否整合正確. 讓系統可以由小到大, 由簡單到複雜, 逐漸演進. 此外它還可以輔助其他practices:
(1) evolutionary design culture: 養成設計並不是只是 one time effort, 而是件持續的事情.
(2) test-driven development: 藉由測試來逐漸增加功能
(3) refactoring: 持續改進 code/desing 的品質(移除 duplication, 增加封裝性)
這些都可以讓 feature team 可以持續改進 component 的設計和品質, 又不會擔心原先的部分有被破壞

 

2. 元件監護人 (component guardians)
如果它是容易有問題的 component, 它會有一個元件監護人. 當你要修改這個 component, 他會負責跟你講要注意的事情, 避免妳改錯方向. 他並不是負責修改的, 修改的是 feature team 的成員. 他會在 design workshop 中給你建議, 或是在 pair programming 給你幫助. 類似 open source development 中 committer 的角色.

 

3. 架構設計監督者 (architecture code police)
他會持續檢查程式碼(不是文件), 看看是否有有問題的地方, 有需要時也會指導開發人員. 他算是元件監護人的一種變形, 負責整體程式的品質, 但是並不是只負責某個 component 而已.

 

4. 設計研討會 (design workshop)
在每次 iteration 中, 針對一些共用的 component 或是基礎建設, feature team 會指派人參加, 花兩個小時或是兩天, 進行 agile modeling, 在白板上進行設計的討論. 然後他再回 feature team, 在 local design workshop 或 pair programming, 把想法分享給 team members

 

    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()