實(shí)例化需求

前言

你手里正拿著或正在屏幕上翻看的這本書，是一系列研究的成果。我們調(diào)查了世界各地的多個(gè)團(tuán)隊(duì)如何在很短的周期內(nèi)說明需求、開發(fā)軟件，并交付正確的、無缺陷的產(chǎn)品。本書呈現(xiàn)的是集體智慧，從公共網(wǎng)站到內(nèi)部支持系統(tǒng)，涉及大大小小約50個(gè)項(xiàng)目。這些項(xiàng)目包含了各種各樣的團(tuán)隊(duì)，有在一個(gè)辦公室里辦公的小團(tuán)隊(duì)，也有跨越大洲的集團(tuán)公司，他們使用了眾多過程，包括極限編程（XP）、Scrum、看板（Kanban）以及一些類似的方法（通常附帶有敏捷或精益的字眼）。這些項(xiàng)目有個(gè)共同點(diǎn)——項(xiàng)目需求說明和測(cè)試能夠良好配合，項(xiàng)目組從中獲益良多。實(shí)例化需求說明如何處理需求說明與測(cè)試，不同的團(tuán)隊(duì)使用不同的名稱，但它們都有一套共同的核心原則與思想，而我認(rèn)為它們?cè)诒举|(zhì)上是一致的。很多團(tuán)隊(duì)使用以下這些名稱來命名這類實(shí)踐：敏捷驗(yàn)收測(cè)試驗(yàn)收測(cè)試驅(qū)動(dòng)開發(fā)實(shí)例驅(qū)動(dòng)開發(fā)故事測(cè)試行為驅(qū)動(dòng)開發(fā)實(shí)例化需求說明相同的做法卻有如此多的名字，這事實(shí)上也反映了當(dāng)前在這一領(lǐng)域內(nèi)有著大量的創(chuàng)新。同時(shí)它還反映了一個(gè)事實(shí)，本書描述的這些做法，影響了團(tuán)隊(duì)的需求描述、開發(fā)和測(cè)試等方面。為保持一致，必須選擇一個(gè)名字。本書將采用實(shí)例化需求說明（Specification by Example）這個(gè)名稱。至于為何選它，稍后的“談?wù)勑g(shù)語”一節(jié)將詳細(xì)解釋。實(shí)踐出真知本書通過案例研究和訪談來呈現(xiàn)這個(gè)話題。之所以選擇這種方式，是為了讓讀者能看到目前真的有團(tuán)隊(duì)正在這么做，并且從中獲益良多。實(shí)例化需求不是一門神秘藝術(shù)，雖然有些主流媒體會(huì)使人這么覺得。書中的一切幾乎都是來自于現(xiàn)實(shí)世界、真實(shí)的團(tuán)隊(duì)以及切實(shí)的經(jīng)驗(yàn)。有一小部分實(shí)踐是作為建議提出的，并沒有真實(shí)案例研究的支持。我認(rèn)為這些思想對(duì)將來會(huì)很重要，也正是因?yàn)槿绱耍也琶鞔_地提出它們。我很確定，我所主導(dǎo)的研究以及我得出的結(jié)論，雖然促成了本書的編寫，但由于這并不是一項(xiàng)嚴(yán)肅的科學(xué)研究，將會(huì)被那些號(hào)稱敏捷開發(fā)不可用、業(yè)界應(yīng)該回到“真正的軟件工程” 的懷疑論者所排斥。那也沒關(guān)系。相比一項(xiàng)嚴(yán)肅的科學(xué)研究所需的資源，編寫本書時(shí)我接觸到的資源是十分有限的。但即使我擁有那些資源，我也不是一個(gè)科學(xué)家，而且我也不用偽裝我自己。我是一名實(shí)踐者。本書讀者對(duì)象如果你像我一樣，是一名實(shí)踐者，并且靠軟件謀生，那么這本書可以提供很多幫助。有些團(tuán)隊(duì)已經(jīng)嘗試去實(shí)施敏捷過程，并且碰到了低質(zhì)量、返工以及未達(dá)客戶預(yù)期等問題，本書主要就是寫給這些團(tuán)隊(duì)的。（沒錯(cuò)，這些都是問題。簡(jiǎn)單地迭代只是權(quán)宜之計(jì)，并非解決方案。）實(shí)例化需求說明、敏捷驗(yàn)收測(cè)試、行為驅(qū)動(dòng)開發(fā)，以及其他不同叫法所指的這個(gè)實(shí)踐，都能解決這些問題。無論你是測(cè)試人員、開發(fā)人員、業(yè)務(wù)分析師，還是產(chǎn)品負(fù)責(zé)人，這本書都可以幫助你開始實(shí)施這些實(shí)踐，并學(xué)習(xí)如何用它們?cè)趫F(tuán)隊(duì)中做出更多貢獻(xiàn)。幾年前，我在大會(huì)上碰到的大多數(shù)人都沒聽說過這些思想。而現(xiàn)在，我碰到的大部分人都或多或少知道這些實(shí)踐，但是很多人都未能妥善落實(shí)。在實(shí)施敏捷開發(fā)的過程中，團(tuán)隊(duì)碰到的問題通常都很少有文字記載，所以每一個(gè)受挫的團(tuán)隊(duì)都認(rèn)為，自己遇到的問題比較特殊，而這些理念無法在他們的“現(xiàn)實(shí)世界”里發(fā)揮作用。只需聽他們述說短短五分鐘，我就能猜中三四個(gè)他們碰到的最大問題，這讓他們覺得驚訝。而當(dāng)他們得知其他團(tuán)隊(duì)也有同樣的問題時(shí)，他們更是完全驚呆了。如果你也在這樣的團(tuán)隊(duì)當(dāng)中，那么本書為你做的第一件事情，將是告訴你“你并不孤單”。本書中我所采訪的那些團(tuán)隊(duì)并不完美——他們也曾遇到數(shù)不清的問題。但他們?cè)谂霰谥?，并沒有放棄，而是決定圍繞這些問題繼續(xù)努力并解決問題。了解這一點(diǎn)通常能鼓舞人們換一種眼光去看待自己的問題。我希望你在讀罷本書后也有同樣的感受。如果你正在實(shí)施實(shí)例化需求說明，本書將就如何解決你當(dāng)前的問題提供非常有用的建議，同時(shí)也能讓你了解未來會(huì)發(fā)生什么事情。我希望你可以從別人的錯(cuò)誤中汲取經(jīng)驗(yàn)，并且完全避免發(fā)生同樣的問題。本書也寫給有經(jīng)驗(yàn)的實(shí)踐者，以及那些在實(shí)施實(shí)例化需求說明的過程中相對(duì)成功的人們。在采訪開始之初，我本以為這些事情都已胸有成竹，只是在求證而已。結(jié)果我發(fā)現(xiàn)，人們?cè)趯?shí)施過程中居然有如此之多的想法，這是我始料未及的。我從這些案例中學(xué)到了很多，希望你也如此。這里所描述的實(shí)踐和想法，應(yīng)該會(huì)激發(fā)你的靈感，促使你對(duì)自己的問題嘗試變通方案，或者讓你在見過類似的故事之后，意識(shí)到可以如何改善團(tuán)隊(duì)的過程。本書內(nèi)容在第一部分，我會(huì)介紹實(shí)例化需求說明。我不會(huì)說服你為什么應(yīng)該遵循本書描述的原則，而是向你展示——用實(shí)例化需求說明的方式——團(tuán)隊(duì)從這個(gè)過程中獲益的例子。如果你在考慮購買這本書，請(qǐng)瀏覽一下第1章，看看有哪些好處可以帶到你的項(xiàng)目中。第2章介紹了關(guān)鍵的過程模式和實(shí)例化需求說明的關(guān)鍵工件（artifact）。在第3章，我會(huì)更詳細(xì)地解釋活文檔的概念。第4章會(huì)展示一些改變過程和團(tuán)隊(duì)文化的最常見的切入點(diǎn)，也會(huì)就開始過程實(shí)施時(shí)需要注意的地方給出一些建議。本書寫作的一個(gè)目的是為團(tuán)隊(duì)在實(shí)施實(shí)例化需求說明時(shí)使用的這些模式、想法和工件創(chuàng)建一致的語言。整個(gè)實(shí)踐在業(yè)界有許多名稱，里面各種要素的名稱更是多出一倍。不同的人分別將同一個(gè)東西叫作功能文檔、故事測(cè)試、BDD文檔、驗(yàn)收測(cè)試等。正因?yàn)槿绱?，在?章中我會(huì)對(duì)所有的關(guān)鍵要素介紹一些我感覺不錯(cuò)的名字。即使你非常有經(jīng)驗(yàn)了，我還是建議閱讀這1章，以確保我們對(duì)本書中的關(guān)鍵名字、用詞和模式的理解是一樣的。在第二部分，我會(huì)展示案例中的團(tuán)隊(duì)用來實(shí)現(xiàn)實(shí)例化需求說明原則的關(guān)鍵性實(shí)踐。不同環(huán)境中的團(tuán)隊(duì)會(huì)做非常不同的事，有時(shí)甚至為了達(dá)到相同效果采取相反或沖突的措施。除了實(shí)踐外，我還記錄了團(tuán)隊(duì)貫徹基本原則的環(huán)境。第二部分差不多按照過程區(qū)域分成7章。在軟件領(lǐng)域沒有最佳實(shí)踐，但是確實(shí)有一些好的想法我們可以嘗試在不同的環(huán)境中去使用。在第二部分中，有些小節(jié)標(biāo)題旁邊會(huì)有拇指向上或向下的圖標(biāo)，代表的是調(diào)查中一些團(tuán)隊(duì)覺得有用的做法，或者是他們經(jīng)常遇到的問題。請(qǐng)根據(jù)建議做適當(dāng)?shù)膰L試或回避，但不要完全照搬套用。箭頭圖標(biāo)出現(xiàn)的地方代表的是各種做法的精髓。軟件開發(fā)不是靜態(tài)的——團(tuán)隊(duì)和環(huán)境都在改變，過程也必須隨著改變。在第三部分中，案例分析展示了一些團(tuán)隊(duì)的實(shí)施歷程。我記錄了他們的過程、約束條件和環(huán)境，并分析了這些過程是如何演化的。這些故事有助于你邁開第一步或讓你更進(jìn)一步，并發(fā)現(xiàn)新的想法與做事方式。本書的最后一章，我總結(jié)了我從促成本書的案例分析中學(xué)到的關(guān)鍵要素。更上一層樓在傳統(tǒng)的學(xué)習(xí)模型守破離（Shu-ha-ri） 中，本書處于破的層次。破是說要打破陳舊的規(guī)則，并證明成功的模型有很多。在我的Bridging the Communication Gap一書中，我展示了我的模型及經(jīng)驗(yàn)。本書中，我盡量不帶進(jìn)以前的背景。只有當(dāng)我覺得有重要觀點(diǎn)需要證明，并且本書中提到的其他任何團(tuán)隊(duì)都沒有類似情況的時(shí)候，我才會(huì)展示那些我自己參與過的項(xiàng)目。從這個(gè)意義上講，本書在Bridging the Communication Gap的基礎(chǔ)上更進(jìn)了一步。我會(huì)在第2章簡(jiǎn)單介紹一些基本的原則。即使你以前從未聽說過這些想法，第2章的簡(jiǎn)介也應(yīng)該可以給你足夠的信息去理解本書的其余部分，但我不會(huì)過多地深入基礎(chǔ)的內(nèi)容。有關(guān)實(shí)例化需求說明的基礎(chǔ)內(nèi)容在Bridging the Communication Gap一書中有詳細(xì)的描述，我不想在本書中重復(fù)。如果你想更詳盡地重溫那些基礎(chǔ)內(nèi)容，請(qǐng)?jiān)L問http：//specificationbyexample.com，登記你購買了本書，就可免費(fèi)獲得Bridging the Communication Gap的PDF版本。我想今后我不會(huì)就這一主題續(xù)寫“離”這個(gè)層次的書籍——因?yàn)樵搶哟问浅綍摹Ａ硪环矫?，我相信本書可以幫助你到達(dá)“離”這一層次。一旦你開始覺得選擇什么工具已經(jīng)無關(guān)緊要，那么你就已經(jīng)達(dá)到了這個(gè)層次。本書沒有源代碼，也不介紹任何工具本書沒有源代碼，也沒有特定工具的使用說明。我覺得必須事先說明這一點(diǎn)，因?yàn)樵诔霭孢^程中，我就曾多次向別人解釋這一點(diǎn)（典型的問題有“什么意思？一本沒有源代碼的軟件開發(fā)書？這怎么可能！”）。實(shí)例化需求說明的原則和實(shí)踐主要影響軟件交付團(tuán)隊(duì)中的人員溝通，以及他們?nèi)绾瓮褂谜吆晚?xiàng)目干系人進(jìn)行協(xié)作。我確信許多工具供應(yīng)商會(huì)試圖賣給你一套技術(shù)方案。如果有工具可以立即消除遇到的問題，許多經(jīng)理會(huì)樂于為此買單。不幸的是，他們遇到的主要是人的問題，而不是技術(shù)問題。比爾·蓋茨說過：“在企業(yè)中應(yīng)用任何一項(xiàng)技術(shù)時(shí)，首要的法則是，在有效率的系統(tǒng)中導(dǎo)入自動(dòng)化，將使效率倍增。第二條法則是，在缺乏效率的系統(tǒng)中導(dǎo)入自動(dòng)化，會(huì)使效率更低下。”很多團(tuán)隊(duì)在使用實(shí)例化需求說明的時(shí)候失敗了，他們使用自動(dòng)化工具反而導(dǎo)致他們的過程更加低效。我不想把注意力放在特定的工具上，相反，我想側(cè)重分析團(tuán)隊(duì)努力實(shí)現(xiàn)這些想法的真實(shí)原因。一旦你們能正確地溝通和協(xié)作，你們就可以選擇適合的工具去使用。在閱讀本書后，如果你想知道更多支持實(shí)例化需求說明的工具，請(qǐng)?jiān)L問網(wǎng)站并查看資源部分。　　

