SpecDD是一個(gè)以需求為核心的混合敏捷開發(fā)方法。它旨在提供一個(gè)簡單的框架，在一系列原則指導(dǎo)下能同時(shí)管理敏捷項(xiàng)目和傳統(tǒng)項(xiàng)目。

 

　　SpecDD中的用戶需求，通過需求Epic，MSWordEpic，Spec，以及文檔附件進(jìn)行表達(dá)。Spec是對(duì)需求條目的規(guī)范化表達(dá)，并用于量化需求。和Scrum一樣，在SpecDD中，一個(gè)開發(fā)項(xiàng)目的研發(fā)過程由一組連續(xù)的迭代組成，每個(gè)迭代完成一系列承諾的工作項(xiàng)，并交付可執(zhí)行軟件。

 

　　不同于單純的敏捷，SpecDD整合了需求和QA測試過程模型。需求被用來生成產(chǎn)品backlog和開發(fā)sprint工作量。QA測試用例可以在開發(fā)迭代開始前，過程中，或之后被創(chuàng)建。為了使QA測試實(shí)踐變得可擴(kuò)展，建議有一個(gè)獨(dú)立的QA團(tuán)隊(duì)與敏捷團(tuán)隊(duì)一起合作，以便在開發(fā)sprint過程中以及全面回歸測試期間進(jìn)行測試。

 

 

　　SpecDD為敏捷團(tuán)隊(duì)提供了一個(gè)實(shí)踐框架，并將敏捷功能與傳統(tǒng)項(xiàng)目管理的最佳實(shí)踐相融合作為實(shí)踐指引。

 

　　需求通過工件的形式表達(dá)在產(chǎn)品backlog上。產(chǎn)品backlog中的條目被消耗并轉(zhuǎn)化生成為可執(zhí)行的軟件，而需求則被完整地保留下來。

 

　　需求與QA測試用例相關(guān)聯(lián)，在開發(fā)sprint開始前，過程中或之后，創(chuàng)造并完善測試用例。

 

　　在SpecDD中，每個(gè)開發(fā)sprint都含有兩個(gè)交付件：改進(jìn)后的可執(zhí)行軟件，和改進(jìn)后的需求表達(dá)。

 

　　SpecDD擁抱變更，但是需求和與之相關(guān)的變更都應(yīng)該被記錄在案，以保留業(yè)務(wù)邏輯或創(chuàng)意在創(chuàng)造和完善過程中產(chǎn)生的智慧。

 

　　SpecDD提供了一個(gè)可擴(kuò)展的質(zhì)量模型，同時(shí)確保了單個(gè)開發(fā)sprint的質(zhì)量和整合后產(chǎn)品的整體質(zhì)量。

 

 

　　SpecDD通過提高團(tuán)隊(duì)的工作效率和創(chuàng)新能力，來實(shí)現(xiàn)可擴(kuò)展的，可重復(fù)的成功。

 

　　在需求層面標(biāo)準(zhǔn)化團(tuán)隊(duì)溝通，將能夠提高團(tuán)隊(duì)的產(chǎn)品創(chuàng)新能力。

 

　　需求和產(chǎn)品backlog的整合，為多團(tuán)隊(duì)和大型敏捷項(xiàng)目提供了一個(gè)清晰的，可擴(kuò)展的模型。

 

　　獨(dú)立的QA回歸測試團(tuán)隊(duì)和引入的QA-floater模式，讓全面質(zhì)量管理更具可擴(kuò)展性。

 

　　它使企業(yè)能夠在產(chǎn)品需求和商務(wù)策略層面上，對(duì)敏捷或非敏捷項(xiàng)目進(jìn)行規(guī)劃。

 

 

　　SpecDD使用Epic和Spec來管理需求。Epic表示一個(gè)大概的想法，一般來說往往過于籠統(tǒng)，范圍也比較大，因此需要進(jìn)一步分解為Spec。Spec表示一個(gè)新功能或者功能改進(jìn)，可能需要進(jìn)一步分解為一個(gè)或多個(gè)開發(fā)任務(wù)進(jìn)行實(shí)現(xiàn)。一個(gè)Spec，不需要在充分理解需求，或者需求被完整文檔化的情況下，才開始實(shí)現(xiàn)。隨著Spec的開發(fā)實(shí)現(xiàn)，可執(zhí)行的軟件本身將幫助團(tuán)隊(duì)更好地理解原始需求。并常常會(huì)為需求添加新的和改進(jìn)后的文檔及附件，包括新的業(yè)務(wù)邏輯模型、更新后的用戶圖形界面、以及新的技術(shù)設(shè)計(jì)文檔等。

 

