敏捷開發用短短十年時間發展為當今最為廣泛使用的開發方法，其原因在于它簡單且有效地提高了開發團隊的生產率。敏捷方法指導團隊將產品需求置于Product Backlog中管理，并按照優先級對每個產品需求進行必要的排列；通過計劃會(Planning Meeting)、Daily Standard Up Meeting(每日立會)、Project Review Meeting(評審會)等，從Product Backlog中挑選最重要的Willing List（意向表），分配到團隊的每個Sprint 研發過程中。高效、靈活的保證了可執行產品的交付，并讓用戶更早提出修改意見。

  但是敏捷方法的普遍使用中，又發現了單純敏捷方法的局限性：

•         缺少對多團隊參與的大型項目的指導框架；
•         缺少開發和QA測試的整合模型；
•         無法支持需求驅動下完整的可追溯性；
•         整個團隊完全致力于項目的開發是基本前提，一旦開發團隊的方向出現變化，會導致項目的崩潰，因為需求總在變化；
•         一旦使用敏捷方法失敗，不但時間會被浪費，團隊人員也會出現松動。當相關人員離職后，整個過程的經驗積累也無法得以保存。

        因此敏捷的自身發展又反過來推動了敏捷方法和其他開發方法的相互整合。當今超過75%的企業敏捷項目，采用了多個方法相融合和雜化的敏捷過程。

例如版本V1.0 采用單一敏捷方法（Scrum）；V2.0采用傳統方法（瀑布）；V3.0采用敏捷和傳統方法相結合。

      理想的敏捷開發方法的基本理念：軟件是構想、功能設計和技術設計相結合的產物，只要設計完善，任何好的開發團隊都能實現它。

      以Scrum為代表的單純敏捷方法論指導將產品需求置于產品待辦目錄（Product Backlog）中管理，并按照優先級對每個產品需求進行必要的排列。但實踐調查發現更多大型項目的成功，依賴于通過需求工作流、需求分析和需求可追溯性，來系統化管理需求，從而在需求層面上對項目做整體規劃和控制，高效、靈活地向客戶交付可執行產品，并保證交付結果的正確性。

同時以Scrum為代表的單純敏捷方法缺乏質量控制的考慮，我們來思考以下觀點是否正確？

•        盡可能多的測試以保證每個Sprint交付的可執行軟件完全沒有缺陷；
•        好的Sprint 開發過程應當保證產品完全沒有缺陷；
•       缺陷在Sprint 開發過程中應當被發現；
•       缺陷應當在當前Sprint中全部被修復。

因此傳統的敏捷開發需要結合與需求管理和質量控制的考慮，SpecDD的建立，解決了Scrum在需求層面上，以及團隊合作上的缺陷、質量保證等問題。

 什么是SpecDD？

      SpecDD是一種管理軟件研發過程的混合型敏捷方法，它基于同時支持敏捷和非敏捷研發過程而設計，使得開發團隊能用相同的辦法來管理敏捷和非敏捷項目。SpecDD框架中包含了產品負責人、項目經理、測試主管、開發團隊和測試團隊五個角色。在SpecDD 模型中，一個項目的研發過程通過三個空間來進行表達，即，需求空間、研發空間和QA測試空間，三個空間是相互完全整合的。

       在SpecDD模型中，開發工作被分解到開發空間、里程碑和各個沖刺迭代中，同時Product backlog和需求管理是相互整合的。此外，SpecDD提供了明確的指導方針，以及如何實踐的做法，實現QA測試用例在開發迭代周期內被定義；借助這樣的模型，使得QA團隊既能夠獨立工作，同時又能與回歸測試相整合。SpecDD解答了在現實項目中，如何有效地實現敏捷開發與需求和質量的整合。

 SpecDD 過程模型
 
SpecDD追溯性模型