在遠古時代，文字沒有出現之前。知識的傳承靠口口相傳，不管隔了多少代，其準確性很高。文字出現後，我們大腦中的這種技能反而逐步衰退。於是各種軟件、各種方法充斥着我們，左右着我們。各位是否也有相同的想法？試想一下，上節課我們講了什麼？每次應允別人的承諾，我們轉過頭就忘記？比如忘記約會，忘記洗車、忘記寫日報？
“要想知道栗子的味道，你得咬一口”這個真理樸實，正確。當用戶提出一款軟件時，我們不要只想着從技術的角度，認爲用戶不專業，他的需求是錯誤的。如果他專業，就沒我們啥事了。用戶大腦中的需求是離散的，不可控的，這時，就需要我們放下成見，彼此真誠相對，讓用戶參與進來，通過各種方法，一條條梳理，直至雙方的理解是一直的。
其作用：1.我們弄懂了用戶爲何會這樣想。2.用戶通過親身參與，頭腦中的需求逐漸變成技術可理解的。“求同去異”是一個很難的過程，需要雙方彼此做出改變，很難.....，往往難得事情纔是最重要的，要不怎麼會有“戰勝困難”的偉大，痛苦成就了歡樂。
軟件的最大價值只有在用戶認可，使用纔算真的有價值。“再牛逼的算法，再嚴謹的邏輯”不符合用戶實際需求，都是白費力氣。“當顧客很飢餓時，他只需要的立馬填報肚子的食物，而不是需要幾天或者幾個月才能做好的滿漢全席”。
扯遠了，迴歸正題。因用戶對軟件領域不專業，腦中對需求沒有一個正確的定論。就需要我們專業人士，運用特殊的方法，梳理用戶真正的意圖。“用戶故事”無疑是最好的方法之一，其包含三個要素“角色、活動、商業價值”，用戶故事的表達方式：”作爲一個<角色>，我想要<活動>，以便於<商業價值>。
“例：作爲一個很飢餓的顧客，我想要一份食物，來填飽我的肚子“。這就是一份明確的用戶故事。
那麼要實現這種記錄方法，有三個原則：
卡片：故事一般寫在小的記事本上。故事儘可能對當前的需求簡單的描述，其作用是爲了以後的交談；
交談：故事背後源於我們和客戶/產品負責人的溝通交流；
確認：可以確認驗證的正確結果、通過驗收測試確認的用戶故事被正確完成，纔算整的完成。
敏捷開發故事細化爲開發提供了可執行標準，其特點是快速迭代，故一個用戶故事的大小和複雜度應該在一個迭代週期內完成。如果是史詩那樣的故事，可能會導致它需要“幾代人”（幾波人，即有可能只做了一半，團隊砍了，新人接手），其弊端不是本次重點。每個人物最好不要超過8小時，如果超過8小時，說明任務的劃分是有問題，如何做到事事清日日清？
用戶故事的6個特性：
- 獨立性
- 可協商性
- 有價值的
- 可以估算的
- 短小的
- 可測試的
正是每個故事的獨立性，才保證其短小，可以估算，也可協商（更改某個故事對系統的影響很小），最終交付給用戶纔是可以測試的，只有軟件通過用戶的測試，軟件的價值纔會被最大化。要避免”孤芳自賞“，做技術的，多少有點讀書人的清高，說通俗點就是有”臭老九“的毛病，我的產品是最好的，你客戶不認可，是你的問題。要學會轉變（不是服軟），運用有用的方法，來實現可協商，可以估算、等六個特性，做到剛柔並濟....
確定用戶故事的優先級，有幾種方法：
相對優先級=價值/工作量
莫斯科規則：必須有的、應該有的、可以有的、這次不會有的；按照價值進行分類，優先處理必須要的和應該有的。如果離約定交付的日期還有一定的空餘時間，可以考慮可以有的，反之跳過。這次不會有的，不多少，看字面各位應該會理解。
卡諾模型：1.基礎型需求；2.期望型需求；興奮型需求。搞過KPI的都會知道，關於目標會有門檻值、期望值、挑戰值，往往我會按挑戰值的來做，最終有可能實現期望值，別問我怎麼知道的.....
風險--價值指標：確定優先級的同時，要考慮風險和價值，至於是先處理哪一個？滅火時，消防員會優先處理哪一個？娃娃一個不哭、一個哭鬧時，我們會優先關注哪一個？
確定好用戶故事的優先級後，我們將這些故事組成產品待辦列表（product backlog），根據backlog和團隊速率（至於如何估算，以後會講）來估算故事規模，並確定最終的發佈計劃。
請根據下面的圖片，構思一下用戶故事