總覽
作者 Mike Cohn
豆瓣評分8.0分
我的評分7.5分
閱讀時間20200502-20200504
拆解
char 1 概覽
1. 為什么需要用戶故事
目的：?
（1）以更快的速度孕索、更少的消耗應對現(xiàn)實世界需求的快速變化苛秕。
（2）但不僅僅是為了快.淮逻，而是相比與傳統(tǒng)亢長的需求文檔桶雀，人的大腦更喜歡圖文并茂的說明欠动，且面對同一主題，只有通過多種不同方式、不同活動的刺激，大腦才能深刻理解并記憶鸵闪。
（3）可以從用戶角度出發(fā)描述功能，避免程序員自行其是暑诸，降低系統(tǒng)開發(fā)進入后期出現(xiàn)整體風險的可能蚌讼，為系統(tǒng)帶來更大的靈活性。
Ron Jeffries个榕，極限編程創(chuàng)始人之一篡石，提出了“3C原則”：card、conversation笛洛、confirmation夏志。
使用卡片記錄用戶故事：
①可以隱藏底層細節(jié)
②可以方便各方人員在白板上將其移動乃坤，以整體圖形的方式將客戶需求有關的內容深深印在團隊的腦海中
③可以從全局角度查看苛让，有利于項目的規(guī)劃。
④用戶故事的確認環(huán)節(jié)湿诊，則以反復的方式狱杰，與用戶確認某個具體使用場景中的關鍵細節(jié)，從而不會導致遺漏厅须。
2. 什么是用戶故事
用戶故事的組成
①一份書面的故事描述仿畸，用來做計劃和作為提示
②有關故事的對話，用于具體化故事細節(jié)
③測試朗和，用于表達和編檔故事細節(jié)且可用于確定故事何時完成
“卡片代客戶需求而不是記錄需求”错沽，卡片包含故事的文字描述，而需求細節(jié)要在“對話”中獲得眶拉，并在“確認”部分得以記錄? ---即：3C原則? ? ? ? ? ? ? ? ? ?
故事不具有契約性質千埃。達成的協(xié)議將由測試來記錄，這些測試將演示故事是否被正確開發(fā)忆植。
3. 規(guī)劃發(fā)布和迭代
一個發(fā)布由一個或多輪迭代組成放可。在規(guī)定的時間內發(fā)布用戶需求。
在進行發(fā)布規(guī)劃時朝刊，需要將故事進行優(yōu)先級排序耀里，一般考慮以下幾點：
①大部分用戶和客戶對特定特許的渴望程度
②小部分重要用戶和客戶對特定特性的渴望程度
③故事之間的關系。 e.g. “縮小”（zoom out ）這個故事的優(yōu)先級可能不高拾氓，但是它可能被看作是高優(yōu)先級的冯挎，因為它與高優(yōu)先級的另一個故事“放大”（zoom in）。??【即需求間的關聯(lián)性】
④當與開發(fā)人員的意見相左時咙鞍，應傾聽其觀點织堂，但要堅持客戶組織利益最大化的原則
⑤要考慮故事的實現(xiàn)成本叠艳，其成本由開發(fā)者給出，每個故事用故事點來估計易阳，故事點表明一個故事相對于其他故事的大小和復雜度附较。
4. 驗收測試
驗收測試是用來驗證實現(xiàn)用戶故事是否符合客戶團隊的期望。
測試應該盡早的在迭代中編寫測試用例潦俺，這樣可以盡早的查漏補缺拒课。?
char 2 編寫故事
1. 優(yōu)秀用戶故事的特點
獨立的（Independent）
?當故事之間存在依賴時，盡可能地將相互依賴的故事合并成一個大的事示、獨立的故事早像，或是用一個不同的方式去分割故事。
可討論的（Negotiable）
故事卡是對功能的簡短描述肖爵，細節(jié)將在客戶團隊和開發(fā)團隊的討論中產(chǎn)生卢鹦。如果我們在編寫故事的時候已經(jīng)知道了一些重要細節(jié)，那么可以在故事卡中以注釋的形式記錄這些細節(jié)劝堪。
過早地制定細節(jié)會帶來更多的工作量冀自，且會導致一種錯覺，故事卡反應了所有細節(jié)秒啦，沒必要跟客戶進行進一步的討論熬粗。
有意義的故事卡應：
①一兩句短語，用來提醒開發(fā)人員和客戶進行對話余境。
②一些注釋驻呐，用以表明在對話中待解決的問題
e.g.?
user story：公司可以用信用卡支付發(fā)布的工作信息的費用.
備注：我們將支持發(fā)現(xiàn)信用卡嗎？
用戶界面?zhèn)渥ⅲ翰恍枰獙ｉT的字段來輸入信用卡的類別卡片種類（可以從卡號的前兩位數(shù)字獲得該信息）
對用戶或客戶有價值的（Valuable to Purchasers or users）
保證每個故事對客戶或用戶有價值的最好辦法是讓客戶來編寫故事芳来。--??【不太可能】
應當避免那些只對開發(fā)人員有價值的故事含末。（技術細節(jié)）
可估計的（Estimatable）
導致故事沒辦法估計的原因有：
①開發(fā)人員缺少領域知識
②開發(fā)人員缺少技術知識
需要做預研，研究對應的技術知識
③故事太大了
可以按照“創(chuàng)建”即舌、“編輯”佣盒、“刪除”這些動作來分解故事；也剋按數(shù)據(jù)的邊界來進行分解
可測試的（Testable）? ? ?
成功通過測試才可以證明開發(fā)人員正確地實現(xiàn)了故事侥涵。通常不能被測試的故事發(fā)生在一些非功能性的需求上沼撕，這些需求和軟件有關，但不直接與功能有關
e.g.
用戶必須覺得軟件很好用芜飘；
用戶絕不需要花很長時間等待窗口出現(xiàn)务豺。
char 3 用戶角色建模
用戶角色 User Role ：是一組屬性的集合，這些屬性刻畫了一群人的特征以及這群人與系統(tǒng)可能的交互嗦明。
要堅持“用戶角色定義的是人笼沥，而不是其他外部系統(tǒng)”
1. 角色建模的步驟
①通過頭腦風暴，列出初始的用戶角色集合
②整理最初的角色集合
③整合角色
④提煉角色
??可以構建虛擬人物和極端人物
虛擬人物：一般為產(chǎn)品的目標用戶，可以使用戶故事更加生動和貼合需求
極端人物：一般在考慮新系統(tǒng)的設計是奔浅，可以使用極端人物馆纳，可以讓我們編寫出原本可能遺漏的故事，或其他靈感汹桦。（但不宜花過多的時間）
char 4 搜集故事
1. 如果進行需求調研
我們要承認無法一次性全部獲取到用戶的需求鲁驶，但還是要在早期嘗試編寫我們可以編寫的故事，即便還是史詩級故事舞骆。隨著時間的推移以及先前迭代中加入產(chǎn)品的故事晨汹，一個故事的相關性會有所變化缸逃。我們要用拖網(wǎng)（trawling）的形式主届，即“拖網(wǎng)漁船捕撈魚”一樣來收集用戶需求另锋。
2. 獲取需求的方法
用戶訪談
①訪談成功的關鍵之一是，選擇正確的受訪者
②要詢問開放式狈惫、與背景無關的問題
問卷調查
適用于收集已有故事的相關信息睛蛛、需要用戶就某些具體問題的回答。
不適合作為捕獲新故事的主要方法胧谈。
觀察
觀察可以讓我們快速直接地從用戶那里獲得反饋忆肾，從而可以更早、更頻繁地發(fā)布軟件第岖。
故事編寫工作坊
是開發(fā)人員难菌、用戶试溯、產(chǎn)品客戶和其他對編寫故事有幫助的人共同參加的會議蔑滓。
在工作坊期間，參與人員編寫盡可能多的故事遇绞，此時不對故事排優(yōu)先級键袱。
??【類似頭腦風暴，適用于研發(fā)新產(chǎn)品】?
char 5 與用戶代理合作
當我們無法接觸到真正是使用用戶時摹闽，就需要求助與用戶代理（user proxy）蹄咖，他們自己可能不是用戶，但是在項目里代表著用戶付鹿。
選擇合適的用戶代理對于項目的成功至關重要澜汤，但是要充分考慮潛在用戶代理的背景和動機。
1. 用戶代理有哪些
① 用戶的經(jīng)理
②開發(fā)經(jīng)理
③銷售人員
④領域專家
⑤市場營銷團隊
⑥以前的用戶
⑦培訓師和技術支持
⑧業(yè)務分析師或系統(tǒng)分析師
2. 設立客戶團隊
當我們沒辦法接觸實際的使用用戶時舵匾，且又為了避免用戶代理的“一面之詞”俊抵，我們可以設立客戶團隊，來盡量獲取到非偏頗的用戶故事坐梯。
設立用戶團隊的方法
① 邀請真實用戶加入徽诲。如果有不同類型的用戶使用軟件，試著邀請每種類型的用戶
② 在客戶團隊中確定一位“項目負責人”，主要負責協(xié)調客戶團隊的協(xié)作谎替，盡力做到傳遞一致的信息偷溺。
③ 確定項目成功必須的關鍵因素。
char 6 用戶故事驗收測試
驗收測試提供了確認故事是否被完整實現(xiàn)的基本標準钱贯。
在一個敏捷的由故事驅動項目中挫掏，測試不是一個與開發(fā)相對抗的活動。發(fā)現(xiàn)bug時秩命，不應該有“被我逮到了”的心態(tài)砍濒。若有bug直到系統(tǒng)投產(chǎn)的時候才被發(fā)現(xiàn)，團隊成員不應該相互推卸責任硫麻，應以“我們共同負責”的心態(tài)防范這種事情發(fā)生爸邢。
測試的目的是發(fā)現(xiàn)并消除bug，沒有必要追求100%代碼覆蓋率或測試所有的邊界條件拿愧「芎樱可以運用我們的直覺、知識和過去的經(jīng)驗來指導測試浇辜。--??【測試人員應該要遍歷所有邊界條件券敌，產(chǎn)品可以不用】
1. 什么時候開始寫測試用例
為了讓程序員盡早了解這些信息，應當在為這個故事編寫代碼前就開始制定驗收測試柳洋。
??【測試用例評審】
在需求宣講后進行測試用例評審待诅，可以在測試用例評審過程中確認開發(fā)團隊對需求的理解，也可以在測試用例過程評審中重新審視需求熊镣，看需求有哪些分支未考慮周全卑雁。
恰當編寫測試用例的時機：
①開發(fā)人員和客戶討論故事且需要記錄明確的細節(jié)時
②在迭代開始時，在寫代碼前作為一項專門的任務
③在開放中或之后任何時候發(fā)現(xiàn)新的測試時
為了測試用例的完整绪囱，應要自問：
①關于這個故事测蹲，程序員還需要知道什么？
②對怎么實現(xiàn)這個故事鬼吵，我的想法是什么扣甲？
③有沒有一些特殊情況會使這個故事有不一樣的行為？
④這個故事在什么情況會出錯齿椅？
2.多少測試才算多琉挖？
只要這些測試還在繼續(xù)為故事增加價值和使它更加清晰，那么就應該繼續(xù)編寫測試涣脚。
但是客戶不負責定義所以可能的測試示辈，客戶應該更專注于能向開發(fā)團隊說明故事意圖的測試。
3. 測試類型
用戶交互測試：確保所有用戶交互組件如期工作涩澡。
可用性測試：確保程序號用顽耳。
性能測試：測量應用程序在各種負荷下的工作狀況坠敷。
壓力測試：使應用程序在用戶和事務的極限值情況或其他任何讓應用程序處在壓力下的情況運行。
char 7 優(yōu)秀用戶故事準則
為了確定用戶故事射富，可以從每個用戶角色使用系統(tǒng)的目標開始考慮
當用戶故事較大時膝迎，可以將它分割成貫穿應用程序所有層面的故事，即可以提供某種程度的完整（end-to-end）的功能
如果有項目領域和環(huán)境的需要胰耗，可以用其他需求搜集或文檔技術來補充故事
可以為故事創(chuàng)建卡片約束（即需求的約束條件）
不要讓故事過早涉及用戶界面
用主動語態(tài)來描述谷歌書
為單個用戶編寫故事限次，這時故事的可讀性通常是最強的
用戶故事要簡短，它的目的是提醒其要溝通柴灯。更多的細節(jié)conversation中討論卖漫。
char 8 估算用戶故事
用故事點（story point）來進行估算用戶故事的完成時間。
故事點代表hi見的模糊單位赠群，可以是一個理想日的工作羊始，也可以是一個理想周的工作。
故事點應該由各個團隊來定義自己認為合適的故事點查描。
對于用戶故事點突委，開發(fā)人員的職責：
①負責用一個方式定義故事點，并且對團隊可用和相關的冬三。努力保證這個定義的一致性匀油。
②負責給出誠實的估算。不屈服于誘惑或壓力二給出低的估算
③負責以團隊估算
④負責估算應與其他估算一致勾笆。即工作量故事要統(tǒng)一敌蚜，大小相似的需求，則工作量時間應一樣
客戶職責
負責參加估算會議窝爪，但是你的任務是回答問題并澄清故事細節(jié)弛车。不必參加故事估算
char 9 發(fā)布計劃
發(fā)布計劃涉及到用戶故事優(yōu)先級的排序。我們需要確定哪些故事要排在這個迭代的發(fā)布計劃中酸舍。
1. MoSCow原則
必須有（Must have）：指系統(tǒng)的基本功能
應該有（Should have）：指很重要但短期內有替代解決方法的功能帅韧。如果項目沒有時間約束里初，則通常認為應該有的功能是強制性的
可以有（Could have）：指如果沒有時間可以在發(fā)布中不考慮的功能
這次不會有（Won't have this time）：客戶期望擁有但同時承認需要在后續(xù)發(fā)布中實現(xiàn)的功能? ? ? ? ?
char 10 迭代計劃
1. 迭代計劃會議內容
①討論故事
②從故事中分解出任務
③開發(fā)人員承擔每個任務的職責
④討論過所有故事啃勉，并且接受所有任務后，開發(fā)人員單獨估計他們承擔的任務双妨，以確保他們不會做出過于樂觀的承諾淮阐。
char 11 測量并監(jiān)控速率
??【實際上就是團隊中迭代的進度及開發(fā)的速率】 對于SM而言，可以知道自己的團隊完成一個用戶故事需要多長時間刁品。
迭代燃盡圖（Burndown Char）：可以了解到當前迭代的進展泣特，及剩余的工作量
char 12 故事不是什么
用戶故事不是IEEE830軟件需求規(guī)格
不管預想多么全面，我們都無法事先完全定義一個完整的具有相當規(guī)模的系統(tǒng)挑随；考慮用戶的目標比列出方案的特性更重要
用戶故事不是用例
用例往往比單個故事大状您，更容易包含關于用戶界面的嵌入式假設；
用例比用戶故事完整，用例存在于整個開發(fā)過程中膏孟，用戶故事往往只是暫時的
用戶故事與用例以不同的目的編寫眯分。用例被編寫成方便開發(fā)人員和客戶討論并達成共識。用戶故事編寫成方便計劃發(fā)布柒桑，并用于提醒需求細節(jié)的討論
用戶故事不是場景
交互式設計場景比用戶故事具體弊决，其提供的細節(jié)類型也不同于用戶故事。一個場景可以由多個用例組成魁淳，它可以組成許多用戶故事飘诗。
char 13 用戶故事的優(yōu)勢
用戶故事強調口頭溝通
人人都可以理解用戶故事
用戶故事的大小適合做計劃
用戶故事適合于迭代開發(fā)
用戶故事鼓勵延遲細節(jié)
用戶故事支持隨機應變的開發(fā)
用戶故事鼓勵參與性設計
用戶故事傳播隱性知識
char 14 用戶故事的不良征兆
故事太小
故事相互依賴
鍍金
故事中包含太多的細節(jié)
過早包含用戶界面細節(jié)
想得太遠
故事劃分太過頻繁
很難為故事安排優(yōu)先級
客戶不愿意寫用戶故事，為故事安排優(yōu)先級
char 15 Scrum與用戶故事
1.Scrum基礎
Sprint
實施Scrum過程的項目往往采用30天為周期的迭代界逛，其迭代就稱為Sprint昆稿，即迭代周期。
在每個Sprint開始的時候息拜，團隊需要確定這個Sprint需要完成而定工作貌嫡。
surum是一種迭代和遞增的過程。
產(chǎn)品Backlog
產(chǎn)品需求池该溯，即包含了產(chǎn)品所有待開發(fā)的需求列表
Sprint Backlog
團隊將需要計劃迭代的需求從產(chǎn)品Backlog中移入下個迭代的需求池岛抄，即為Sprint Backlog。
Scrum團隊
一個Scrum團隊通常由4-7個開發(fā)人員組成狈茉。有兩個承當特殊角色的人員是：產(chǎn)品負責人和ScrumMaster夫椭。
Scrum產(chǎn)品負責人：主要負責管理Product Backlog的內容以及排列優(yōu)先級
ScrumMaster：職能類似于項目經(jīng)理，只不過他不是管理者的角色氯庆，更像是研發(fā)leader蹭秋。
Sprint計劃會議?
在每個Sprint的開始是Sprint計劃會議。會議的參與者包含：PO堤撵、SM及團隊的所有開發(fā)人員（其他的管理人員或用戶代表也可參加）
在Sprint計劃會議仁讨，PO負責把待開發(fā)的高優(yōu)先級功能介紹給團隊成員 ；團隊成員根據(jù)所宣講的內容進行提問实昨。如果團隊達成一致無疑問洞豁，則可以將該功能從產(chǎn)品Backlog移到Sprint Backlog 中。團隊和產(chǎn)品負責人一起確定整個Sprint目標荒给。一旦Sprint開始丈挟，只有團隊成員才能向Sprint中添加工作。
?? 【類似需求迭代會議志电，但是需求迭代會議并不會像Sprint計劃會議一樣曙咽，在會議中確定需求的優(yōu)先級以及決定需要移入Sprint Backlog中；而是在需求迭代會議之前單獨與SM確定需求的優(yōu)先級及下個迭代的計劃挑辆。在需求會議的時候直接向團隊成員進行迭代需求的宣講例朱。
好處：避免需求迭代會議時間過長孝情；缺點：團隊其他成員的參與感不強】? ?
Sprint評審會議? ? ? ??
在每個Sprint結束時，都會有一個Sprint評審會議洒嗤。在會議上大家一起蘋果是否達到了Sprint計劃會上設定的Sprint目標咧叭。Sprint評審會議應該是非正式會議性質，盡量不要用幻燈片烁竭，準備時間也不要超過兩個小時菲茬，不要讓團隊成員感到干擾或是負擔
??同需求回顧會議類似，即在每個迭代需求上線后派撕，團隊成員舉行需求回顧會議婉弹。每個團隊成員進行發(fā)言，回顧在迭代過程中自己或他人做得到的好的终吼，做得不好的镀赌，以及對團隊的建議? ? ?
每日Scrum簡會（Daily Scrum）
團隊每天都會有一個簡單的會議，在會議上所有成員審查團隊的進度际跪，并根據(jù)需要做出調整商佛。每日Scrum簡會一般安排在9：00或是9：30。所有的團餐成員都需要參加姆打。會議必須簡短良姆，一般在15分鐘內結束，最多不能超過30分鐘幔戏。為了保證會議時間不至于過長玛追，很多團隊要求參加者站著開會，所以也被稱為“每日站會”
在每日Scrum簡會中闲延，每個團隊成員要求回答以下三個問題：
①你昨天做了什么痊剖？
②你今天打算做什么？
③有什么困難垒玲？? ? ? ? ? ? ? ? ? ? ? ? ? ?
?PS：不要讓每日Scrum簡會演變成成員向Sm匯報工作的會議陆馁。這個會議的重要目的是了解團隊成員自己負責的需求開發(fā)進度。PO也需要向其他團隊成員一樣匯報進度合愈。SM作為會議的組織者叮贩，需要保證會議的節(jié)奏。
管理層人員和其他人如果有興趣了解項目狀況想暗，可以參加妇汗；但是非團隊成員參加需要遵守一個規(guī)則：在會議中只有項目組內不人員才能夠提問。
附錄-極限編程概覽
1. 極限編程的原則
快速反饋（rapid feedback）
向客戶提供快速反饋说莫，并從反饋中學習
假設簡單（assuming simplicity）
喜歡簡單，并總是試圖在轉移到更復雜的解決方案前寞焙，先做簡單的解決方案
增量變化（incremental change）
通過小的储狭、增量的i安華提高軟件質量
擁抱變化（embrace change）
擁抱變化互婿，因為他們知道自己是真正地善于包容和適應
高品質產(chǎn)品（quality work）
堅決主張軟件應該始終展示出最高的質量工藝
2. 極限編程的價值
溝通（communication）
簡單（simplicity）
反饋（feedback）
勇氣（courage）
3. 極限編程的12個實踐
短交付周期（small releases）
計劃游戲（the planing game）
重構（refactoring）
測試（testing）
結對編程（pair programming）
持續(xù)一致的速度（sustainable pace）
團隊代碼所有權（team code ownership）
編碼標準（coding standard）
簡單設計（simple design）
隱喻（metaphor）
持續(xù)集成（continuous integration）
現(xiàn)成客戶（on-site customer）
?
?
