- 量化需求，以驅動開發
- 需求分解：需求先被分解為Epic需求面（大致需求）
- 需求量化：進一步分解為Spec需求點,并可使用Spec去關聯需求文檔和設計文檔
- 需求分配：Spec被分配到開發空間中，生成多個Story和 task進行實現，且每個task可以含有多個QA測試子任務
- 開發工作被分解到開發空間、里程碑和各個沖刺迭代中
- 需求與產品Backlog相整合：產品Backlog是一組待處理的Story和開發任務列表。Story需要進一步分解為多個開發任務，代表了團隊在開發周期中承諾的待開發任務。
- QA測試用例在開發迭代周期內被定義，QA團隊既能夠獨立工作，同時又能與回歸測試相整合
Sprint工作量來源于產品負責人選定的一組候選功能和缺陷列表。功能以Story的形式分配到Sprint，每個Story包含一些細分的開發任務。缺陷通常以獨立存在的開發任務（不與Story相關聯）分配到Sprint。
隨著任務負責人對各自工作進展的推動，每個開發任務經歷初始狀態、中間狀態，到最終完成狀態。使用一個簡單的敏捷工作流，常常能夠幫助團隊管理任務的生命周期。SpecDD框架下的任務工作流，往往包含以下幾個狀態：待分配，處理中，QAFloater驗證和完成任務。隨著任務負責人每天的進展，剩余工作時間理想情況下，將從最初的估計值不斷減少直至為零。伴隨開發團隊自我管理，自我驅動地完成所有承諾的開發任務，生成的燃盡圖報表（如圖）最佳地展現了團隊Sprint工作量的進展。
Sprint工作量由一組待實現的Story、開發任務和缺陷組成。在Sprint開始時，為開發人員估計每個工作項的工作量，可以使用剩余時間或點數。那是否需要創建與開發任務同級別的QA測試任務，并作為工作量的一部分？
一個常用的，但并不合理的做法是為所有的開發任務創建同級別的QA測試任務，使用同樣的辦法，為QA測試任務也設定具體的剩余時間，從而驅動QA測試任務的進展。對于一個開發任務，估計剩余時間是可能的，并且能很好地激勵任務負責人，在估計的時間內努力完成工作。
而對于QA測試工作來說，在Sprint開始時，將所有可能需要的各種測試任務創建完畢，并且估計剩余時間，實際上是不可能的。更為重要的是，對QA測試總時間的估計，阻礙了建設一個自我驅動的團隊。不包含QA測試時間，對于Sprint的總剩余時間，團隊總是可以自我驅動的，并將它作為要達成的動態目標。而包含QA測試時間，它只會損害一個自我驅動的開發團隊，在他們估計的時間內，努力完成所有開發工作的積極性。
在SpecDD模型中，通過為開發任務建立子任務來表示QA測試工作。對于功能性開發任務，可以基于開發任務所對應的父級需求，生成相應地測試標準。隨著需求被充分理解并文檔化，團隊可以為需求Spec和Story創建測試用例，來準確表達質量標準。對于缺陷修復任務，測試子任務可能并不會與測試用例相關聯，因為缺陷描述本身往往就保留了QA測試的標準。右圖說明了基于QA測試子任務的SpecDD Sprint質量模型。
在QA floater和測試子任務模型下，一個理想的SpecDD Sprint將能夠交付一個沒有缺陷的可執行軟件。但現實中往往是，在多個Sprint迭代后，相互集成的產品，勢必會有一些缺陷。沒有一個穩固的回歸測試實踐，多團隊參與的大型項目，無疑將缺乏質量控制和可擴展性。
SpecDD使用測試用例，并與運行時的環境變量相結合，正規化表達并量化產品的質量。QA測試計劃為產品的發布指定了測試標準。為了更加靈活高效地執行測試計劃，常常使用測試周期來表示較小的測試迭代，一個測試周期可用于覆蓋QA測試計劃可能產生的所有任務的一個子集。
一個測試周期包含一組測試任務，測試任務是基于測試用例與運行環境變量排列組合下產生的具體實例?？梢允謩踊蚴褂米詣踊瘻y試工具，來執行這些測試任務。左圖反映了開發迭代周期與QA 測試周期的關系。正如您所見，QA測試周期的規劃和執行，不一定同步于開發迭代周期。當您想將新發現的缺陷分配到當前進展中的Sprint時，敏捷開發方法會要求測試團隊只能將缺陷提交到產品Backlog中。QA回歸測試團隊負責提交缺陷，但他們并沒有權利決定何時修復這些缺陷。擁有一個獨立的測試團隊，更早地發現缺陷，并在產品Backlog中對缺陷進行優先級排序，實際上有助于創造一個更加靈活的敏捷過程。
了解更多SpecDD 專題介紹和文章
售后服務平臺登錄