讀《用戶故事與敏捷方法》這本書有三天了，看了差不多快四分之一。慚愧的是看完后不能像大家那樣有很多總結，很快能舉一反三，有自己的想法等等，大概是看的書真的太少的緣故。不過目前對自己的要求也很明確，主要還是掃盲和快速入門。

流程：搜集需求，編寫用戶故事放入Backlog，計劃會議將故事細化、確定驗收標準，計劃撲克估算故事的、講故事分成小任務、估算工作時間、將故事放入Sprint Backlog，優先級排序…

故事有三個方面因素需要考慮：故事描述、故事細節、測試故事的部分。傳說中的3C.

故事的關鍵在于寫下來的是對客戶有價值的地方。

用戶故事的描述要控制在合理且實際的范圍。具體的故事細節可以不用在意，可以讓開發團隊和客戶后面慢慢討論。

客戶團隊的構建：測試、交互設計師、實際用戶、產品經理

驗收測試，在迭代開始前或中即可開始。

優秀的用戶故事應當具備的幾個特點：獨立的、可討論的、對用戶或客戶有價值的、可估計的、小的、可測試的 （INVEST）

獨立的：是為了避免故事間的依賴；

可討論的：強調了需求的對話的必要性

對用戶或客戶有價值的：

。。。

給故事加上注釋的最好方法是給它編寫測試用例。

用戶角色確定的根本目的是為了使我們站在用戶的角度去思考問題，以此讓影響到項目成敗的那些角色感到滿意

角色建模：頭腦風暴（開發人員及客戶…）--> 整理角色集合? -->整合角色-->提煉角色（定義角色特征）

虛構角色：不只是給用戶角色去個名字，二是讓其做真正代表產品的目標用戶

極端人物：能夠搜集到被遺漏的故事

引出&捕捉式搜集需求的方式不可取，問題在于：用戶并不知道所有需求，不能單純依靠引出。

trawling拖網，根據重要性、有迭代的、不是所有的都捕捉到的方式。而使用該技能的重要要素是，知道去哪里能捕捉到需求（對人的要求）！！

傳統規范過程與敏捷過程搜集需求的方式最大的區別在于，后者認為用戶故事沒法在單一階段獲取所有的用戶故事，而是依靠迭代來不斷加入用戶故事。

但是另一點就是，要盡早嘗試編寫故事，并且故事描述較模糊也是可以容忍的，然后不斷演進使其為更小的、更有用的多個故事。

搜集故事的方法：用戶訪談（真實用戶、不同角色用戶、與用戶一同尋找需求、開放式及背景無關式提問）、問卷調查（捕撈故事法中不太有效）、觀察（有機會了解到用戶實際子做的事情時）、故事編寫工作坊（重點在于數量而非質量，結合頭腦風暴及簡單原型，甚至可以結合競爭對手或同類產品）

原型里的流程，需要讓每個角色都重復走這個過程，所以在這之前要決定從哪種用戶角色開始；可用方框代表軟件的某個頁面，然后寫出角色在當前頁面可以做什么，然后下一界面…逐步討論

畫原型的幾個問題有助于找到遺漏故事：用戶接下來最有可能做什么？用戶會在這里犯什么錯誤？用戶在這里會有什么困惑？用戶需要什么額外的信息？

以上為讀書所感。

總結

以上是生活随笔為你收集整理的读书笔记1——《用户故事与敏捷方法》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。