內(nèi)容概要

　　《實(shí)例化需求：團(tuán)隊(duì)如何交付正確的軟件》是在世界各地調(diào)查了多個(gè)團(tuán)隊(duì)軟件交付過程后的經(jīng)驗(yàn)總結(jié)。書中介紹了這些團(tuán)隊(duì)如何在很短的周期內(nèi)說明需求、開發(fā)軟件，并交付正確的、無缺陷的產(chǎn)品；為團(tuán)隊(duì)在實(shí)施實(shí)例化需求說明時(shí)使用的模式、想法和工件創(chuàng)建了一致的語言；展示了案例中的團(tuán)隊(duì)用來實(shí)現(xiàn)實(shí)例化需求說明原則的關(guān)鍵性實(shí)踐；并在案例分析部分展示了一些團(tuán)隊(duì)實(shí)施實(shí)例化需求說明的歷程。
　　《實(shí)例化需求：團(tuán)隊(duì)如何交付正確的軟件》適合與項(xiàng)目管理、開發(fā)、測(cè)試、交付有關(guān)的人員閱讀。

作者簡(jiǎn)介

Gojko Adzic
戰(zhàn)略軟件交付顧問，專注于敏捷和精益開發(fā)，尤其擅長敏捷測(cè)試、實(shí)例化需求和行為驅(qū)動(dòng)開發(fā)。Gojko經(jīng)常在國際上重要的軟件開發(fā)和測(cè)試會(huì)議上發(fā)言，并運(yùn)營著英國的敏捷測(cè)試用戶小組。最近這十多年來，他一直在財(cái)務(wù)和能源交易平臺(tái)、移動(dòng)定位、電子商務(wù)、在線游戲和復(fù)雜配置管理系統(tǒng)等行業(yè)項(xiàng)目中，從事程序員、架構(gòu)師、技術(shù)指導(dǎo)和顧問等工作。除本書外，他還著有Bridging the Communication Gap、Test Driven.Net Development with FitNesse和The Secret Ninja Cucumber Scrolls等書。

