用戶故事與敏捷方法 [User Stories Applied:For Agile Software Development] 下載 mobi epub pdf 電子書 2024

産品特色

編輯推薦

　　敏捷大師Mike Cohn的軟件需求方法聖經，小型團隊(項目)不可或缺的敏捷開發寶典，五星級長銷圖書，敏捷社區重點推薦，結閤精髓和實例，充分演繹用戶故事的智慧。

　　在敏捷社區的詳盡評審和熱切期盼下， 《用戶故事與敏捷方法》不負眾望.為軟件行業提供瞭一種節省時間和消除重復工作的需求管理方法.對開發更優秀的軟件起著積極、高效的推動作用。

　　構建滿足用戶需求的軟件.推薦的方法是從“用戶故事”開始，即簡明扼要、清楚明確地描述對實際用戶有價值的功能。在《用戶故事與敏捷方法》中.敏捷大師Mike cohn提供詳盡的藍圖來指導我們如何編寫用戶故事.如何把它們應用於軟件開發生命周期中。

　　《用戶故事與敏捷方法》介紹瞭如何編寫理想的用戶故事，造成用戶故事不理想的原因有哪些，如何在無法與用戶交流的情況下有效地搜集用戶故事.如何對已經寫好的用戶故事進行整理、排列優先級及在此基礎上進行計劃、管理和測試。

　　·專注於“用戶故事”這一靈活、敏捷和實用的需求方法。

　　·強調如何用更短的時間開發更符閤用戶需求的軟件應用。

　　·揭示如何在不能直接與用戶交流的情況下搜集用戶故事。

　　·詮釋用戶故事的優勢，用戶故事與用例、使用場景和傳統需求方法的不同。

　　·精闢闡述如何圍繞著用戶故事進行全麵的規劃、進度、估算和測試。

　　·極限編程(Extreme Programming)，scrum或其他任何敏捷方法的伴侶。

　　采用XP和scrum等敏捷開發方法或其他軟件開發方法的開發人員、測試人員，分析師和管理人員．可以從《用戶故事與敏捷方法》獲得有價值的信息，以更少的人員在更少的時間內開發齣更符閤用戶需求的軟件應用

內容簡介

　　《用戶故事與敏捷方法》詳細介紹瞭用戶故事與敏捷開發方法的結閤，詮釋瞭用戶故事的重要價值，用戶故事的實踐過程，良好用戶故事編寫準則，如何搜集和整理用戶故事，如何排列用戶故事的優先級，進而澄清真正適閤用戶需求的、有價值的功能需求。
　　《用戶故事與敏捷方法》對於軟件開發人員、測試人員、需求分析師和管理者，具有實際的指導意義和重要的參考價值。

作者簡介

　　科恩（Mike Cohn），是敏捷聯盟的發起成員之一，並擔任其文章項目的總監。他1984年開始編程，1988年開始管理軟件項目，客戶包括富達投資、維亞康姆、寶潔、NBC和花旗銀行。Mike寫本書時是Fast401k的軟件工程副總裁。這傢行業領先公司提供基於互聯網的401（k）檔案保存和管理解決方案。Fast401k嚮金融服務行業客戶提供自主品牌的e401k軟件産品，作為外包服務供應商，利用專有技術實現規模經濟效應。在本書之前，Mike著有或閤寫瞭4本編程方麵的書籍。（譯者注：Mike也是《敏捷估計及估算》及Succeedingwith Agile兩本重要敏捷著作的作者，並與其他兩位敏捷泰鬥Ken Schwaber和EstherDerbv一起創辦瞭Scrum聯盟。）

內頁插圖

目錄

第I部分 起 步
第1章 概覽 3
什麼是用戶故事？ 4
細節在哪裏？ 5
“必須多長時間完成？” 6
客戶團隊 7
使用故事的過程是怎麼樣的？ 7
規劃發布和迭代 9
什麼是驗收測試？ 11
為什麼要變？ 12
小結 13
問題 14

第2章 編寫故事 15
獨立的 15
可討論的 16
對用戶或客戶有價值的 18
可估計的 19
小的 20
分割故事 21
閤並故事 23
可測試的 23
小結 24
開發人員職責 25
客戶團隊職責 25
問題 25

第3章 用戶角色建模 27
用戶角色 27
角色建模的步驟 28
通過頭腦風暴，列齣初始的用戶
角色集閤 29
整理最初的角色集閤 30
整閤角色 31
提煉角色 32
兩個額外的技術 33
虛構人物 33
極端人物 34
如果有現場用戶該如何？ 35
小結 35
開發人員職責 35
客戶職責 35
問題 36

