并不局限于敏捷團隊
不是只有敏捷團隊才可以從協作制定需求說明中獲益。在Bridging the Communication Gap一書中，我建議在更為傳統的結構過程中應用類似的實踐。
英國Sopra集團的高級測試顧問Matthew Steer幫助一個大型電信公司的第三方離岸軟件交付伙伴實現了這些實踐。他們意識到項目需求定義不明確后，決定作出改變。Steer比較了實施實例化需求說明前后一年的交付成本。不出意料，這些項目使用瀑布方式開發，沒能達到零缺陷的級別，但是這些改變“提高了上游缺陷的發現率，減少了下游的返工和成本”。Steer說：
我們在軟件生命周期早期發現的很多缺陷，傳統上要到晚期才能發現，這足以證明這個方法行之有效。缺陷數在生命周期的晚期有明顯的下降，而在早期則有所提升。
最后結果是，交付成本僅在2007年就節省了170萬英鎊。
減少返工
一般來講，頻繁地發布會促進快速反饋，使得開發團隊能夠更快地發現錯誤、修復錯誤。但是快速迭代并不能避免錯誤。通常情況下，團隊實現一個功能時會有三四次反復。開發人員稱，這是因為客戶在拿到產品試用前并不知道自己想要什么。我并不這么認為。使用實例化需求說明后，通常團隊第一次實現的就是客戶所要的，無需返工。這可以節省大量的時間，并使得交付流程更具可預測性、更加可靠。
位于倫敦的英國天空廣播公司（British Sky Broadcasting）的天空網絡服務（SNS）部門負責寬帶和電話的服務配置（provisioning）軟件，它的業務流程和系統集成都極為復雜。該部門由6個團隊組成，他們使用實例化需求說明已經有好幾年了。據他們的資深敏捷Java程序員Rakesh Patel說：“當我們說交付時，確實是能馬上交付的。”并且該部門在Sky公司內具有很高的聲望。Patel曾和其他公司的團隊一起工作了一段短暫的時間，他對兩個團隊做了比較，他說：
他們（其他公司的程序員）每次在迭代（sprint）快要結束的時候才把軟件交給測試人員，測試人員總是發現問題并退回給程序員。而在這里（Sky），我們不會如此反復。如果有錯誤，我們會編寫一個測試，而后在開發過程中使測試變綠——要么通過，要么不過。我們可以當場發現問題。
其他不少團隊注意到了返工的大量減少，其中包含LeanDog，它為一家美國大型保險機構開發聚合應用軟件。他們的應用軟件為很多大型主機和基于Web的服務提供統一的用戶界面，而且由于擁有來自全國各地的大量項目干系人，該軟件變得更加復雜。最初，在需求方面，該項目遭受了很多功能缺失的問題。Rob Park是LeanDog里幫助團隊轉型的敏捷教練，他說：
剛開始理清頭緒時，我們需要澄清需求，而后我們發現不得不切實做些改變。
該團隊實施了實例化需求說明，結果需求說明改善了，返工也減少了。據Park說，雖然當程序員針對某個故事卡開展工作時，有些問題還要向業務分析師咨詢，但是“問題已經大為減少，而且重復性工作少了，只剩下不同的問題”。對他來說，實例化需求說明最有價值的方面在于“當著手實現一個故事時，你可以領會它的意圖，并了解它的范圍。”
很多團隊還發現在開發周期的起始階段，使用實例化需求說明會讓需求更加精確，這樣管理產品功能清單（product backlog）會更加容易。例如，能夠盡早識別太含糊或有太多功能缺失的故事，這樣可以防止以后出現問題。如果沒有實例化需求說明，團隊經常要到迭代中期才發現問題，這會中斷流程而且需要耗費時間重新討論——在大公司，決定功能范圍的項目干系人往往無法輕易預約到。
實例化需求說明能幫助團隊建立一個協作制定需求的過程，這可以減少迭代中期的問題。此外，實例化需求說明適用于短迭代，并且不需要花費數月的時間來編寫冗長的文檔。
Ultimate軟件公司位于佛羅里達州的韋斯頓，對于它的全球智能管理（Global Talent Management）團隊來說，減少返工是一個主要的優點。協作制定需求說明在專注開發工作方面有著顯著的影響。據Ultimate軟件公司的資深測試開發工程師Scott Berger所述：
在團隊認可一個故事之前，與產品負責人一起審核測試場景可以使工作小組（產品負責人、開發人員和測試人員）澄清模棱兩可或缺失的需求。有時，會議結果甚至會把故事給撤銷了，例如，測試場景會揭露出系統隱藏的復雜性或相互矛盾的需求。有一次，進行這樣的討論之后，大家做出的決定是幾乎重新設計整個功能！產品負責人獲得了重寫和重新分割需求的機會，而不是在開發進行之后，中途停止或取消該故事。通過舉行這些會議，我們發現自己的生產力和效率都提高了，因為減少了浪費，而且模糊和需求缺失的程度降到了最低。同時還讓團隊對預期達成了共識。
大多數團隊顯著地減少或完全消除了由于誤解需求或忽視客戶的期望而造成的返工。本文所描述的實踐，可以讓團隊更好地與商業用戶打交道，并確保大家對結果達成共識。 在互聯網時代，交付速度是當今軟件開發的主題。十年前，項目通常要持續好幾年，并且項目階段是以月來衡量的。如今，多數團隊的項目周期是按月來衡量的，而項目階段則減少到幾周甚至幾天。任何需要長遠規劃的東西都將被拋棄，比如大量的前期軟件設計和詳細的需求分析。超過項目階段平均周期的任務將不復存在。跟代碼凍結（Code Freeze）以及數周的手動回歸測試說再見吧！
變化頻率如此之高，文檔很快就會過時。不斷更新詳細需求說明和測試計劃（Test Plan）需要投入大量精力，相當浪費。那些以往在日常工作中依賴于此的人們，如業務分析師或者測試人員，在這個每周迭代的新環境中經常會無所適從。開發人員原本以為不會受到紙質文檔缺失的影響，現在卻要把時間浪費在不必要的返工與功能維護上。他們不是花時間去制訂宏偉的計劃，而是要浪費數周的時間去修正有問題的產品。
在過去的十年里，軟件開發社區致力于使用“正確”的方式來構建軟件，關注使用技術實踐和思想來確保質量。但是，正確地構建產品和構建正確的產品是兩碼事。我們要二者兼顧才能取得成功。
圖1-1
圖1-1 實例化需求說明可以幫助團隊構建正確的軟件產品，而技術實踐 可以確保正確地構建產品
想要有效地構建正確的產品，軟件開發實踐必須滿足以下幾點。
● 保證所有項目干系人和交付團隊的成員都對需要交付哪些東西有一致的理解。
● 有準確的需求說明，這樣交付團隊才能避免由模棱兩可和功能缺失造成的無謂返工。
● 有用來衡量某項工作是否已經完成的客觀標準。
● 具有引導軟件功能或團隊結構變更的文檔。
傳統意義上，構建正確的產品需要龐大的功能需求說明、文檔以及漫長的測試階段。如今，軟件每周都要有交付，這一套已經行不通了。我們尋求的方案要能帶來如下好處。
避免過度說明需求從而產生浪費，避免花時間在開發前會發生改變的細節上。
有一種可靠的文檔，可以解釋系統的行為，據此我們能容易修改系統行為。
可以有效地檢查系統行為與需求說明的描述是否一致。
以最少的維護成本維持文檔的相關性與可靠性。
適合短迭代和基于流的過程，這樣能為即將開展的工作提供即時足夠的信息。
圖1-2 對于敏捷項目，構建正確文檔的關鍵因素
乍一看，這些目標似乎互相沖突，但有很多團隊已經成功地達成了所有目標。在做調研時，我采訪了30個團隊，他們完成了大約50個項目。我試圖找出一些模式與通用做法，并挖掘出這些方式背后的基本原則。這些項目的共同思想，定義了一種構建正確軟件的好方法：實例化需求說明。
實例化需求說明是一組過程模式，它幫助團隊構建正確的軟件產品。使用實例化需求說明，團隊編寫的文檔數量恰到好處，在短迭代或基于流的開發中可以有效地協助變更。
實例化需求說明的關鍵過程模式將在下一章介紹。本章我將闡述實例化需求說明的好處。我將使用實例化需求說明的風格來進行闡述，而不是以理論介紹的方式來構建一個案例，我將展示18個真實的例子，它們都來自于那些大大受益于實例化需求說明的團隊。
在開始之前，我想強調一下，在一個項目中很難孤立地看待某種思想的影響或作用。本文所描述的實踐，可以與已經開展的敏捷軟件開發實踐[例如測試驅動開發（TDD）、持續集成以及使用用戶故事做計劃等]共同使用，而且可以增強其他實踐的效用。當我們轉而去看那些有著不同背景的項目時，很多模式浮現了出來。我采訪的團隊中，有些在實施實例化需求說明前一直使用敏捷過程，而有些團隊則是在過渡到敏捷過程的過程中實施了實例化需求說明。大多數團隊使用基于迭代的過程，例如Scrum和極限編程，或者是基于流的過程，例如看板。但是有些團隊，盡管他們使用了這些實踐，但他們的過程以任何標準來看都不是敏捷的過程。然而，他們大多都收獲了如下類似的收益。
更有效地實施變更。他們擁有活文檔——系統功能的可靠信息來源——讓他們得以分析潛在變更的影響，同時可以有效地分享知識。
更高的產品質量。他們清晰地定義了預期，使得驗證過程很有效率。
更少的返工。他們在需求說明上協作得更好，并確保所有團隊成員對預期達成共識。
同一項目不同角色的活動協調得更好。改善協作形成定期的交付流程。
在接下來的4個小節中，我們將通過現實世界的例子，近距離地審視這些收益。
更有效地實施變更
在做調研的過程中，我獲得的最重要的經驗是關于活文檔（living documentation）的長期收益的——事實上，我認為這是一個最重要信息，本文廣泛地涵蓋了這部分內容。活文檔是系統功能的一個信息源，它與程序代碼一樣可靠，但更容易使用和理解。活文檔幫助團隊共同分析變更所帶來的影響并討論潛在的方案。團隊還可以為新的需求擴展已有的文檔。長此以往，可以使需求說明和實施變更更有效。大多數成功的團隊都發現活文檔的長期收益是實施實例化需求說明所帶來的結果。
總部設在美國西得梅因市的愛荷華州助學貸款流動資產管理公司（Iowa Student Loan Liquidity Corporation，下文簡稱Iowa Student Loan），在2009年進行了一項相當重要的商業模式變更。過去一年，金融市場動蕩使得貸款方幾乎無法為私人學生貸款找到資金來源，因此，許多貸款方被迫放棄私人學生貸款市場或改變自己的商業模式。該公司適應了當時的市場。它從銀行和其他金融機構募集資金來支助私人助學貸款，而不是使用債券收益。
Tim Andersen是一位軟件分析師，同時也是一名開發人員，他說為了有效地適應市場，他們不得不“有聲有色地進行系統核心大檢修”。在開發軟件時，他們的團隊把活文檔作為一項主要機制來編寫業務需求文檔。活文檔系統讓他們可以探悉新需求所帶來的影響、幫助他們確定所需的變更，而且可以確保系統的其余部分仍舊正常工作。他們當時只花了一個月時間就對系統實施了根本性的變更并將其發布到了生產環境，活文檔系統是做這項變更的根本。Andersen說：
| 任何未進行這些測試（活文檔）的系統，都必將導致開發停頓和重寫。 |
在加拿大魁北克省的蒙特利爾市，Pyxis技術公司的Talia項目團隊也有類似的經驗。Talia是企業系統的一個虛擬助理，它是一個擁有復雜規則、能與員工交流的聊天機器人。從最初開始，Talia團隊就使用實例化需求說明來構建一個活文檔系統。一年之后，他們不得不從頭開始編寫虛擬代理引擎的核心——而此時，正是在活文檔方面的投資大顯成效的時候。Talia的產品總監Andre? Brissette是這樣說的：
他們的活文檔系統使得團隊在變更完成時可以自信地說，新系統具有和老系統一樣的功能。該活文檔系統還能幫助Brissette管理并追蹤項目的進度。
總部位于倫敦的現場音樂消費性網站Songkick的團隊在重新開發網站活動摘要時，使用了一個活文檔系統來協助變更。他們意識到目前的摘要系統無法擴展到所需的容量，活文檔在重新構建摘要系統時就提供了有力的支持。Phil Cownas是Songkick的CTO，據他估計，因為擁有了活文檔系統，他們的團隊在實施變更時節省了至少50％的時間。據Cowans所述：
| 因為我們擁有讓人滿意的覆蓋率，并且我們確實信任這些（在活文檔系統里的）測試，所以我們很有信心可以快速地對基礎結構進行大的變更。我們知道，系統功能不會改變，即使變了，測試也會發現。 |
ePlan Services是一個養老金服務機構，位于科羅拉多州的丹佛市，它的開發團隊從2003年開始就已經使用了實例化需求說明。他們構建并維護一個金融服務系統，該系統涉及眾多的項目干系人、復雜的業務邏輯以及復雜的監管需求。在項目開始三年之后，其中一位經理搬去了印度，而對于系統遺留部分，有些內容是只有他才掌握的。根據ePlan Services的測試人員及Agile Testing: A Practical Guide for Testers and Teams一書作者Lisa Crispin的描述，當時，團隊努力地學習那位經理所擁有的知識并將其構建成活文檔。活文檔系統幫助他們獲得了業務流程的專業知識，并立即提供給所有的團隊成員。他們借此消除了知識傳遞的瓶頸，可以有效地支持并擴展系統。
在比利時Oostkamp的IHC集團，病人管理中心項目組實施了一個活文檔系統，并取得了類似的結果。該項目開始時重寫了一個大型機系統，它是從2000年開始的，目前還在進行中。Pascal Mestdach是該項目的方案架構師，他說團隊從中受益匪淺：
| 當時遺留系統中的一部分功能只有少數幾個人了解，而現在情況已經好很多了，那是因為團隊擁有一套針對那部分功能的、不停增長的測試套件（活文檔），它描述了該遺留系統的功能。當專家休假時，還可以從活文檔系統中尋找問題的答案。對其他開發人員來說，可以更清晰地了解軟件中某部分的功能。并且還是測試過的。 |
這些例子闡述了活文檔系統如何幫助交付團隊分享知識并應付人員變動。它還使得業務可以更有效地響應市場變化。我將在第3章里對此做更具體的說明。
更高的產品質量
實例化需求說明可以改善交付團隊成員之間的協作，促進商業用戶更好地參與，并為交付提供清晰客觀的目標——大幅提高產品質量。
有兩個突出的案例，分別來自Wes Williams[來自世博控股（Sabre Holdings）的敏捷教練]以及Andrew Jackman[為法國巴黎銀行（BNP Paribas）的一個項目工作的顧問開發人員]，他們將描述之前失敗過多次的項目如何通過實例化需求說明走向成功。本文中描述的方法幫助他們的團隊克服了業務領域的復雜性，之前這種復雜性是很難處理的。同時還幫助他們確保了交付的高質量。
在世博控股，Wes Williams工作的項目是一個為期兩年的航班訂票項目，團隊分布在全球各地，流程又是數據驅動的，這使得項目十分復雜。項目有3個團隊，30名開發人員，分布于兩個洲。據Williams說，系統頭兩次構建都失敗了，但是第三次使用實例化需求說明后就成功了。Williams說：
| 我們在一家大客戶（一家大型航空公司）上線時缺陷非常少，在（業務驗收）測試階段只有1個缺陷是比較嚴重的，是故障切換（fail-over）相關的問題。 |
Williams認為實例化需求說明是他們取得成功的一個關鍵因素。除了保證高質量外，實例化需求說明還有助于建立開發人員和測試人員之間的信任。
在法國巴黎銀行，Sierra項目是另一個很好的例子，可以展現實例化需求說明如何帶來高質量的產品。Sierra是一個債券的數據倉庫，整合了一些內部系統、評級機構和其他來自外部的信息，并將它們分發給銀行內部的各種系統。許多系統和組織使用相同的術語，表達的意思卻不盡相同，這導致了許多誤解。最初兩次實現系統的嘗試都失敗了，據Channing Walton說，團隊中的一個開發人員促使了第三次嘗試的成功。第三次努力的成功部分歸功于實例化需求說明幫助團隊處理了復雜性問題，并且確保了團隊的共識。最終的產品質量令人印象深刻。項目從2005年上線以來一直在運行，Sierra項目的顧問開發人員Andrew Jackman說：“生產環境中沒有出現大的問題。”現在Sierra項目中的大多數工作人員都不是項目啟動時的那些人，但是質量水平一直都很高。
Bekk咨詢公司在為一家大型法國銀行支行開發租車系統時也取得了類似的成果。Aslak Helles?y曾是那個團隊的成員，還是Cucumber——一個支持實例化需求說明的熱門自動化工具的創造者，據他說，盡管現在維護這個軟件的是一個全新的團隊，但他們在系統上線后的兩年中卻只發現了5個缺陷。
Lance Walton曾在一家大型瑞士銀行倫敦分行的一個項目中擔任過程顧問，這個項目是要開發一個訂單管理系統，開始的幾次也都失敗了。Walton進入這個項目時，大家都認為實現這個系統需要至少和開發團隊一樣大的支持團隊。他的團隊使用了實例化需求說明，項目開始9個月后就交付了生產系統，一天內就通過了業務驗收測試，之后6個月內沒有發現任何缺陷。Walton說新的系統不需要額外的支持人員，成本比預期要低，而且團隊更早地交付了成品。相比之下，他們旁邊的團隊需要10倍于開發團隊的支持人員。Walton指出：
| 現在團隊依然每周發布一次，用戶總是對它非常滿意。從質量上看，它棒極了。 |
實例化需求說明的技術不僅僅適合于新建項目，同時也適用于改建項目。建立起值得信賴的文檔、清理遺留的系統，都需要一定的時間，但是團隊很快就能看到諸多的好處，并對新的交付充滿信心。
還有一個不錯的例子是倫敦摩根大通的外匯交易系統。Martin Jackson是該項目的自動化測試顧問，他說業務分析員預計項目會推遲，然而事實上，項目提前兩個星期就交付了。高質量的產品讓他們成功地在一個星期內完成了業務驗收測試階段，而不是原先計劃的4個星期。Jackson說：
| 我們部署好系統后，系統工作正常。業務人員向董事會報告說這是他們經歷過的最好的用戶驗收測試（UAT）。 |
實例化需求說明還使Jackson的團隊在項目開發晚期快速實現了“一次重大的技術改動”，提高了計算的精確度。Jackson稱：
| FitNesse套件（活文檔）覆蓋的所有功能，通過了完整的系統測試和用戶驗收測試，在生產環境上線時也沒有發現任何缺陷。系統測試時發現了幾個核心計算組件以外的錯誤。業務人員之所以覺得用戶驗收測試非常好，是因為出現計算錯誤時，我們都非常確定根本問題是在計算代碼的上游。使用了FitNesse后，很容易診斷出缺陷的根源，從而可以更加利落快速地交付到生產環境中。 |
科羅拉多州丹佛市的惠好公司有個軟件開發團隊，他們編寫并維護一些工程應用和木制框架的計算引擎。在使用實例化需求說明以前，結構工程師通常不會參與到軟件開發過程中，即使團隊正在處理一些復雜的科學計算公式和規則。這導致了一些質量問題和延誤，由于使用這個引擎的應用程序有好幾個，計算過程變得更加復雜。項目的軟件質量保證主管Pierre Veragen認為發布前的艱難時期會拖累項目，版本發布出去后很少會沒問題。
實施實例化需求說明后，團隊現在和結構工程師合作制定需求說明，并自動化驗證結果。當有變更需求進來時，測試人員和結構工程師一起得出期望的計算結果，并在開發開始前用實例把結果記錄在需求說明中。之后批準變更的工程師會編寫需求說明和測試。
Veragen說新方法的主要好處是他們在做改動時有信心了。到2010年初，他們的活文檔系統中已經有超過30 000個檢查，而且幾年內都沒有發現大的缺陷，現在已經停止追蹤缺陷了。Veragen指出：
| 我們不需要（缺陷數）這個指標了，因為我們知道它不會再回來了……工程師們喜歡測試先行的方式，并且能直接訪問自動化測試。 |
Lance Walton參與過一家大型法國銀行倫敦分行的信用風險管理程序的開發。項目剛開始的時候，有外來的顧問幫助團隊采用極限編程的實踐，但是他們沒有采用任何實例化需求說明的做法（雖然極限編程包括客戶測試，這個與可執行的需求說明很接近）。6個月后，Walton加入了這個項目，他發現代碼質量很低。雖然團隊每兩個星期都會有交付，但是寫出來的代碼使驗證變得很復雜。開發人員只測試最近實現的功能，隨著系統的增長，這樣的做法就不夠了。“當有版本發布時，大家都緊張地圍坐著，想確保所有功能都能正常運行，并且期望可以在幾個小時內發現一些問題。”Walton如此說。在實施實例化需求說明后，產品的質量和人員的信心都有了顯著的提高。他補充道：
我們十分確信我們發布的版本沒有問題。我們高興地部署完以后就出去享受午餐了，不用再擔心是否會出問題。
與此形成鮮明對比的是，英國貿易者傳媒（Trader Media）集團的網站重寫項目停止使用實例化需求說明后，卻遭遇了質量問題。起初團隊協作完成需求說明和自動化驗證。在管理層的壓力下，他們為了更早更快地交付更多的功能而沒有繼續下去。測試團隊的主管Stuart Taylor說：“我們注意到質量出現了大幅下滑……以前我們（測試人員）很難找到缺陷，而后來我們卻發現一個用戶故事會有四五個缺陷。”