使用者故事與敏捷方法第一章是對使用者故事的概覽。
首先第乙個問題使用者故事是什麼？使用者故事描述了對使用者、系統或軟體購買者有價值的功能。使用者故事由三個方面組成，包括1 .乙份書面的故事描述，用來做計畫和作為提示。2.有關故事的對話，用於具體化故事細節。3.測試，用於表達和編檔故事細節且可用於確定故事何時完成。
然後第二個問題細節，故事的細節可以用另外的使用者故事來描述，多個小故事遠遠勝於乙個龐大的故事。書上將大的故事成為史詩故事，那些史詩故事可以分為多個小故事。例如將「使用者可以搜尋工作」分為1.使用者通過地區、薪水範圍、職位、公司名和發布日期來搜尋。2.使用者可以檢視搜尋結果中的每個工作的資訊。3.使用者可以檢視發布工作的公司的詳細資訊。但是故事並不一定要分解到可以覆蓋到每個細節。一些細節可以讓開發團隊和客戶討論，換句話說要讓這些細節變得重要時才被討論。
第三個問題是使用者期望，要將使用者期望記錄下來在紙質卡片的背面或者是電子文件的空白處。讓開發人員了解客戶的期望。客戶團隊是因為找不到專職人員排列工作的優先順序，以及回到開發人員的問題而建立的，它理應包括滿足使用者需求的所有人，其中有測試人員，產品經理，實際使用者，互動設計師。
第四個問題使用故事的過程是怎麼樣的？在傳統的面向瀑布的模型中只有在開始和結束時參與。對於故事驅動的專案而言，客戶和使用者在整個過程都參與，他們在編寫使用者故事時承擔非常活躍的角色，尤其是在團隊極限程式設計時。編寫使用者故事的過程最好從考慮系統的使用者類別開始，客戶團隊最好包括這些實際的客戶類別，如果不能，則可以使用使用者角色建模代替。然後開始寫故事的初稿，初稿一般是在故事編寫工作坊中寫的，（使用者故事可以在專案生命週期的任何時候寫），大家充分發揮想象來寫故事。寫完故事初稿後，客戶團隊和開發人員一起選擇迭代的長度。每輪迭代客戶團隊高度參與故事和測試。確定迭代長度後，開發人員會估計每輪迭代做的事情，然後估計發布計畫。在迭代時把最高優先順序的故事放在第一堆，然後依次進行，直到專案完成。（每輪迭代之前客戶團隊可以修訂計畫，用實際速率來代替估計速率，並進行修正。）
第五個問題規劃發布和迭代，客戶和開發人員都要參與發布和迭代，排列故事優先順序時，應該堅持組織利益最大化，同時要聽從技術人員的意見。
第六個問題驗收測試。驗收測試是用來驗證使用者故事是否符合客戶團隊的期望。測試應該盡早在迭代中編寫，這樣客戶團隊的假設和預期會更早與開發人員溝通。
通過第一章的閱讀，我認識到，開發的過程使用者參與非常的重要，使用者故事在整個開發過程中起著主導作用，同時開發人員還要對使用者的故事提出技術上的修正和指導。客戶團隊和開發人員在開發過程中不斷修正方向最終才能完成任務。
《使用者故事與敏捷方法》閱讀筆記一
作者在文中給出了如下的定義 描述對使用者 系統或軟體購買者有價值的功能。我們不難看出，對於使用者故事，他的立足點是使用者，那麼他就是對使用者需求的描述。在bigmoneyjob 的例子中 作者給出了幾個事例故事 1 使用者可以搜尋職位 2 公司可以發布新職位 3 使用者可以限制瀏覽其簡歷的人。不難總...
使用者故事與敏捷方法閱讀筆記02
今天我主要閱讀了 使用者故事與敏捷方法 第 三 四 五章，這三章給我最深的感受是使用者故事蘊含著很多與寫 相似的方法與步驟 讀完第三章我發現，第三章講的是類似於給 虛構人物，類似於 不過在這裡主要是六部分 通過頭腦風暴，列出初始的使用者角色集合 整理最初的角色集合 整合角色 提煉角色 虛構人物 極端...
使用者故事與敏捷方法閱讀筆記02
這次讀的部分是第三章使用者角色建模。首先使用者角色是一組屬性的集合，這些屬性描述了一群人的特徵以及這群人與系統之間可能的互動。角色建模的步驟主要分為 1.通過頭腦風暴，列出初始的使用者角色集合。進行頭腦風暴時，要堅持 已確認的角色代表的是單一使用者 的原則。2.整理最初的角色集合移動卡片的位置，以表...