實例化需求-圖靈社區(qū)

精選優(yōu)質(zhì)文檔-----傾情為你奉上精選優(yōu)質(zhì)文檔-----傾情為你奉上專心---專注---專業(yè)專心---專注---專業(yè)精選優(yōu)質(zhì)文檔-----傾情為你奉上專心---專注---專業(yè)主要優(yōu)點1第1章1第1章在互聯(lián)網(wǎng)時代，交付速度是當今軟件開發(fā)的主題。十年前，項目通常要持續(xù)好幾年，并且項目階段是以月來衡量的。如今，多數(shù)團隊的項目周期是按月來衡量的，而項目階段則減少到幾周甚至幾天。任何需要長遠規(guī)劃的東西都將被拋棄，比如大量的前期軟件設(shè)計和詳細的需求分析。超過項目階段平均周期的任務(wù)將不復(fù)存在。跟代碼凍結(jié)（CodeFreeze）以及數(shù)周的手動回歸測試說再見吧！變化頻率如此之高，文檔很快就會過時。不斷更新詳細需求說明和測試計劃（TestPlan）需要投入大量精力，相當浪費。那些以往在日常工作中依賴于此的人們，如業(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實例化需求說明可以幫助團隊構(gòu)建正確的軟件產(chǎn)品，而技術(shù)實踐

可以確保正確地構(gòu)建產(chǎn)品想要有效地構(gòu)建正確的產(chǎn)品，軟件開發(fā)實踐必須滿足以下幾點。第1章主要優(yōu)點保證所有項目干系人和交付團隊的成員都對需要第1章主要優(yōu)點有準確的需求說明，這樣交付團隊才能避免由模棱兩可和功能缺失造成的無謂返工。有用來衡量某項工作是否已經(jīng)完成的客觀標準。具有引導軟件功能或團隊結(jié)構(gòu)變更的文檔。傳統(tǒng)意義上，構(gòu)建正確的產(chǎn)品需要龐大的功能需求說明、文檔以及漫長的測試階段。如今，軟件每周都要有交付，這一套已經(jīng)行不通了。我們尋求的方案要能帶來如下好處。避免過度說明需求從而產(chǎn)生浪費，避免花時間在開發(fā)前會發(fā)生改變的細節(jié)上。有一種可靠的文檔，可以解釋系統(tǒng)的行為，據(jù)此我們能容易修改系統(tǒng)行為?？梢杂行У貦z查系統(tǒng)行為與需求說明的描述是否一致。以最少的維護成本維持文檔的相關(guān)性與可靠性。適合短迭代和基于流的過程，這樣能為即將開展的工作提供即時足夠的信息。圖1-2對于敏捷項目，構(gòu)建正確文檔的關(guān)鍵因素乍一看，這些目標似乎互相沖突，但有很多團隊已經(jīng)成功地達成了所有目標。在為本書做調(diào)研時，我采訪了30個團隊，他們完成了大約50個項目。我試圖找出一些模式與通用做法，并挖掘出這些方式背后的基本原則。這些項目的共同思想，定義了一種構(gòu)建正確軟件的好方法：實例化需求說明。實例化需求說明是一組過程模式，它幫助團隊構(gòu)建正確的軟件產(chǎn)品。使用實例化需求說明，團隊編寫的文檔數(shù)量恰到好處，在短迭代或基于流的開發(fā)中可以有效地協(xié)助變更。實例化需求說明的關(guān)鍵過程模式將在下一章介紹。本章我將闡述實例化需求說明的好處。我將使用實例化需求說明的風格來進行闡述，而不是以理論介紹的方式來構(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)實世界的例子，近距離地審視這些收益。1.1更有效地實施變更在為本書做調(diào)研的過程中，我獲得的最重要的經(jīng)驗是關(guān)于活文檔（livingdocumentation）的長期收益的——事實上，我認為這是本書的一個最重要信息，本書廣泛地涵蓋了這部分內(nèi)容。活文檔是系統(tǒng)功能的一個信息源，它與程序代碼一樣可靠，但更容易使用和理解。活文檔幫助團隊共同分析變更所帶來的影響并討論潛在的方案。團隊還可以為新的需求擴展已有的文檔。長此以往，可以使需求說明和實施變更更有效。大多數(shù)成功的團隊都發(fā)現(xiàn)活文檔的長期收益是實施實例化需求說明所帶來的結(jié)果。總部設(shè)在美國西得梅因市的愛荷華州助學貸款流動資產(chǎn)管理公司（IowaStudentLoanLiquidityCorporation，下文簡稱IowaStudentLoan），在2009年進行了一項相當重要的商業(yè)模式變更。過去一年，金融市場動蕩使得貸款方幾乎無法為私人學生貸款找到資金來源，因此，許多貸款方被迫放棄私人學生貸款市場或改變自己的商業(yè)模式。該公司適應(yīng)了當時的市場。它從銀行和其他金融機構(gòu)募集資金來支助私人助學貸款，而不是使用債券收益。TimAndersen是一位軟件分析師，同時也是一名開發(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)，都必將導致開發(fā)停頓和重寫。在加拿大魁北克省的蒙特利爾市，Pyxis技術(shù)公司的Talia項目團隊也有類似的經(jīng)驗。Talia是企業(yè)系統(tǒng)的一個虛擬助理，它是一個擁有復(fù)雜規(guī)則、能與員工交流的聊天機器人。從最初開始，Talia團隊就使用實例化需求說明來構(gòu)建一個活文檔系統(tǒng)。一年之后，他們不得不從頭開始編寫虛擬代理引擎的核心——而此時，正是在活文檔方面的投資大顯成效的時候。Talia的產(chǎn)品總監(jiān)Andre?Brissette是這樣說的：如果沒有活文檔，任何重大重構(gòu)都無疑是自尋死路。他們的活文檔系統(tǒng)使得團隊在變更完成時可以自信地說，新系統(tǒng)具有和老系統(tǒng)一樣的功能。該活文檔系統(tǒng)還能幫助Brissette管理并追蹤項目的進度?？偛课挥趥惗氐默F(xiàn)場音樂消費性網(wǎng)站Songkick的團隊在重新開發(fā)網(wǎng)站活動摘要時，使用了一個活文檔系統(tǒng)來協(xié)助變更。他們意識到目前的摘要系統(tǒng)無法擴展到所需的容量，活文檔在重新構(gòu)建摘要系統(tǒng)時就提供了有力的支持。PhilCownas是Songkick的CTO，據(jù)他估計，因為擁有了活文檔系統(tǒng)，他們的團隊在實施變更時節(jié)省了至少50％的時間。據(jù)Cowans所述：因為我們擁有讓人滿意的覆蓋率，并且我們確實信任這些（在活文檔系統(tǒng)里的）測試，所以我們很有信心可以快速地對基礎(chǔ)結(jié)構(gòu)進行大的變更。我們知道，系統(tǒng)功能不會改變，即使變了，測試也會發(fā)現(xiàn)。ePlanServices是一個養(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ù)ePlanServices的測試人員及AgileTesting:APracticalGuideforTestersandTeams 該書中文版名為《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》，已由清華大學出版社于2010年出版。——譯者注一書作者LisaCrispin的描述，當時， 該書中文版名為《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》，已由清華大學出版社于2010年出版。——譯者注在比利時Oostkamp的IHC集團，病人管理中心項目組實施了一個活文檔系統(tǒng)，并取得了類似的結(jié)果。該項目開始時重寫了一個大型機系統(tǒng)，它是從2000年開始的，目前還在進行中。PascalMestdach是該項目的方案架構(gòu)師，他說團隊從中受益匪淺：當時遺留系統(tǒng)中的一部分功能只有少數(shù)幾個人了解，而現(xiàn)在情況已經(jīng)好很多了，那是因為團隊擁有一套針對那部分功能的、不停增長的測試套件（活文檔），它描述了該遺留系統(tǒng)的功能。當專家休假時，還可以從活文檔系統(tǒng)中尋找問題的答案。對其他開發(fā)人員來說，可以更清晰地了解軟件中某部分的功能。并且還是測試過的。這些例子闡述了活文檔系統(tǒng)如何幫助交付團隊分享知識并應(yīng)付人員變動。它還使得業(yè)務(wù)可以更有效地響應(yīng)市場變化。我將在第3章里對此做更具體的說明。1.2更高的產(chǎn)品質(zhì)量實例化需求說明可以改善交付團隊成員之間的協(xié)作，促進商業(yè)用戶更好地參與，并為交付提供清晰客觀的目標——大幅提高產(chǎn)品質(zhì)量。有兩個突出的案例，分別來自WesWilliams[來自世博控股（SabreHoldings）的敏捷教練]以之前失敗過多次的項目如何通過實例化需求說明走向成功。本書中描述的方法幫助他們的團隊克服了業(yè)務(wù)領(lǐng)域的復(fù)雜性，之前這種復(fù)雜性是很難處理的。同時還幫助他們確保了交付的高質(zhì)量。在世博控股，WesWilliams工作的項目是一個為期兩年的航班訂票項目，團隊分布在全球各地，流程又是數(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ù)語，表達的意思卻不盡相同，這導致了許多誤解。最初兩次實現(xiàn)系統(tǒng)的嘗試都失敗了，據(jù)ChanningWalton說，團隊中的一個開發(fā)人員促使了第三次嘗試的成功。第三次努力的成功部分歸功于實例化需求說明幫助團隊處理了復(fù)雜性問題，并且確保了團隊的共識。最終的產(chǎn)品質(zhì)量令人印象深刻。項目從2005年上線以來一直在運行，Sierra項目的顧問開發(fā)人員AndrewJackman說：“生產(chǎn)環(huán)境中沒有出現(xiàn)大的問題?！爆F(xiàn)在Sierra項目中的大多數(shù)工作人員都不是項目啟動時的那些人，但是質(zhì)量水平一直都很高。Bekk咨詢公司在為一家大型法國銀行支行開發(fā)租車系統(tǒng)時也取得了類似的成果。AslakHelles?y曾是那個團隊的成員，還是Cucumber—一個支持實例化需求說明的熱門自動化工具的創(chuàng)造者，據(jù)他說，盡管現(xiàn)在維護這個軟件的是一個全新的團隊，但他們在系統(tǒng)上線后的兩年中卻只發(fā)現(xiàn)了5個缺陷。LanceWalton曾在一家大型瑞士銀行倫敦分行的一個項目中擔任過程顧問，這個項目是要開發(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)。MartinJackson是該項目的自動化測試顧問，他說業(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ù)雜的科學計算公式和規(guī)則。這導致了一些質(zhì)量問題和延誤，由于使用這個引擎的應(yīng)用程序有好幾個，計算過程變得更加復(fù)雜。項目的軟件質(zhì)量保證主管PierreVeragen認為發(fā)布前的艱難時期會拖累項目，版本發(fā)布出去后很少會沒問題。實施實例化需求說明后，團隊現(xiàn)在和結(jié)構(gòu)工程師合作制定需求說明，并自動化驗證結(jié)果。當有變更需求進來時，測試人員和結(jié)構(gòu)工程師一起得出期望的計算結(jié)果，并在開發(fā)開始前用實例把結(jié)果記錄在需求說明中。之后批準變更的工程師會編寫需求說明和測試。Veragen說新方法的主要好處是他們在做改動時有信心了。到2010年初，他們的活文檔系統(tǒng)中已經(jīng)有超過30000個檢查，而且?guī)啄陜?nèi)都沒有發(fā)現(xiàn)大的缺陷，現(xiàn)在已經(jīng)停止追蹤缺陷了。Veragen指出：我們不需要（缺陷數(shù)）這個指標了，因為我們知道它不會再回來了……工程師們喜歡測試先行的方式，并且能直接訪問自動化測試。LanceWalton參與過一家大型法國銀行倫敦分行的信用風險管理程序的開發(fā)。項目剛開始的時候，有外來的顧問幫助團隊采用極限編程的實踐，但是他們沒有采用任何實例化需求說明的做法（雖然極限編程包括客戶測試，這個與可執(zhí)行的需求說明很接近）。6個月后，Walton加入了這個項目，他發(fā)現(xiàn)代碼質(zhì)量很低。雖然團隊每兩個星期都會有交付，但是寫出來的代碼使驗證變得很復(fù)雜。開發(fā)人員只測試最近實現(xiàn)的功能，隨著系統(tǒng)的增長，這樣的做法就不夠了。“當有版本發(fā)布時，大家都緊張地圍坐著，想確保所有功能都能正常運行，并且期望可以在幾個小時內(nèi)發(fā)現(xiàn)一些問題?！盬alton如此說。在實施實例化需求說明后，產(chǎn)品的質(zhì)量和人員的信心都有了顯著的提高。他補充道：我們十分確信我們發(fā)布的版本沒有問題。我們高興地部署完以后就出去享受午餐了，不用再擔心是否會出問題。與此形成鮮明對比的是，英國貿(mào)易者傳媒（TraderMedia）集團的網(wǎng)站重寫項目停止使用實例化需求說明后，卻遭遇了質(zhì)量問題。起初團隊協(xié)作完成需求說明和自動化驗證。在管理層的壓力下，他們?yōu)榱烁绺斓亟桓陡嗟墓δ芏鴽]有繼續(xù)下去。測試團隊的主管StuartTaylor說：“我們注意到質(zhì)量出現(xiàn)了大幅下滑……以前我們（測試人員）很難找到缺陷，而后來我們卻發(fā)現(xiàn)一個用戶故事會有四五個缺陷?！辈⒉痪窒抻诿艚輬F隊不是只有敏捷團隊才可以從協(xié)作制定需求說明中獲益。在BridgingtheCommunicationGap一書中，我建議在更為傳統(tǒng)的結(jié)構(gòu)過程中應(yīng)用類似的實踐。在那本書出版后，我在為本書做調(diào)研時正好碰到一家公司這么做了。英國Sopra集團的高級測試顧問MatthewSteer幫助一個大型電信公司的第三方離岸軟件交付伙伴實現(xiàn)了這些實踐。他們意識到項目需求定義不明確后，決定作出改變。Steer比較了實施實例化需求說明前后一年的交付成本。不出意料，這些項目使用瀑布方式開發(fā)，沒能達到零缺陷的級別，但是這些改變“提高了上游缺陷的發(fā)現(xiàn)率，減少了下游的返工和成本”。Steer說：我們在軟件生命周期早期發(fā)現(xiàn)的很多缺陷，傳統(tǒng)上要到晚期才能發(fā)現(xiàn)，這足以證明這個方法行之有效。缺陷數(shù)在生命周期的晚期有明顯的下降，而在早期則有所提升。最后結(jié)果是，交付成本僅在2007年就節(jié)省了170萬英鎊。1.3減少返工一般來講，頻繁地發(fā)布會促進快速反饋，使得開發(fā)團隊能夠更快地發(fā)現(xiàn)錯誤、修復(fù)錯誤。但是快速迭代并不能避免錯誤。通常情況下，團隊實現(xiàn)一個功能時會有三四次反復(fù)。開發(fā)人員稱，這是因為客戶在拿到產(chǎn)品試用前并不知道自己想要什么。我并不這么認為。使用實例化需求說明后，通常團隊第一次實現(xiàn)的就是客戶所要的，無需返工。這可以節(jié)省大量的時間，并使得交付流程更具可預(yù)測性、更加可靠。位于倫敦的英國天空廣播公司（BritishSkyBroadcasting）的天空網(wǎng)絡(luò)服務(wù)（SNS）部門負責寬帶和電話的服務(wù)配置（provisioning）軟件，它的業(yè)務(wù)流程和系統(tǒng)集成都極為復(fù)雜。該部門由6個團隊組成，他們使用實例化需求說明已經(jīng)有好幾年了。據(jù)他們的資深敏捷Java程序員RakeshPatel說：“當我們說交付時，確實是能馬上交付的。”并且該部門在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