書籍目錄

目　錄
 
第一部分　開始
第1章　主要優(yōu)點(diǎn)　2
1.1　更有效地實(shí)施變更　4
1.2　更高的產(chǎn)品質(zhì)量　5
1.3　減少返工　8
1.4　更好的協(xié)作　10
1.5　銘記　11
第2章　關(guān)鍵過程模式　12
2.1　從目標(biāo)中獲取范圍　13
2.2　協(xié)作制定需求說明　14
2.3　舉例說明　14
2.4　提煉需求說明　15
2.5　自動(dòng)化驗(yàn)證時(shí)不修改需求說明　15
2.6　頻繁驗(yàn)證　17
2.7　演化出一個(gè)文檔系統(tǒng)　17
2.8　實(shí)際的例子　18
2.8.1　商業(yè)目標(biāo)　18
2.8.2　范圍　18
2.8.3　關(guān)鍵實(shí)例　18
2.8.4　帶實(shí)例的需求說明　19
2.8.5　可執(zhí)行的需求說明　20
2.8.6　活文檔　20
2.9　銘記　20
第3章　活文檔　21
3.1　為什么我們需要權(quán)威的文檔　22
3.2　測(cè)試可以是好文檔　22
3.3　根據(jù)可執(zhí)行的需求說明創(chuàng)建文檔　23
3.4　以文檔為中心的模型所具有的好處　25
3.5　銘記　25
第4章　開始改變　26
4.1　如何開始改變過程　27
4.1.1　把實(shí)施實(shí)例化需求說明當(dāng)作更廣闊的過程變更的一部分　27
4.1.2　專注于提高質(zhì)量　27
4.1.3　從功能測(cè)試自動(dòng)化開始　28
4.1.4　引入一個(gè)可執(zhí)行需求說明的工具　29
4.1.5　使用測(cè)試驅(qū)動(dòng)開發(fā)作為踏腳石　30
4.2　如何開始改變團(tuán)隊(duì)文化　31
4.2.1　避免使用“敏捷”術(shù)語　31
4.2.2　確保你得到管理層的支持　32
4.2.3　把實(shí)例化需求說明當(dāng)作是比執(zhí)行驗(yàn)收測(cè)試更好的方式來推銷　33
4.2.4　不要讓測(cè)試自動(dòng)化成為最終的目標(biāo)　34
4.2.5　不要太關(guān)注工具　34
4.2.6　在遷移過程中，遺留腳本也要有人維護(hù)　35
4.2.7　跟蹤哪些人在運(yùn)行(以及沒有運(yùn)行)測(cè)試自動(dòng)檢查程序　35
4.3　團(tuán)隊(duì)如何在流程和迭代中集成協(xié)作　36
4.3.1　Ultimate軟件公司的Global Talent Management團(tuán)隊(duì)　37
4.3.2　BNP Paribas銀行的Sierra團(tuán)隊(duì)　38
4.3.3　天空網(wǎng)絡(luò)服務(wù)部門　39
4.4　處理簽收和可追溯性　40
4.4.1　在版本控制系統(tǒng)中保存可執(zhí)行需求說明　41
4.4.2　通過導(dǎo)出的活文檔來簽收　41
4.4.3　簽收的是范圍，而非需求說明　41
4.4.4　在“精簡(jiǎn)的用例”上簽收　42
4.4.5　引入用例實(shí)現(xiàn)　42
4.5　警告信號(hào)　43
4.5.1　注意頻繁改動(dòng)的測(cè)試　43
4.5.2　當(dāng)心回退　44
4.5.3　注意組織級(jí)的失調(diào)　44
4.5.4　當(dāng)心“以防萬一”的代碼　44
4.5.5　注意霰彈式修改　45
4.6　銘記　45
第二部分　關(guān)鍵過程模式
第5章　從目標(biāo)中獲取范圍　48
5.1　構(gòu)建正確的范圍　49
5.1.1　理解“為什么”和“誰”　50
5.1.2　理解價(jià)值從何而來　51
5.1.3　了解商業(yè)用戶預(yù)期的輸出是什么　52
5.1.4　讓開發(fā)人員提供用戶故事的“我想要”部分　53
5.2　在沒有高層次控制權(quán)的情況下，協(xié)作確定范圍　53
5.2.1　詢問“為什么這些東西有用？”　54
5.2.2　詢問替代方案　54
5.2.3　不要只顧最低層次的需求　55
5.2.4　確保團(tuán)隊(duì)交付完整的功能　55
5.3　更多信息　56
5.4　銘記　56
第6章　通過協(xié)作制定需求說明　58
6.1　為什么需要協(xié)作制定需求說明　58
6.2　最熱門的協(xié)作模型　59
6.2.1　嘗試大型的全體工作坊　59
6.2.2　嘗試小型工作坊(“神勇三劍客”)　61
6.2.3　結(jié)對(duì)編寫　62
6.2.4　讓開發(fā)人員在迭代開始前頻繁地審查測(cè)試　63
6.2.5　嘗試非正式交談　64
6.3　準(zhǔn)備協(xié)作　65
6.3.1　舉辦介紹會(huì)　65
6.3.2　邀請(qǐng)項(xiàng)目干系人　66
6.3.3　進(jìn)行具體的準(zhǔn)備工作并事先審查　67
6.3.4　讓團(tuán)隊(duì)成員盡早審查故事　68
6.3.5　只準(zhǔn)備初始的實(shí)例　69
6.3.6　不要讓過度的準(zhǔn)備阻礙了討論　69
6.4　選擇協(xié)作模型　70
6.5　銘記　71
第7章　舉例說明　72
7.1　舉例說明：一個(gè)例子　74
7.2　例子必須精確到位　75
7.2.1　不要在例子中出現(xiàn)“是/否”的回答　75
7.2.2　避免使用等價(jià)抽象類　75
7.3　例子必須完整　76
7.3.1　用數(shù)據(jù)作試驗(yàn)　76
7.3.2　使用替代方法來檢驗(yàn)功能　76
7.4　例子必須要真實(shí)　77
7.4.1　避免虛構(gòu)自己的數(shù)據(jù)　77
7.4.2　直接從客戶那里獲得基本的例子　78
7.5　例子應(yīng)該易于理解　79
7.5.1　避免探討所有可能的組合　80
7.5.2　尋找隱含的概念　80
7.6　描述非功能性需求　81
7.6.1　取得精確的性能需求　82
7.6.2　為UI使用低保真度的原型　82
7.6.3　試用QUPER模型　83
7.6.4　討論時(shí)使用核查清單　84
7.6.5　建立一個(gè)參照的例子　84
7.7　銘記　85
第8章　提煉需求說明　86
8.1　一個(gè)好的需求說明的例子　87
8.1.1　免費(fèi)送貨服務(wù)　87
8.1.2　實(shí)例　87
8.2　一個(gè)劣質(zhì)需求說明的例子　88
8.3　提煉需求說明時(shí)要關(guān)心什么　90
8.3.1　實(shí)例要精確可測(cè)　90
8.3.2　腳本不是需求說明　90
8.3.3　不要使用流程式的描述　91
8.3.4　需求說明應(yīng)關(guān)注業(yè)務(wù)功能，而不是軟件設(shè)計(jì)　92
8.3.5　避免編寫與代碼緊密耦合的需求說明　92
8.3.6　不要在需求說明中引入技術(shù)難點(diǎn)的臨時(shí)解決方案　93
8.3.7　不要陷入到用戶界面的細(xì)節(jié)里　93
8.3.8　需求說明應(yīng)該是不言自明的　94
8.3.9　使用敘述性標(biāo)題并使用短篇幅闡釋目標(biāo)　94
8.3.10　展示給別人看并保持沉默　94
8.3.11　不要過度定義實(shí)例　95
8.3.12　從簡(jiǎn)單的例子入手，然后逐步展開　96
8.3.13　需求說明要專注　97
8.3.14　在需求說明中使用“Given-When-Then”語言　97
8.3.15　不要在需求說明中明確建立所有依賴　98
8.3.16　在自動(dòng)化層中應(yīng)用缺省值　99
8.3.17　不要總是依賴缺省值　99
8.3.18　需求說明應(yīng)使用領(lǐng)域語言　100
8.4　提煉實(shí)戰(zhàn)　100
8.5　銘記　102
第9章　自動(dòng)化驗(yàn)證而不修改需求說明　103
9.1　非得自動(dòng)化嗎　104
9.2　從自動(dòng)化開始　105
9.2.1　為了學(xué)習(xí)工具，先嘗試一個(gè)簡(jiǎn)單的項(xiàng)目　105
9.2.2　事先計(jì)劃自動(dòng)化　106
9.2.3　不要拖延自動(dòng)化工作或?qū)⑵湮伤恕?07
9.2.4　避免根據(jù)原有的手動(dòng)測(cè)試腳本進(jìn)行自動(dòng)化　107
9.2.5　通過用戶界面測(cè)試贏得信任　108
9.3　管理自動(dòng)化層　109
9.3.1　別把自動(dòng)化代碼當(dāng)作二等公民　109
9.3.2　在自動(dòng)化層里描述驗(yàn)證過程　110
9.3.3　不要在測(cè)試自動(dòng)化層里復(fù)制業(yè)務(wù)邏輯　111
9.3.4　沿著系統(tǒng)邊界自動(dòng)化　112
9.3.5　不要通過用戶界面檢查業(yè)務(wù)邏輯　113
9.3.6　在應(yīng)用程序的表皮之下進(jìn)行自動(dòng)化　113
9.4　對(duì)用戶界面進(jìn)行自動(dòng)化　115
9.4.1　以更高層次的抽象來詳細(xì)說明用戶界面的功能　115
9.4.2　UI需求說明只檢查UI功能　117
9.4.3　避免錄制的UI測(cè)試　117
9.4.4　在數(shù)據(jù)庫中建立環(huán)境　118
9.5　管理測(cè)試數(shù)據(jù)　119
9.5.1　避免使用預(yù)填充數(shù)據(jù)　119
9.5.2　嘗試使用預(yù)填充的引用數(shù)據(jù)　120
9.5.3　從數(shù)據(jù)庫獲取原型　120
9.6　銘記　121
第10章　頻繁驗(yàn)證　122
10.1　提高穩(wěn)定性　123
10.1.1　找出最煩人的問題并將其解決掉，然后不停地重復(fù)　123
10.1.2　用CI測(cè)試歷史找到不穩(wěn)定的測(cè)試　124
10.1.3　搭建專用的持續(xù)驗(yàn)證環(huán)境　125
10.1.4　使用全自動(dòng)部署　125
10.1.5　為外部系統(tǒng)創(chuàng)建較簡(jiǎn)單的測(cè)試替代品　125
10.1.6　選擇性地隔離外部系統(tǒng)　126
10.1.7　嘗試多級(jí)驗(yàn)證　127
10.1.8　在事務(wù)中執(zhí)行測(cè)試　127
10.1.9　對(duì)引用數(shù)據(jù)做快速檢查　128
10.1.10　等待事件，而非等待固定時(shí)長　128
10.1.11　將異步處理變成可選　129
10.1.12　不要用可執(zhí)行需求說明做端到端的驗(yàn)證　129
10.2　獲得更快的反饋　130
10.2.1　引入業(yè)務(wù)時(shí)間　130
10.2.2　將較長的測(cè)試分割成較小的模塊　131
10.2.3　避免使用內(nèi)存數(shù)據(jù)庫做測(cè)試　131
10.2.4　把快速的和緩慢的測(cè)試分開　132
10.2.5　保持夜間測(cè)試的穩(wěn)定　132
10.2.6　為當(dāng)前迭代創(chuàng)建一個(gè)測(cè)試包　133
10.2.7　并行運(yùn)行測(cè)試　133
10.2.8　禁用風(fēng)險(xiǎn)較低的測(cè)試　134
10.3　管理失敗的測(cè)試　135
10.3.1　創(chuàng)建已知失敗了的回歸測(cè)試包　135
10.3.2　自動(dòng)檢查那些被禁用的測(cè)試　136
10.4　銘記　137
第11章　演化出文檔系統(tǒng)　138
11.1　活文檔必須易于理解　138
11.1.1　不要?jiǎng)?chuàng)建冗長拖沓的需求說明　138
11.1.2　不要使用許多小的需求說明來描述單個(gè)功能　139
11.1.3　尋找更高層次的概念　139
11.1.4　避免在測(cè)試中使用技術(shù)上的自動(dòng)化概念　139
11.2　活文檔必須前后一致　140
11.2.1　演化出一種語言　141
11.2.2　將需求說明語言擬人化　142
11.2.3　協(xié)作定義語言　143
11.2.4　將構(gòu)建模塊文檔化　143
11.3　活文檔必須組織得井井有條，便于訪問　144
11.3.1　按用戶故事組織當(dāng)前的工作　144
11.3.2　按功能區(qū)域組織用戶故事　145
11.3.3　按用戶界面的導(dǎo)航路徑組織　146
11.3.4　按業(yè)務(wù)流程來組織　146
11.3.5　引用可執(zhí)行需求說明時(shí)請(qǐng)使用標(biāo)簽而不要使用URL　147
11.4　聆聽活文檔　147
11.5　銘記　148
第三部分　案例研究
第12章　uSwitch　152
12.1　開始改變流程　152
12.2　優(yōu)化流程　154
12.3　當(dāng)前的流程　156
12.4　結(jié)果　157
12.5　重要的經(jīng)驗(yàn)教訓(xùn)　157
第13章　RainStor　159
13.1　改變流程　159
13.2　當(dāng)前流程　161
13.3　重要的經(jīng)驗(yàn)教訓(xùn)　162
第14章　愛荷華州助學(xué)貸款公司　163
14.1　改變流程　163
14.2　優(yōu)化流程　164
14.3　活文檔作為競(jìng)爭(zhēng)優(yōu)勢(shì)　166
14.4　重要的經(jīng)驗(yàn)教訓(xùn)　167
第15章　Sabre Airline Solutions　168
15.1　改變流程　168
15.2　改善協(xié)作　169
15.3　結(jié)果　171
15.4　重要的經(jīng)驗(yàn)教訓(xùn)　171
第16章　ePlan Services　172
16.1　改變流程　172
16.2　活文檔　174
16.3　當(dāng)前的流程　175
16.4　重要的經(jīng)驗(yàn)教訓(xùn)　176
第17章　Songkick　177
17.1　改變流程　177
17.2　當(dāng)前的流程　179
17.3　重要的經(jīng)驗(yàn)教訓(xùn)　180
第18章　思想總結(jié)　182
18.1　協(xié)作制定需求能在項(xiàng)目干系人與交付團(tuán)隊(duì)之間建立信任　182
18.2　協(xié)作需要事先準(zhǔn)備　183
18.3　協(xié)作的方式多種多樣　183
18.4　將最終目的視為業(yè)務(wù)流程文檔，不失為一種有用的模型　184
18.5　活文檔帶來的長期價(jià)值　184
附錄A　資源　186

