敏捷已成爲當今最被廣泛接受，並被廣泛實踐的開發方法。有趣的是，敏捷方法的流行並不是因爲它取代了其他開發方法，相反它與這些方法進行了更好地融合。現實中，衆多敏捷項目的成功，也證明了敏捷將走向雜化的未來。
SpecDD是一個以需求爲核心的混合敏捷開發方法。它旨在提供一個簡單的框架，在一系列原則指導下能同時管理敏捷項目和傳統項目。
SpecDD中的用戶需求，通過需求Epic，MS Word Epic，Spec，以及文檔附件進行表達。Spec是對需求條目的規範化表達，並用於量化需求。和Scrum一樣，在SpecDD中，一個開發項目的研發過程由一組連續的迭代組成，每個迭代完成一系列承諾的工作項，並交付可執行軟件。
不同於單純的敏捷，SpecDD整合了需求和QA測試過程模型。需求被用來生成產品backlog和開發sprint工作量。QA測試用例可以在開發迭代開始前，過程中，或之後被創建。爲了使QA測試實踐變得可擴展，建議有一個獨立的QA團隊與敏捷團隊一起合作，以便在開發sprint過程中以及全面迴歸測試期間進行測試。
什麼是SpecDD？
SpecDD爲敏捷團隊提供了一個實踐框架，並將敏捷功能與傳統項目管理的最佳實踐相融合作爲實踐指引。
需求通過工件的形式表達在產品backlog上。產品backlog中的條目被消耗並轉化生成爲可執行的軟件，而需求則被完整地保留下來。
需求與QA測試用例相關聯，在開發sprint開始前，過程中或之後，創造並完善測試用例。
在SpecDD中，每個開發sprint都含有兩個交付件：改進後的可執行軟件，和改進後的需求表達。
SpecDD擁抱變更，但是需求和與之相關的變更都應該被記錄在案，以保留業務邏輯或創意在創造和完善過程中產生的智慧。
SpecDD提供了一個可擴展的質量模型，同時確保了單個開發sprint的質量和整合後產品的整體質量。
SpecDD的優勢
SpecDD通過提高團隊的工作效率和創新能力，來實現可擴展的，可重複的成功。
在需求層面標準化團隊溝通，將能夠提高團隊的產品創新能力。
需求和產品backlog的整合，爲多團隊和大型敏捷項目提供了一個清晰的，可擴展的模型。
獨立的QA迴歸測試團隊和引入的QA-floater模式，讓全面質量管理更具可擴展性。
它使企業能夠在產品需求和商務策略層面上，對敏捷或非敏捷項目進行規劃。
量化需求，以驅動開發
SpecDD使用Epic和Spec來管理需求。Epic表示一個大概的想法，一般來說往往過於籠統，範圍也比較大，因此需要進一步分解爲Spec。Spec表示一個新功能或者功能改進，可能需要進一步分解爲一個或多個開發任務進行實現。一個Spec，不需要在充分理解需求，或者需求被完整文檔化的情況下，纔開始實現。隨着Spec的開發實現，可執行的軟件本身將幫助團隊更好地理解原始需求。並常常會爲需求添加新的和改進後的文檔及附件，包括新的業務邏輯模型、更新後的用戶圖形界面、以及新的技術設計文檔等。
當Spec被分配到產品Backlog時，Story將被創建，用來作爲對Spec實現分配的承諾。實際項目中，單個Spec的實現，可能需要生成多個Story，經過多次實現分配才最終完成。
下圖說明了Spec、Story和任務之間的關係。Spec被分配到開發空間中，生成一個或多個Story。每個Story可以進一步分解爲一個或多個開發任務。每個開發任務可能含有一個或多個QA測試子任務。
在SpecDD模型中，需求“驅動”並不意味着需求在驅動開發和質量實踐前，需要被完整的定義。Spec 是以客戶價值角度，表達的某個產品功能，可能並不包含最初需求的細節。需求Spec的實現過程，與需求Spec的重定義過程，常常並行發生。SpecDD提倡團隊使用需求作爲交流的標準，並使用文檔記錄改進後的需求理解，以保存團隊在需求決策過程中所做的“智慧”。
SpecDD開發迭代
Sprint工作量來源於產品負責人選定的一組候選功能和缺陷列表。功能以Story的形式分配到Sprint，每個Story包含一些細分的開發任務。缺陷通常以獨立存在的開發任務（不與Story相關聯）分配到Sprint。
隨着任務負責人對各自工作進展的推動，一個個開發任務從初始狀態，經過中間狀態，並且最終到達完成狀態。使用一個簡單的敏捷工作流，常常能夠幫助團隊管理任務的生命週期。SpecDD框架下的任務工作流，往往包含以下幾個狀態：待分配，處理中，QAFloater驗證和完成任務。隨着任務負責人每天的進展，剩餘工作時間理想情況下，將從最初的估計值不斷減少直至爲零。伴隨開發團隊自我管理，自我驅動地完成所有承諾的開發任務，生成的燃盡圖報表（例如下圖）最佳地展現了團隊Sprint工作量的進展。
SpecDD Sprint質量模型
SpecDD框架中，Sprint工作量由一組待實現的Story，開發任務和缺陷組成。在Sprint開始的時候，爲開發人員估計每個工作項的工作量，可以使用剩餘時間或點數。這裏有一個問題：是否需要創建與開發任務同級別的QA測試任務，並作爲工作量的一部分？
一個常用的，但不合理的做法是爲所有的開發任務創建同級別的QA測試任務，使用同樣的辦法，爲QA測試任務也設定具體的剩餘時間，從而驅動QA測試任務的進展。對於一個開發任務，估計剩餘時間是可能的，並且能很好地激勵任務負責人，在估計的時間內努力完成工作。
然而對於QA測試工作來說，在Sprint開始的時候，將所有可能需要的各種測試任務創建完畢，並且估計剩餘時間，實際上是不可能的。更爲重要的是，對QA測試總時間的估計，阻礙了建設一個自我驅動的團隊。不包含QA測試時間，對於Sprint的總剩餘時間，團隊總是可以自我驅動的，並將它作爲要達成的動態目標。而包含QA測試時間，它只會損害一個自我驅動的開發團隊，在他們估計的時間內，努力完成所有開發工作的積極性。
在SpecDD模型中，通過爲開發任務建立子任務來表示QA測試工作。對於功能性開發任務，可以基於開發任務所對應的父級需求，生成相應地測試標準。隨着需求被充分理解並文檔化，團隊可以爲需求Spec和Story創建測試用例，來準確表達質量標準。對於缺陷修復任務，測試子任務可能並不會與測試用例相關聯，因爲缺陷描述本身往往就保留了QA測試的標準。下圖說明了基於QA測試子任務的SpecDD Sprint質量模型。
SpecDD Sprint質量模型創造了一種“平衡”的質量控制概念。可執行軟件的創造人員，自我驅動並努力將Story和開發任務轉化爲可執行的軟件。QA Floater是可執行軟件的保護者，他們爲開發任務創建QA測試子任務，以確保開發任務完成之前進行充分的測試。可執行軟件的創造者想要燃盡圖走的更快，總是主動積極並達成剩餘時間估計目標。而保護者則是減緩剩餘時間的進展，有時，他們甚至因爲發現新的缺陷，而增加了開發任務的剩餘時間。SpecDD Sprint質量模型爲這兩個關注面創造了一種動態的平衡，優化了開發產生力和質量保障。
對於每個SpecDD的敏捷開發團隊，推薦1-2名測試人員加入開發團隊，加入的測試成員稱爲QA floater。QA floater主導測試，並促進最佳測試實踐，同時幫助每個敏捷團隊成員成爲更好的測試人員。建立並完善測試用例，是敏捷Sprint測試實踐中的主要產物，以確保高質量的Sprint。測試用例將被保存於測試用例庫中，完整的測試用例庫未來會進一步指導測試團隊的全面迴歸測試。
SpecDD迴歸測試模型
在QA floater和測試子任務模型下，一個理想的SpecDD Sprint將能夠交付一個沒有缺陷的可執行軟件。但現實中往往是，在多個Sprint迭代後，相互集成的產品，勢必會有一些缺陷。沒有一個穩固的迴歸測試實踐，多團隊參與的大型項目，無疑將缺乏質量控制和可擴展性。
SpecDD使用測試用例，並與運行時的環境變量相結合，正規化表達並量化產品的質量。QA測試計劃爲產品的發佈指定了測試標準。爲了更加靈活高效地執行測試計劃，常常使用測試周期來表示較小的測試迭代，一個測試周期可用於覆蓋QA測試計劃可能產生的所有任務的一個子集。
一個測試周期包含一組測試任務，測試任務是基於測試用例與運行環境變量排列組合下產生的具體實例。可以手動或使用自動化測試工具，來執行這些測試任務。下圖反映了開發迭代週期與QA 測試周期的關係。
正如您所看到的，QA測試周期的規劃和執行，不一定同步於開發迭代週期。當您想將新發現的缺陷分配到當前進展中的Sprint時，敏捷開發方法會要求測試團隊只能將缺陷提交到產品Backlog中。QA迴歸測試團隊負責提交缺陷，但是他們並沒有權利決定何時修復這些缺陷。擁有一個獨立的測試團隊，更早地發現缺陷，並在產品Backlog中對缺陷進行優先級排序，實際上有助於創造一個更加靈活的敏捷過程。
結論
敏捷技術，正成爲一個個構建基石，嵌入到其他開發方法。有了這樣的信念，SpecDD爲團隊提供了指引，將敏捷技術與團隊現有實踐進行最佳的融合。
對於使用瀑布模型的團隊，SpecDD幫助他們擴展了需求管理，並支持產品Backlog。隨着產品Backlog的優先級排序，團隊可以開始嘗試較短的迭代開發，同時通過燃盡圖和每日敏捷練習，創造自我驅動的團隊。伴隨需求驅動的開發和質量的實踐，他們很快就會看到生產率的提高。
對於已經實踐敏捷開發的團隊，SpecDD有助於全面整合需求管理與產品Backlog，實現需求完整可追溯。通過引入敏捷Sprint QA測試，並建立一個獨立的QA團隊來執行迴歸測試，使得多團隊參與的敏捷項目變得更具有擴展性。
作者簡介
周鐵人，畢業於美國Kansas 州立大學，獲計算機科學專業碩士學位和人工智能專業博士學位；在攻讀博士學位期間，他致力於實驗室自動化、概念建模、機器人技術和人工智能的研究。如今，作爲"以知識爲核心"的應用生命週期管理（ALM）領域內的專家，周鐵人博士提倡以知識爲核心的軟件過程改進，並針對當今的分佈式開發團隊和服務支持團隊的特點和需求，設計開發 ALM 解決方案，幫助企業全面管理軟件生命週期內的各個流程，從概念形成、設計規劃、到開發實施和產品交付。周博士曾參與過全球最大的開發團隊的培訓及實踐工作，其獨創的SpecDD混合的敏捷開發方法論，已成功指導和應用於EA、SONY、RIM、聯邦快遞等國際知名企業，優化了QA和需求管理相整合的敏捷過程，組織推動了均衡和可擴展的敏捷開發方法論。