網頁

2018年9月24日 星期一

加速 (Accelerate) - 測量的誤區以及你該測量什麼

soruce: measurement



從二十世紀初開始,科學管理之父泰勒(Fredrick W. Taylor, 1856-1915) 就開始推廣的科學化管理,也就是運用科學方法(觀察、測量、實驗、分析、比較)來解決管理問題,這個立意可能是好的但是也最容易被誤用,所以加速 (Accelerate) 這本書第二章開頭先不說該測量什麼,而是不該怎麼量。

還記得大學時候的軟體工程聽到的測量指標 line of Code 就是一大誤區!!



生產力(Producitity )測量的四大誤區:



1. 專注在 Output 而不是 Outcome

東西有交出來就好,能不能用好不好用不重要,此外也會產生 throughput 和 stability 的矛盾現象。

2. 測量 Line of Code

我們都知道code 寫太長其實垃圾很多,寫太短又不容易閱讀

3. Velocity 績效化

Velocity 只是 capacity planning tools 而不是測量的工具,千萬不要把 story point 當作團隊的速度和績效指標

4. 測量 Utilization (利用率)

這也是最常被誤用的指標,PM:我一定要把大家的工時塞滿,代表利用率最高產能最好。
其實利用率越高代表彈性越少,越少時間可以拿來處理急件,越少時間可以拿來當緩衝變更計畫,甚至越少時間用來成長學習。

此外根據排隊理論,越高的Utilitzation 代表 lead time 趨近無限大。


在網路上也找到另一張圖順便解釋了為什麼scrum 會推行sprint( small batch )的好處



在 Less 的官網也有專門的章節在解釋排隊理論的影響:Indirect Benefits of Reducing Batch Size and Cycle Time



那在這本書中推薦要測量哪些指標呢?剛好前兩項跟 throughput 相關,後兩項跟 stability 相關:
  • Delivery lead time
  • Deployment frequency
  • Time to restore service
  • Change fail rate

而接下來整個第二章就是根據這四點展開談論,且讓我們繼續看下去.....


沒有留言:

張貼留言