什么是refinement
Refinement 這個詞是加工、提煉的意思，在scrum里，其實就是對下階段的需求做一個討論、澄清、細化的一個活動，希望通過這個活動，使得團隊能對后續階段的需求能有一個common understanding，盡量避免團隊因為對需求理解的不一致所導致的各類問題，并幫助團隊在下個迭代開始的時候更快進入開發狀態，它一般是發生在下個迭代開始前的一段時間里。中文一般叫做產品待辦列表梳理會議（product backlog refinement）。
其實refinement在之前還有一個名字，叫做grooming，但據說這個詞的意思在英國會令人不太舒服，所以后來scrum聯盟就改用了refinement這個詞。如果你發現還有人在使用grooming，你可以告訴他/她，"你out了,_"
它和傳統模式下得需求評審有什么不同
refinement（grooming）并不是一個在scrum下才有的新的概念，它和傳統的軟件開發流程中的產品需求評審非常像，不過它們還是有些區別：
- 發生的時間不同
- 需求評審往往發生在整體開發之前，一次性的居多；refinement可以分次開展，一般發生在每個迭代中間靠后階段
- 產生的方法不同
- 需求評審是由產品單方面給出，其他人提意見；refinement是期望所有人一起來完成
- 存在的目的不同
- 需求評審是上下游交接的手段；refinement是讓大家達成common understanding的方式
操作方式
簡單的來說，refinement目的就是讓我們backlog里的story更加DEEP，DEEP的意思是：
- Detailed appropriately
- Emergent
- Estimated
- Prioritized
具體操作方式如下圖。
整個refinement的過程也可以簡單看成一個發散和收斂的過程。
發散
發散的意思就是在對一個story做梳理的前期，我們需要針對目標story做發散思維的討論，盡力考慮到各個方面的問題、假設、困難，防止專家思維的局限，這是個腦暴的過程。
發散的過程中有幾個小tips：
- 暫緩對別人觀點的評論
- 鼓勵異想天開的想法
- 借“題”發揮，別人的觀點上繼續延生
- 專注在story上，不要離題
- 圖文并茂，鼓勵使用可視化的方式
- 做加法，點子越多越好（先不關注點子的質量）
為了更好的引導這個腦暴的過程，我們常見的指導分析方法有 FURPS+ 和 SQA，這兩個方法下面單獨介紹。
收斂
在充分發散的基礎上我們就要開始收，這樣我們才能拿到refinement最終的結果，這就是收斂的過程。
為了幫助收斂，我們常用的手段有：
- 明確產出結果形式
- 投票找到公認的重點
- 時間盒
常見需求分析方法
FURPS+
- Functionality （功能性）
- Usability （可用性）
- Reliability （可靠性）
- Performance （性能相關的）
- Supportability （其它對內部研發支持，比如文檔、為了可測性、可擴展性等）
- “+” （其它更多可能的考慮）
- 設計上的限制（比如系統以前的架構局限）
- 實現上得限制（比如語言，人力資源，操作環境等）
- 接口的需求（外部依賴的接口和服務）
- 硬件的需求（物理硬件的限制）
“FURPS+”更像一個checklist，它能提醒我們在發散的時候要從這些角度去思考，避免有大塊的遺漏。
SQA
相對于上面的FURPS+的方法，SQA的方法在我遇到的實際中更加常用和易用。
SQA就是通過大家一起回答目標story的"Questions"，"Scope"，"Assumptions"三個問題來澄清我們的需求。
- Question：任何對這個需求不清楚的問題
- Scope：team為了完成這個需求到底要做哪些事，不做哪些事情
- Assumptions：為了做這些事的前提假設，可能是成立的，也可能是不成立的
這里會有很多疑問和假設，PO需要在團隊討論的過程中隨時解答團隊的疑問和澄清假設，不能當場澄清的，團隊和PO需要會后帶回去，在下個迭代planning meeting前完成澄清。
注意
分組討論
發散和收斂的討論是一個非常費時的過程，那我們該怎么更高效的完成這個refinement呢？
比較推薦的做法就是分組來討論：
- 把團隊隨即拆成2-3個group，每個group分到一個高優先級的story來討論。比如圍在一個A0的大紙前，討論這個story的S、Q、A。
- 團隊成員把討論中能想到的SQA記錄在紙上，PO巡視各個小組，并回答紙上的問題。
- 討論差不多的時候，每個group留一個人，其他人交換到其他group里來，留下的人負責給新加入這個話題的人做介紹，大家討論并繼續完善這個話題
- 最后每個group里找到一個可能對這個story了解最少的人給整個team介紹最終SQA的內容
refinement的范圍
refinement并不只是梳理下個迭代的開發內容，而是下個階段重要的開發需求，refinement梳理的內容范圍往往會大于下個迭代能完成的范圍。
在某些變化比較快的領域還會出現refinement的內容并沒有出現在下個迭代開發列表中的情況。
refinement并不止在會議上發生
需求的梳理其實不僅僅只發生在每個迭代的refinement的會議上，它其實應該是貫徹發生在整個軟件開發的全過程中。只是在refinement 會議上做了最大量的需求梳理的工作，然后從sprint的開始，花費在需求梳理上的時間會慢慢減少，花費在軟件設計開發上的時間慢慢增加，到了sprint得后期就慢慢沒有了需求方面的工作而只剩下開發上面的工作了。
時間花費占比
refinement活動還是比較花費團隊時間的，那么對于時間總是不夠的開發團隊來說，花費多少時間來做refinement是比較合理的呢？
推薦整個迭代花費在refinement會議的時間占總時間的5%，比如一周的迭代，refinement通常在2個小時左右。