章節(jié)摘錄

版權(quán)頁：   插圖：   例子既能避免歧義又是進(jìn)行準(zhǔn)確溝通的好方法。在日常的交談和寫作中，我們會(huì)不假思索地使用例子。當(dāng)我在Google里搜索“例如”這個(gè)詞組時(shí)，返回的搜索結(jié)果超過了2.1億頁。 使用傳統(tǒng)的需求說明時(shí)，例子會(huì)在軟件開發(fā)過程中時(shí)隱時(shí)現(xiàn)。業(yè)務(wù)分析師通常會(huì)從商業(yè)用戶那里獲取到訂單、發(fā)貨單以及報(bào)表的樣本，然后他們會(huì)將其轉(zhuǎn)換成抽象的需求。開發(fā)人員會(huì)想出一些例子來解釋邊界情況并向商業(yè)用戶或分析師作出澄清，而后他們會(huì)將其轉(zhuǎn)化成代碼，但他們并不會(huì)記錄下這些例子。測(cè)試人員會(huì)設(shè)計(jì)出測(cè)試用例，它們實(shí)際上就是系統(tǒng)應(yīng)當(dāng)如何工作的實(shí)例；這些例子僅供他們自己使用，而不會(huì)拿來與開發(fā)人員或分析師進(jìn)行溝通。 每個(gè)人都會(huì)創(chuàng)造自己的例子，且不說這些例子是否完整，連例子的一致性都無法確保。這就是為什么在軟件開發(fā)中最終結(jié)果往往會(huì)背離最初設(shè)想的原因。為了避免這種情況，我們必須防止不同角色之間出現(xiàn)的誤解，只維護(hù)一處事實(shí)來源。 例子是避免溝通問題的好工具。如果我們自始至終都能夠捕獲所有的例子，并在分析、開發(fā)和測(cè)試中一致地使用它們，那么我們就可以避免進(jìn)入傳話游戲中（而導(dǎo)致信息失真）。 Beazley公司引入實(shí)例化需求說明的時(shí)候，Marta Gonzalez Ferrero是當(dāng)時(shí)的測(cè)試負(fù)責(zé)人。據(jù)她所述，開發(fā)團(tuán)隊(duì)承諾的工作量超出了他們的能力，同時(shí)他們發(fā)現(xiàn)，在實(shí)現(xiàn)開始的時(shí)候所獲得的信息往往遠(yuǎn)遠(yuǎn)不夠。他們的迭代周期是6周，而且開發(fā)團(tuán)隊(duì)和業(yè)務(wù)分析師身處于不同的大洲，這讓事情進(jìn)一步復(fù)雜化。開發(fā)人員從業(yè)務(wù)分析師那里得到的驗(yàn)收條件也比較抽象（例如，“對(duì)于這個(gè)業(yè)務(wù)單元，要確保所有正確的產(chǎn)品都能夠顯示出來”）。在迭代半途中發(fā)現(xiàn)缺少某些重要的東西，會(huì)嚴(yán)重?cái)_亂產(chǎn)出。某輪迭代結(jié)束時(shí)，客戶說團(tuán)隊(duì)交付的東西完全不是他們所期望的。每個(gè)迭代的最后一周保留給Model Office：實(shí)際上是一個(gè)迭代的演示會(huì)議。有一次，F(xiàn)errero到美國做ModelOffice，并且與業(yè)務(wù)分析師一起工作了兩天，對(duì)需求進(jìn)行舉例說明。結(jié)果，團(tuán)隊(duì)在下一個(gè)迭代承諾交付的工作減少了20％，最終他們成功交付了自己承諾的部分。 “團(tuán)隊(duì)的情緒也好了很多，”Ferrero說道，“在此之前，（開發(fā)人員）在實(shí)現(xiàn)的時(shí)候會(huì)感覺自己是在瞎做，必須等待業(yè)務(wù)分析師的反饋?！睋?jù)Ferrero所述，在他們開始對(duì)需求做舉例說明后，返工量急劇下降。

