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