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, 然後就開工了
可是在agile的開發環境時, 在每個iteration, 我們所面對的是要deliver feature或是user story. 就大家所知道的, 每個feature可能需要多個component 才能完成他所想要的功能. 因此這樣的拆解, 會影響組織的運作.
怎麼說呢?
首先, 要有人來負責分析這個功能吧? 這時候你可能會找分析師來處理. 確認需要是否很清楚, 範圍到底是在哪裡.
接著, 你會想說要做點架構設計吧? 然後你會請architect或是RD lead來設計. 確認每個component需要負責的功能是甚麼, 要提供那些API, 彼此之間要如何互動, interface為何等等. 這時候各個component team就可以開工.
然後, 若是要驗證feature是否做完, 像是acceptance testing, system performance testing等等, 需要等所有component 完成, 整合在一起才能進行.
所以這代表甚麼呢? Waterfall!!. 所有的動作都要依序進行, 都需要交棒的動作. 因此心態上, 容易有前面沒有做完, 後面就無法開工. 前面話太多時間, 後面的人就會被犧牲.
就算你採用scrum, 就算你是iteration, 這樣的組織還是讓你回到waterfall.
我們需要真正的concurrent engineering, 需要打破一棒交接一棒的狀況.
而component team的組織通常會和循序式的waterfall開發流程連結在一起, 讓你無法是真的在做agile
留言列表