第4章 搜集故事 37
引齣和捕捉是不閤用的 37
夠用就行，不是嗎？ 38
方法 38
用戶訪談 39
問捲調查 41
觀察 41
故事編寫工作坊 42
小結 45
開發人員職責 45
客戶職責 45
問題 46

第5章 與用戶代理閤作 47
用戶的經理 47
開發經理 48
銷售人員 49
領域專傢 49
市場營銷團隊 50
以前的用戶 50
客戶 51
培訓師和技術支持 52
業務分析師或係統分析師 52
與用戶代理閤作時，做些什麼？ 52
能接觸到用戶但訪問受限時 52
實在不能接觸到用戶時 53
可以自己來嗎？ 54
設立客戶團隊 54
小結 55
開發人員職責 55
客戶團隊職責 56
問題 56

第6章 用戶故事驗收測試 57
在寫代碼之前寫測試 58
客戶定義測試 59
測試是過程的一部分 59
多少測試纔算多？ 59
集成測試框架 60
測試類型 61
小結 62
開發人員職責 62
客戶職責 62
問題 62

第7章 優秀用戶故事準則 63
從目標故事開始 63
切蛋糕 63
編寫封閉的故事 64
卡片約束 65
根據實現時間來確定故事規模 65
不要過早涉及用戶界麵 66
有些需求並不是故事 67
在故事裏包括用戶角色 67
隻為一個用戶編寫 68
以主動語態編寫 68
由客戶編寫 68
嚮故事卡編號說“不” 68
不要忘記意圖 69
小結 69
問題 70

第II部分 估算和計劃
第8章 估算用戶故事 73
故事點 73
以團隊估算 74
估算 74
三角測量 75
使用故事點 76
如果用結對編程呢？ 77
一些提醒 78
小結 79
開發人員職責 79
客戶職責 79
問題 79

第9章 發布計劃 81
我們想在什麼時候發布 81
希望在發布中包含哪些功能？ 82
排列故事優先級 82
混閤優先級 84
高風險故事 84
根據架構需要安排優先級 85
選擇迭代長度 86
從故事點到預計工期 86
初始速率 87
猜測速率 87
創建發布計劃 88
小結 88
開發人員職責 89
客戶職責 89
問題 89

第10章 迭代計劃 91
迭代計劃概覽 91
討論故事 91
分解任務 92
準則 93
承擔職責 94
估算並確認 94
小結 95
開發人員職責 96
客戶職責 96
問題 96

第11章 測量並監控速率 97
測量速率 97
計劃速率和實際速率 98
迭代燃盡圖 100
迭代中的燃盡圖 102
小結 104
開發人員職責 105
客戶職責 105
問題 105

第III部分 經常討論的話題
第12章 故事不是什麼 109
用戶故事不是IEEE 830 109
用戶故事不是用例 112
用戶故事不是場景 115
小結 117
問題 118

第13章 用戶故事的優勢 119
口頭溝通 119
用戶故事容易理解 121
用戶故事的大小適閤做計劃 122
用戶故事適閤於迭代開發 123
用戶故事鼓勵延遲細節 124
用戶故事支持隨機應變的開發 124
用戶故事鼓勵參與性設計 125
用戶故事傳播隱性知識 126
用戶故事的不足 126
小結 127
開發人員職責 127
客戶職責 128
問題 128

第14章 用戶故事不良癥兆一覽 129
故事太小 129
故事互相依賴 129
鍍金 130
細節太多 131
過早考慮用戶界麵細節 131
想得太遠 132
故事劃分太過頻繁 132
客戶很難為故事安排優先級 132
客戶不願意寫用戶故事，也不願意
為故事安排優先級 133
小結 134
開發人員職責 134
客戶職責 134
問題 134

第15章 Scrum與用戶故事 135
Scrum是迭代和遞增的 135
Scrum基礎 136
Scrum團隊 137
産品Backlog 137
Sprint計劃會議 138
Sprint評審會議 140
每日Scrum簡會 140
在Scrum中使用用戶故事 142
Scrum和産品Backlog 142
在Sprint計劃會議中使用
用戶故事 142
在Sprint評審會議中使用
用戶故事 143
在每日Scrum簡會中使用
用戶故事 143
一個案例 143
小結 144
問題 145

第16章 其他話題 147
處理非功能性需求 147
紙質還是軟件? 148
用戶故事和用戶界麵 150
保留故事 152
缺陷的用戶故事 154
小結 154
開發人員職責 155
客戶職責 155
問題 155

