讀書筆記1——《使用者故事與靈活方法》

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

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

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

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

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

客戶團隊的建構：測試、互動設計師、實際使用者、産品經理

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

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

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

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

對使用者或客戶有價值的：

。。。

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

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

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

虛構角色：不隻是給使用者角色去個名字，二是讓其做真正代表産品的目标使用者

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

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

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

傳統規範過程與靈活過程搜集需求的方式最大的差別在于，後者認為使用者故事沒法在單一階段擷取所有的使用者故事，而是依靠疊代來不斷加入使用者故事。

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

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

原型裡的流程，需要讓每個角色都重複走這個過程，是以在這之前要決定從哪種使用者角色開始；可用方框代表軟體的某個頁面，然後寫出角色在目前頁面可以做什麼，然後下一界面…逐漸讨論

畫原型的幾個問題有助于找到遺漏故事：使用者接下來最有可能做什麼？使用者會在這裡犯什麼錯誤？使用者在這裡會有什麼困惑？使用者需要什麼額外的資訊？

以上為讀書所感。