基礎上，我比較喜歡稱之為 refinement workshop，而不稱之為 refinement meeting。主要的理由是，我希望團隊是透過這個 "workshop" 一起去進行 story clarification (需求澄清)，並且最後可以有一個 common understanding (共同理解)。
也為了讓這個 refinement workshop 可以更有效的被舉行，達到 "share common understanding" ，上周的 sprint retrospective meeting 後，用一個小時的時間，先跟大家過了一下主題：refinement workshop 到底目的跟產出物會有哪些，先有一個大框架的理解，才不致於讓 refinement 變了調(台語俗稱的: 走鐘)，或大家覺得白白浪費時間。
步驟上大致是：
1. 先解釋一下，為什麼 scrum 後來會去追加定義 refinement 這個活動的誕生。
以 Vision -> EPIC 或 Features -> User Story -> Tasks -> Potentially Shippable Product Increment 的整個產品 從 概念願景 至 軟體交付 的生命周期過程，以及相關的 scrum meeting 的 artifacts 有哪些，並在 whole product life 講述 refinement workshop 的定位是什麼，要產出的是什麼，互動過程如何。
2. 針對 refinement workshop 會產生的 artifacts. ownership. attendees. goals 跟大家解釋一下各自會有哪些重點：
Artifacts部份我這次挑了一些我覺得比較需要溝通及強調的項目：
描述、技術可行性、驗收條件(AC)、粗估算、相依性、障礙狀態、優先序、如何展示。
Artifacts的相關Ownership也跟大家過一次。(所有artifacts都可以共創，但需要釐清的是這個項目是哪個角色的call)
3. 可能的誤區會有哪些. (先打些預防針或預告需注意的事項)
舉辦時間的選擇、議而不決、沒有共同理解、只想追求制式DoR、交付內容與決議有嚴重落差。
圖1. 溝通時候使用的畫布及其最終的產出
本周實際上執行時，總結一下觀察到的幾個點:
Bad smell:
- 會前、會始的議程溝通待改善，這比較屬於有效開會的障礙掃出，簡單來說是 預期 與實際 schedule 不符，這屬於開會前沒有事先進行會議障礙的掃除確認。(好吧，我被抱怨沒有專職的Scrum Master來掃除這類型的障礙很久了)
- Facilitator中離去面試沒有全程參與(沒辦法，難找出時間) 。
- 時間關係，驗收條件 未能有討論，產出幾近於 0。(目前活在每個人的心中，鐵定認知會不同)
- end-to-end 的部份一開始未破題。雖然這是個流程上的選擇，因為 end-to-end 一開始就講明，團隊成員可能會缺了點共創感、或對設計的What(Why/How/What三元素)會有定錨效應。故，端看workshop期待的過程與產出為何。
- 粗估算的部份比較有價值上的爭議，不過第一次進行，這點大家對其價值性較不理解或無共識是個人覺得是正常現象。
Good smell:
- 因共創型態的關係，請大家用 3m post-it 來進行 features -> stories 的產出，似乎有達到預熱效果(那時正好是我去面試的時間，所以我只能推測)
- 帶了Time Timer來協助做 time-boxing，感覺還是有達到一定的效率效果。
- 事前先與大家溝通過一次，且把掛布拉到現場當reminder的效果還不錯，可以隨時回顧是否漏了什麼，以及是否schedule上有很大的延遲。會議結束，效果達成後就讓掛布功成身退了。
- How-to-demo 的產出物，大家分工共創、下筆、繪圖，成果比很有視覺化的傳達力。使PO來確認內容的互動所需時間縮短很多。(這些都工程師畫出來的喲)
- 優先序 及 因應粗估算所進行的 Features 取捨或 Scope Change 有被較充足的被討論。大家對於整體 end-to-end 要做到什麼程度感覺有不錯的理解 (但最後成果還是得看後續 sprint planning 、實作時的互動、交付軟體 來確認是否為真)
圖2. 共同討論並釐清細節與優先序
圖3. 工程師們共創的 How to Demo 整個流程
本篇文末我則想多著墨一下可能造成 refinement workshop 價值減損的幾個誤區。
1. 舉辦時間的選擇
共創時間的refinement最好是大家能有連續時間、專注當下去進行，否則時間會拖的很長而且很沒效益。與 sprint planning 之間的時間也是需要注意的點，提前太多或沒有舉行都會有相應的議題需處理。
2. 未形成最終的共識(俗稱的 "議而不決"), 沒達到 share common understanding 的用意。或未能對DoR的重點項目有一定程度的討論與共識。
3. 太拘泥於Definition of Ready (DoR) 而讓執行結果變成 mini waterfall.
這部份可參考 Ruddy 老師的 Blog:
Ruddy Lee 分享空間 Emergent Design 演化設計 Definition of Ready: 工程師要學會如何講好故事
搞笑談軟工：
Definition of Ready—可以開工了嗎？
這部份成員也有提出來對於 怎樣才叫做 mini waterfall 的一些疑問。而我最後給的建議是，以及在 TenMax 中我希望的原則：
如果有些大家覺得缺漏的地方，但大家的心態上卻開始浮現「這應該是誰的責任、誰應該在某個meeting前或開工前就去補齊這些資訊啊」，卻不認為要嘗試在當下大家一起討論去補齊去詢問，那整個執行方向上就已經有往 mini waterfall 的方向上在傾斜了。4. 未盡到 澄清/釐清 (clarification) 的目的，只想追求產出制式 DoR。簡言之，制式 DoR 是死的，大家能達到 share common understanding 才是真正的價值。
5. 做出來的東西與 refinement 的 common understanding 不相符。或對交付物進行變更未與相關權責人員討論。
沒有留言:
張貼留言