《用戶故事與敏捷方法》讀書筆記

1. 什麼叫用戶故事
   描述了對用戶、系統或軟件購買者有價值功能。
2. 用戶故事的組成
   1）一份書面的故事描述，用來作計劃和做爲提示；
   2）有關故事的對話，用來具體化故事細節；
   3）測試，用於表達和編制故事細節且可用於肯定故事什麼時候完成。
3. 如何建立用戶故事
   1）用戶訪談
   2）問卷調查，不適合做爲拖網捕獲新故事主要方法
   3）觀察
   4）故事編寫工做坊：會議，快速捕獲故事最有效辦法，結合頭腦風暴最佳要素和簡單原型法
4. 用戶故事的特徵
   1）獨立的
   2）可討論的
   3）對用戶或客戶有價值的
   4）可估計的
   5）小的
   6）可測試的
5. 用戶故事的優點
   1）用戶故事強調口頭溝通
   2）人人均可以理解用戶故事
   3）用戶故事適合於迭×××發
   4）用戶故事鼓勵延遲細節
   5）用戶故事的大小適合作計劃
   6）用戶故事支持隨機應變的開發
   7）用戶故事鼓勵參與性設計
   8）用戶故事傳播隱性知識
6. 用戶故事準則
   1）從目標故事開始
   2）切蛋糕（slicing the cake）
   3）編寫封閉的故事，值那種隨着一個有意義的目標的實現而結束的故事，能讓用戶使用後以爲他完成了某個任務
   4）卡片約束
   5）根據實現時間來肯定故事規模
   6）不要過早涉及用戶界面
   7）有些需求並非故事
   8）在故事裏包括用戶角色
   9）只爲一個用戶編寫
   10）以主動語態編寫
   11）由客戶編寫故事
   12）向故事卡編號說「不」
   13）不要忘記意圖
7. 用戶故事的不足
   1）在用於大量用戶故事大型項目中，故事間關係錯綜複雜，難於捉摸
   2）若是開發過程規定要有需求可追溯性，必然離不開額外文檔
   3）不適用特大規模，多團隊結構
8. 如何估算故事
   1）不管何時得到有關故事新信息，都容許咱們之間改變想法
   2）適用於史詩故事和小故事
   3）不須要花不少時間
   4）提供進度和剩餘工做的有用信息
   5）不太精確的估算也不會有太大問題
   6）能夠用來制定發佈計劃
9. 如何發佈計劃
   發佈計劃排列優先級方法：莫斯科（MoSCow）規則
   1）必須有，指系統的基本功能
   2）應該有，指很重要但短時間內有替代解決方法的功能
   3）能夠有，指若是沒有時間就能夠在發佈中不予考慮的功能
   4）此次不會有，指客戶指望擁有但同時認可須要在後續發佈中實現的功能
10. 敏捷項目與傳統規範過程區別
    1）傳統規範過程：在項目早期正確地獲取寫出全部的需求
    2）敏捷項目：沒有一種理想辦法能夠在一個單一階段獲取全部用戶故事
11. 用戶故事與IEE830軟件需求規格、用例和交互場景設計的區別
    1）用戶故事與IEE830需求規格
    a.IEE830側重於關注需求的檢查清單，而不是用戶目標
    b.IEE830在寫下全部需求前，每一個需求成本是不可見的
    2）用戶故事與用例
    a.範圍：故事範圍小，對故事大小有限制
    b.完整性
    c.壽命：用例做爲永久性工做持續存在，故事不會超過包含他們的迭代
    d.用例容易包括用戶界面和細節
    e.目的：編寫故事是爲了更方便發佈計劃和迭代計劃
    3）用戶故事與交互場景設計：範圍和細節
12. Scrum
    1）迭代的過程是一種持續改進的過程，相似於雕刻
    2）遞增的過程是指團隊按照功能點開發和發佈軟件
    3）Scrum和XP都是基於遞增和迭代方式的過程
    4）採用30天爲週期迭代，稱爲Sprint
    5）Scrum沒有區分架構師和測試人員角色，而是有產品負責人和ScrumMaster
    a.產品負責人：主要負責管理product backlog內容和排列優先級
    b.ScrumMaster：負責爲團隊排除障礙
    6）產品backlog：全部待開發產品功能列表
    7）一旦sprint開始，只有團隊成員才能向sprint中添加工做
    8）每日scrum短會：
    a.你昨天作了什麼
    b.你今天打算作什麼
    c.有什麼困難
    9）每日scrum短會目的
    讓每一個人在本身以及同事面前作出承諾，是團隊成員之間的承諾
    10）用戶故事、sprint評審會議
    好處就是很容易評估sprint中哪些部分已經完成
    11）用戶故事、每日scrum短會
    確保整個團隊關注於完成餘下面向客戶和最終用戶的任務
13. XP極限編程
    1）XP的12種實踐
    a.短交付週期（small releases）：每輪迭代一般是1-3周時間
    b.計劃遊戲（the planning game）：發佈計劃和迭代計劃名稱
    c.重構（refactoring）：重組或重寫代碼以改善代碼
    d.測試（testing）
    e.結對編程（pair programming）
    f.持續一致的速度（sustainable pace）
    g.團隊代碼全部權（team code ownership）
    h.編碼標註（coding standard）
    i.簡單設計（simple design）
    j.隱喻（metaphor）：提供了一個他們如何思考系統的參照體系
    k.持續集成（continuos intergration）
    l.現場客戶（on-site customer）
    2）XP的價值
    a.溝通
    b.簡單
    c.反饋
    d.勇氣
    3）XP的關鍵原則
    a.快速反饋
    b.假設簡單
    c.增量變化
    d.擁抱變化
14. 其它名詞定義
    1）史詩故事（epic）
    指故事很大
    2）面向瀑布模型和故事驅動
    a.面向瀑布模型：用戶和客戶在蒐集需求後到驗收之間的這段時間幾乎都不參與
    b.故事驅動：客戶與用戶在項目過程當中全程參與
    3）故事卡由客戶團隊編寫
    a.最瞭解如何表達須要實現需求
    b.共同肯定故事細節和安排故事優先級
    4）速率：是開發人員能夠在一輪迭代中完成的工做量
    5）拖網
    描述收集需求的過程，需求像魚同樣，會成長也會死亡，需求會隨着時間推移變化，須要一些技巧來發現需求
    6）故事點表明時間的模糊單位，或叫NUT（XP編程）
    7）迭代計劃會議內容：
    a.討論故事
    b.從故事中分解出任務
    c.開發人員承擔每一個任務的職責
    d.討論過全部故事，而且接受全部任務後，開發人員單獨估計他們承擔的任務，以確保他們不會作出額過於樂觀承諾。
    8）迭代計劃是發佈計劃進一步計劃，但只在迭代即將開始時纔開始作迭代計劃9）迭代燃盡圖：展現以故事點表示的每輪迭代末剩餘工做量10）計算速率時只考慮那些已完成的故事，即經過驗收測試的故事，不要計算迭代中團隊未所有完成的故事。