<td id="pkj9t"></td>
敏捷已成為當今最被廣泛接受，并被廣泛實踐的開發方法。有趣的是，敏捷方法的流行并不是因為它取代了其他開發方法，相反它與這些方法進行了更好地融合?，F實中，眾多敏捷項目的成功，也證明了敏捷將走向雜化的未來。
SpecDD是一個以需求為核心的混合敏捷開發方法。它旨在提供一個簡單的框架，在一系列原則指導下能同時管理敏捷項目和傳統項目。
SpecDD中的用戶需求，通過需求Epic，MS Word Epic，Spec，以及文檔附件進行表達。Spec是對需求條目的規范化表達，并用于量化需求。和Scrum一樣，在SpecDD中，一個開發項目的研發過程由一組連續的迭代組成，每個迭代完成一系列承諾的工作項，并交付可執行軟件。
不同于單純的敏捷，SpecDD整合了需求和QA測試過程模型。需求被用來生成產品backlog和開發sprint工作量。QA測試用例可以在開發迭代開始前，過程中，或之后被創建。為了使QA測試實踐變得可擴展，建議有一個獨立的QA團隊與敏捷團隊一起合作，以便在開發sprint過程中以及全面回歸測試期間進行測試。
什么是SpecDD？
SpecDD為敏捷團隊提供了一個實踐框架，并將敏捷功能與傳統項目管理的最佳實踐相融合作為實踐指引。
SpecDD的優勢
SpecDD通過提高團隊的工作效率和創新能力，來實現可擴展的，可重復的成功。
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提倡團隊使用需求作為交流的標準，并使用文檔記錄改進后的需求理解，以保存團隊在需求決策過程中所做的“智慧”。
Sprint工作量來源于產品負責人選定的一組候選功能和缺陷列表。功能以Story的形式分配到Sprint，每個Story包含一些細分的開發任務。缺陷通常以獨立存在的開發任務（不與Story相關聯）分配到Sprint。
隨著任務負責人對各自工作進展的推動，一個個開發任務從初始狀態，經過中間狀態，并且最終到達完成狀態。使用一個簡單的敏捷工作流，常常能夠幫助團隊管理任務的生命周期。SpecDD框架下的任務工作流，往往包含以下幾個狀態：待分配，處理中，QAFloater驗證和完成任務。隨著任務負責人每天的進展，剩余工作時間理想情況下，將從最初的估計值不斷減少直至為零。伴隨開發團隊自我管理，自我驅動地完成所有承諾的開發任務，生成的燃盡圖報表（例如下圖）最佳地展現了團隊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質量模型創造了一種“平衡”的質量控制概念?？蓤绦熊浖膭撛烊藛T，自我驅動并努力將Story和開發任務轉化為可執行的軟件。QA Floater是可執行軟件的保護者，他們為開發任務創建QA測試子任務，以確保開發任務完成之前進行充分的測試?？蓤绦熊浖膭撛煺呦胍急M圖走的更快，總是主動積極并達成剩余時間估計目標。而保護者則是減緩剩余時間的進展，有時，他們甚至因為發現新的缺陷，而增加了開發任務的剩余時間。SpecDD Sprint質量模型為這兩個關注面創造了一種動態的平衡，優化了開發產生力和質量保障。
對于每個SpecDD的敏捷開發團隊，推薦1-2名測試人員加入開發團隊，加入的測試成員稱為QA floater。QA floater主導測試，并促進最佳測試實踐，同時幫助每個敏捷團隊成員成為更好的測試人員。建立并完善測試用例，是敏捷Sprint測試實踐中的主要產物，以確保高質量的Sprint。測試用例將被保存于測試用例庫中，完整的測試用例庫未來會進一步指導測試團隊的全面回歸測試。
在QA floater和測試子任務模型下，一個理想的SpecDD Sprint將能夠交付一個沒有缺陷的可執行軟件。但現實中往往是，在多個Sprint迭代后，相互集成的產品，勢必會有一些缺陷。沒有一個穩固的回歸測試實踐，多團隊參與的大型項目，無疑將缺乏質量控制和可擴展性。
SpecDD使用測試用例，并與運行時的環境變量相結合，正規化表達并量化產品的質量。QA測試計劃為產品的發布指定了測試標準。為了更加靈活高效地執行測試計劃，常常使用測試周期來表示較小的測試迭代，一個測試周期可用于覆蓋QA測試計劃可能產生的所有任務的一個子集。
一個測試周期包含一組測試任務，測試任務是基于測試用例與運行環境變量排列組合下產生的具體實例?？梢允謩踊蚴褂米詣踊瘻y試工具，來執行這些測試任務。下圖反映了開發迭代周期與QA 測試周期的關系。
正如您所看到的，QA測試周期的規劃和執行，不一定同步于開發迭代周期。當您想將新發現的缺陷分配到當前進展中的Sprint時，敏捷開發方法會要求測試團隊只能將缺陷提交到產品Backlog中。QA回歸測試團隊負責提交缺陷，但是他們并沒有權利決定何時修復這些缺陷。擁有一個獨立的測試團隊，更早地發現缺陷，并在產品Backlog中對缺陷進行優先級排序，實際上有助于創造一個更加靈活的敏捷過程。
敏捷技術，正成為一個個構建基石，嵌入到其他開發方法。有了這樣的信念，SpecDD為團隊提供了指引，將敏捷技術與團隊現有實踐進行最佳的融合。
對于使用瀑布模型的團隊，SpecDD幫助他們擴展了需求管理，并支持產品Backlog。隨著產品Backlog的優先級排序，團隊可以開始嘗試較短的迭代開發，同時通過燃盡圖和每日敏捷練習，創造自我驅動的團隊。伴隨需求驅動的開發和質量的實踐，他們很快就會看到生產率的提高。
對于已經實踐敏捷開發的團隊，SpecDD有助于全面整合需求管理與產品Backlog，實現需求完整可追溯。通過引入敏捷Sprint QA測試，并建立一個獨立的QA團隊來執行回歸測試，使得多團隊參與的敏捷項目變得更具有擴展性。
周鐵人，畢業于美國Kansas 州立大學，獲計算機科學專業碩士學位和人工智能專業博士學位；在攻讀博士學位期間，他致力于實驗室自動化、概念建模、機器人技術和人工智能的研究。如今，作為"以知識為核心"的應用生命周期管理（ALM）領域內的專家，周鐵人博士提倡以知識為核心的軟件過程改進，并針對當今的分布式開發團隊和服務支持團隊的特點和需求，設計開發TechExcel ALM 解決方案，幫助企業全面管理軟件生命周期內的各個流程，從概念形成、設計規劃、到開發實施和產品交付。周博士曾參與過全球最大的開發團隊的培訓及實踐工作，其獨創的SpecDD混合的敏捷開發方法論，已成功指導和應用于EA、SONY、RIM、聯邦快遞等國際知名企業，優化了QA和需求管理相整合的敏捷過程，組織推動了均衡和可擴展的敏捷開發方法論。
