本書已獲2012年Jolt大獎圖書
Gojko Adzic是《執行個體化需求》（Specification by Example）一書的作者， 在該書中他給出了一些建議和原則，幫助大家在軟體開發項目中采用執行個體化需求去建立活文檔。執行個體化需求是一組方法，它以一種對開發團隊有所幫助的方式（理想情況下表現為可執行的測試）描述計算機系統的功能和行為，讓不懂技術的利益相關者也可以了解，即使客戶的需求在不斷變化，它也具有很好的可維護性，可以保持需求的相關性。
執行個體化需求：團隊如何傳遞正确的軟體（靈活開發新經典文獻2012年Jolt大獎圖書）
該書擁有衆多的例子和建議，其中的50多個案例分析驗證了不同的團隊群組織通過采用該方法取得了不同程度的成功。作者并沒有掩飾在引進該方法時所面臨的挑戰，通過分析那些失敗案例所具有的模式和範例，給出了一些避免失敗的建議。
作者不僅通過案例分析和舉例辨識出團隊在引進執行個體化需求時可能面臨的一些常見挑戰和問題，而且還提供了具體的建議用于解決這些問題。
盡管該書中所舉的大部分例子和案例分析，涉及的是一些采用靈活開發的團隊群組織，但是作者也指出了一個重要觀點，這些方法并非局限或依賴于靈活方法。
該書講到了測試自動化的價值，并給出了實作自動化方面的建議，但是作者沒有深入探究一些可用的工具及其如何配置它們。不過配套的網站提供了一些資源，包括書籍、開源和商業軟體的連結、一些文章的連結、視訊教程以及示範文稿.
在Adzic自己的網站上，他介紹了該書的幾個主要思想：
執行個體化需求是一組過程模式，可以協助軟體産品的變更，確定有效地傳遞正确的産品。 這裡所說的正确産品，指的是該軟體能滿足客戶或企業使用者提出的商業需求，或者能達成預定的商業目标；同時它要具備一定的靈活性，未來能以相對平穩的投入接受後續改進。
他描述了該過程的多個步驟用以獲得需求，并将其轉化成一份“活文檔“：
從目标中擷取範圍
用執行個體進行描述
精煉需求說明
自動化驗證，無須改變需求說明
頻繁驗證
演進出一個文檔系統
Gojko說：
自動化的執行個體化需求，如果仍以自然語言表達，并且團隊的所有成員都可以輕易擷取到，那這實際上就形成了一份可執行的需求說明。
“活文檔”是執行個體化需求的最終産物。為了建立起活文檔系統，很多團隊最終都為需求說明和測試設計了一門領域相關的語言。
出版商為InfoQ的讀者制作了一個示例章節，可以在這裡找到。
作者還在amazon.com和amazon.co.uk上進行“A-B測試”的對比，并為協助測試者提供一份海報。
最近InfoQ的Shane Hastie通路了該書的作者：
InfoQ：請你簡單介紹一下你自己，還有是什麼啟發了你寫《執行個體化需求》呢？
Gojko：我是一個顧問，主要與緻力于提高軟體品質和以疊代為傳遞模式的團隊合作。過去的5、6年時間裡，我一直在關注靈活驗收測試和行為驅動開發上，而執行個體化需求是一個很自然的延續。有兩點啟發了我寫這本新書。其中一個是Tom Gilb在2009靈活測試日演講時宣傳靈活并不實用，而且沒有資料能證明靈活如大多數描寫和示範它的人說得那樣好。另外一個是一篇2009年在InfoQ上發表的文章，其中問到是否真有人在靈活過程中實作了自動化驗收測試，還是說該想法隻是一個理論上的提議。在那時，我已經目睹過該過程在一些環境下獲得了很大的成功，我無法了解這些針對靈活的懷疑和否定，是以我決定開始收集真實的故事，而不是自我感覺，用以展示給大家确實有人，而且是很多人，已經通過實踐該過程從中獲得了很大的益處。
InfoQ：編寫這本書的目的是為了解決哪些問題？
Gojko：在軟體開發社群中，人們對于執行個體化需求、驗收測試驅動開發以及行為驅動開發，确實有不少誤解。五年前，我在各種會議中遇見的很多人都從沒聽說過這些概念。現在大部分我見過的人都聽說過它們， 但還是隻有極少數人在他們的過程中成功地實施了這些想法。大多數的失敗主要是由于那些常見誤解造成的。在本書中，我介紹了那些成功團隊在他們的過程中實施成功的7個關鍵模式，還有很多從50個不同背景的項目經驗中擷取的竅門和應該避免的注意點。我希望這些知識能夠幫助問題團隊找出他們自己的典型障礙，排除他們，并提高他們的傳遞過程。
InfoQ：在該書中，很多經常提到的概念和想法就是大家所說的驗收測試驅動開發（ATDD）或者行為驅動開發（BDD），為什麼你要提出新的術語執行個體化需求，而不是使用它們兩個？
Gojko：這個術語的負面看法最少。在編寫本書的時候，我遇到的一個很大的問題就是如何将來自不同團隊的知識以一個統一的概念展現給大家，同時我也意識到作為一個社群我們在這整件事情上采用了完全錯誤的言詞。我們使用技術術語為其命名，卻造成了商業使用者的困惑，以至于很多想讓他們參與進來的想法都失敗了。而且我們在命名各種軟體過程的工件時也很少會有一緻性，這造成了更多的困惑。由此我決定這本書的目标就是要推廣一套術語，幫助人們在腦袋裡建立起正确的心理圖像，讓團隊可以避免那些常見的陷阱和誤解。一個主要的問題是在整個開發過程中，團隊過分側重于測試的方面，将整件事情了解成隻是一個測試活動。這就是為什麼我不想使用ATDD的原因。而BDD則是一個還沒有精确定義的方法論。取決于你讨論的對象，它可能包括也可能不包括基于拉動式的工作模式，從外到内的設計之類的事情。使用執行個體作為功能的需求說明，并基于那些執行個體進行自動化測試是BDD的核心支柱，但是它可能不止這些。我們很可能要等Dan North寫一本關于BDD的書去将其明确說明。我希望這本書就是一組具體的實踐方法，可以運用在不同的方法論中，就像我曾通路過的那些使用XP、Scrum、Kanban及其他方法的團隊。
InfoQ：這本書的目标群體是誰呢？
Gojko：所有想傳遞高品質軟體的人。我努力讓這本書變的與技術無關，并能讓多種不同角色的人員都可以了解，高品質的過程和産品源于整體觀和協作：沒有單一群體能夠獨自将其傳遞。産品經理、業務分析員、測試人員、開發人員以及項目經理都能夠平等地從中獲益。
InfoQ：你很明确地指出你不會深入到任何一款特定工具的細節中，但是顯然，想要有效地将你的想法付諸實踐，就需要對相關工具有一個全面的了解。你能給讀者一些在工具使用上的建議嗎？
Gojko: 工具自動化過程，他們能讓過程走得更快。如果你的過程有問題，自動化隻會讓問題更加突出。我曾錯誤得認為一個工具可以盡早将問題解決，結果卻遭到了慘痛的失敗。當我意識到團隊協作是我們過去所忽略的時，這一想法促使了我開始編寫我的第一本書。很多我為編寫《執行個體化需求》采訪過的團隊也犯過同樣的錯誤，而這也确實是我在各種 會議中參與讨論時大家提到的一個常見問題。我給讀者的建議是首先要完善過程，然後将其自動化以使其運作得更平穩。一旦擁有了良好的過程，一個好的工具将會使其發揮最大的作用。
InfoQ：你使用“活文檔”的概念來描述執行個體化需求的産物，這個概念同傳統的文檔或使用者故事卡等輕量級的靈活文檔有什麼差別呢？
Gojko：故事卡本意并不會長期儲存。在做短期的優先級排列和計劃時它們非常有用。但是當一個故事完成六個月後，如果你需要了解系統時，這些卡片卻不會有太大的幫助。而傳統的文檔又很容易過期。把程式源代碼當作唯一可靠的資源用以了解系統的功能，會導緻資訊瓶頸和黑洞，從長期來看，這正是編寫良好的執行個體化需求的作用。由于這些需求的驗證通過驗收測試自動化了，并經常被執行，是以我們可以相信系統的行為符合這些測試所指定的功能。或者從另外一個角度來講，這些文檔實時追蹤着系統的功能。一個編寫良好的執行個體化需求，應該簡單易懂，并容易擷取，可以幫助我們消除那些資訊瓶頸。
我曾工作過的許多大公司，因為沒有一個可靠的文檔系統，不僅讓軟體傳遞團隊面臨着很大的問題，而且更重要的是它在商業上也會造成很大程度的損失。通過建立和維護一份可靠和可維護的業務流程文檔，活文檔可以為IT團隊帶來額外的商業價值。
InfoQ：你對于那些想要實施這種方法的團隊有什麼建議嗎，為了確定他們已經準備好去做這些改變，他們要做些什麼呢？
Gojko：所有的事情都是有前後關系的。每個團隊都需要知道他們的問題是什麼，然後利用書上的想法作為啟發來解決這些問題。一個好的對策就是讓整個團隊能夠對他們在傳遞高品質産品所面臨的首要問題上達到一緻，并緻力去解決它，然後接着解決下一個問題。這是個非常有效的改進政策，因為它提出了一個共同的目标，可以減少抵制心理，并給管理層提供了一個令人信服的理由去支援改變（因為團隊正在解決他們的首要問題）。
InfoQ：為了采用這種方法，團隊群組織需要做出的最大改變是什麼？
Gojko：再強調下，這是有前後關系的。通常情況下最大的改變就是文化，從塗鴉牆上什麼任務應該要抛棄掉、什麼責任需要被轉移的傳統方式轉變到一個更具協作性和整體性的軟體傳遞方式上。執行個體化需求需要團隊不同角色間緊密的合作，并共同支援團隊向一個更為協作的環境轉變。
InfoQ：你見過的最常見的錯誤是什麼，團隊應該怎樣去避免他們呢？
Gojko：把精力放在一個特定工具上是很多人都會犯的一個嚴重錯誤，因為這并不會提高協作能力，反而會造成更多的問題。還有一個常見的問題就是實施這一過程時單純從測試角度去考慮問題，工件變成了過度飽和的資料和測試用例的組合爆炸，這讓執行個體化需求失去了作為溝通工具的作用。第三個常見的問題就是需求說明的錯誤設計，利用技術語言或腳本去描述某個功能是怎麼被測試的，而不是去描述系統應該怎麼工作。
這會造成後期維護的困難。
為了避免這些問題，團隊必須專注于價值、協作和改進溝通，發展出一套通用的語言，并在所有工件中使用一緻。
InfoQ：你能給團隊什麼建議來幫助他們維持這種改變，并保持活文檔的“活性”呢？
Gojko：團隊應該意識到随着知識領域的發展和商業機會的改變，項目語言也會随着時間的推移而演進。這會影響執行個體化需求以及活文檔系統組織和解釋事情的方式。為了獲得長期的受益，團隊必須保持活文檔系統的一緻性。這是一個更為廣泛的話題，包括領域驅動設計、統一語言以及如何一緻地使用它去支援對稱的改變：一個業務功能上的小改動将通過軟體和文檔中的小變動來展現。如果我們讓這些模式慢慢分開，那麼軟體很快就會變為古董，到了某一時刻，很多人就會放棄更改而決定重寫。但是如果這些模式能夠協調一緻，我們完全可以避免這種遺留陷阱。是以，活文檔系統的确可以更早地提醒我們這類問題，我認為團隊應該要明白保持文檔活性的同時可以確定相關軟體的活性。
InfoQ：那些采用執行個體化需求的團隊群組織是如何從中受益的呢？
Gojko：大體上可分為四種好處：更高的産品品質、疊代時團隊在分析/開發/測試等活動上可以保持更好的一緻性、 更有效地實作變更、大幅降低返工。這些都意味着可以更快地推向市場，并具備更好的品質。比如說：有一個團隊盡管每兩個禮拜釋出一次，但産品多年來都沒出現嚴重的缺陷；有一個團隊成功地改進了一個可怕的遺留系統，他們停用了缺陷跟蹤系統；某個團隊将産品推向市場的時間從6個月降到平均4天。重要的是這個過程并不是一件錯綜複雜的事情，也不是什麼黑色藝術，它是完全可以達到的，隻要大家付出努力，并通過正确的方式去實踐，它的成功就是可以複制的。
Blogger Craig Smith是這本書的早期評論者，他在部落格中寫道：
總體上來說，任何團隊（尤其是靈活團隊），隻要他們嘗試去平衡或尋找一種适當的關于需求和測試的方法，那麼他們就應該閱讀這本書。針對在靈活團隊中如何處理測試和需求的問題，它很好地平衡了各種模式，提供了真實的案例學習。在我必讀的圖書清單中，該書位于測試類書籍的前5名，靈活類的前10名。現在我終于明白如何正确命名内嵌在高速公路上的貓眼了！
他從書中提取了如下要點：
以下是我從書中總結的要點：
- 這是人的問題，而不是技術問題。
- 正确地建構一個産品和建構一個正确的産品是兩件完全不同的事情，我們要確定他們都成功。
- 活文檔，從根本上來講，如同程式源代碼一樣，是關于系統功能的另一個可靠的資訊源，隻是更容易被擷取，更容易被了解。
- 讓産品待辦事項更容易地管理。
- 隻有當團隊已經準備好實作某事項時才開始着手執行個體化需求，比如疊代開始的時候。
- 從目标擷取範圍，交流商業意圖，然後團隊提出解決方案。
- 冗長的描述會過度地限制系統，與其描述什麼是必須要做的，不如描述為什麼需要去做什麼。
- 傳統的驗證方式有這樣的問題：如果我們在業務需求和技術自動化之間轉化時丢失了某些資訊，那麼我們就冒着引入問題的危險。
- 自動化的執行個體化需求，如果仍然用可被人們讀懂的方式去描述，而且整個團隊的成員都很容易擷取到，那麼它實際上就變成了并可執行的需求。
- 測試就是需求，需求就是測試。
- 将活文檔視為服務不同客戶和利益相關者的獨立産品。
- 使用執行個體化需求後，可能會發現不再需要使用者驗收測試了。
- 改變過程時，将執行個體化需求作為文化變革的一部分推出，關注品質的提高，從自動化功能測試開始，引進新的工具，使用TDD作為階梯。
- 改變文化，要避免靈活術語，得到管理層的支援，執行個體化需求是一種更好地執行使用者驗收測試的方法，不要将自動化作為最終目标；不要關注于特定工具；留一個人遷移曆史遺留腳本（稱之為“蝙蝠俠”）；跟蹤誰在和誰不在運作自動化測試；聘用有經驗的人；引進顧問；推行教育訓練。
- 實行簽收制和可追溯制，将需求說明放入版本控制系統中，擷取活文檔的簽收，擷取項目範圍的簽收而不是具體需求的簽收，擷取精簡用例的簽收，引入用例實作。
- 警告信号有：頻繁改動的測試、退回返工、測試延誤、以防萬一的代碼以及霰彈式修改（即到處修改）。
- F16戰機，原先的需求是高速，但真正的問題是要能在戰鬥中逃避敵人的戰機，30多年後它還是非常成功。
- 範圍隐含着解決方案，制定出目标，并進行協作，确定出與目标一緻的項目範圍。
- 人們告訴你他們認為他們想要的，但是通過詢問他們為什麼想要，可以确定出新的真正的需求。
- 要了解為什麼有的東西是需求的、什麼人需要，是提出解決方案的關鍵點。
- 讨論，劃分優先級和評估目标等級，可以更好地了解需求，減少所需的精力。
- 從外到内的設計模式，先從系統的輸出結果開始，調查為什麼需要它們，以及軟體如何提供這些功能（來自BDD）。
- 另外一個方法就是讓程式員去編寫故事卡的“我需要……”的部分。
- 如果你對範圍沒有控制權，就去詢問為什麼某些東西是有用的，詢問另外一種解決方案，不要隻關注最低那一層的需求，傳遞完整的功能。
- 團隊協作是非常有價值的，可以嘗試進行整個大團隊的工作坊，也可以嘗試更小的工作坊（三個人），開發人員和業務分析師結對進行測試，開發人員稽核測試，使用非正式的對話進行協作。
- 業務分析人員是傳遞團隊的一部分，而不是客戶代表。
- 當你拿起一張使用者故事卡，說到“我不是很确定”時，就說明詳細程度十分恰當，而這會促使你與業務人員進行一次交流。
- 團隊協作，進行具有引導性的會議，讓利益相關者參與進來，提前準備，程式員和測試人員一起審查使用者故事，隻準備基本的例子，廣泛地進行障礙性讨論。
- 檢查需求是否完整的一個最好的辦法就是設計一個與之相對應的黑盒測試用例。如果我們沒有足夠的資訊去設計一個好的測試用例，那麼我們絕對沒有足夠的資訊去開發一個系統。
- 功能子產品的例子必須具有精确性（不是簡單的是或否的答案，使用具體的例子）、真實性（使用真實資料，從客戶那兒擷取真實的例子）、完整性（使用不同的資料組合去試驗，利用其他方式去檢驗和測試），并易于了解（不用試驗所有組合，尋找隐含的概念你）。
- 無論什麼時候如果發現需求中有太多執行個體或執行個體太複雜，就要努力将其複雜度降低，描述簡單化。
- 應該闡明非功能性需求，擷取精确的性能需求，在使用者界面設計上使用簡單原型，使用QUPER模型（譯者注：一種确定非功能性需求的方法），讨論時使用檢查清單，對于那些難以量化的事項（比如要有趣味性），可以建立參考的例子用來說明。
- 好的需求說明，應該是精确的、可測試的，不應該用腳本去編寫，也不應該寫成流程描述的樣子。
- 對系統應該如何工作的描述應予以避免，要關注于思考系統應該做什麼。
- 需求說明應該與軟體設計無關，不應與代碼聯系太緊，應避開技術難題，不要深陷在使用者界面細節裡。
- 需求說明應該具有自我解釋性，具有描述性标題，對目标的描述要簡短，能被他人了解，不要過度定義，從基本開始然後擴充。
- 需求說明要集中，使用“given—when—then”模式，不要特意細節化所有的依賴，可在技術層使用預設值，但不要依賴它們。
- 定義和使用一門統一語言。
- 從自動化開始，使用小的試驗項目，事先計劃好，不要推遲或者委派，避免自動化現有的手動腳本，從UI測試中擷取信任。
- 管理自動化測試，不要将其定位成用以描述驗證的二等代碼。不要複制業務邏輯，根據系統邊界進行自動化，不要用UI層去驗證業務邏輯。
- 自動化使用者界面，定義更高層次的互動（例如“登入功能”，而不要定義成“填寫登入頁面”），與UI需求一同驗證UI功能，避免錄制和回放，在資料庫中建立上下文。
- 測試資料的管理，應避免使用預先生成的資料，使用預先制定的參考資料，從資料庫擷取原型。
- Bott’s Dott’s（譯者注：凸起的，會反光的路面标記）是一種車道标志，在人們越線時給以警示。持續內建在軟體開發中有同樣的作用，在持續內建中運作執行個體化需求，我們就會擁有持續的驗證。
- 降低不可靠性，找到最困擾的問題并将其修複，确認不穩定的測試，建立專門的驗證環境，完成自動部署，對于外部系統使用測試替身（test
double），實作多級驗證，在事務中執行測試，對參考資料進行快速驗證，等待事件而非消耗時間，将異步執行設定為可選項，不要把需求說明當成是端到端的驗證。
- 為了更快地擷取回饋，可以引入業務時間，将長時間測試拆分成小的子產品，避免使用記憶體資料庫做測試，區分快測試和慢測試，保持過夜測試的穩定，建立一個目前疊代包，平行地執行測試。
- 管理失敗的測試，有的時候你無法修正所有的測試，這時可以建立一個回歸的失敗包，自動檢查屏蔽的測試。
- 要讓文檔容易了解，應避免過長的需求說明，避免使用多個較小的需求說明去描述單一功能，尋求更高層的概念，避免技術上的自動化概念。
- 文檔要一緻，演進出一門統一語言，使用虛構人物，在制定語言時進行協作，記錄建構單元。
- 改善文檔的組織方式，便于通路，可以使用使用者故事、功能區域、UI互動路徑、業務流程，使用标簽而不要使用URLs。
關于作者
Gojko Adzic是戰略軟體傳遞顧問，他與多個具有上進心的團隊合作，幫助他們改進軟體産品和過程的品質。他專注于實施靈活和精益的品質提高，尤其擅長靈活測試、執行個體化需求和行為驅動開發。Gojko經常在重要的軟體開發和測試會議上發言，并營運着英國的靈活測試使用者小組。最近這11年來，他一直在财務和能源交易平台、移動定位、電子商務、線上遊戲和複雜配置管理系統等行業項目中，從事程式員、架構師、技術指導和顧問等工作。
他是如下書籍的作者：《Specification by Example》，《Bridging the Communication Gap》，《Test Driven.Net Development with FitNesse》和《The Secret Ninja Cucumber Scrolls》。
檢視英文原文：Interview and Book Review: Specification by Example
本文選自：InfoQ 作者 Shane Hastie 譯者 陳菲 釋出于 2011年12月13日
可在當當網進行購買，連結為：