2017年4月1日 星期六

Scrum Team 中關於插單事件的視覺化的感想


這個問題已經困擾我好一陣子了,照理來說遇到問題應該在Retrospetive 的時候討論,大家一起思考解決方案,但是如果沒辦法透過數字說話,一切流於"感覺",容易造成發散與責難的討論。

最後想出來的解決方法在 Richard 的blog 已經整理的蠻詳盡的,實體看板的再度邂逅插單看板可視化的誕生 ( 實體看板的再度邂逅系列 - 2 )

我在這邊想要補充的是,相同的問題如果不透過實體看板,想要透過電子化看板(如:JIRA) 來凸顯問題,我嘗試過的方法與侷限性,下面是我從JIRA 上收集出來的數字,每一列代表一個Sprint規劃的工作事項,而紅色框框起來的部分代表是plan meeting 後產生的新工作(issue added to sprint after start time),這些工作可能是:
  • 插單 (change feature,new feature...等)
  • 營運問題排查與排解 (bug,fault...等)
  • Plan 時break down story沒想清楚,新增加的task




可以看出來嚴重的時候,可能超過一半的工作都是當初沒有預期的,但是光是用 issue added to sprint after start time 可能太廣泛,沒辦法真得凸顯問題(插單/營運問題),因為Plan 時沒想清楚後來再新增的task 有時候是必要的。

所以下圖是我嘗試以另一個維度來分析,就是task 的種類,正常來說一個sprint我們只會產生Story 然後會在Story 下開sub task,所以只要是非Stroy 型態(task,bug,fault...等)就應該是插單,所以依舊可以看出來非預期的數量很多。




電子化看板(JIRA)的好處是事後分析方便,但是sprint 發生的當下,與daily stand up meeting 卻不容易突顯出來,因為:
  • 大家可能接單就順手修掉了,沒有去系統上開issue,很多是我事後要求補填的
  • 電子化看板之前都專注在每個人要做什麼事,不是以Story 的角度來看,不容易凸顯問題
  • 電子化看板對大家來說只是記錄工作歷程,大家只會專注在自己的工作項目,不會看到整體,通常只有team lead 或是 SM,PO會去關注。

所以直到把sprint 的工作實體看板化後,大家才正式到這個問題,好像插單真得很多,也唯有這樣才比較容易把問題講開。


另外電子化看板不容易隨時根據我們的需求去group by,而實體看辦就有這個好處,我們馬上就可以針對各種維度的問題去group by,包含:
  • 哪些問題有跟PO討論過,哪些沒有?
  • 哪些問題是bug,哪些不是?
    • 那些是上個sprint 產生的,哪些是更久以前產生的
  • 這些問題哪些是插單?
  • 哪些問題是Team Lead 撿走,那些是Team member撿走
透過不同group by 的方法,就能有不同層面的檢討方式,詳情請見插單看板可視化的誕生 ( 實體看板的再度邂逅系列 - 2 )
張貼留言