敏捷可執行需求說明：Scrum提煉及實現技術 ( 簡體 字) |
| 作者：（美）Mario Cardinal 著 | 類別：1. -> 程式設計 -> 綜合 |
| 譯者： |
| 出版社：機械工業出版社 |  3dWoo書號： 39854
詢問書籍請說出此書號！【缺書】
NT售價： 195 元 |
| 出版日：10/1/2014 |
| 頁數：154 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787111480600 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：于需求說明方面的書籍有很多。不幸的是，這些書絕大多數對于軟件開發團隊來說都不實用。因為那些書依賴于傳統的工程實踐。他們假設需求是可以事先獲得的，并且一旦被寫出來，在項目進行過程中就不會再修改。而且，他們認為就算發生變更，都是一些細微的變化，因此，可以通過變更管理流程來進行追蹤。他們創建了從明確需求階段開始的系列流程，而這個階段將在團隊開始設計和實現產品之前提供詳細的需求說明。
本書目標
我認為傳統的工程實踐對軟件開發來說并不適用。提煉軟件需求說明的流程的核心問題是不確定性很高，這與傳統的工程是不同的。幸運的是，在過去十年，隨著敏捷社區的成長，我們已經整合出了更符合軟件開發現實問題的知識體系。很多書都提到，敏捷方面的書籍已成為對軟件開發感興趣的所有人必讀的書籍。這些書絕大部分都包含了至少一到兩章跟需求相關的內容，其中有些甚至整本書都只討論這個話題。我認為描述的有些內容非常重要，因此我會在本書里引用或參考這些內容。
我寫本書是為了讓敏捷知識體系更加飽滿。這是可執行需求說明相關的敏捷實踐的綱要。可執行需求說明能夠讓你更加輕松地測試軟件行為是否滿足需求。在本書中，我自始至終都在解釋如何在前提條件尚不明確的時候，以及需求難以把握且需要持續演進的情況下把軟件需求說清楚。軟件研發實踐者們將學會如何一步一步地緊緊圍繞愿景，采用浮現式迭代實踐，漸進明細地捕捉需求。他們還將學會如何通過編寫細小的需求分支而將需求說清楚。
本書的目標是解釋獲得可執行需求說明收益所需要的技術機制。它不僅會提供一個迭代式挖掘需求的可靠案例，還將進一步地教你如何將需求說明與正在構建的軟件連接起來。整個流程將引導你創建一個可執行的需求說明書。
即使我們有很好的意圖也不能強制要求干系人同意我們的做法意識到這一點很重要。有句非洲諺語簡潔明了地闡述了這個問題：“你不能拔苗助長。”當認知尚未完善，需求也在持續變更的時候，我們不能再依賴傳統的工程技術。相反，強調經驗技術的迭代式需求探索方式顯得至關重要。探尋目標不僅是為了正確地解決問題，同時也是要解決正確的問題——這是軟件構建過程面臨的最大挑戰。
本書的獨特之處在于，它將教會你如何通過使用可執行的需求說明把需求和架構連接起來。你將學會通過Scrum框架如何在說明需求的同時，將需求驗證過程自動化。讀完本書，你可以選擇一種工具，開始為將來的敏捷項目創建可執行需求說明。以下我列舉了閱讀本書的五個好處：
你將明白，當從傳統的方式轉型成敏捷實踐的時候，業務分析工作將會發生何種變化。
你將學會如何在Scrum 框架內提煉浮現式需求。
你將見識如何采用故事板和紙原型法改善跟干系人之間的溝通。
你將發現如何開展浮現式設計，同時確保任何時候的實施的正確性。
你將了解采用敏捷實踐的軟件架構師如何隨著當前的軟件開發進行浮現式設計。
誰應該是本書的讀者
本書的讀者應該是已經在應用Scrum框架或者正在轉型實施敏捷實踐的人。他們理解敏捷的本質，但是并不熟悉可執行需求說明。他們希望了解為什么可執行需求說明有用，以及最重要的是如何開始實施這一新的實踐。
隨著Scrum框架的大量使用，敏捷團隊面臨的第二大挑戰就是如何將業務分析師和架構師組合成活躍互動的團隊成員。任何面臨這一挑戰的Scrum Master、經理、決策者都應該閱讀本書。另外，所有參與敏捷項目的團隊成員也將從本書獲益。它并沒有直接宣稱業務分析師和軟件架構師將會因找到一本直接說出他們所關注的問題的書而高興。
高級或專家級的敏捷實踐者將會對本書清晰的可執行需求說明全局感興趣。他們可以利用本書成功地將團隊引領到這條路上。另外，全書使用的術語可以幫助領導者更有效地與同事溝通。
本書的路線圖
可執行需求說明提煉方法要求人們在思維方式上做出改變。本書的重點也在于此。可執行需求說明提煉方法有助于縮小干系人希望軟件能做什么（什么）和該軟件的確能做什么（如何）之間的差距。可執行需求說明以一種使開發團隊很容易根據可執行需求說明來驗證軟件的方法澄清需求，而這跟需求變更一樣在頻繁地發生。
為了促進這種思維方式的改變，本書提供了一個跨越9章的獨特思路。
第1章：解釋了為了有效應對持續變更的需求而采用迭代探索和可執行需求說明的必要性。
第2章：解釋了如何識別那些不可改變的事情：那些團隊應該依賴的、核心的、有把握的事情。而這些有把握的事情不是需求本身。它們是能夠保證一個方案得以實現的防護欄。它們組成了一個牢固的基石，保證迭代式需求探索方法成為可能。
第3章：揭示了為了找出不確定性，團隊必須通過短周期反饋環挖掘干系人的期望和需求（“愿求”）。
第4章：介紹了如何采用用戶故事表達“愿求”，并學會如何使用產品待辦事項列表記錄它們。
第5章：解釋了如何通過優化產品待辦事項列表來幫助我們做迭代計劃，這樣可以提高整個反饋環成功的概率。
第6章：展示了如何通過故事場景編寫用戶故事行為腳本來確認用戶故事。
第7章：解釋了如何將故事場景轉換成自動化測試，這樣我們就可以很容易地對照逐漸演進的需求說明確認軟件行為是否符合預期。
第8章：介紹了如何通過詳細說明非功能性需求保障軟件質量。
第9章：本書最后一章，總結了全書最關鍵的要素。
致謝
我最想感謝的人是第一個說服我寫作本書的Nathalie Provost。在寫作本書的整個過程中，她都一直支持我并照料我們的四個孩子，讓我得以實現夢想。
感謝我的業務伙伴Erik Renaud，他和我一起討論了關于非功能性需求和協作白板的內容。同樣，感謝Rob Daigneau和Stefan Surdek，他們在我撰寫本書的全過程中給我提供了寶貴的意見和建議。
眾所周知，學習來自于現實世界的經驗。感謝Urban Turtle團隊，特別是Francois Beauregard、Dominic Danis、Louis Pellerin、Guillaume Petitclerc和Luc Dorval，在他們的幫助下，我學到了很多關于Scrum、優化待辦事項列表和可執行需求說明的知識。同樣，我也忘不了和Tyco以及RunAtServer team團隊，特別是和Yanick Brunet以及Gabriel Labrecque一起探險的經歷，跟他們在一起，我有幸體驗了使用故事板和紙原型構建一個真正的軟件的過程。
我想感謝我的審稿人，他們閱讀本書初稿并提供了大量的建議幫助我改進本書內容。感謝David Starr、Leyna Zimdars、Robert Bogetti、Jochen Krebs以及另一位匿名的審稿人。
特別感謝Leita Boucicaut，她協助審稿和修改草稿。突出的能力和堅定的信念使她總能找到合適的字詞。她通過質疑我而使所有的文字都能被所有人理解，即使是不懂技術的讀者。
最后，我想說的是，如果沒有Addison Wesley公司的支持，我不可能出版這本書。感謝首席編輯Christopher Guzikowski、助理編輯Olivia Basegio、資深研發編輯Christopher J. Zahn以及資深項目編輯Lori Lyons。 |
內容簡介：簡介
本書由著名敏捷教練、MVP專家親筆撰寫，多位Scrum專家傾情推薦。書中深度解析了在前提條件尚不明確、需求難以把握且需持續演進的情況下如何闡釋清楚軟件需求說明，不僅提供了一個迭代式挖掘需求的可靠案例，還介紹了如何將需求說明與正在構建的軟件連接起來，以創建一個可執行的需求說明。
全書共9章：第1章解釋為了有效應對持續變更的需求而采用迭代探索和可執行需求說明的重要性；第2章介紹如何識別那些不可改變的事情，是它們保證迭代式需求探索方法成為可能；第3章揭示為了找出不確定性，團隊必須通過短周期反饋環挖掘干系人的期望和需求；第4章介紹如何采用用戶故事表達“愿求”，以及如何使用產品待辦事項列表記錄它們；第5章解釋如何通過優化產品待辦事項列表來幫助我們做迭代計劃，這樣可以提高整個反饋環成功的概率；第6章展示如何通過故事場景編寫用戶故事行為腳本來確認用戶故事；第7章解釋如何將故事場景轉換成自動化測試；第8章介紹如何通過詳細說明非功能性需求保障軟件的質量；第9章總結全書最關鍵的要素。 |
目錄：本書贊譽
譯者序
前言
第1章 解決正確的問題 1
1.1 從解決方案中甄別需求 4
1.2 識別不確定性的影響 4
1.3 處理不確定性 7
1.4 小結 8
1.5 參考資料 9
第2章 依賴堅實的基礎 10
2.1 界定不可更改的邊界 11
2.2 組建一個健康的團隊 11
2.3 要求所有干系人參與 13
2.4 明確一個可以共享的愿景 14
2.5 識別出一個有意義的共同目標 17
2.6 識別出一系列高級別的特征 18
2.7 驗證“可能存在”的假設 19
2.8 小結 20
2.9 參考資料 20
第3章 使用短周期反饋環探索干系人的“愿求” 21
3.1 運用試錯法 21
3.2 應用短周期反饋環 25
3.3 根據預期收益設定反饋目標 27
3.4 關注干系人的“愿求” 27
3.5 小結 30
3.6 參考資料 30
第4章 使用用戶故事表達“愿求” 31
4.1 使用用戶故事描述愿求 31
4.2 通過研究角色及其利益探索“愿求” 34
4.3 建立一種通用語言 37
4.4 使用待辦事項列表記錄“愿求” 37
4.5 小結 40
4.6 參考資料 41
第5章 優化產品待辦事項列表提煉用戶故事 42
5.1 管理產品待辦事項列表 42
5.2 通過合作優化產品待辦事項列表 45
5.3 采用圓點投票法對用戶故事進行排序 46
5.4 采用故事板的方式闡明用戶故事的需求 49
5.5 通過比較的方式估算用戶故事規模 53
5.6 按照業務價值拆分用戶故事 57
5.7 使用協作白板追蹤用戶故事 59
5.8 交付一組功能連貫的用戶故事 65
5.9 使用用戶故事計劃工作 67
5.10 小結 68
5.11 參考資料 69
第6章 使用場景確認用戶故事 70
6.1 使用場景創建用戶故事腳本 71
6.1.1 用標準形式表達場景 73
6.1.2 使用FIT表格化格式編寫場景腳本 74
6.1.3 使用已知–當…時–那么句型結構編寫場景腳本 75
6.1.4 選擇FIT表格化格式或者已知–當…時–那么的句型結構 78
6.1.5 規范化通用語言 78
6.2 將場景拆分成指令和查詢 81
6.3 兩步法流程協同確認 82
6.4 從場景里剔除技術考量 87
6.5 在Sprint過程中演進場景 89
6.5.1 按照特征（feature）組織場景 89
6.5.2 通過特征編寫場景文檔 91
6.5.3 避免重復和合并沖突 92
6.6 小結 92
6.7 參考資料 94
第7章 使用驗收測試自動確認需求 95
7.1 在驗收測試中引入場景 96
7.2 使用紅–綠–重構循環自動化場景 99
7.3 將場景轉換成驗收測試 102
7.3.1 使用內部DSL進行調換 102
7.3.2 創建一個測試 105
7.3.3 將DSL代碼寫進新創建的測試中 106
7.4 將新創建的測試與接口連接起來 108
7.4.1 接口設計練習 109
7.4.2 場景步驟間的背景鏈 111
7.4.3 使測試失敗 112
7.5 實現接口 113
7.5.1 用需求說明–情景測試替換單元測試 114
7.5.2 讓測試通過 115
7.6 演進驗收測試 115
7.7 使用持續集成并同時運行驗收測試 116
7.8 通過測試結果來增強場景 117
7.9 小結 119
7.10 參考資料 120
第8章 處理非功能性需求 121
8.1 使用約束改善外部質量 123
8.1.1 將非功能性需求轉換成約束條件 125
8.1.2 將功能性需求范圍降低至一個簡單場景 127
8.1.3 設置可度量的質量目標 129
8.1.4 使用行之有效的實踐來測試約束 133
8.2 使用正確的工程實踐確保內部質量 135
8.3 通過協作構建掌握實踐 138
8.4 小結 139
8.5 參考資料 140
第9章 結論篇 141
9.1 本書概要重述 142
9.2 流程總結 144
9.3 提請注意各種角色 146
詞匯表 148 |
| 序： |
