3. 建立反饋與度量機制
當流程能夠建立之後, 並且有適當的 WIP 以及 policy, 接下來便是度量和反饋的機制. 你必須有些現況的資料, 大家利用資料講話, 或是來解讀資料, 而非光是憑感覺決策.
以下是在建立反饋與度量機制要注意的事情:
(1) 數據和反饋能夠及時獲得
之前有提到指標有兩類 leading 指標和 lagging 指標:
Leading 指標: 度量的項目會很嚴重的影響到未來的效能.
Lagging 指標: 度量的項目是過去行為的結果.
agile 常用的 "cycle time" 或是 "iteration 之後發現的 bug 數目”, 都是屬於 lagging 指標, 這些有幫助, 但是不及時. 你如果想要團隊能夠快速應變, 你需要更積極的指標.
同理, 回饋也要及時. 以前專案都是結束時才召開檢討會. 可是很多人會說專案都結束了, 要開這個會幹什麼. 所以 retrospective 是非常必要, 要能每隔一段時間, 就討論哪些地方需要修正, 這樣才能讓你更有彈性.
(2) 數據和反饋能夠輕易獲得
agile 想的的指標, 都要是很容易可以產生的. 如果需要很複雜的公式來計算, 並且是要手動來處理, 這通常會不 work. 因為每次產生都要花很多時間, 或是很多精力, 人們就會懶得去做, 時間久就會漸漸不見了.
例如: burn down chart. 一開始時, 我們會去數目前還有多少 story point 還沒有做完. 可是當 story 張數一多時, 這些story 的 story point 要加起來也是很花時間. 後來改成只數 story 的張數, 事情就變得比較容易.
回饋要能輕易獲得, 不是件容易的事情. 因為人心最難, 你不容易讓人們輕易說出真心話. 這需要長時間的培養團隊默契. 如果你想要以快速達到效果, 可能要增強引導的功力. 看看"誰說我們不能一起做決定？參與式決策引導者寶典” 是個不錯的開始 XDD
(3) 是不是容易從中得到系統性原因
有時候得到的資訊非常直白, 你無法幫助你做進一步分析. 例如 burn down chart 或者 cycle time. 這時候你需要多增加一些輔助分析機制的資料收集在裡頭, 但是千萬記住不要走火入魔, 讓資料變得很複雜.
像是 cycle time 的 distribution chart 或者 CFD 可能就會比較好些. 因為他可以讓你做進一步的分析, 但是又不會太難做出來.
圖: cycle time distribution chart
回饋也是一樣不要只會做 good, bad 這種類型的 retrospective. 有時候 ORID 或是魚骨圖要拿來用用, 才能找出問題背後的問題.
圖: 傳統 good and bad 的 retrospective
參考資料: 2015 AHA conference, 精益產品開發實踐分享, 張震, 何勉
全站熱搜
留言列表