　　當(dāng)Spec被分配到產(chǎn)品Backlog時(shí)，Story將被創(chuàng)建，用來作為對(duì)Spec實(shí)現(xiàn)分配的承諾。實(shí)際項(xiàng)目中，單個(gè)Spec的實(shí)現(xiàn)，可能需要生成多個(gè)Story，經(jīng)過多次實(shí)現(xiàn)分配才最終完成。

 

　　下圖說明了Spec、Story和任務(wù)之間的關(guān)系。Spec被分配到開發(fā)空間中，生成一個(gè)或多個(gè)Story。每個(gè)Story可以進(jìn)一步分解為一個(gè)或多個(gè)開發(fā)任務(wù)。每個(gè)開發(fā)任務(wù)可能含有一個(gè)或多個(gè)QA測試子任務(wù)。

 

 

　　在SpecDD模型中，需求“驅(qū)動(dòng)”并不意味著需求在驅(qū)動(dòng)開發(fā)和質(zhì)量實(shí)踐前，需要被完整的定義。Spec是以客戶價(jià)值角度，表達(dá)的某個(gè)產(chǎn)品功能，可能并不包含最初需求的細(xì)節(jié)。需求Spec的實(shí)現(xiàn)過程，與需求Spec的重定義過程，常常并行發(fā)生。SpecDD提倡團(tuán)隊(duì)使用需求作為交流的標(biāo)準(zhǔn)，并使用文檔記錄改進(jìn)后的需求理解，以保存團(tuán)隊(duì)在需求決策過程中所做的“智慧”。

 

 

　　Sprint工作量來源于產(chǎn)品負(fù)責(zé)人選定的一組候選功能和缺陷列表。功能以Story的形式分配到Sprint，每個(gè)Story包含一些細(xì)分的開發(fā)任務(wù)。缺陷通常以獨(dú)立存在的開發(fā)任務(wù)（不與Story相關(guān)聯(lián)）分配到Sprint。

 

　　隨著任務(wù)負(fù)責(zé)人對(duì)各自工作進(jìn)展的推動(dòng)，一個(gè)個(gè)開發(fā)任務(wù)從初始狀態(tài)，經(jīng)過中間狀態(tài)，并且最終到達(dá)完成狀態(tài)。使用一個(gè)簡單的敏捷工作流，常常能夠幫助團(tuán)隊(duì)管理任務(wù)的生命周期。SpecDD框架下的任務(wù)工作流，往往包含以下幾個(gè)狀態(tài)：待分配，處理中，QAFloater驗(yàn)證和完成任務(wù)。隨著任務(wù)負(fù)責(zé)人每天的進(jìn)展，剩余工作時(shí)間理想情況下，將從最初的估計(jì)值不斷減少直至為零。伴隨開發(fā)團(tuán)隊(duì)自我管理，自我驅(qū)動(dòng)地完成所有承諾的開發(fā)任務(wù)，生成的燃盡圖報(bào)表（例如下圖）最佳地展現(xiàn)了團(tuán)隊(duì)Sprint工作量的進(jìn)展。

 

 

 

　　SpecDD框架中，Sprint工作量由一組待實(shí)現(xiàn)的Story，開發(fā)任務(wù)和缺陷組成。在Sprint開始的時(shí)候，為開發(fā)人員估計(jì)每個(gè)工作項(xiàng)的工作量，可以使用剩余時(shí)間或點(diǎn)數(shù)。這里有一個(gè)問題：是否需要?jiǎng)?chuàng)建與開發(fā)任務(wù)同級(jí)別的QA測試任務(wù)，并作為工作量的一部分？

 

　　一個(gè)常用的，但不合理的做法是為所有的開發(fā)任務(wù)創(chuàng)建同級(jí)別的QA測試任務(wù)，使用同樣的辦法，為QA測試任務(wù)也設(shè)定具體的剩余時(shí)間，從而驅(qū)動(dòng)QA測試任務(wù)的進(jìn)展。對(duì)于一個(gè)開發(fā)任務(wù)，估計(jì)剩余時(shí)間是可能的，并且能很好地激勵(lì)任務(wù)負(fù)責(zé)人，在估計(jì)的時(shí)間內(nèi)努力完成工作。

 

