為了改善開發生產力，他們從2023年初開始用DORA指標追蹤團隊開發效率，尤其聚焦部署頻率（DF）和變更準備時間（LTFC）。在2023年三月部署頻率每月不到20次，而變更準備時間更是長達了30小時。

雖然這個數據已經遠比臺灣許多企業的DevOps能力好，根據我們去年CIO大調查，臺灣半數大型企業關鍵應用每月部署次數不到5次，部署時間短則一天，長則好幾天。
Booking.com高層對這個團隊原有的開發效率高度不滿意，想要找出拖慢效率的瓶頸。

分析後發現，第一個影響部署頻率不佳的瓶頸是，他們的程式碼難以理解，但是又很容易修改，工程師若不小心改錯，得花好幾周才能找出問題，如此一來，更讓工程師不願意改進。

後來，他們參考了一條童子軍規則「要讓露營地比你來的時候更乾淨。」也就是看到有垃圾就馬上清理，來幫下一組露營的人改善環境。在去年三月開始推動許多小規模的重構和推動測試自動化，進行程式碼更新或修復問題時，也同時改善周邊的程式碼，來提高程式碼品質，並且同步要求開發團隊刻意花時間來解重構的題目，透過大量練習來提高重構技能。

雖然逐漸改善程式碼可讀性，但因為許多小型重構計畫，去年六月發現，出現了大量合併請求，程式碼審查時間成了新的瓶頸。他們轉而一方面改採少量批次合併請求的策略，來減少每次審查時間，也要求工程師優先審查程式碼，來減少相互等待的時間，在七月逐漸解決這個問題。

七月時，他們轉向處理拖慢部署時間的痛點，當時要進行兩次金絲雀部署和驗證，每次部署涉及許多手動作業，部署時間至少得花40分鐘，因為有些功能的金絲雀部署出錯機率幾乎是零，因此，他們決定導入自動化部署，將合併請求直接合併到主版本，直接部署到正式環境，而不用手動驗證。

另外，還採取了一些自動化部署作為配套，像是良好的測試自動化機制、同儕程式碼審查和小變更策略，一次不做大變更而是盡量採取多次小變更策略，一但程式碼品質指標檢測沒有達標，也會自動回覆到舊版，來確保既有服務的穩定。

金融科技部門這個新作法將部分功能的部署時間從40分鐘縮短到4分鐘，也同步提高了DORA的部署頻率和更新準備時間。八月時，部署次數甚至一度達到每月43次，整體的平均部署時間約1.3小時。

不過，在前端的單體式應用的交付效率仍舊難解，在去年八月時，這一類應用每月部署次數只有6～8次，每次平均準備時間長達2-3天。

Booking.com團隊決定導入微前端（Micro Frontend）開發模式，把前端單體應用，改成類似微服務的前端模組，並改用JavaScript來開發用戶端的網頁應用。在九月導入微前端開發模式之後，明顯改善了開發效率，但是他們卻發現，另一個DORA指標的數值變差了，開發準備時間反而比預期來得更長。

Booking.com團隊回頭查看了過去一整個月的合併請求紀錄，包括提交、評論、批准、合併和部署的各種統計資料才發現新的問題。因為微前端應用的合併請求審查流程，比平常前端應用的開發更複雜，因此，開發流程上需要金融科技部門外部的內部其他專家社群來審查和批准，每次審查都得等上很久。光在外部專家程式碼批准這個階段，平均就得等待17.1個小時。

後來，金融科技部門找來這群專家，討論初多項優化審查流程的作法，自己也避免進行大量的批次部署，盡量採取小型合併請求的方式，才將批准時間縮短到8分鐘。最後，到了去年十月，終於將這類單體式應用的變更準備時間大幅減少到14小時。

從年初每月20次部署、每次30小時事前準備時間，到年底十一月時縮短到每月40次部署，每次平均14小時。Booking.com的金融科技團隊就是靠DORA指標的監控，找出了一個又一個的開發團隊瓶頸，逐一解決，才能在不到一年，達到交付能力翻倍的成果。

Booking.com開發團隊主管更強調，這個做法不只提高了效率，更帶來了一種新的工作態度和方式，讓開發團隊聚焦於內部品質和嘗試，看重長期績效而非短期效益。