上兩篇闡釋了Why：為什么使用戶故事，而不是詳盡的文檔？

What、How、Who：什么是用戶故事，怎么寫，誰來寫，誰使用？

這一篇闡釋When，在Scrum流程的各個環節如何使用用戶故事：

When：什么時機，如何使用用戶故事？

終于來到敏捷的流程上。

用戶故事幾乎是貫穿于整個敏捷開發流程。在每個環節都有其重要做用。任何一個環節如果沒有很好的執行和使用，就難以發揮用戶故事的作用，造成團隊轉而對詳盡的文檔的再度依賴。

用戶故事與敏捷方法在流程中的應用

用Scrum為例子，Scrum的5大活動：

-- Sprint計劃會議（Sprint Planning Meeting）

-- 每日站會（Daily Scrum Meeting）

--?Sprint評審會議（Sprint Review Meeting）

--?Sprint回顧會議（Sprint Retrospective Meeting）

--?產品Backlog梳理會議（ Product Backlog Refinement）

要用好用戶故事，需要進行如下活動：

1、用戶故事估算

2、優先級排序

3、用戶故事拆分

4、任務拆分和估算（與用戶故事估算區分）

5、發布計劃

6、迭代計劃

7、測量和監控速率

用戶故事估算：

Why為什么要進行用戶故事估算？

作用一：客戶團隊參考用于排優先級。比如：一個業務價值高的故事估算出來要4周完成，1個或者多個業務價值中等的用戶故事只需要1天就可以完成。客戶團隊可能會將業務價值中等的這個故事排出更高的優先級，先做。

作用二：為后續的發布計劃提供必要的數據參考，以便得出發布周期和范圍，允許±2個迭代的誤差。

作用三：（附加作用）此過程讓團隊充分溝通，客戶團隊和開發團隊達成共識，需求的討論存在于大家共同的腦海里。

What什么是用戶故事估算？

粗粒度的用戶故事，還沒有排入迭代的產品特性或者已拆分的獨立故事。團隊共同預估和猜測這個用戶故事的大小，以粗略估計其工作量。

How如何進行用戶故事估算？

撲克牌

經驗（猜測）、理想周、小于一個理想周的工作量用斐波那契數列計算（1、2、3、5、8、13、21、34、55、89）以團隊7人為例。

Who誰來進行用戶故事估算？

理論上是團隊共同決定，開發人員參加的越多越好。現實中，團隊重要人員參與，根據實際情況。

1、客戶團隊：不能主動對估點發表意見，不參與估點。只能盡其所能的回答開發團隊的問題（不知道答案，先猜猜看）。

2、開發團隊：盡可能多的問問題。通過撲克牌進行估點，經過幾輪（一般不超過3論）討論，最終達成一致。

When什么時候進行用戶故事估算，多久一次？

產品Backlog梳理會議。根據發布頻率決定，比如三個月一次發布，每三個月進行一次用戶故事估算。舉例，如果三個月一次發布，每次發布之間留一個星期進行產品Backlog梳理，這個期間是最好的進行下一次發布用戶故事估算的時間。

失敗因素：

1、客戶團隊和開發團隊關系不融洽。

2、客戶團隊和開發團隊任何一方都太過于強勢，無法平等溝通。

3、存在不平等的關系，造成并非每個人都參與其中，存在一部分人只是看重要人物的決定而跟風。

任務拆分和任務估算：

Why為什么要進行拆分和估算？

1、拆分便于多人共同協作于一個用戶故事。

2、估算便于合理安排一個迭代可完成的任務量。

What什么是任務拆分和估算？

按照優先級排列，準備放入當前迭代的用戶故事，進行任務拆分，便于團隊共同協作于一個用戶故事。并由任務完成者對這個任務進行工作量的預估。

How如何進行任務拆分和估算？

拆分可以根據開發團隊的特定技術專長來進行。比如：一個用戶故事需要后端開發，前端開發，測試，就可以拆分為三個任務卡。

拆分可以根據任務的邏輯流程的先后順序來進行。比如：一個用戶故事需要先新增一條數據，然后對數據進行讀取、計算并修改數據，最后刪除數據，可以拆分為三個任務卡。

用理想天的方式進行估算。

Who誰來進行任務拆分和估算？

團隊一起決定用何種方式拆分，由任務完成者主力進行該任務的估算。

When什么時候進行任務拆分和估算？

迭代計劃會議的時候

失敗因素：

過于糾纏于細節

優先級排序：

Why為什么要進行優先級排序？

為了計劃一個發布，PO和客戶團隊必須排列一個故事的優先級。

What什么是優先級排序？

