接觸了解用戶故事到現(xiàn)在蛤克，近十個月了，一直沒用這種方法進行完整的實踐夷蚊，趁著這兩天休假构挤，將前期了解的知識整理一下。
敏捷與極限編程
對于敏捷的粗淺了解僅有一些概念性的東西和最近一段時間的實踐撬码。敏捷強調(diào)遞增與迭代儿倒，在迭代中完善細(xì)節(jié)版保。
敏捷宣言
個人和交流重于過程和工具
正在運行的軟件本身重于復(fù)雜的文檔
與客戶的溝通和交流重于使用合同約束客戶
對變化的快速響應(yīng)重于跟隨計劃
極限編程
12個實踐
短交付周期：2周左右呜笑，通常1-3周，不超過4周
計劃游戲：發(fā)布計劃和迭代計劃彻犁。
重構(gòu)：不斷關(guān)注重構(gòu)叫胁。
測試：測試驅(qū)動開發(fā)，測試-編碼-測試-編碼汞幢。
結(jié)對編程
持續(xù)一致的速度
團隊代碼所有權(quán)
編碼標(biāo)準(zhǔn)
簡單設(shè)計
隱喻
持續(xù)集成
現(xiàn)場客戶：產(chǎn)品驼鹅、測試、開發(fā)團隊及時溝通森篷。
極限編程價值
溝通：面對面溝通
簡單：最簡單可行的方式
反饋：重視反饋输钩，越快越好
勇氣：重視勇氣
關(guān)鍵原則
快速反饋
假設(shè)簡單
增量變化
擁抱變化
高品質(zhì)質(zhì)量
用戶故事
概覽
用戶故事包括：描述、對話和注釋仲智。必須是：獨立的买乃、有價值的、可討論的钓辆、可估計的剪验、可測試的、規(guī)模合理的（小的）前联。史詩故事包括復(fù)合故事和復(fù)雜故事功戚，根據(jù)具體情況對用戶故事進行分割和合并。
描述是對用戶故事的簡單書面描述似嗤，它是主動的啸臀。
對話用來提醒客戶團隊和開發(fā)亟待討論的問題，不需要記錄太多細(xì)節(jié)烁落。
注釋主要包括驗收測試用例乘粒。測試用例在開發(fā)前已經(jīng)由產(chǎn)品和測試完成。
故事需要所有團隊成員經(jīng)過多輪的討論顽馋，才不斷完善谓厘。
優(yōu)秀用戶故事準(zhǔn)則
考慮每一個用戶角色，從目標(biāo)故事（高層次故事）開始衍生
切蛋糕原則：每個故事具有某種程度的完整性
編寫封閉的故事寸谜，有明確的范圍邊界
卡片約束
根據(jù)時間來確定故事規(guī)模和精確度
不要過早涉及用戶界面
有些需求并不是故事竟稳，可以使用其他的形式表達某些需求
故事里包括用戶角色
一個用戶故事只為一個角色編寫
以主動語態(tài)編寫
由客戶編寫
不需要編號，增加無謂的流程
有序號，表示優(yōu)先順序
故事卡用來提醒客戶和開發(fā)的對話討論他爸，要簡潔聂宾，盡量只有切人點提醒，不加入太多的細(xì)節(jié)
角色建模
列出角色（角色卡）
整理角色
提煉角色
角色特征（角色卡）
構(gòu)造虛擬人物
簡單分析極端人物
搜集故事
故事作坊：頭腦風(fēng)暴（記錄而不評價故事诊笤，重在數(shù)量而非質(zhì)量）系谐；簡單原型（類似簡單頁面結(jié)構(gòu)和功能的結(jié)合體），及時拋棄簡單原型讨跟。
用戶訪談：了解怎么使用開放式和背景無關(guān)的提問纪他。
觀察用戶
問卷調(diào)查
驗收測試
開發(fā)之前寫測試用例：客戶定義測試，開發(fā)會定義一些其他測試晾匠。測試用例編寫的時機包括：討論需要記錄明確的細(xì)節(jié)時茶袒；寫代碼之前作為一項任務(wù)；開發(fā)過程中或之后發(fā)現(xiàn)新的測試時凉馆。
產(chǎn)品和測試共同編寫詳細(xì)的測試薪寓，產(chǎn)品帶來目標(biāo)，測試帶來懷疑的心態(tài)
開發(fā)團隊會為很多詳細(xì)的用例寫單元測試澜共，客戶不負(fù)責(zé)定義所有可能的測試向叉，應(yīng)該更專注于那些向開發(fā)團隊說明故事意圖的測試
測試類型
集成測試
交互測試
可用性測試
性能測試
壓力測試
注意：測試的是缺陷，而不是覆蓋率嗦董；高度合作的團隊心態(tài)：不應(yīng)該推卸責(zé)任母谎，而應(yīng)該是我們共同負(fù)責(zé)；理清測試重點展懈。
故事點估算
開發(fā)和客戶團隊參與销睁，以團隊估算
每個開發(fā)人員估算，經(jīng)過多輪估算得出估算值
三角測量：比較故事的故事點存崖；列出所有故事的故事點冻记，按故事點排列比較
使用故事點：史詩故事不需要與拆分后的故事點數(shù)值相同
制定發(fā)布計劃
莫斯科原則MoSCoW
必須有的（基本功能）
應(yīng)該有的（重要但短期內(nèi)有替代解決方案的功能）
可以有的（沒時間就不考慮的）
這次不會有（客戶期望擁有但同時承認(rèn)需要在后續(xù)發(fā)布中實現(xiàn)的功能）
方法
根據(jù)用戶的廣泛性和重要性、故事之間的關(guān)系来惧、時間等制定優(yōu)先級
制定優(yōu)先級前應(yīng)該先估算故事點
價值優(yōu)先or風(fēng)險優(yōu)先
根據(jù)架構(gòu)需要安排優(yōu)先級
確定迭代周期時間長度
從故事點到預(yù)計工期
初始速率：歷史速率or進行一輪迭代試試or猜猜猜
開發(fā)人員幫助排列優(yōu)先級冗栗，提供信息，在基礎(chǔ)性需求供搀、架構(gòu)需求與其他需求之間取得權(quán)衡
產(chǎn)品故事有順序編號
制定迭代計劃
討論故事：開發(fā)人員沒有必要理解故事所有的細(xì)節(jié)隅居；客戶克制，不要改變優(yōu)先級
從故事中分解任務(wù)
某些任務(wù)不需要在每個版本的故事中都列出（以前的迭代中了解或全局的規(guī)范）
開發(fā)人員承擔(dān)每個任務(wù)的職責(zé)
接受任務(wù)后葛虐，開發(fā)人員單獨估計任務(wù)
測量并監(jiān)控速率
根據(jù)已完成的故事測量速率胎源，不急于調(diào)整，在多輪迭代有穩(wěn)定速率后調(diào)整發(fā)布計劃
幾個圖
計劃速率和實際速率（故事點-迭代次數(shù)）
計劃故事點和實際故事點（累計故事點-迭代次數(shù)）
迭代燃盡圖（剩余故事點數(shù)-迭代次數(shù)）
每日燃盡圖（剩余小時數(shù)-天）反應(yīng)剩余工作量：開發(fā)人員剩余工作時間可調(diào)整屿脐，但應(yīng)該在開始盡可能合理評估涕蚤；可以增加新的必須的任務(wù)
用戶故事不良征兆
故事太小
故事互相依賴
開發(fā)人員鍍金
故事中包含太多細(xì)節(jié)
故事中太早出現(xiàn)用戶界面
想得太遠
故事劃分太過頻繁（故事太大宪卿，一輪迭代難以完成；故事包括高優(yōu)先級和低優(yōu)先級的子故事）
很難為故事排優(yōu)先級（故事太大万栅；不具有直接商業(yè)價值的用戶故事）
用戶故事與用戶界面 （敏捷版以使用為中心的設(shè)計）
用戶角色建模
捕撈高層次的用戶故事
排列故事優(yōu)先級
精煉高優(yōu)先級和中等優(yōu)先級的故事
對故事整理分組
建立書面的原型
精煉該原型
開發(fā)
客戶團隊
開發(fā)團隊
