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