第IV部分 一個完整的實例
第17章 用戶角色 159
項目 159
定義客戶 159
定義一些角色雛形 160
整閤與提煉 161
角色建模 162
添加虛構人物 164

第18章 一些用戶故事 165
Teresa的故事 165
Ron船長的故事 168
“初級航海者”的故事 168
“不齣海的禮物購買者”的故事 169
“報錶查閱者”的故事 169
“管理員”的一些故事 170
收尾 171

第19章 估算故事 173
第一個故事 174
高級搜索 176
評分和評論 177
賬戶 177
完成估算 178
所有估算 179

第20章 發布計劃 181
估算速率 181
給故事安排優先級 181
最終的發布計劃 182
第21章 驗收測試 185
搜索測試 185
購物車測試 186
購買書 187
用戶賬戶 187
管理 188
測試限製條件 189
最後一個故事 190

第V部分 附 錄
附錄A 極限編程概覽 193
附錄B 參考答案 203

精彩書摘

　　我們需要一種協同工作的方法，讓雙方都不占絕對主導地位，共同麵對感情用事和辦公室政治化的資源分配問題。若資源分配問題完全落在一方，項目必定會失敗。如果隻讓開發人員來承擔這些問題（他們通常會被告知“我不關心你們怎麼做，但請你們在6月份之前完成”），他們可能會犧牲質量來換取額外的特性，也可能隻部分實現一個特性，或者自行做齣一些本該在有客戶和用戶參與情況下纔能做齣的決定。如果隻是客戶和用戶承擔資源分配的責任，那麼我們通常會在項目開始時看到一係列漫長的討論，項目中的特性逐漸減少。之後，在最終發布軟件時，隻剩下很少的功能，甚至少於被減掉的功能。

　　至此我們已經瞭解到，我們不能完美地預測軟件開發項目。當用戶看到軟件的早期版本時，他們會想齣新的點子，從而改變他們的觀點。由於軟件的這種不可控性，大部分開發人員都會遇到眾所周知的艱難時刻，估計需要多長時間纔能完事兒。因為這些因素及其他一些因素，導緻我們無法勾勒齣一幅完美的PERT圖①來展示項目中所有必須完成的事情。

　　……

前言/序言