　　然而對(duì)于QA測試工作來說，在Sprint開始的時(shí)候，將所有可能需要的各種測試任務(wù)創(chuàng)建完畢，并且估計(jì)剩余時(shí)間，實(shí)際上是不可能的。更為重要的是，對(duì)QA測試總時(shí)間的估計(jì)，阻礙了建設(shè)一個(gè)自我驅(qū)動(dòng)的團(tuán)隊(duì)。不包含QA測試時(shí)間，對(duì)于Sprint的總剩余時(shí)間，團(tuán)隊(duì)總是可以自我驅(qū)動(dòng)的，并將它作為要達(dá)成的動(dòng)態(tài)目標(biāo)。而包含QA測試時(shí)間，它只會(huì)損害一個(gè)自我驅(qū)動(dòng)的開發(fā)團(tuán)隊(duì)，在他們估計(jì)的時(shí)間內(nèi)，努力完成所有開發(fā)工作的積極性。

 

　　在SpecDD模型中，通過為開發(fā)任務(wù)建立子任務(wù)來表示QA測試工作。對(duì)于功能性開發(fā)任務(wù)，可以基于開發(fā)任務(wù)所對(duì)應(yīng)的父級(jí)需求，生成相應(yīng)地測試標(biāo)準(zhǔn)。隨著需求被充分理解并文檔化，團(tuán)隊(duì)可以為需求Spec和Story創(chuàng)建測試用例，來準(zhǔn)確表達(dá)質(zhì)量標(biāo)準(zhǔn)。對(duì)于缺陷修復(fù)任務(wù)，測試子任務(wù)可能并不會(huì)與測試用例相關(guān)聯(lián)，因?yàn)槿毕菝枋霰旧硗捅Ａ袅薗A測試的標(biāo)準(zhǔn)。下圖說明了基于QA測試子任務(wù)的SpecDDSprint質(zhì)量模型。

 

 

 

　　SpecDDSprint質(zhì)量模型創(chuàng)造了一種“平衡”的質(zhì)量控制概念。可執(zhí)行軟件的創(chuàng)造人員，自我驅(qū)動(dòng)并努力將Story和開發(fā)任務(wù)轉(zhuǎn)化為可執(zhí)行的軟件。QAFloater是可執(zhí)行軟件的保護(hù)者，他們?yōu)殚_發(fā)任務(wù)創(chuàng)建QA測試子任務(wù)，以確保開發(fā)任務(wù)完成之前進(jìn)行充分的測試。可執(zhí)行軟件的創(chuàng)造者想要燃盡圖走的更快，總是主動(dòng)積極并達(dá)成剩余時(shí)間估計(jì)目標(biāo)。而保護(hù)者則是減緩剩余時(shí)間的進(jìn)展，有時(shí)，他們甚至因?yàn)榘l(fā)現(xiàn)新的缺陷，而增加了開發(fā)任務(wù)的剩余時(shí)間。SpecDDSprint質(zhì)量模型為這兩個(gè)關(guān)注面創(chuàng)造了一種動(dòng)態(tài)的平衡，優(yōu)化了開發(fā)產(chǎn)生力和質(zhì)量保障。

 

　　對(duì)于每個(gè)SpecDD的敏捷開發(fā)團(tuán)隊(duì)，推薦1-2名測試人員加入開發(fā)團(tuán)隊(duì)，加入的測試成員稱為QAfloater。QAfloater主導(dǎo)測試，并促進(jìn)最佳測試實(shí)踐，同時(shí)幫助每個(gè)敏捷團(tuán)隊(duì)成員成為更好的測試人員。建立并完善測試用例，是敏捷Sprint測試實(shí)踐中的主要產(chǎn)物，以確保高質(zhì)量的Sprint。測試用例將被保存于測試用例庫中，完整的測試用例庫未來會(huì)進(jìn)一步指導(dǎo)測試團(tuán)隊(duì)的全面回歸測試。

 

　　SpecDD回歸測試模型

 

　　在QAfloater和測試子任務(wù)模型下，一個(gè)理想的SpecDDSprint將能夠交付一個(gè)沒有缺陷的可執(zhí)行軟件。但現(xiàn)實(shí)中往往是，在多個(gè)Sprint迭代后，相互集成的產(chǎn)品，勢必會(huì)有一些缺陷。沒有一個(gè)穩(wěn)固的回歸測試實(shí)踐，多團(tuán)隊(duì)參與的大型項(xiàng)目，無疑將缺乏質(zhì)量控制和可擴(kuò)展性。

 

　　SpecDD使用測試用例，并與運(yùn)行時(shí)的環(huán)境變量相結(jié)合，正規(guī)化表達(dá)并量化產(chǎn)品的質(zhì)量。QA測試計(jì)劃為產(chǎn)品的發(fā)布指定了測試標(biāo)準(zhǔn)。為了更加靈活高效地執(zhí)行測試計(jì)劃，常常使用測試周期來表示較小的測試迭代，一個(gè)測試周期可用于覆蓋QA測試計(jì)劃可能產(chǎn)生的所有任務(wù)的一個(gè)子集。

 

