GA4

2017年7月5日 星期三

來場共創型的 refinement workshop

今日來談談 TenMax Refinement Workshop 在台北RD團隊施行的第一次執行與一些觀察心得分享

基礎上,我比較喜歡稱之為 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 不相符。或對交付物進行變更未與相關權責人員討論。






沒有留言:

張貼留言