第3章 用戶角色建模：
用戶角色是一組屬性的集合拓诸，這些屬性刻畫了一群人的特征以及這群人與系統(tǒng)可能的交互绍昂。
用戶建模步驟：
l頭腦風(fēng)暴鳖悠，列出初始的用戶角色集合拓瞪。
l整理最初的角色集合
l整合角色
l提煉角色
一個用戶角色是一個用戶：已確認(rèn)的角色代表的是單一用戶官份。
盡量堅持一個原則：用戶角色定義的是人只厘，而不是其他外部系統(tǒng)。
角色特征是關(guān)于同屬這一類的用戶的事實或有用信息舅巷。
虛構(gòu)人物是假想的用戶角色代表羔味。創(chuàng)建虛構(gòu)人物需要的不只是在用戶角色上加一個名字，其描述應(yīng)當(dāng)是十分充分的钠右。要注意赋元，應(yīng)事先做好充分的市場和目標(biāo)用戶群調(diào)查，要確保虛構(gòu)人物能夠真正代表產(chǎn)品的目標(biāo)用戶飒房。
考慮極端人物很可能會讓你編寫出原本可能遺漏的故事搁凸。
第4章 搜集故事
創(chuàng)建故事最有用的一些方法：
l用戶訪談：
選擇正確的受訪者，開發(fā)人員也要積極尋找問題解決方案
開放式問題和背景無關(guān)的問題
l問卷調(diào)查：不適合作為拖網(wǎng)捕獲新故事的主要方法狠毯。
l觀察
l故事編寫工作坊：在較高的層次上討論
畫原型护糖，深度優(yōu)先，扔掉原型
維護(hù)一個代辦事項列表
重點放在數(shù)量上而不是質(zhì)量上
不要為每個故事都陷入長時間的討論中
不要在整個過程中評價某個故事的好或壞
第6章 用戶故事驗收測試
測試兩步流程：
1垃你、將測試要點記錄在故事卡的背面椅文，任何時候發(fā)現(xiàn)新的測試，都可以記錄到故事卡的背面惜颇。
2皆刺、將測試要點變成全面的測試，用來演示故事已正確凌摄、完整地實現(xiàn)羡蛾。
在寫代碼之前寫測試
客戶定義測試
測試是過程的一部分。產(chǎn)品經(jīng)理和測試人員共同負(fù)責(zé)列出詳細(xì)的測試锨亏。
客戶應(yīng)該更專注于那些能向開發(fā)團(tuán)隊說明故事意圖的測試
集成測試框架FIT
測試的是缺陷而不是覆蓋率
12月27日 小組分享會：
Groom需求討論痴怨，明確需求(小而多次，可拉多個人器予。類似于產(chǎn)品內(nèi)部的會浪藻，產(chǎn)出用戶故事)->P規(guī)劃會，明確需求細(xì)節(jié)->S站會->S演示會乾翔，按版本開（PO給高層做演示爱葵，展示成果）->R回顧會
R評審會施戴，按迭代開(研發(fā)給PO演示，集體評審萌丈，“我沒做錯”)
Q：為什么要使用用戶故事這種模式赞哗？
A:強(qiáng)制站在用戶的角度來看待需求，有獨立價值辆雾，方便快速交付肪笋。
可以立刻測試，提高效率
用戶故事編寫需要聽取技術(shù)團(tuán)隊的意見
Story劃分先基于經(jīng)驗度迂，然后明確關(guān)鍵點與技術(shù)難點進(jìn)行調(diào)整藤乙。Story要盡量小，滿足一個sprint能夠完成惭墓。
用戶故事是漸進(jìn)明細(xì)的湾盒。
理論上是客戶寫用戶故事，要貼近用戶
第5章與用戶代理合作
盡可能接觸真正的業(yè)務(wù)場景诅妹，盡可能接近真實的最終用戶。要充分與實際用戶進(jìn)行溝通毅人，確保真正理解用戶的意圖吭狡。
第7章 優(yōu)秀用戶故事準(zhǔn)則
要學(xué)會“切蛋糕”，分割成貫穿應(yīng)用程序所有層面的故事丈莺。
編寫封閉故事划煮，能讓用戶使用后覺得她完成了某個任務(wù)
不要過早涉及用戶界面
有些需求用非故事的形式表達(dá)也是可以的
不必編寫故事卡號
用戶故事不能取代與用戶的對話
第8章 估算用戶故事
無論什么時候獲得有關(guān)故事的新信息，都允許我們改變之前的想法?
這里面強(qiáng)調(diào)的核心是避免浪費缔俄。與其做出來的是廢品弛秋，還不如直接就不做了。
估算故事時俐载，一定要考慮完成這個故事需要做的所有事蟹略！
點數(shù)要合理，而不是絕對精確遏佣。
需要對估算做三角測量挖炬。將故事卡根據(jù)他們的大小貼在墻上是個三角測量的好方法。
估算方式要前后一致状婶。
精度隨故事大小增加而降低意敛。可以使用斐波那契數(shù)列膛虫。
注意：
團(tuán)隊之間的估算值沒有可比性草姻。
小故事的估算值總和沒必要一定等于史詩故事的估算值。
任務(wù)的估算值總和沒必要一定等于所屬故事的估算值稍刀。
不需要糾結(jié)什么加一起一致不一致的問題撩独，必然不一致。還是要清晰背后的每個元素的目的，Epic估算的目的是排年度或季度計劃（一般不估算）跌榔。Story估算是為了排發(fā)版和迭代計劃异雁。對于任務(wù)來說如果是Story的任務(wù)那么沒必要估算。
第9-11章
排列故事優(yōu)先級的方法：
1僧须、MoSCoW規(guī)則：
必須有的
應(yīng)該有的
可以有的
這次不會有
這一規(guī)則的問題是纲刀，有可能會傾向于全部為必須有的，基于這個可能會改變故事的優(yōu)先級排序担平。
2示绊、COD
采用一種模型，從多個維度來衡量故事優(yōu)先級：價值暂论、緊急程度面褐、研發(fā)成本、風(fēng)險等取胎。
分解任務(wù)需要靈活掌握：如果是很簡單的故事就沒有必要再拆分展哭，如果比較復(fù)雜，比如需要5人天闻蛀，就要做拆分匪傍，或者拆分后可以分給多個開發(fā)人員進(jìn)行并行開發(fā)，提高效率觉痛。
估算時使用故事點可以做到盡量客觀役衡，有一個估算標(biāo)準(zhǔn)可以參照。