　　一個(gè)測試周期包含一組測試任務(wù)，測試任務(wù)是基于測試用例與運(yùn)行環(huán)境變量排列組合下產(chǎn)生的具體實(shí)例。可以手動(dòng)或使用自動(dòng)化測試工具，來執(zhí)行這些測試任務(wù)。下圖反映了開發(fā)迭代周期與QA測試周期的關(guān)系。

 

 

　　正如您所看到的，QA測試周期的規(guī)劃和執(zhí)行，不一定同步于開發(fā)迭代周期。當(dāng)您想將新發(fā)現(xiàn)的缺陷分配到當(dāng)前進(jìn)展中的Sprint時(shí)，敏捷開發(fā)方法會(huì)要求測試團(tuán)隊(duì)只能將缺陷提交到產(chǎn)品Backlog中。QA回歸測試團(tuán)隊(duì)負(fù)責(zé)提交缺陷，但是他們并沒有權(quán)利決定何時(shí)修復(fù)這些缺陷。擁有一個(gè)獨(dú)立的測試團(tuán)隊(duì)，更早地發(fā)現(xiàn)缺陷，并在產(chǎn)品Backlog中對(duì)缺陷進(jìn)行優(yōu)先級(jí)排序，實(shí)際上有助于創(chuàng)造一個(gè)更加靈活的敏捷過程。

 

 

　　敏捷技術(shù)，正成為一個(gè)個(gè)構(gòu)建基石，嵌入到其他開發(fā)方法。有了這樣的信念，SpecDD為團(tuán)隊(duì)提供了指引，將敏捷技術(shù)與團(tuán)隊(duì)現(xiàn)有實(shí)踐進(jìn)行最佳的融合。

 

　　對(duì)于使用瀑布模型的團(tuán)隊(duì)，SpecDD幫助他們擴(kuò)展了需求管理，并支持產(chǎn)品Backlog。隨著產(chǎn)品Backlog的優(yōu)先級(jí)排序，團(tuán)隊(duì)可以開始嘗試較短的迭代開發(fā)，同時(shí)通過燃盡圖和每日敏捷練習(xí)，創(chuàng)造自我驅(qū)動(dòng)的團(tuán)隊(duì)。伴隨需求驅(qū)動(dòng)的開發(fā)和質(zhì)量的實(shí)踐，他們很快就會(huì)看到生產(chǎn)率的提高。

 

　　對(duì)于已經(jīng)實(shí)踐敏捷開發(fā)的團(tuán)隊(duì)，SpecDD有助于全面整合需求管理與產(chǎn)品Backlog，實(shí)現(xiàn)需求完整可追溯。通過引入敏捷SprintQA測試，并建立一個(gè)獨(dú)立的QA團(tuán)隊(duì)來執(zhí)行回歸測試，使得多團(tuán)隊(duì)參與的敏捷項(xiàng)目變得更具有擴(kuò)展性。

 

　　作者簡介

 

　　周鐵人，畢業(yè)于美國Kansas州立大學(xué)，獲計(jì)算機(jī)科學(xué)專業(yè)碩士學(xué)位和人工智能專業(yè)博士學(xué)位；在攻讀博士學(xué)位期間，他致力于實(shí)驗(yàn)室自動(dòng)化、概念建模、機(jī)器人技術(shù)和人工智能的研究。如今，作為"以知識(shí)為核心"的應(yīng)用生命周期管理（ALM）領(lǐng)域內(nèi)的專家，周鐵人博士提倡以知識(shí)為核心的軟件過程改進(jìn)，并針對(duì)當(dāng)今的分布式開發(fā)團(tuán)隊(duì)和服務(wù)支持團(tuán)隊(duì)的特點(diǎn)和需求，設(shè)計(jì)開發(fā)TechExcelALM解決方案，幫助企業(yè)全面管理軟件生命周期內(nèi)的各個(gè)流程，從概念形成、設(shè)計(jì)規(guī)劃、到開發(fā)實(shí)施和產(chǎn)品交付。周博士曾參與過全球最大的開發(fā)團(tuán)隊(duì)的培訓(xùn)及實(shí)踐工作，其獨(dú)創(chuàng)的SpecDD混合的敏捷開發(fā)方法論，已成功指導(dǎo)和應(yīng)用于EA、SONY、RIM、聯(lián)邦快遞等國際知名企業(yè)，優(yōu)化了QA和需求管理相整合的敏捷過程，組織推動(dòng)了均衡和可擴(kuò)展的敏捷開發(fā)方法論。