敏捷項目管理-用戶故事

在遠古時代，文字沒有出現以前。知識的傳承靠口口相傳，無論隔了多少代，其準確性很高。文字出現後，咱們大腦中的這種技能反而逐步衰退。因而各類軟件、各類方法充斥着咱們，左右着咱們。各位是否也有相同的想法？試想一下，上節課咱們講了什麼？每次應允別人的承諾，咱們轉過頭就忘記？好比忘記約會，忘記洗車、忘記寫日報？

「要想知道栗子的味道，你得咬一口」這個真理樸實，正確。當用戶提出一款軟件時，咱們不要只想着從技術的角度，認爲用戶不專業，他的需求是錯誤的。若是他專業，就沒咱們啥事了。用戶大腦中的需求是離散的，不可控的，這時，就須要咱們放下成見，彼此真誠相對，讓用戶參與進來，經過各類方法，一條條梳理，直至雙方的理解是一直的。

其做用：1.咱們弄懂了用戶爲什麼會這樣想。2.用戶經過親身參與，頭腦中的需求逐漸變成技術可理解的。「求同去異」是一個很難的過程，須要雙方彼此作出改變，很難.....，每每可貴事情纔是最重要的，要不怎麼會有「打敗困難」的偉大，痛苦成就了歡樂。

軟件的最大價值只有在用戶承認，使用纔算真的有價值。「再牛逼的算法，再嚴謹的邏輯」不符合用戶實際需求，都是白費力氣。「當顧客很飢餓時，他只須要的立馬填報肚子的食物，而不是須要幾天或者幾個月才能作好的滿漢全席」。

扯遠了，迴歸正題。因用戶對軟件領域不專業，腦中對需求沒有一個正確的定論。就須要咱們專業人士，運用特殊的方法，梳理用戶真正的意圖。「用戶故事」無疑是最好的方法之一，其包含三個要素「角色、活動、商業價值」，用戶故事的表達方式：」做爲一個<角色>，我想要<活動>，以便於<商業價值>。

「例：做爲一個很飢餓的顧客，我想要一份食物，來填飽個人肚子「。這就是一份明確的用戶故事。

那麼要實現這種記錄方法，有三個原則：
卡片：故事通常寫在小的記事本上。故事儘量對當前的需求簡單的描述，其做用是爲了之後的交談；
交談：故事背後源於咱們和客戶/產品負責人的溝通交流；
確認：能夠確認驗證的正確結果、經過驗收測試確認的用戶故事被正確完成，纔算整的完成。

敏捷開發故事細化爲開發提供了可執行標準，其特色是快速迭代，故一個用戶故事的大小和複雜度應該在一個迭代週期內完成。若是是史詩那樣的故事，可能會致使它須要「幾代人」（幾波人，即有可能只作了一半，團隊砍了，新人接手），其弊端不是本次重點。每一個人物最好不要超過8小時，若是超過8小時，說明任務的劃分是有問題，如何作到事事清日日清？

---

用戶故事的6個特性：

1. 獨立性
2. 可協商性
3. 有價值的
4. 能夠估算的
5. 短小的
6. 可測試的

正是每一個故事的獨立性，才保證其短小，能夠估算，也可協商（更改某個故事對系統的影響很小），最終交付給用戶纔是能夠測試的，只有軟件經過用戶的測試，軟件的價值纔會被最大化。要避免」孤芳自賞「，作技術的，多少有點讀書人的清高，說通俗點就是有」臭老九「的毛病，個人產品是最好的，你客戶不承認，是你的問題。要學會轉變（不是服軟），運用有用的方法，來實現可協商，能夠估算、等六個特性，作到剛柔並濟....

肯定用戶故事的優先級，有幾種方法：

相對優先級=價值/工做量
莫斯科規則：必須有的、應該有的、能夠有的、此次不會有的；按照價值進行分類，優先處理必需要的和應該有的。若是離約定交付的日期還有必定的空餘時間，能夠考慮能夠有的，反之跳過。此次不會有的，很少少，看字面各位應該會理解。
卡諾模型：1.基礎型需求；2.指望型需求；興奮型需求。搞過KPI的都會知道，關於目標會有門檻值、指望值、挑戰值，每每我會按挑戰值的來作，最終有可能實現指望值，別問我怎麼知道的.....
風險--價值指標：肯定優先級的同時，要考慮風險和價值，至因而先處理哪個？滅火時，消防員會優先處理哪個？娃娃一個不哭、一個哭鬧時，咱們會優先關注哪個？
肯定好用戶故事的優先級後，咱們將這些故事組成產品待辦列表（product backlog），根據backlog和團隊速率（至於如何估算，之後會講）來估算故事規模，並肯定最終的發佈計劃。

---

請根據下面的圖片，構思一下用戶故事