如何衡量敏捷對於軟體研發效能的利益？

面對敏捷或 DevOps 藥方，病人可能帶著各種不同的動機而來，但終歸都會提出同樣的疑問：我怎麼知道敏捷有沒有效？怎麼衡量成效？

這問題，可能在導入之後的某個時刻會問，但更有可能像戰國時代梁惠王那樣，才剛第一次接見孟子，居然劈頭就問：「叟，不遠千里而來，亦將有以利吾國乎？」

對這議題，常有兩種極端的反應。

如果你像孟子一樣，一開頭就企圖曉以大義： ¹

總經理呀，何必一開頭就談「衡量成效利益」呢？你更應該看重的是「內涵與精神」呀！

如果總經理成天想著「對我們的公司有什麼可衡量的成效」，主管成天想著「對我們部門有什麼可衡量的成效」，員工成天想著「對我個人有什麼可衡量的成效」，上下各自算計著成效利益，整間公司就很危險了！

只怕你會像孟子一樣，很快就離開這個國家了。

輕蔑指標固然不可取，但另一個極端「指標狂人」也很可怕。

近年來「數位轉型」蔚為顯學，延燒到傳統產業，甚至連傳統管理顧問機構也來湊熱鬧。於是乎，世界就多了更多指標，更多成熟度衡量，更多培訓、證照、鑑定標章——更多所謂的「商機」。

這世界不缺指標，缺的是能引領有效行動的指標。若不懂軟體研發的獨特性，就會訂出沒有行動意義的落後指標，或是沒有合理因果證據的偽指標。就像 Bryan Finster 在 “5 Minute DevOps: McKinsey Gets Developer Productivity Wrong” 一文對於某管顧公司近日端出的 “Developer Productivity” framework 所做的批評：

The real problem is that too many in management don’t understand the work they manage. Management can understand the intricacies of software engineering if they become leaders and study the work they manage. Not all managers are leaders. Some simply want a framework to hold people accountable.

Those who do understand tend to measure the right things. The one thing McKinsey doesn’t do with this framework is help fix this problem. They are making it worse.

那麼，軟體研發活動有什麼獨特性？正確的衡量角度又是什麼？Daniel Terhorst-North 的 “McKinsey Developer Productivity Review” 一文說得好：

Software development is a collaborative, generative enterprise, and we can easily measure the effectiveness of a team, and more importantly how this is trending over time, using Theory of Constraints and flow-based metrics like lead time and throughput. Take a look at the work of Eliyahu Goldratt and Donald Reinertsen for a deeper understanding of these. An organisation like McKinsey endorsing these approaches would be a great help to the industry.

這段話點出幾個關鍵：

• 團隊 vs 個人

• 縱貫研究 vs 橫斷研究

• Theory of constraints & lean thinking

• Flow, lead time & throughput

我們就從這些角度來切入，尤其是 “flow” 角度。

從 Flow 角度看軟體研發效能的本質指標

我喜歡用以下這五個主要的 flow 指標來整體衡量軟體研發效能：

為了對於「軟體研發效能」得出較全面的 flow 視角，我結合幾個信度效度兼具、又不複雜的論述：

• SRE 的 4 golden signal: latency, traffic, errors, saturation。
• Scrum 之父 Ken & Jeff 在《告別瀑布，擁抱 Scrum》第 7 章提出的主要指標：productivity, quality, value。
• Theory of Constraints 提到的 bottleneck/constraints 及 throughput。
• Lean 提到的 lead time。

它們之間的對應關係是：

五個指標，儘管數量不多，但很容易展開成更細部的指標。譬如：

• Traffic 可往下展開成 product backlog 管理、dual track、definition of ready 等指標。

• Saturation 可往下展開成 velocity、queue length、WIP、cycle time、interrupt 等指標。

• Lead time 可往下展開成 value stream、MTTR 等指標。

• Throughput 可往下展開成 value points、cumulative flow diagram、deployment frequency、feedback 等指標。

• Quality 可往下展開成 code complexity、change failure rate、rework rate 等指標。

這五個指標以簡馭繁，很好用。

我通常會從這五大指標出發，蒐集初始資料，形成假設，求證，並佐以 Theory of Constraints 分析，找到關鍵 constraints，用聚焦五步驟界定優先順序，再去探討解決方案。

從 GSM 角度看敏捷能解決什麼問題

這五個指標，儘管是偏向落後指標，但很容易展開成可行動的領先指標。

當然啦，在展開成領先指標之前，最好還是先回到最原始的動機：之所以會想尋求敏捷或 DevOps 這帖藥方，一開始的痛點及原因究竟是什麼？

界定好「待解決問題」之後，我建議根據《Google 的軟體工程之道》所介紹的 GSM process，一步步找出合適的領先指標：

• Goal：期望當問題解決之後，能夠達到什麼樣的目標狀態？

• Signal：有什麼明顯的信號，可以告訴我們說：目標已經達到了？

• Measurement：對於上述信號，有什麼明顯的量測值，或是具有預測效度的量測值？

最後，則是透過 GSM 規劃出行動策略：

• Task：從 Goals 找出能夠提升 Metrics 的 Tasks，而不是直接從 Metrics 找出 Task。

價值

最近看到 Howie 對五年前的老話題有感而發：

經過了五年的歷練，我的回答還是一樣，但更多了一份篤定：

TL;DR　對於「價值」是否有增益。

1. 回頭看看當初導入敏捷的痛點及原因，找出起初認定（或誤認）的價值是什麼。尤其是：這所謂的「價值」，是否可追溯至敏捷宣言或 Modern Agile 四層面。若追溯不了，或許一開始就投錯藥方了。

2. 導入敏捷後，是否在敏捷宣言或 Modern Agile 四層面有所進展。進而檢討：這些進展，是否有對應到當初導入敏捷的痛點及原因。

希望這份關於五大軟體研發效能指標的分析，有助於你用敏捷解決正確的問題，並用正確的方式衡量成效。