　　數年前，Mike Cohn寫瞭這本User Stories Applied： For Agile Software Development，而我從2007年纔真正開始接觸敏捷，沒想到在2009年我竟有機會能夠參與翻譯這本有關用戶故事的經典著作，我感到十分的榮幸。
　　敏捷開發近些年在國內軟件開發公司中十分流行，因為它為軟件開發指引瞭一個方嚮。而用戶故事是敏捷實踐中一個十分重要的環節。它能幫助我們高效地收集客戶真正的需求。軟件開發都起始於需求收集與分析。如果一開始需求都弄錯瞭，軟件的成功也就無從談起。同時，用戶故事帶來瞭一個十分重要的作用，即高效溝通，不論是開發團隊與客戶的溝通，還是團隊內部成員之間的溝通。溝通使客戶和團隊成員都朝同一個方嚮前進，這意味著更少的錯誤，更少的浪費、風險和成本。用戶故事還是敏捷計劃與估算的重要基礎。
　　我十分有幸能在Irdeto BSS進行敏捷開發。在這裏，我們使用Scrum，結閤XP進行開發。用戶故事自然是不可或缺的。在這裏，每個團隊都有一個白闆，上麵貼有一些卡片。它們是這個Sprint團隊計劃完成的用戶故事以及這些故事劃分的任務。這些用戶故事卡片概要描述瞭需求，形如“作為(角色)，我想要(功能)，以此(商業價值)”，有時上麵還附著另一張卡片寫著驗收條件。在做計劃和開發的時候，團隊可以拿著這個用戶故事討論故事細節，故事如何纔算完成，等等，正如Ron Jeffries所描述的3C：Card(卡片)，Conversation(交談)和Confirmation(確認)。
　　用戶故事從始至終貫穿於整個開發流程。首先産品負責人根據收集來的需求編寫用戶故事，放入産品Backlog中。在Sprint計劃會議中，團隊成員討論其中的一些用戶故事，細化故事細節，確定驗收標準，使用Planning Poker(計劃撲剋)估算故事點。然後，將故事分成一些小的任務，並估算工作時間。最後，將故事放入Sprint Backlog中，並按優先級排序。Sprint開始時，故事卡片和任務卡片都放在白闆的To Do欄，團隊成員按故事的優先級挑選任務，將任務卡片挪到Doing欄。任務完成後，將任務卡片挪到Done欄。團隊盡可能地先完成優先級高的故事。在故事開發的初始階段，測試人員和産品負責人一起確認測試用例。故事的任務都完成後，産品負責人驗收並確認故事已完成，將故事卡片挪到Done欄中。如此完成整個Sprint的所有故事。Sprint結束時，團隊還要將完成的故事演示給利益相關人、其他産品負責人和團隊等。這樣，每個Sprint團隊都會通過完成一係列的用戶故事來嚮客戶輸齣商業價值。
　　這次翻譯我們一共四個人參與，我和石永超主要負責翻譯，滕振宇和李國彪主要負責審核。前期的第一個月，我們幾乎沒有什麼太大的進展。我們討論過後，發現這次翻譯其實是一個具有固定交付時間、固定範圍(21章和兩個附錄)且依賴虛擬兼職開發團隊的項目，包含開發(翻譯)和測試(審核)等工作，何不用敏捷的方式來開展？於是，第二個月開始，我們使用敏捷的思想來指導翻譯工作。我們首先把每一章當作一個用戶故事，每個故事估算一個故事點(這個是我們做的不足的地方，一個故事點顯然不能準確反映各章的不同篇幅)。我們以一個星期為一個迭代，用一份Excel文檔作電子白闆。每個周末固定時間用Skype開一次網上語音會議。如同Scrum的每日例會一樣，大傢迴答三個問題：這個星期我做瞭什麼，下個星期準備做什麼，有什麼睏難。然後討論大傢遇到的一些翻譯難點，統一一些術語的翻譯。大傢在完成每個星期的翻譯工作的同時，必須及時簡單地更新Excel中故事的狀態。這樣一來，每個人都能及時知道每一章的進度，哪一章可以審核，哪一章沒有人翻譯，可以任領。同時，Excel中還有燃盡圖，告訴我們離目標還有多遠，是否需要調整。如此，這份Excel文檔就成為我們的另一個溝通工具。另外，我們還有十分重要的工具，如同我們的軟件項目一樣，對於項目中的所有文件(包括電子白闆和術語錶)，我們使用版本管理工具Subversion和持續集成工具CruiseControl。我們每次簽入，持續集成工具都會立即發一封郵件通知大傢有新的改動，郵件包含有簽入的描述，這樣可以提醒大傢某一章翻譯完瞭，應該審核，等等 。這樣，從第二個月開始，我們的翻譯工作就始終保持穩定的進度，團隊通過更多更頻繁的迴饋不斷學習成長，持續改善譯稿和翻譯過程，最終按時交付瞭翻譯稿。
　　這次翻譯成為我們軟件開發之外的一次敏捷實踐，獲益良多。同樣，我們也希望能夠讓更多的人瞭解敏捷，讓更多從事軟件開發的人和其他行業的人從中獲益。翻譯這本書也希望能為傳播敏捷思想與方法盡一份力。讓更多的人瞭解用戶故事，使用用戶故事，帶來更多成功的項目。
　　在此感謝一起翻譯的夥伴們：李國彪、滕振宇和石永超。感謝你們讓我能夠獲得參與翻譯此書的機會，我從中學習瞭很多很多，不僅僅是對用戶故事更深入的瞭解，還有在這次翻譯過程中對敏捷更全麵、深刻的理解。

好棒的經典書目，瞭解到瞭什麼是oop

適閤敏捷入門看。

東西不錯！！！！！！！！

根據現有的氣象資料分析，6月22號開始的這場冷渦雷雨，正值副熱帶高壓北抬期間，而且冷渦深度南下，有西南、東南季風的水汽支援，有華北平原長期高溫的能量支持，強度不會比2011年6.23暴雨弱。或者可以這麼說，它將是2011年以來，京津冀遭遇的最強冷渦暴雨。北京氣象局已經連續報齣6月22、23號兩天大雨，中央氣象颱的降雨預報圖上，標誌著大暴雨的紅色區域已經進入北京，北京、天津、雄安新區都在暴雨範圍內。

京東快遞速度很快，書已收到，慢慢看。參加瞭敏捷項目管理培訓，一口氣買瞭敏捷三部麯。

這是一本不錯的翻譯書～

不錯不錯，值得一看的作品

不知道為啥其他人說不是新的，我收到的書包裝很完整，內容還沒看，等看完後在追加評價。

朋友推薦的，等空瞭好好看看，印刷質量還行！