媒體關(guān)注與評(píng)論

“獨(dú)一無二的、基于大量的業(yè)內(nèi)研究提取出來的知識(shí)。”——Mike Stockdale Syterra軟件公司“本書是我的摯愛，它教會(huì)我如何正確地做測(cè)試。”——Craig Smith Suncorp公司“本書將改變我們討論和思考測(cè)試的方式。”——David Evans ThinkAlike咨詢公司“本書是有關(guān)需求收集與維護(hù)的最好的圖書?！薄狾leksandr Alesinskyy NAVTEQ“基于眾多團(tuán)隊(duì)的經(jīng)驗(yàn)，它將讓你的測(cè)試自動(dòng)化事半功倍。”Rick Mugridge Rimu研究公司

編輯推薦

以“specification by example”為主題講解了50多個(gè)案例以對(duì)世界級(jí)成功團(tuán)隊(duì)數(shù)十次采訪為基礎(chǔ)與大家分享世界級(jí)團(tuán)隊(duì)的工作訣竅敏捷開發(fā)的新經(jīng)典文獻(xiàn)亞馬遜網(wǎng)站全五星評(píng)價(jià)成功開發(fā)軟件的必備秘籍

圖書封面

圖書標(biāo)簽Tags

無

評(píng)論、評(píng)分、閱讀與下載

---

    實(shí)例化需求 PDF格式下載

---