Feature Driven Development (FDD) 也是一種敏捷開發方法, 它最先出現於 Java Modeling in Color with UML這本書中.  但是聽過的人比較少, 讓我們來簡單的介紹一下.

FDD 是一個 model driven, short iteration 的流程. 一開始要建立一個整體的 model, 然後再利用一連串兩周的 "design by feature, build by feature” 的 iteration, 來建立出整個系統.

 

FDD-processes-02  

FDD 的開發流程:
1: Develop an Overall Model
在架構師或是領域專家的指導下, 由領與需求人員, 和開發人員一起合作, 產生出一個可以涵蓋整個系統和應用 scenario 的 domain model (要處理的問題領域) 和 state chart (描述 UI). 這個產生是為了方便大家溝通使用, 而非要產生一個完整精細的東西.

關於建立Domain Model, 可以看Matin Fowler的"Analysis Pattern”, 或者Peter Coad的"Java Modeling With Color In UML"

2: Build a Features List
接著由 RD lead 或是專案經理, 產生出 model 的 feature set. 這些 feature set 是要對使用者有意義的, 並且可以被專案經理用來追蹤進度的. 通常這些 feature 是要可以在兩周內完成的.

3: Plan By Feature
將 feature 的優先順序排好, 並且計劃好哪些功能可以在那些 iteration 內完成. 這個 planning team 會是由專案經理和 RD lead 所處理的. 並且這裡要得到的計劃, 也不是要一個很清楚, 很詳盡的計劃, 而是要一個可以夠可以開始的計劃. 將來這個計劃的內容, 是會逐步在演進的.

4: Design By Feature
RD lead 針對某個 feature, 建立起 feature team. 然後會進行細部設計, 像是 class diagram, sequence diagram. 當然也可以回頭修正前面的 model. 但是修正後, 應該是會影響之前的估算.

5: Build By Feature
工程師在這個階段會開始實作系統, 進行單元測試. 然後 RD lead 會幫忙進行 code review 的活動. 

它跟 Scrum 和 XP 最大差別的地方, 就是 FDD 會先對要做的系統, 先分析出一個 model, 你可以稱這是 high level design,  也就是 Scrum 和 XP 中常提到的 iteration 0 要做的事情(也就是步驟 1-3 做的事情). 但是在 FDD 他是很正式有一套做法來處理 iteration 0 的事情.

所以對於傳統 waterfall 做法的團隊, 這方法的誘因很大, 因為有一部分傳統很像, 並且因為有做 high level design, 大家可能用起來會比較安心.

但是和傳統不一樣的地方, 開始討論時, 是會邀請開發人員, 分析師, 領域專家, 一起來討論. 是一個互動性高, 互相合作的過程. 然後建立出一個剛好夠用的 model. 至於細節, 就是在之後 iteration 逐漸演儘和細緻化. 所以這個 modle 的重點, 是在澄清需求, 讓大家對一些東西有共同的語言.

我想對於 waterall 世界的人, 或許這個方法對他們來說, 是比較安全, 或者是說是比較可以想像, 比較可以控制的做法. 不過似乎參考資料不是很多, 我只念過兩本書 …..

arrow
arrow
    全站熱搜

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