系列文章

上一篇 “用戶故事不良癥兆一覽”

---

如有問題請留言

文章目錄

• 系列文章
• 前言
• 文章概覽
• 1. Scrum是迭代和遞增的
• 2. Scrum基礎
• 3. Scrum 團隊
• 4. 產品 Backlog
• 5. Sprint 計劃會議
• 6. Sprint 評審會議
• 7. 每日Scrum 簡會
• 8. 在Scrum 中使用用戶故事
• Finish

---

前言

如何把用戶故事和另一種敏捷過程Scrum結合在一起？

---

文章概覽

1. Scrum是迭代和遞增的

• 一輪迭代是一種持續改進的過程。
• 例如：雕刻家會首先選擇一塊石頭，畫出大體輪廓，然后在增添細節。
• 一個遞增的軟件是指團隊按照功能點開發和發布軟件。
• 例如：雕刻家會先確定一個部分，然后專注于這個部分。

2. Scrum基礎

• 實施Scrum過程的項目往往采用30天為一周期的迭代，稱為Sprint。在每個Sprint開始時，團隊需要確定這個Sprint需要完成的工作。
• 所有工作內容放到一個稱為產品Backlog 的排好優先序列的列表中。
• 團隊根據自己的經驗從產品Backlog 中選擇下一個Sprint能夠完成的任務，放到另一個稱為Sprint Backlog的列表中。
• 團隊每天都會有一個會議稱為 Daily Scrum。在會議上做出各種調整。

3. Scrum 團隊

• 通常由4～7個開發組成。團隊分工并不是非常明確，根據需求隨時做調整。

4. 產品 Backlog

• 這個指的是待開發產品功能列表，在項目初期一般不需要很大的精力寫出所有功能。通常只寫下一些比較顯而易見的功能。產品負責人會優先排序。

5. Sprint 計劃會議

• 在每個Sprint的開始時計劃會議。這個會議通常會持續很久。其參加者包括產品負責人，ScrumMaster和團隊的所有開發人員。
• 會議前半段產品負責人會把待開發的優先級高的功能介紹給Scrum團隊。
• 第二階段，開始針對第一階段提問。
• 團隊和產品負責人一起確定整體的Sprint 目標。在會議的后半段，團隊會討論這些用戶故事，決定下一輪迭代能夠完成的工作量。

6. Sprint 評審會議

• 每個Sprint 都要發布一個“潛在可以交付的產品功能增量”。這意味著每一個Sprint 結束時，團隊都會發布完成測試的可以使用的一部分功能。
• 會議最好時非正式會議，不要稱為成員的負擔。

7. 每日Scrum 簡會

• 這個會議主要是為了了解項目當前情況。
• 你昨天做了什么？
• 你今天打算做什么？
• 有什么困難？

8. 在Scrum 中使用用戶故事

• Scrum和產品Backlog
• 產品Backlog 中每一個故事必須對客戶或者產品負責人有價值。
• 如果限制產品 Backlog 中只有用戶故事，那么排列優先級對產品負責人來說會比較簡單。
• 在Sprint 計劃會議中使用用戶故事
• 在Sprint 評審會議中使用用戶故事
• 在每日 Scrum 簡會中使用用戶故事

---

Finish

下一篇 “其他話題”

參考書籍《用戶故事與敏捷方法》

總結

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

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