最近一段時間在關注一種新的敏捷模式，當然這里說新，是由于目前很少看到有項目在應用，其實這種模式很早就已經誕生了。一個偶爾的機會，在苦尋敏捷測試的 過程中，無意中看一本書，關于如何提高敏捷過程中需求、開發和驗收的測試效率，讓我很是感興趣，這本書名《實例化需求：團隊如何交付正確的軟件》。可能是 由于翻譯的原因，讀起來給我的幫助并不是那么大，但至少先讓初步了解他的思想，我想這就是最大的幫助了，因為我確實接受了他。
關于如何處理需求說明與測試，不同的組織使用不同的名稱，或者說是不同的定義，但他們都有一套共同的核心原則與思想，而且當你接受他了之后，我們便可以認為他們本質上是一致的。通常有如下定義：
● 敏捷驗收測試
● 驗收測試驅動開發
● 實例驅動開發
● User Story測試
● BDD行為驅動開發
● 實例化需求說明（Specification by Example）
對于以上的概念，我想大家都不陌生，但可能都是一個概念，因為沒有實踐。當具體去實踐，其實就發現跟我們平時的流程相對也很容易理解，只是方式不一樣， 或者執行流程不一樣，當然這里要說的就是不同，那就是方法。方法都是總結出來，多實踐之后，提煉出來的就是適合我們的方法。就如同我們在實施了一段時間之 后，突然有一天有人問我什么是BDD（行為驅動開發），我發現我很疑惑，我不理解。但細想，我現在做的流程不就是BDD嗎，而我現在做的流程準確來說被定 義為實例化需求，但這個概念似乎不能把開發和測試給拉進來，而用BDD來定義，似乎就一瞬間把需求、設計、開發和測試拉綁定在了一起。
何為BDD？其實就是通過真實用戶的行為來定義我們需要開發出什么樣的產品來，個人理解。但再結合實例化需求，就會發現，我們就是把用戶的行為通過一個實 例化的過程描述出來，然后整理成設計、開發和測試都能看懂的，當然最重要的是用戶也能看懂，而且用戶看完之后就認可，這就是我想要的，這就是BDD，也就 是實例化需求過程。
它既不是傳統的需求文檔，也不是設計文檔，更不是測試用例文檔，但適用于從需求、設計、開發和測試的每一個階段，而且都是從用戶的角度為出發點的。那我就認為那就是我們想要的過程模式。
以下為實例化需求說明的主要過程模式：
當我們獲取一個業務目標時，將按照上述流程圖來生產實例化需求過程
● 從目標中獲取范圍
通過用戶提供的需求描述，我們將這些描述轉變成另一種用戶能夠理解且真實用戶實際地行為方式，這里就要引入User Story用戶故事的概念。然后以客戶的業務目標為起始，然后通過協作界定可以實現目標的范圍。這里最關鍵的就是與用戶更密切地溝通，通過不斷細化，確認 這才是用戶想要的功能。
● 從協作中制定需求說明
之所以要提出協作制定需求說明，目的是讓需求、設計、開發以及測試都參與進來，發揮整個Team的知識和經驗，力求讓項目的干系人都更多的參與到交付過程中。
● 舉例說明
舉例說明其實是項目需求交流過程中不可或缺的，團隊中不同職能人都有，而且每個人的業務背景不同，通過舉例說明的方式可以讓目標更一致。
● 提煉需求說明
協作過程中的開發討論可以建立大家對相關領域的共識，但最終得到的實例往往包含很多不必要的細節。而關鍵實例必須是精簡的。提煉需求說明的過程，其實就伴隨著實例化需求的產生，且這些提煉好的實例就可以當作交付的驗收條件。
● 頻繁驗證
頻繁驗證的依據就是提煉需求產生的實例化需求，它是所有過程實施中都必須要反復進行的工作。需求通過頻繁驗證與用戶進行頻繁確認；設計通過實例 化需求來頻繁驗證設計是否滿足用戶的需求；開發通過實例化需求頻繁驗證代碼中業務邏輯；測試通過實例化需求來頻繁驗證交付的功能，并作為最后驗收測試的依 據。
● 演化出一個文檔系統
通過以上的這些流程，最后演化出一個文檔系統。之所以稱為文檔系統，主要是體現它的可靠性、權威性。所有設計、開發、變更以及測試過程都以此為出發點來考慮，并及時更新，長久維護。
實例化需求過程的核心就是與用戶站在一起，從溝通開始，不斷舉例、細化、精簡到統一確認。