最近一段時間在關注一種新的敏捷模式，當然這裡說新，是由於目前很少看到有專案在應用，其實這種模式很早就已經誕生了。乙個偶爾的機會，在苦尋敏捷測試的過程中，無意中看一本書，關於如何提高敏捷過程中需求、開發和驗收的測試效率，讓我很是感興趣，這本書名《例項化需求：團隊如何交付正確的軟體》。可能是由於翻譯的原因，讀起來給我的幫助並不是那麼大，但至少先讓初步了解他的思想，我想這就是最大的幫助了，因為我確實接受了他。
關於如何處理需求說明與測試，不同的組織使用不同的名稱，或者說是不同的定義，但他們都有一套共同的核心原則與思想，而且當你接受他了之後，我們便可以認為他們本質上是一致的。通常有如下定義：
對於以上的概念，我想大家都不陌生，但可能都是乙個概念，因為沒有實踐。當具體去實踐，其實就發現跟我們平時的流程相對也很容易理解，只是方式不一樣，或者執行流程不一樣，當然這裡要說的就是不同，那就是方法。方法都是總結出來，多實踐之後，提煉出來的就是適合我們的方法。就如同我們在實施了一段時間之後，突然有一天有人問我什麼是bdd（行為驅動開發），我發現我很疑惑，我不理解。但細想，我現在做的流程不就是bdd嗎，而我現在做的流程準確來說被定義為例項化需求，但這個概念似乎不能把開發和測試給拉進來，而用bdd來定義，似乎就一瞬間把需求、設計、開發和測試拉繫結在了一起。
何為bdd？其實就是通過真實使用者的行為來定義我們需要開發出什麼樣的產品來，個人理解。但再結合例項化需求，就會發現，我們就是把使用者的行為通過乙個例項化的過程描述出來，然後整理成設計、開發和測試都能看懂的，當然最重要的是使用者也能看懂，而且使用者看完之後就認可，這就是我想要的，這就是bdd，也就是例項化需求過程。
它既不是傳統的需求文件，也不是設計文件，更不是測試用例文件，但適用於從需求、設計、開發和測試的每乙個階段，而且都是從使用者的角度為出發點的。那我就認為那就是我們想要的過程模式。
例項化需求的概念和流程
最近一段時間在關注一種新的敏捷模式，當然這裡說新，是由於目前很少看到有專案在應用，其實這種模式很早就已經誕生了。乙個偶爾的機會，在苦尋敏捷測試的 過程中，無意中看一本書，關於如何提高敏捷過程中需求 開發和驗收的測試效率，讓我很是感興趣，這本書名 例項化需求 團隊如何交付正確的軟體 可能是 由於翻譯的...
閱讀《例項化需求》1 3章有感
今天我閱讀了 例項化需求 的1 3章。第一章主要是講例項化需求的好處。例項化需求說明是一組過程模式，他幫助團隊構建正確的產品。使用例項化需求說明，團隊編寫的文件恰到好處，在短迭代或基於流的開發中可以有效地協助變更。例項化需求 這本書不是以理論的方式來構建乙個案例來闡述例項化需求說明的好處，而是來自 ...
敏捷開發每日一貼 需求管理和例項化需求
需求管理和例項化需求 軟體開發的最大問題之一往往是需求，而且它也很容易的被作為替罪羊。在公司專案延遲和出大問題的最大藉口，就是 需求不清楚 需求變更 那把需求早點弄清楚不就行了嘛？聽著挺容易，但要做好它卻很困難。敏捷迭代起來以後是否會好點呢？理論上會好點，因為需求在乙個迭代中東西會少點，更容易理清楚...