SpecDD是一個以需求為核心的混合敏捷開發方法。它旨在提供一個簡單的框架，在一系列原則指導下能同時管理敏捷項目和傳統項目。
基本介紹
- 中文名：SpecDD：混合型的敏捷開發方法
- 核心：需求
- 性質：混合敏捷開發方法
- 宗旨：提供一個簡單的框架
- 優點：時管理敏捷項目和傳統項目
- SpecDD：2005年創立
由來,SpecDD概念,SpecDD優勢,需求驅動開發,整體框架,結論,
由來
企業一直在實踐中探尋更好的軟體開發方法，近些年來，敏捷開發模式在業界風生水起，SCRUM、XP、測試驅動開發等等，演化出很多方法論。關於軟體開發流程和模式的探討一直未曾停止，由方法論及實踐引發的開發過程適應性及處理複雜問題能力的矛盾也日益浮上水面，從而使得軟體開發方法的相互借鑑、融合之道成為大勢所趨。
SpecDD概念
理論思想
規範點驅動開發（Specification Driven Development, 簡稱SpecDD）是一種全新的軟體開發概念性框架，它貫穿於套用生命周期管理（Application Lifecycle Management，簡稱ALM）的各個階段，支持各種成熟開發模型，旨在幫助開發團隊提高項目質量，促進軟體項目成功。
SpecDD概念性框架用規範點（Specification，以下簡稱Spec）來表述/定義產品或版本功能，並通過中央知識庫與整個團隊有效共享，使 Spec成為貫穿ALM各階段的要素，從需求分析到項目規劃，從編碼到QA測試，驅動整個開發流程。
Spec是SpecDD概念性框架中的最小單元。通常情況下，由來自各種渠道的客戶和產品需求，結合以往積累的知識文檔，提煉出多個 Spec。它們可以是正規表達的新功能、功能增強或缺陷修復，並與對應的需求和知識相關聯。Spec是高度結構化的，其樹形結構準確地對應產品/版本功能 樹，以保證開發人員不丟失任何需求。圖2以Browser產品為例，要完成6.0版本，開發團隊需要開發“OS Support”、“Tabbed Browsing”等幾類新功能，實現“User Interface”、“AJAX”、“Application” 三類基於之前版本的功能提升，修復客戶或內部發現的一些缺陷，所有這些Spec都體現為分支上的樹葉。
用Spec完整表達軟體產品SpecDD的關鍵思想有如下體現：將來自於客戶或產品經理的需求文檔分解為結構化的“需求樹”，需求的進一步添加和修改，可以直接 體現在需求樹上；依照需求樹，由經驗豐富的技術人員將需求轉變為可量化的Spec單元，通過“Spec樹”直觀正規地表達需求和設計；在做項目規劃時，依據Spec樹、團隊安排和開發階段，進行巨觀層面的子項目分解，並將Spec樹中的Spec直接分配到相應子項目下，具體落實每個Spec的開發計畫。有 了這棵“項目樹”，Spec就能驅動產品的開發和測試了。
以知識為核心
“以知識為核心”的SpecDD：首先，知識不僅包括項目的各種文檔，也涵蓋了注釋、web連結和email等內容，使用戶對知識的使用和積累變 得更加方便快捷。通過算法對知識項目排序，也提高了知識使用的效率。另外，知識管理細化了需求管理的顆粒度，通過外掛程式從MS Office格式的需求文檔中直接check-in需求片斷，就能在需求描述頁面中查看相關的那部份內容，而不需要打開附屬檔案中的整個需求文檔。
SpecDD&敏捷開發
雖然敏捷開發在中國還處於剛剛起步階段，但近幾年來發展迅速，敏捷已經逐漸從“軟體開發”層面滲透到整個套用生命周期。概括地說，敏捷開發具有以下基本特徵：客戶提出需求列表並確定需求優先權；開發團隊按照客戶的詳細需求提交產品所需增加的模組；客戶可以在任何時間增加、刪除或修改 需求。正是由於開發過程上的敏捷，使得產品或服務能更好更快地反應客戶的需求，從“開發敏捷”最終實現“業務敏捷”。
然而，敏捷開發也存在一系列問題。例如，往往只有小型的、人員集中的團隊更願意採用敏捷方法；項目進展常常過度依賴於頻繁的面對面 溝通；溝通過程缺乏必要的知識記錄等。SpecDD很大程度上彌補了這些不足。
總結
SpecDD為敏捷團隊提供了一個實踐框架，並將敏捷功能與傳統項目管理的最佳實踐相融合作為實踐指引。
- 需求通過工件的形式表達在產品backlog上。產品backlog中的條目被消耗並轉化生成為可執行的軟體，而需求則被完整地保留下來。
- 需求與QA測試用例相關聯，在開發sprint開始前，過程中或之後，創造並完善測試用例。
- 在SpecDD中，每個開發sprint都含有兩個交付件：改進後的可執行軟體，和改進後的需求表達。
- SpecDD擁抱變更，但是需求和與之相關的變更都應該被記錄在案，以保留業務邏輯或創意在創造和完善過程中產生的智慧。
- SpecDD提供了一個可擴展的質量模型，同時確保了單個開發sprint的質量和整合後產品的整體質量。
SpecDD優勢
- 理解和掌握大型開發項目的有效管理策略和多團隊協作模型；
- 提供敏捷與其它方法整合的最佳化框架；
- 提供有效實現敏捷開發與需求&質量、需求&backlog、項目&資源、項目組合管理、QA&測試團隊的整合框架；
- 闡述開發團隊如何能用相同的辦法來管理敏捷和非敏捷項目；
- 開發工作被分解到開發空間，里程碑，和各個衝刺疊代中，同時Product backlog和需求管理是相互整合的；
- 提供明確的指導方針，以及如何實踐的做法，實現QA測試用例在疊代周期內被定義；
- QA團隊既能夠獨立工作，同時又能與回歸測試相整合；
需求驅動開發
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工作量的進展。
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團隊來執行回歸測試，使得多團隊參與的敏捷項目變得更具有擴展性。
