用戶故事概念&內(nèi)容
這里羅列概念比較干，但還是不得不說碎乃，因?yàn)檫@些是引出用戶故事編寫思路的引子。如果已經(jīng)了解了可直接看后面“我的用戶故事模板”部分～
用戶故事三要素
角色、目標(biāo)（收獲）琳猫、價(jià)值
用戶故事3C原則
卡片(Card)、交談(Conversation)和確認(rèn)(Confirmation)
-
卡片（Card）：最初的用戶故事一般在小卡片上寫著故事的簡短描述矩桂，規(guī)則和完成標(biāo)準(zhǔn)（AC-用例）沸移。
卡片（Card）
現(xiàn)在都電子化了，所以如果覺得用物理卡片麻煩侄榴，可以用電子文檔記錄雹锣。
-
交談（Conversation）：用戶故事背后的細(xì)節(jié)來源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通，確保各方對故事的理解正確癞蚕。同時(shí)也是卡片中的規(guī)則和完成標(biāo)準(zhǔn)的來源蕊爵。
交談（Conversation） -
確認(rèn)（Confirmation）：通過驗(yàn)收測試確認(rèn)用戶故事被正確完成，也就是保證滿足卡片中的規(guī)則和完成標(biāo)準(zhǔn)桦山。
確認(rèn)（Confirmation）
用戶故事INVEST原則
Independent（獨(dú)立的）攒射；Negotiable（可協(xié)商的）；Valuable（有價(jià)值的）恒水；Estimable（可評估）会放；Small（小的）；Testable（可測試的）钉凌。
Idependent（獨(dú)立的）
要盡可能的讓一個(gè)用戶故事獨(dú)立于其他的用戶故事咧最。用戶故事間保持獨(dú)立性不僅便于排列和調(diào)整優(yōu)先級，使得發(fā)布和迭代計(jì)劃更容易制定，便于獨(dú)立地理解矢沿、跟蹤滥搭、實(shí)現(xiàn)、測試以及頻繁交付捣鲸，也使得用戶故事的大小估算所涉及的范圍更清晰瑟匆，從而估算偏差更小。Negotiable（可協(xié)商的）
一個(gè)用戶故事的內(nèi)容要是可以協(xié)商的栽惶，用戶故事不是合同愁溜。一個(gè)用戶故事只是對用戶故事的一個(gè)簡短的描述，不包括太多的細(xì)節(jié)媒役；具體的細(xì)節(jié)在溝通階段產(chǎn)出祝谚。一個(gè)用戶故事帶有了太多的細(xì)節(jié)，實(shí)際上限制了用戶酣衷、團(tuán)隊(duì)的想法和溝通交惯。Valuable（有價(jià)值的）
每個(gè)故事必須對客戶具有價(jià)值（無論是用戶、購買方還是公司內(nèi)部角色）穿仪。用戶故事對于最終的用戶是有價(jià)值的席爽，因此應(yīng)該站在用戶的角度去編寫，描述的是一個(gè)一個(gè)的feature啊片，而非一個(gè)一個(gè)的task只锻。
這個(gè)特點(diǎn)促進(jìn)團(tuán)隊(duì)的開發(fā)和測試成員由傳統(tǒng)的指令式工作方式向自驅(qū)動的價(jià)值導(dǎo)向工作方式轉(zhuǎn)變，使團(tuán)隊(duì)中的每個(gè)人知道自己每天做的工作價(jià)值紫谷。Estimatable（可評估）
計(jì)劃會議里面一個(gè)很重要的環(huán)節(jié)齐饮，那就是故事點(diǎn)的估計(jì)。實(shí)際上就是對要開發(fā)的User Story進(jìn)行一個(gè)粗量級的估算笤昨，以便于團(tuán)隊(duì)能夠知道這個(gè)user story的復(fù)雜度（工作量）祖驱。
重點(diǎn)放在當(dāng)前迭代里能否按照該用戶故事的接收條件和團(tuán)隊(duì)定義的DoD(完成標(biāo)準(zhǔn))來完成這個(gè)用戶故事，如果不能完成瞒窒，給出理由捺僻，由PO來決定是否拆分或者重新設(shè)計(jì)用戶故事。
讓開發(fā)者難以估計(jì)故事的問題來自：對于領(lǐng)域知識的缺乏（這種情況下需要更多的溝通）崇裁，或者故事太大了（這時(shí)需要把故事切分成小些的）匕坯。Small（小的）
一個(gè)好的故事在工作量上要盡量短小，最好不要超過10個(gè)理想人/天的工作量,至少要確保的是在一個(gè)迭代中能夠完成拔稳。用戶故事越大葛峻，在安排計(jì)劃，工作量估算等方面的風(fēng)險(xiǎn)就會越大巴比。Testable（可測試的）
一個(gè)用戶故事要是可以測試的泞歉，以便于確認(rèn)它是可以完成的逼侦。如果一個(gè)用戶故事不能夠測試匿辩，那么你就無法知道它什么時(shí)候可以完成腰耙。一個(gè)不可測試的用戶故事例子：軟件應(yīng)該是易于使用的。
我的用戶故事模板
上面的都是死的概念铲球，為了能真正理解挺庞，咱們可以推導(dǎo)自己理解的用戶故事模板。我根據(jù)前面提到的用戶故事三要素來思考：角色稼病、目標(biāo)（收獲）选侨、價(jià)值
角色：作為XX角色，
目標(biāo)（收獲）：我 希望/想要/需要 得到 XX 服務(wù)/結(jié)果/數(shù)據(jù)/承諾品如合同/聲望等然走，
價(jià)值：以便達(dá)到滿足角色XX需求（馬斯洛需求層次理論-生理援制、安全、歸屬芍瑞、尊重晨仑、自我實(shí)現(xiàn)）
注意這個(gè)模板中：
- 目標(biāo)（收獲） 中大部分時(shí)間不是表述具體的做什么，而是做什么后拿到的東西拆檬。具體做什么的一系列展開更像是根據(jù)用戶故事寫出的AC（用例）洪己。描述收獲而不是具體做什么，恰恰可以激發(fā)為怎么得到想要的東西讓大家面對面的去聊方案竟贯，這樣才能讓思維發(fā)散出去（INVEST中Negotiable原則）答捕。
- 價(jià)值 中角色需求的根本能歸結(jié)到馬斯洛需求層次理論，但用戶故事往往需要更具像化的表述屑那，用來更清晰的體現(xiàn)角色需求拱镐，如具像化的需求可能是：更高效、更省力持际、更好體驗(yàn)沃琅、更實(shí)惠（高性價(jià)比）、更健康选酗、更安全阵难、更滿足、更受尊重等等（INVEST中Valuable原則）芒填∥亟校可參考馬斯洛需求層次理論的細(xì)粒度劃分。
- 過程中殿衰，如果一個(gè)用戶故事很大朱庆，可以再將其盡可能拆分為獨(dú)立的小故事并且是可以驗(yàn)證的（INVEST中的Idependent、Small闷祥、Estimatable娱颊、Testable原則）傲诵。
實(shí)踐一下
幾乎每個(gè)公司都有客服人員，那我們就拿他們作為角色來寫一下他們的需求吧箱硕。作為員工拴竹，絕大部分人其實(shí)是為了獲得報(bào)酬而工作的。這么想的話整個(gè)過程就可以定義用戶故事為：
作為客服剧罩，我希望能夠獲得工作報(bào)酬栓拜，以便讓我能夠活著。
大家也許要笑了惠昔，但是我覺得這就是一個(gè)用戶故事幕与，因?yàn)樗衔抑罢f的用戶故事模板。但這個(gè)故事并沒有意義镇防，一是它太大了啦鸣，二是它不能指導(dǎo)產(chǎn)品需求的擴(kuò)展，更不用說用來優(yōu)化客服的工作来氧。
想一想诫给，一個(gè)客服來找產(chǎn)品經(jīng)理提需求，肯定是要結(jié)合客服平日最主要工作的收獲饲漾，如接受客戶咨詢并給予解答獲得好評蝙搔。那這個(gè)用戶故事該怎么寫？
作為客服考传，我希望能夠盡可能多的得到客戶好評反饋吃型，以便我能獲得更多的報(bào)酬。
相對第一個(gè)故事僚楞，這個(gè)用戶故事好多了是不是勤晚，起碼我們具像化了用戶的收獲，為之后的溝通討論奠定了基礎(chǔ)泉褐。但它還是有些大赐写，因?yàn)楦鶕?jù)這個(gè)故事我們起碼還無法評估怎么做。我們可以進(jìn)行故事的拆分有：
作為客服膜赃，我希望能夠盡可能多的得到客戶好評反饋挺邀，以便我能獲得更多的報(bào)酬。
- 作為客服跳座，我希望能夠在客戶咨詢時(shí)得到通知端铛，以便我立即能夠給予回應(yīng)。（更高效）
- 作為客服疲眷，我希望能夠在客戶咨詢時(shí)獲得客戶基本信息禾蚕，以便我快速準(zhǔn)確的解答用戶的問題。（更高效）
- 作為客服狂丝，我希望能夠獲得客戶的評價(jià)换淆，以便我的工作可被評估哗总。（更客觀）
上面拆分的3個(gè)用戶故事的用戶收獲和價(jià)值更加的具像化了，而且也更好評估了倍试。我們拿第一個(gè)用戶故事來模擬下可能的AC（用例）：
作為客服讯屈，我希望能夠在客戶咨詢時(shí)得到通知，以便我立即能夠給予回應(yīng)易猫。（更高效）
- AC1：在客戶發(fā)起咨詢時(shí)耻煤，客服能在電腦上收到一條彈出框提醒。
- AC2：客服能在彈出框提醒上直接進(jìn)入反饋頁面准颓。
- AC3：N個(gè)客服不會出現(xiàn)同時(shí)收到同一個(gè)客戶咨詢單的情況。
- AC4：棺妓。攘已。。
測試人需關(guān)注
了解用戶故事可以讓測試人員更好的了解產(chǎn)品經(jīng)理的思路和產(chǎn)品的重心怜跑，為我們分析產(chǎn)品需求提供工具样勃，同時(shí)也幫助我們對不符合用戶需求的產(chǎn)品設(shè)計(jì)提出質(zhì)疑，保證產(chǎn)品的走向性芬。實(shí)踐中峡眶，可以將用戶故事作為分析需求、跟蹤需求的方法植锉，起到綱領(lǐng)作用辫樱；而用例作為記錄需求細(xì)節(jié)的工具。