每個用戶故事都是獨立的可測試的完整可發布使用的功能。PO按照優先級排列，確認哪些先做和后做。團隊按照優先級從高到低在承諾時間內優先完成優先級高的任務。

基本優先級排序：

--?高優先級 High

--?中優先級 Mediem

--?低優先級 Low

為了避免無休止的對優先級的爭論，可以使用DSDM方法

--?必須有（High）

--?應該有（High）

--?可以有（Mediem）

--?這次不會有（Low）

為了避免并列存在并列高優先級無法取舍，可以使用序列法

--?1、2、3、4、5

How如何進行優先級排序？

優先級排序分風險驅動和價值驅動。

敏捷模式下，是價值驅動高于風險驅動。先做高價值的用戶故事，風險也許會隨著時間推移而消失。但是如果隨著時間推移，風險并未消失，甚至有增無減，仍然要考慮先處理風險高的任務。

優先級排序要考慮的因素，包括但不限于以下幾種：

--?用戶故事的價值

--?用戶故事的規模

--?用戶故事的風險

Who誰來進行優先級排序？

PO和客戶團隊，也可以參考開發團隊的意見

When什么時候進行優先級排序？

任何時候，已經進入迭代并開始沖刺的用戶故事除外。

取決于團隊的靈活機動性，靈活性高的話，計劃會議時候是最好的優先級排序和調整的時機。

團隊速率：

How如何計算團隊速率？

初始速率：第一個迭代的速率估計，歷史經驗、猜測

例子：6人團隊，2周一個迭代10天，團隊的理想天是6*10=60天，這僅僅是理想天，因此要根據情況減半，或者1/3。由此算出的第一個迭代的初始速率為20或者30。

團隊速率：通過6個月的持續反饋和改進，團隊的速率接近一個穩定的值，這個值就是團隊的速率。

Who誰來計算團隊速率？

SM

When什么時候計算團隊速率？

一個迭代完成，或者開始。

發布計劃：

Why為什么要制定發布計劃？

即便敏捷開發是不斷順應市場變化而變化的，仍然是需要一個預期和發布時間預估，只是無法精準到天，允許±2個迭代的誤差。（傳統瀑布流的開發模式也無法精確到天，事實上傳統模式下的開發總會比計劃的發布日期拖延幾個月到半年交付）

敏捷項目三角

What什么是發布計劃？

根據產品路線圖，規劃發布。以做出一個合理的預測，完成符合用戶期望的發布需要多少輪迭代。

發布計劃需要包含以下要素：

1、粗粒度故事，不包含很多細節。

2、對這些故事的用戶故事估點，和優先級排序。

3、選擇一個固定的迭代長度。（1周、2周、4周，長度越長風險越大，因為反饋周期變長，反思和修正的機會變少）

4、團隊的速率

How如何將用戶故事估算轉換為開發速率和發布時間預估？

用理想周進行估算的例子：

通過SM、PO、客戶團隊達成一致，本次發布計劃預計包括用戶故事： A、B、C、D、E

A用戶故事的估算是一個理想周（5天），團隊總共7人。總共任務點數=5天*7人=35點。

B用戶故事的估算是兩個理想周（10天），團隊總共7人。總共任務點數=10*7=70點。

C用戶故事估算是斐波那契數列8點

D用戶故事估算是4個理想周（20天），團隊總共7人。總共任務點數=20*7=140點。

E用戶故事估算是斐波那契數列21點

總計 故事點數為 35+70+8+140+21=274

若團隊速率為62，則開發時間為274/62=4.4個迭代±2個迭代。

因此可以估計發布時間點為6~7個迭代后。團隊經過6~7個迭代可以發布A、B、C、D、E五個用戶故事所構成的交付產品。

Who誰來制定發布計劃

團隊

When什么時候制定發布計劃

按照發布周期，2~6個月，發布完成后，休整一個星期。這個星期進行backlog梳理，需求澄清會，發布計劃會，等等。

迭代計劃：

Why為什么要做迭代計劃？

對粗粒度的用戶故事進行更加細致的討論，但仍然避免過于糾纏于細節。目的是確定團隊這個迭代做什么，排列優先級，并從高優先級的用戶故事開始選取。

What什么是迭代計劃？

每個迭代開始的第一天，團隊共同討論做什么，如何做，誰來做。

How如何進行迭代計劃？

-- 優先級排序

--?任務拆分

--?任務估點

Who誰來做迭代計劃?

團隊

When什么時候做迭代計劃？

每個迭代開始的第一天

讀書筆記用戶故事與敏捷方法----流程篇就更新到這里，后續繼續更新用戶故事與敏捷方法-----產品篇。

謝謝！

歡迎添加QQ討論：26988505