《用戶故事與敏捷方法》讀書筆記
阿新 • • 發佈：2018-06-23
sig ase 同事 創建用戶 有一種 思考 目的 ogr 速度 什麽叫用戶故事
描述了對用戶、系統或軟件購買者有價值功能。
用戶故事的組成
1）一份書面的故事描述，用來做計劃和作為提示；
2）有關故事的對話，用來具體化故事細節；
3）測試，用於表達和編制故事細節且可用於確定故事何時完成。
如何創建用戶故事
1）用戶訪談
2）問卷調查，不適合作為拖網捕獲新故事主要方法
3）觀察
4）故事編寫工作坊：會議，快速捕獲故事最有效辦法，結合頭腦風暴最佳要素和簡單原型法
用戶故事的特征
1）獨立的
2）可討論的
3）對用戶或客戶有價值的
4）可估計的
5）小的
6）可測試的
用戶故事的優勢
1）用戶故事強調口頭溝通
2）人人都可以理解用戶故事
3）用戶故事適合於叠×××發
4）用戶故事鼓勵延遲細節
5）用戶故事的大小適合做計劃
7）用戶故事鼓勵參與性設計
8）用戶故事傳播隱性知識
用戶故事準則
1）從目標故事開始
2）切蛋糕（slicing the cake）
3）編寫封閉的故事，值那種隨著一個有意義的目標的實現而結束的故事，能讓用戶使用後覺得他完成了某個任務
4）卡片約束
5）根據實現時間來確定故事規模
6）不要過早涉及用戶界面
7）有些需求並不是故事
8）在故事裏包括用戶角色
9）只為一個用戶編寫
10）以主動語態編寫
11）由客戶編寫故事
12）向故事卡編號說“不”
13）不要忘記意圖
用戶故事的不足
1）在用於大量用戶故事大型項目中，故事間關系錯綜復雜，難於捉摸
2）如果開發過程規定要有需求可追溯性，必然離不開額外文檔
如何估算故事
1）無論什麽時候獲得有關故事新信息，都允許我們之間改變想法
2）適用於史詩故事和小故事
3）不需要花很多時間
4）提供進度和剩余工作的有用信息
5）不太精確的估算也不會有太大問題
6）可以用來制定發布計劃
如何發布計劃
發布計劃排列優先級方法：莫斯科（MoSCow）規則
1）必須有，指系統的基本功能
2）應該有，指很重要但短期內有替代解決方法的功能
3）可以有，指如果沒有時間就可以在發布中不予考慮的功能
4）這次不會有，指客戶期望擁有但同時承認需要在後續發布中實現的功能
敏捷項目與傳統規範過程區別
1）傳統規範過程：在項目早期正確地獲取寫出所有的需求
2）敏捷項目：沒有一種理想辦法可以在一個單一階段獲取所有用戶故事 用戶故事與IEE830軟件需求規格、用例和交互場景設計的區別
1）用戶故事與IEE830需求規格
a.IEE830側重於關註需求的檢查清單，而不是用戶目標
b.IEE830在寫下所有需求前，每個需求成本是不可見的
2）用戶故事與用例
a.範圍：故事範圍小，對故事大小有限制
b.完整性
c.壽命：用例作為永久性工作持續存在，故事不會超過包含他們的叠代
d.用例容易包括用戶界面和細節
e.目的：編寫故事是為了更方便發布計劃和叠代計劃
3）用戶故事與交互場景設計：範圍和細節
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短會
確保整個團隊關註於完成余下面向客戶和最終用戶的任務
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.擁抱變化
其它名詞定義
1）史詩故事（epic）
指故事很大
2）面向瀑布模型和故事驅動
a.面向瀑布模型：用戶和客戶在搜集需求後到驗收之間的這段時間幾乎都不參與
b.故事驅動：客戶與用戶在項目過程中全程參與
3）故事卡由客戶團隊編寫
a.最了解如何表達需要實現需求
b.共同確定故事細節和安排故事優先級
4）速率：是開發人員可以在一輪叠代中完成的工作量
5）拖網
描述收集需求的過程，需求像魚一樣，會成長也會死亡，需求會隨著時間推移變化，需要一些技巧來發現需求
6）故事點代表時間的模糊單位，或叫NUT（XP編程）
7）叠代計劃會議內容：
a.討論故事
b.從故事中分解出任務
c.開發人員承擔每個任務的職責
d.討論過所有故事，並且接受所有任務後，開發人員單獨估計他們承擔的任務，以確保他們不會做出額過於樂觀承諾。
8）叠代計劃是發布計劃進一步計劃，但只在叠代即將開始時才開始做叠代計劃
9）叠代燃盡圖：展示以故事點表示的每輪叠代末剩余工作量
10）計算速率時只考慮那些已完成的故事，即通過驗收測試的故事，不要計算叠代中團隊未全部完成的故事。
描述了對用戶、系統或軟件購買者有價值功能。
1）一份書面的故事描述，用來做計劃和作為提示；
2）有關故事的對話，用來具體化故事細節；
3）測試，用於表達和編制故事細節且可用於確定故事何時完成。
1）用戶訪談
2）問卷調查，不適合作為拖網捕獲新故事主要方法
3）觀察
4）故事編寫工作坊：會議，快速捕獲故事最有效辦法，結合頭腦風暴最佳要素和簡單原型法
1）獨立的
2）可討論的
3）對用戶或客戶有價值的
4）可估計的
5）小的
6）可測試的
1）用戶故事強調口頭溝通
2）人人都可以理解用戶故事
3）用戶故事適合於叠×××發
4）用戶故事鼓勵延遲細節
5）用戶故事的大小適合做計劃
7）用戶故事鼓勵參與性設計
8）用戶故事傳播隱性知識
1）從目標故事開始
2）切蛋糕（slicing the cake）
3）編寫封閉的故事，值那種隨著一個有意義的目標的實現而結束的故事，能讓用戶使用後覺得他完成了某個任務
4）卡片約束
5）根據實現時間來確定故事規模
6）不要過早涉及用戶界面
7）有些需求並不是故事
8）在故事裏包括用戶角色
9）只為一個用戶編寫
10）以主動語態編寫
11）由客戶編寫故事
12）向故事卡編號說“不”
13）不要忘記意圖
1）在用於大量用戶故事大型項目中，故事間關系錯綜復雜，難於捉摸
2）如果開發過程規定要有需求可追溯性，必然離不開額外文檔
1）無論什麽時候獲得有關故事新信息，都允許我們之間改變想法
2）適用於史詩故事和小故事
3）不需要花很多時間
4）提供進度和剩余工作的有用信息
5）不太精確的估算也不會有太大問題
6）可以用來制定發布計劃
發布計劃排列優先級方法：莫斯科（MoSCow）規則
1）必須有，指系統的基本功能
2）應該有，指很重要但短期內有替代解決方法的功能
3）可以有，指如果沒有時間就可以在發布中不予考慮的功能
4）這次不會有，指客戶期望擁有但同時承認需要在後續發布中實現的功能
1）傳統規範過程：在項目早期正確地獲取寫出所有的需求
2）敏捷項目：沒有一種理想辦法可以在一個單一階段獲取所有用戶故事
1）用戶故事與IEE830需求規格
a.IEE830側重於關註需求的檢查清單，而不是用戶目標
b.IEE830在寫下所有需求前，每個需求成本是不可見的
2）用戶故事與用例
a.範圍：故事範圍小，對故事大小有限制
b.完整性
c.壽命：用例作為永久性工作持續存在，故事不會超過包含他們的叠代
d.用例容易包括用戶界面和細節
e.目的：編寫故事是為了更方便發布計劃和叠代計劃
3）用戶故事與交互場景設計：範圍和細節
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短會
確保整個團隊關註於完成余下面向客戶和最終用戶的任務
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.擁抱變化
1）史詩故事（epic）
指故事很大
2）面向瀑布模型和故事驅動
a.面向瀑布模型：用戶和客戶在搜集需求後到驗收之間的這段時間幾乎都不參與
b.故事驅動：客戶與用戶在項目過程中全程參與
3）故事卡由客戶團隊編寫
a.最了解如何表達需要實現需求
b.共同確定故事細節和安排故事優先級
4）速率：是開發人員可以在一輪叠代中完成的工作量
5）拖網
描述收集需求的過程，需求像魚一樣，會成長也會死亡，需求會隨著時間推移變化，需要一些技巧來發現需求
6）故事點代表時間的模糊單位，或叫NUT（XP編程）
7）叠代計劃會議內容：
a.討論故事
b.從故事中分解出任務
c.開發人員承擔每個任務的職責
d.討論過所有故事，並且接受所有任務後，開發人員單獨估計他們承擔的任務，以確保他們不會做出額過於樂觀承諾。
8）叠代計劃是發布計劃進一步計劃，但只在叠代即將開始時才開始做叠代計劃
9）叠代燃盡圖：展示以故事點表示的每輪叠代末剩余工作量
10）計算速率時只考慮那些已完成的故事，即通過驗收測試的故事，不要計算叠代中團隊未全部完成的故事。
《用戶故事與敏捷方法》讀書筆記