需求規格實例化:團隊如何交付正確的軟體

《需求規格實例化:團隊如何交付正確的軟體》
基本資料
原書名：Specification by Example:How Successful Teams Deliver the Right Software
作者： (塞爾)阿契克(Adzic,G.) [作譯者介紹]
譯者： 張昌貴 張博超 石永超
叢書名： 圖靈程式設計叢書
出版社：人民郵電出版社
ISBN：9787115290267
上架時間：2012-8-28
出版日期：2012 年9月
開本：16開
頁碼：1
版次：1-1
所屬分類： 電腦

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

本圖書資訊來源於：中國互動出版網