SpecDD實踐框架：
- 理解和掌握大型開發項目的有效管理策略和多團隊協作模型；
- 提供敏捷與其它方法整合的優化框架；
- 提供有效實現敏捷開發與需求& 質量、需求& backlog、項目& 資源、項目組合管理、QA& 測試團隊的整合框架；
- 闡述開發團隊如何能用相同的辦法來管理敏捷和非敏捷項目；
- 開發工作被分解到開發空間，里程碑，和各個沖刺迭代中，同時Product backlog和需求管理是相互整合的；
- 提供明確的指導方針，以及如何實踐的做法，實現QA測試用例在迭代周期內被定義；
- QA團隊既能夠獨立工作，同時又能與回歸測試相整合；
- ……
團隊管理
可擴展的多團隊開發模型
以Scrum為代表的單純敏捷方法，提高了軟件開發過程的有效性和生產率；但是它不能幫助團隊實現可持續和能擴展的成功。它缺少對多團隊協作大型開發項目的有效管理模型?，F實中，更多的企業敏捷項目，采用了質量與需求整合的敏捷過程。
- SpecDD強調和質量管理團隊的整合。SpecDD中，QA部門既能夠獨立工作，同時又能與回歸測試相整合，從而有效地和敏捷開發團隊協作。
- SpecDD強調和需求管理團隊的整合。通過系統化地需求管理，實現需求的完全可追溯性，高效、靈活地推動了交付結果的正確性。同時，更好的將創造產品功能時所經歷過的團隊討論與決定過程，進行管理。
開發和需求的整合
產品Backlog
產品Backlog 是一組待處理的Story和開發任務列表。產品Backlog中的Story不是具體的需求，是基于需求生成的一次實現分配。我們可以直接將需求從需求空間分配到Sprint；也可以先將需求分配到產品Backlog，由產品負責人對Backlog中的所有條目統一進行優先級排序，然后選擇能實現的部分放入Sprint中。一旦Story被分配到Sprint中，就自動從產品Backlog中移除。
Story
- Story是對指定需求的具體實現
- 包含功能 Story、缺陷Story
- 獨立的Story, 沒有相對應的需求
- 需要進一步分解為多個開發任務
需求變更管理，并高效變更推送開發空間、測試空間
如果您的團隊需要對需求變更執行嚴格的審批流程，DevSpec提供了需求變更管理視圖，并可自定義需求變更審批流程。
您也可以簡化，直接對需求列表做變更操作。業務部門評估需求變更的影響范圍，通過需求變更標識子任務（Change Flagging Event），將變更內容自動推送到受影響的關聯開發任務和測試用例，幫助團隊輕松管理需求變更。
開發和測試的整合
開發周期中做適量的測試
- 在Sprint 開始之前，根據需求的質量標準，定義好測試用例
- 測試人員將設計好的測試用例，緊密地與開發任務相關聯
- 開發和測試合作，完善并創造測試用例，達成有質量保證的開發結果
獨立的測試部門，有效和敏捷開發團隊協作，全面的測試覆蓋面
- 為新完成的相關產品功能，找到所有的測試用例，應用具體環境變量
- 選中所有可能影響的測試區域，進行回歸測試
- 測試團隊可以為多個開發團隊開展測試工作
- 發現的缺陷可以被提交到共享的或單獨的迭代Backlog中
流動的QA
- 推薦1-2名測試人員加入開發團隊，加入的測試成員主導測試工作
- 通過QA測試協同子任務，將測試用例與開發任務相整合，并管理Sprint過程中的缺陷和質量保證
- 測試結果，直接影響開發人員的剩余工作時間
需求和測試的整合
測試和需求
- 基于需求設計定義測試用例
- 測試計劃應用具體環境變量，生成測試任務
高效保證測試質量
通過調整環境變量復用測試用例，保證相同的產品在不同環境中的測試質量
項目跟蹤
工作流引擎
工作流引擎驅動的跟蹤機制, 使得需求及任務流程不再混亂?？勺远x的工作流程, 保證不同職能團隊前后協調工作。
敏捷項目是否需要計劃—YES！不過項目計劃建立在需求層面。與項目計劃緊密關聯的任務管理機制，直觀的條目化展現形式，讓您不再使用白板和便簽，信息量更大，管理卻更加簡潔。
完整的歷史記錄讓任務可追蹤，可追溯。