實(shí)例化需求：團(tuán)隊(duì)如何交付正確的軟件

第一部分 　開始
第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é)作制定需求說(shuō)明　　14
2.3 　舉例說(shuō)明　　14
2.4 　提煉需求說(shuō)明　　15
2.5 　自動(dòng)化驗(yàn)證時(shí)不修改需求說(shuō)明　　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í)例的需求說(shuō)明　　19
2.8.5 　可執(zhí)行的需求說(shuō)明　　20
2.8.6 　活文檔　　20
2.9 　銘記　　20
第3章 　活文檔　　21
3.1 　為什么我們需要權(quán)威的文檔　　22
3.2 　測(cè)試可以是好文檔　　22
3.3 　根據(jù)可執(zhí)行的需求說(shuō)明創(chuàng)建文檔　　23
3.4 　以文檔為中心的模型所具有的好處　　25
3.5 　銘記　　25
第4章 　開始改變　　26
4.1 　如何開始改變過程　　27
4.1.1 　把實(shí)施實(shí)例化需求說(shuō)明當(dāng)作更廣闊的過程變更的一部分　　27
4.1.2 　專注于提高質(zhì)量　　27
4.1.3 　從功能測(cè)試自動(dòng)化開始　　28
4.1.4 　引入一個(gè)可執(zhí)行需求說(shuō)明的工具　　29
4.1.5 　使用測(cè)試驅(qū)動(dòng)開發(fā)作為踏腳石　　30
4.2 　如何開始改變團(tuán)隊(duì)文化　　31
4.2.1 　避免使用“敏捷”術(shù)語(yǔ)　　31
4.2.2 　確保你得到管理層的支持　　32
4.2.3 　把實(shí)例化需求說(shuō)明當(dāng)作是比執(zhí)行驗(yàn)收測(cè)試更好的方式來(lái)推銷　　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í)行需求說(shuō)明　　41
4.4.2 　通過導(dǎo)出的活文檔來(lái)簽收　　41
4.4.3 　簽收的是范圍，而非需求說(shuō)明　　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)心“以防萬(wàn)一”的代碼　　44
4.5.5 　注意霰彈式修改　　45
4.6 　銘記　　45
第二部分 　關(guān)鍵過程模式
第5章 　從目標(biāo)中獲取范圍　　48
5.1 　構(gòu)建正確的范圍　　49
5.1.1 　理解“為什么”和“誰(shuí)”　　50
5.1.2 　理解價(jià)值從何而來(lái)　　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é)作制定需求說(shuō)明　　58
6.1 　為什么需要協(xié)作制定需求說(shuō)明　　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章 　舉例說(shuō)明　　72
7.1 　舉例說(shuō)明：一個(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 　使用替代方法來(lái)檢驗(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章 　提煉需求說(shuō)明　　86
8.1 　一個(gè)好的需求說(shuō)明的例子　　87
8.1.1 　免費(fèi)送貨服務(wù)　　87
8.1.2 　實(shí)例　　87
8.2 　一個(gè)劣質(zhì)需求說(shuō)明的例子　　88
8.3 　提煉需求說(shuō)明時(shí)要關(guān)心什么　　90
8.3.1 　實(shí)例要精確可測(cè)　　90
8.3.2 　腳本不是需求說(shuō)明　　90
8.3.3 　不要使用流程式的描述　　91
8.3.4 　需求說(shuō)明應(yīng)關(guān)注業(yè)務(wù)功能，而不是軟件設(shè)計(jì)　　92
8.3.5 　避免編寫與代碼緊密耦合的需求說(shuō)明　　92
8.3.6 　不要在需求說(shuō)明中引入技術(shù)難點(diǎn)的臨時(shí)解決方案　　93
8.3.7 　不要陷入到用戶界面的細(xì)節(jié)里　　93
8.3.8 　需求說(shuō)明應(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 　需求說(shuō)明要專注　　97
8.3.14 　在需求說(shuō)明中使用“Given-When-Then”語(yǔ)言　　97
8.3.15 　不要在需求說(shuō)明中明確建立
所有依賴　　98
8.3.16 　在自動(dòng)化層中應(yīng)用缺省值　　99
8.3.17 　不要總是依賴缺省值　　99
8.3.18 　需求說(shuō)明應(yīng)使用領(lǐng)域語(yǔ)言　　100
8.4 　提煉實(shí)戰(zhàn)　　100
8.5 　銘記　　102
第9章 　自動(dòng)化驗(yàn)證而不修改需求說(shuō)明　　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 　以更高層次的抽象來(lái)詳細(xì)說(shuō)明用戶界面的功能　　115
9.4.2 　UI需求說(shuō)明只檢查UI功能　　117
9.4.3 　避免錄制的UI測(cè)試　　117
9.4.4 　在數(shù)據(jù)庫(kù)中建立環(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ù)庫(kù)獲取原型　　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í)長(zhǎng)　　128
10.1.11 　將異步處理變成可選　　129
10.1.12 　不要用可執(zhí)行需求說(shuō)明做端到端的驗(yàn)證　　129
10.2 　獲得更快的反饋　　130
10.2.1 　引入業(yè)務(wù)時(shí)間　　130
10.2.2 　將較長(zhǎng)的測(cè)試分割成較小的模塊　　131
10.2.3 　避免使用內(nèi)存數(shù)據(jù)庫(kù)做測(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)建冗長(zhǎng)拖沓的需求說(shuō)明　　138
11.1.2 　不要使用許多小的需求說(shuō)明來(lái)描述單個(gè)功能　　139
11.1.3 　尋找更高層次的概念　　139
11.1.4 　避免在測(cè)試中使用技術(shù)上的自動(dòng)化概念　　139
11.2 　活文檔必須前后一致　　140
11.2.1 　演化出一種語(yǔ)言　　141
11.2.2 　將需求說(shuō)明語(yǔ)言擬人化　　142
11.2.3 　協(xié)作定義語(yǔ)言　　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ù)流程來(lái)組織　　146
11.3.5 　引用可執(zhí)行需求說(shuō)明時(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 　活文檔帶來(lái)的長(zhǎng)期價(jià)值　　184
附錄A 　資源　　186