最近團隊對refinement meeting有一些討論,過去也曾討論過,我認為這一連串的討論很有意思,所以把從過去到現在refinement meeting如何進行與調整記錄下來。要開始寫這篇時才發現,書到用時方恨少,我手邊竟然沒有半本關於Scrum的書,看完幾本卻始終沒有一本是擺在自己身邊的,只好請Google大神幫我找些資料了。
在水果公司時,團隊算是成功的Scrum團隊,特別是自省會議後對團隊的改善是玩真的,而不只是說說感謝誰或是只聽到好話,檢討起來常常會超出預定的會議時間,有時候還會火力四射,之前的自省會議提到一件事情,就是sprint的planning meeting越來越久,甚至到快用掉半個sprint的時間才把目標確認、task切割和時數估完,原因和scrum的另一個活動有關:refinement meeting。
在繼續討論原因前,我覺得需先說明一下團隊過去refinement meeting的運作情況,我加入團隊時就已有refinement meeting的慣例,由團隊全部成員參與(大約1x人),時間在每個sprint (一個sprint兩周)第一周的周五。在refinement meeting召開前,PO會將接下來要做的需求(feature)其發想的成果寫成一份詳細的企劃文件(跟團隊過去開發遊戲的經驗有關)。
會議有時會搭配可簡單操作的blueprint雛形展示,然後針對PO將企劃文件所條列的功能切割而成若干的user stories進行討論與估點,當時,這些user stories常遭到抱怨,原因有幾項:(1) 常有非end-to-end的user story、(2) 從模組開發的角度去思考,造成user story間的dependency變高、(3) 從畫面的角度切割,造成user story的內容有重複性、(4) user story的敘述超長卻看不出價值。幾次下來後,在一次的自省會議中,達成了一個共識:user story的切割應該要以使用者能得到的價值為主。
雖然常被抱怨,但當時開發的情況其實還算穩定(burn down chart還算平穩下降),但有一個現象在當時已經開始浮現:需求從發想、refinement後到開工的時間相當長,因此導致這段時間若干的story後來是被捨棄沒有開發的,我稱之為現象而不是問題主要是,若這些story真的是不需要的,捨棄不開發反而是減少後期開發時間的浪費。
第一次調整後,PO調整了user story的寫法,確實滿足了團隊當初所提的重點:價值導向,但幾次下來,PO開始有點抱怨,而團隊成員也有點抱怨,因為每個story都很大,當時估點story point常常有40這樣的數字出現,當然這樣的story不會被接受,因此refinement meeting常常都是在做切割story,事實上這本來就是refinement meeting要做的事,只是當每次的story都很大,開會時間都超長,團隊中非程式的人員例如美術,常常只是陪程式人員耗著。成員會覺得為什麼不乾脆一開始就讓我們自己寫user story,還比較能節省refinement meeting的時間,此外,PO也覺得每次refinement meeting結束後,為了追蹤確保事情都被完成,他要修改許多文件,包含企劃文件、資訊系統上user story的關聯等等。
因此再次在自省會議中檢討refinement meeting該怎麼進行,會議的結論是:PO不再需要寫一份超完整的企劃文件,只要UX完成一份大概的流程圖就能送進refinement meeting,refinement meeting分成若階段:(1) 第一階段由PO用流程圖解釋需求,全員在當下釐清可行性或是提出改善;(2) 第二階段由程式根據流程圖、end-to-end、價值和施工工法進行story的切割;(3) 對story進行估點,估點時美術團隊會再次加入。這三階段不一定要在一次的refinement meeting中全部完成。
但第一次調整後團隊開發是否有遭遇問題呢?這段期間大概實行了8個sprint,事實上有遇到問題,但和refinement無關,而是別的因素造成,為此還畫了幾次魚骨圖檢討原因(有機會再談)。除此之外,因為由團隊進行再切割,story的規模穩定,且在review時,每個story都有可展示的部分,而時程的估計和實際的開發時間也算吻合,可以說是進入開發速度的穩定期,但後期團隊的成員開始增加,開發速度再次出現變化。
第二次調整只實施了兩個sprint,而用新refinement方式所產出的story,因為整體App上市時程上的考量被封存,並沒有真正地被排入planning meeting中,但平心而論,那兩次的refinement meeting是相當有效率的,而且story的品質是全團隊都認為相當優質的結果,只能說相當可惜。
只實施兩個sprint的主因是,在成員增加到2x人(程式、美術、UX、企劃和PO)後,一次的自省會議上,PO轉達一位(相當重要的)stakeholder的意見:他在一次活動中看到許多新創團隊在很短(相較於我們目前App的已開發時間)的時間就能上架一款App,他覺得團隊的應變速度不夠快。針對這點,長久以來的現象終於被拿出來討論,scrum master將資訊系統中,一個需求從開始發想到開工需要時間大概是兩個月(與團隊討論可行性,幾次往返才能完成發想),開工後平均的開發時間大概也是一個月到兩個月(視需求大小),平均來說,一個需求大概要三個月,也可以說團隊的應變時間大概是三個月,雖然不能稱之為waterfall,但在需求釐清確實花了不少時間。
因此,會議中提出了一個建議,團隊分成A、B兩組,每組都有企劃、UX、美術和程式,針對接下來兩個feature,撥出sprint約30%的時間由兩組成員進行發想,發想結果由stakeholder選擇後,馬上進行planning並開發,就時間軸上來看,這兩個feature從發想到完工只花了2-3個sprint,也就是應變時間從三個月縮短到一個月,能縮短到這麼短,真的是因為改變方法嗎?不完全是,就規模來說,這兩個feature相較於過去開發的feature小很多。而且也出現了副作用:sprint n和sprint n + 1這兩個sprint陷入少見的加班期,原因簡單說是過多的context switch,說是撥出30%的時間,但發想會議常常無法如期結束,有時還要加開,延誤到原本的開發,成員為了追回進度自願加班,就長遠來看這不是好現象。但目前仍有不少團隊成員認為是最好的方式,因為能參與到最一開始的發想,有一種產品就是自己的小孩,而不是幫別人開發產品。
就在這兩個需求完成後,團隊開始了另一個client平台Android的開發(原先全力專注在iOS的開發),也就是文章在一開始提到的情況,Server組和iOS組進入收尾期,Server組開始進行performance tuning,iOS組開始修bug與iOS 8 SDK的升級,由於Android組是移植iOS上所有的功能(直接由我和PO決定story優先順序),iOS組和Server組要做的事都是技術細節,PO就交由團隊自行選擇,refinement meeting也好幾個sprint沒有舉行,但這出現了一個問題,story的優先順序也由團隊自行選擇,兩組對於微調的優先順序認知不同,有些微調整需要兩組間的配合,於是iOS組想確定Server組是否能配合某些story,Server組也想知道iOS組能配合那些story,雖然最後都能取得共識,但長時間的會議容易造成會議效率的下降,確認這些優先順序花了不少時間。
因此在本文一開始提到的自省會議中再次討論起refinement meeting,決議是refinement meeting還是視情況召開,除有新需求一定會召開外,只要任何成員認為有需要討論story順序或細節就能跟PO要求召開,而且也將時間固定在原本每個sprint第一周的周五,但不相關的成員可以自由參加,例如技術細節的story討論,美術可以不用參加。該自省會議後確實召開了一次refinement meeting,不過是因為新需求而召開,進行方式原則上算是第二次調整和第三次調整的混和體,PO先講解這次UX調整的理念(這部分還是由UX團隊與公司另外一個部門討論後,由stakeholder定案的),而細節由全成員討論,確認後由開發成員切割story (但竟然忘記估點了XD),和討論施工的優先順序。
Scrum和過去其他開發法不同,只明確定義了極少的幾個活動,其中refinement meeting大多只提到怎樣的story算是ready to plan,但refinement meeting如何進行較少有討論,畢竟如何進行與團隊特性有關,接案團隊與創業(開發自有產品的)團隊的進行就不一樣,對接案團隊來說,對story本身的喜好,團隊較少會有想法(即便有,通常也不具有決定權),只要需求明確能夠施工即可;但創業團隊就會很在意story的內容,會有相當多的意見,refinement meeting就是一個很好的場合讓大家把對需求的想法提出來,否則讓成員失去參與感,這對創業團隊是很大的傷害。
目前refinement meeting在幾次的檢討後,算是抓到一個平衡點,但我也不認為我們的團隊會滿足於現況,重要的是持續改善,對於refinement meeting如何進行,這裡簡單分享我們如何改善給大家參考。