實例化需求—概念

    最近一段時間在關注一種新的敏捷模式，當然這裏說新，是由於目前很少看到有項目在應用，其實這種模式很早就已經誕生了。一個偶爾的機會，在苦尋敏捷測試的過程中，無意中看一本書，關於如何提高敏捷過程中需求、開發和驗收的測試效率，讓我很是感興趣，這本書名《實例化需求：團隊如何交付正確的軟件》。可能是由於翻譯的原因，讀起來給我的幫助並不是那麼大，但至少先讓初步瞭解他的思想，我想這就是最大的幫助了，因爲我確實接受了他。

　　關於如何處理需求說明與測試，不同的組織使用不同的名稱，或者說是不同的定義，但他們都有一套共同的核心原則與思想，而且當你接受他了之後，我們便可以認爲他們本質上是一致的。通常有如下定義：

• 敏捷驗收測試
• 驗收測試驅動開發
• 實例驅動開發
• User Story測試
• BDD行爲驅動開發
• 實例化需求說明（Specification by Example）

　　對於以上的概念，我想大家都不陌生，但可能都是一個概念，因爲沒有實踐。當具體去實踐，其實就發現跟我們平時的流程相對也很容易理解，只是方式不一樣，或者執行流程不一樣，當然這裏要說的就是不同，那就是方法。方法都是總結出來，多實踐之後，提煉出來的就是適合我們的方法。就如同我們在實施了一段時間之後，突然有一天有人問我什麼是BDD（行爲驅動開發），我發現我很疑惑，我不理解。但細想，我現在做的流程不就是BDD嗎，而我現在做的流程準確來說被定義爲實例化需求，但這個概念似乎不能把開發和測試給拉進來，而用BDD來定義，似乎就一瞬間把需求、設計、開發和測試拉綁定在了一起。

　　何爲BDD？其實就是通過真實用戶的行爲來定義我們需要開發出什麼樣的產品來，個人理解。但再結合實例化需求，就會發現，我們就是把用戶的行爲通過一個實例化的過程描述出來，然後整理成設計、開發和測試都能看懂的，當然最重要的是用戶也能看懂，而且用戶看完之後就認可，這就是我想要的，這就是BDD，也就是實例化需求過程。

　　它既不是傳統的需求文檔，也不是設計文檔，更不是測試用例文檔，但適用於從需求、設計、開發和測試的每一個階段，而且都是從用戶的角度爲出發點的。那我就認爲那就是我們想要的過程模式。