文章目錄
- 什麼是Feature:
- 特徵驅動開發定義：
- FDD過程：
- FDD中的角色
- FDD相關的度量
- FDD的最佳實務
- 觀點彙集：
- Ozzzzzz：
- colorUML其實可以用一句話來表達。
- 開發一個全面模型
- Ozzzzzz：
什麼是Feature: The unit of development and thus an increment in an FDD project - a feature - is tiny; … Features (tiny, granular pieces of client-valued function) are being completed every week in an FDD project。特性Feature作為一個開發單位，也是FDD項目中的一個增量，是指“使用者眼中最小的有用的功能”， 可以在1周內實現。 特徵驅動開發定義： 特徵驅動開發（FDD-Feature Driven Development）方法是敏捷式軟體開發 (Agile Software Development)過程中的一種，是由Jeff de Luca 、Eric Lefebvre、Peter Coad共同開發的。它強調特性驅動，快速迭代，即能保證快速開發，又能保證適當文檔和品質，非常適合中小型團隊開發管理。它提出的每個功能開發時間不超過兩周，為每個用例user case限定了粒度，具有良好可執行性，也可以對項目的開發進程進行精確及時地監控。它抓住了軟體開發的核心問題領域，即正確和及時地構造軟體。FDD還打破了傳統的將領域和業務專家/分析師與設計者和實現者隔離開來的壁壘。分析師被從抽象的工作中解脫出來，直接參与到開發人員和使用者所從事的系統構造工作中。 FDD過程： FDD是一個模型驅動( model-driven)、短期迭代(short-iteration)的過程。 注意，FDD是一個開發過程，過程總是有起點和終點，FDD的起點是起源於建立一個全域的模型輪廓（不要求很精確，大概模樣就可以），然後是周期低於兩周的一系列的"design by feature, build by feature"的迭代，逐漸豐富模型功能內容。一個FDD開發過程如附件1圖所示。 其由5個活動組成： 1. 開發一個全域的模型 （Develop an Overall Model） 四色原型（http://www.jdon.com/mda/archetypes.html） 領域驅動設計 2. 建立特徵列表（Build Feature List） 在此採用下述格式進行描述： - 針對功能： <action>the<result><by | for | of | to>a(n)<object> - 針對功能集：<action><-ing>a(n)<object> - 針對主功能集：<object>management 3. 依據特徵規劃(Plan by Feature) 4. 依據特徵設計(Design By Feature) 5. 依據特徵構建(Build By Feature) FDD中的角色 1. Domain expert(s) ：領域專家 2. Chief Architect(s) ：首席架構師 3. Chief Programmer(s) ：主程式員 Feature Team一般由Domain expert ，Chief Programmers，Class Owners組成，一個Chief Programmers可以帶領多個Class Owners。 FDD相關的度量 採用FDD方式進行開發時，各階段成本的分配大致如下所示： 1. 開發一個全域的模型 （Develop an Overall Model）10% Initial, 4% on-going 2. 建立特徵列表（Build Feature List） 4% initial, 1% on-going 3. 依據特徵規劃(Plan by Feature) 2% initial, 2% on-going 4. 依據特徵設計和依據特徵構建 77%（2周迭代一次） FDD的最佳實務 • 持續整合Continuous Integration. • 對領域（業務）對象建模Domain Object Modeling. • 按特性開發Developing By Feature. • 類的所有者Individual Class ownership. • 按特性組織團隊Feature Teams. • 原始碼控制Source Control. • 彙報/結果可見度Reporting/Visibility of results 觀點彙集：1. 在FDD中，它認為：
只有良好定義的並且簡單的過程才能被很好地執行。2. 不過FDD由於必須有2個關鍵的人物——首席構架師和首席程式員，因此門檻並不低。同時由於FDD的客戶參與度可以做的很高，那麼團隊的文化很容易受到其客戶的文牘主義的影響。並且由於FDD的前期工作可能會很長，因此也很容易被人們搞成一場打著敏捷旗幟的重型方法會展。不過好在如果你提前意識到這三個方面的問題，它們就可以預防。 Ozzzzzz：首先FDD沒有強求你使用color UML，但是我實在找不出比這個方法更加簡單明了的領域建模的方法了。問題領域內被認為存在四種類的模版，粉紅的Moment/Interval,黃色的Role，綠色的PPT（Party,Place,Thing），藍色的Description。而Domain Neutral Component是一種在業務系統中反覆出現的模式，用我的話來說就是什麼人在一個什麼時間以一種什麼身份做什麼樣的事情。我相信有的人可能不知道什麼是名詞，但是他也能把一件事情按照上面的格式來表達。當初我曾經交給我的客戶使用CRC卡片建模，他們並沒有覺得有什麼複雜。而當我給他們color UML的時候，客戶覺得比CRC還簡單明了，並且感覺自己也可以做一個程式員。 而Feature——<action><resule><object>，也非常簡單明了。不過很多人會誤解Feature是一種表達需求的手段，就如同Use Case和Usestoris一樣，其實他們都是對於需要的分析手段。只不過Feature更加靠近程式，而Use Case更加靠近業務，Usestory則可以被使用在這兩種風格——但是一個Usestory只有一個風格。也就是說一個Use Case或者Usestory可以用幾個Feature來進行構造。更加奇妙的是使用Feature可以很量化的表示你的開發進度，領域走查1%，設計40%，設計審查3%，編碼45%，代碼審查10%，提交構造1%。當然你可以根據你組織的具體情況來調整這個資料，不過只要你不是太頻繁的調整，那麼任何人都能夠即時的知道你究竟過的好不好。使用Feature你會發現客戶可以直接理解你程式的結構和進度，而不僅僅是通過你提交的文檔的估計。當然這個能力對於很多習慣作假的人是深惡痛絕的。 同時我們會發現如果長期使用FDD在一個領域或者幾個相關領域進行程式開發，那麼領域模型會愈來愈固定，而以此為基礎的人員會愈來愈成為某個方面的專家。同時更多類似的Feature，會頻繁的出現。以至於當你僅僅使用以前的Feature就可以分析出現在的客戶業務存在的問題。也就是說使用color UML和Feature不僅僅可以對需求進行整理，還可以對業務進行整理。 而且如果你夠敏感，你會發現FDD被稱為Processes。確實FDD第一次的使用就是在一個大型的項目，並且最後結果很成功。並且就如同Lean一樣，FDD這裡大型項目的例子非常多——無論是從代碼的數量，需求的複雜，參與的人員數量，進行的時間，這些方面來說大型項目並不是FDD所欠缺的。而在小型和中型項目上，FDD由於可以很好的記錄經驗，也可以取得很好的效果。同時由於FDD的過程太少了（才10頁A4），因此很少有人有對他做裁剪的慾望。同時這個方法使用的技術也夠簡單明了，也很少能夠被人所非議是不是不容易學習掌握。不過確實FDD的內容沒有包括SCM和coding方面的內容，但是你可以結合XP的持續整合，TDD，重構來完善他。而且由於Feature的結構統一，以其為基礎構造Test Case是更有指引性。況且由於FDD使用溫和的代碼責任，你也不會產生過分重構的問題。而由於Feature的粒度統一，對於控制check in和check out也方便，因此至少做到每日構建是容易做到的。 colorUML其實可以用一句話來表達。任何的需求（其實任何的事情）都可以表現為: 什麼人（或者事物）在一個什麼時間（或者什麼時間段）以一種什麼方式做了一種什麼樣的行為。當然你還可以使用不同的時態來構造這個表達。其實這是我們語言上陳述句子的基本形式，當然你可以使用oo的方式來構造。不過我覺得fp的基本要素也孕育在其中了。也就是說這個基本的模式，其實oop和fp都是這個基本現實形態的一個投影。 開發一個全面模型Jeff De Luca認為，與其它敏捷方法相比，FDD在初始階段（開發一個全面模型）允許項目團隊掌握整個項目，以便回答諸如“項目還剩多少沒完成”之類的問題：如果我們完全是純粹的增量反覆式開發法——即僅限於迭代內的需求與分析——那麼，我們當然很難回答“整個項目我們進行了多少”，以及“項目還有多少沒完成”。因為我們還沒有瀏覽過剩下的需求呢。所以一開始一定要做一些資訊收集或分析活動，以便我們瞭解並設定可以跟蹤和反饋的基準，這樣我們就可以回答上面的問題了。FDD是唯一一個能夠正確做到這一點的敏捷方法。 在這一階段的這個問題上可以看作是大量預先設計（Big Design Up-Front，BDUF）：並不是做BDUP那種被人鄙視的“全面預先設計”，而是做“恰好夠用的設計”。同時還應注意，在FDD中的這個第一項活動不但包括高層次的設計，也包括需求及需求分析。 Ozzzzzz：1.FDD是反覆式開發法，這一點必須加以強調。 2.整體模型更大程度上是分析模型，而不是需求模型。更多的涉及的是會出現什麼東西，而不是會實現什麼能力。這個模型是更多的是從業務分析角度出發，而不是從軟體系統實現角度出發。這個整體模型不是構架，而只是部門內容是構架的一個部分。這一點非常重要，基本上FDD處理複雜問題的強大，就是從這裡開始的。 3.按照《action》《result》《object》建立特徵列表。習慣上我們將feature翻譯為特徵，這裡更加體現了這個feature是《object》的一些能力，而不是軟體的一些功能。軟體的功能往往需要一些特徵集體發生作用。實際上在操作的時候，如果整體模型按照正確的原則進行了構造，那麼出現一個肥胖的feature的機會是很少的。基本上每一個feature的完成都會在2-3天以下，有很多可能就是幾個小時，更少的只有幾分鐘。 4.主程式員所負責的往往是自己熟悉的和有興趣的分析類，專案經理沒有權利去去給他們分配工作，而不能去指定他們去負責什麼類。實際上FDD存在3個主要的關鍵的管理方面的角色，專案經理、主設計師、開發經理。這3個角色可以由3個人負責，也可以由2個人負責，當然也可以由一個人負責。但是不管如何，這3個角色的任務和工作都是不同的，必須加以注意。而feature必須有具體的人負責，但是注意這必須是在類都有了主人的情況下。 5.上一條我已經表明類的所有者的來曆，關鍵是大家必須理解，任何的agile都不會存在什麼詳細設計。其實這個階段的所謂設計，更多的是要找出一個feature是會涉及到什麼類，而各個的類主人會按照什麼協議參加到這個feature的建造中來，什麼時間這些人可以參加到這個feature中來，以及他們之間的協議如何可以得到檢查實施。 6.這個階段相對任務比較明確，但是切記不要把所謂的傳統軟體工程的方法影響到其中，所謂的複審和評審都是不應該進行的，而是應該使用tdd和pp這樣更加有效率的做法。特別是由於存在主程式員，pp完全可以在上一個階段的頭腦風暴中進行。可以說設計和構造階段其實更多的時候不是沒有明確的區分界限的，或者說設計階段更多的時候是沒有一個明確的階段的。這其實體現了agiler一般喜歡的持續設計風格。 至於作者最後問的問題，根本就不是問題，是他對於FDD的角色和迭代不理解造成的誤解。至於裡程碑，在FDD中是很容易確定的，每一次迭代都應該是一個裡程碑，而每一次提交給客戶更加應該是一個大的裡程碑。所謂的計劃，其實就是確定feature優先實現層級，而這個優先實現層級其實就是來著客戶的功能優先列表。這裡的兩個列表都是動態，是會經常性的做出調整的，並且很多複雜情況下分析模型也是會有調整的，可能會出現更多的分析類，也就是說主程式員的負責的類會根據情況進行調整。 FDD其實是一個比較複雜的體系，至少我認為比RUP並不簡單。FDD中有許多策略和技術方面的問題，不是那麼容易理解。可以說FDD是為職業程式員預備的專業開發方法。其實任何一直agile都是職業程式員的開發方法，一般情況下應該存在一個教練的角色，主設計師往往就是承擔這個角色。 我強調整體模型不是需求模型，是基於幾點考慮。1、一個項目是否允許你在開始的時候能從容的建立一個整體的模型？至少從我面前對於國內的軟體開發行業的客戶來看，他們是不會給你這個機會的。因此絕大多數情況下，是在你開始進行這個項目前，這個模型就應該已經存在了。那麼這個模型顯然不是來自於具體化了的“需求”，而是來自更加寬泛化的“領域”。實際上我更加願意稱他為領域模型或者領域分析模型。 2、由於1的觀點，同時再考慮到大多數的開發團體，都是在一個比較固定的領域範圍內部進行工作。他們的工作應該能，也應該進行一定程度的積累。而這個領域分析模型，就是一個很好的介質。 3、由於領域分析模型非常強調於領域中出現的概念，因此以此為基礎可以更加好的而簡單的建立其對於領域的認識。而如果過多的從更加關注流程的需求入手，則複雜性和可認識性會大幅度降低。同時也應該明白，由於領域分析模型是FDD團隊組織圖的基礎性依賴，保持一個相對穩定的模型是非常必要的。 而這裡一個關鍵的容易產生錯誤認識的點就在於，將這領域模型系統化到具體的軟體結構系統中去，也就是你說的所謂“系統模型圖”。 而在我們具體的實踐中，往往Team Dev的所使用的系統構架architecture是另外一個相對穩定的體系，並且這個體系也如同那個領域分析模型一樣有很多類似的特點。因此完全可以在他們兩個的基礎上進行總計和提煉，建立一個更加針對化的快速開發架構。而一旦將兩種結構混淆，那麼本已經複雜的業務和系統結構，將會變得更加複雜和難於認識。同時也應該明確，如果業務同具體的技術實現過於緊密的耦合在一起，將會在今後的開發過程中造成業務的改變必須調整技術結構的後果。 而如你看我上面關於FDD的闡述，你會發現FDD在實現和實施層面有大量的陷阱和必須使用的技巧。這些方式和方法，是僅僅憑看書和思維不能體會到的。而即使有這個方面的培訓，如果沒有真正熟悉這個方法操作的人做現場過程的指導，也是很難一下子體會到其中的奧妙的。 同時我們也應該明白，agile的方法體系，很多說法所代表的內容和傳統的觀念還是有些區別。特別是FDD，方法的精緻和結構的規整，很容易讓使用者在本身固有的重型思維方式的引導下，走入於agile背道而馳的泥坑。這本身也是其複雜性的一個表現。
