Yazılım ekibinin performansı nasıl ölçülür? DORA metrikleri ve ölçmemeniz gerekenler

Bir yazılım ekibinin ne kadar iyi çalıştığını kod satırıyla, commit sayısıyla ya da kapanan görev adediyle ölçemezsiniz; bunlar çabayı sayar, sonucu değil. Savunulabilir ölçüm kişiyi değil teslim akışını ölçer ve DORA'nın beş metriği tam olarak bunu yapar: değişiklik teslim süresi, yayına alma sıklığı ve başarısız yayından kurtulma süresi akışı gösterir, değişiklik hata oranı ile yayın tekrar işi oranı kararsızlığı gösterir. Beşi birlikte okunduğunda "ne kadar hızlı ve ne kadar güvenli teslim ediyoruz" sorusunun cevabını verir. Tek tek okunduğunda ya da kişi bazına indirildiğinde ölçmek istediğiniz şeyi bozar.

Önce ölçmemeniz gerekenler

Kod satırı, commit sayısı, açılan pull request adedi, sprint velocity'si. Dördü de aynı hatayı yapar: üretilen işin hacmini, o işin işe yarayıp yaramadığından bağımsız olarak sayar. Velocity'yi hedefe çevirdiğiniz hafta puanlar şişer, kod satırını ölçtüğünüz hafta kimse kod silmez. Goodhart yasasının yazılım ekiplerindeki hâli budur ve DORA'nın kendi rehberi de bu uyarıyı metriklerin başına koyuyor: metriği hedefe çevirmek, ekibi gerçekten iyileşmeye değil sayıyı oynatmaya yöneltir.

Bu tartışmanın referans noktası 2023 yazında yaşandı. McKinsey "yazılım geliştirici verimliliğini ölçebilirsiniz" başlıklı bir makale yayımladı, iki hafta sonra Kent Beck ve Gergely Orosz iki bölümlük bir yanıt yazdı. Eleştirinin özü şuydu: önerilen çerçeve çabayı ve çıktıyı ölçüyor, sonucu ve etkiyi değil. Bir geliştiricinin haftada ne kadar iş ürettiğini bilmek, o işin gelire ya da müşteri değerine dönüşüp dönüşmediği hakkında hiçbir şey söylemiyor.

Pratikte "ekibin performansı" sorusunun altında genelde üç ayrı soru yatar. Yeterince hızlı mıyız? Kalite düşüyor mu? Harcadığımız paranın karşılığını alıyor muyuz? DORA metrikleri ilk ikisini iyi ölçer. Üçüncüsü için bambaşka veriye ihtiyacınız var ve bu yazının sonunda oraya geleceğiz.

DORA'nın beş metriği tam olarak ne sayar

Metrikler 2014'te dört taneydi, bugün beş. İsimleri ve tanımları da yolda değişti, o yüzden hangi tanımı kullandığınızı yazılı hâle getirmeden ölçmeye başlamayın.

Değişiklik teslim süresi (change lead time): Bir değişikliğin sürüm kontrolüne işlendiği andan üretime çıktığı ana kadar geçen süre. Dikkat edilecek nokta, sayacın fikirden değil commit'ten başlaması. "Talebi verdik, altı hafta sonra canlıya çıktı" farklı bir ölçüdür ve ürün tarafı için genelde daha anlamlıdır, ama DORA'nın ölçtüğü şey değildir. İkisini birbirine karıştıran ekip, kuyrukta bekleyen analiz süresini mühendislik yavaşlığı sanır.

Yayına alma sıklığı (deployment frequency): Belirli bir dönemde üretime yapılan yayın sayısı ya da iki yayın arasındaki süre.

Başarısız yayından kurtulma süresi (failed deployment recovery time): Hemen müdahale gerektiren başarısız bir yayından toparlanma süresi. Bu metrik 2023'te eski "ortalama kurtarma süresi"nden (MTTR) ayrıldı, çünkü MTTR veri merkezi arızası gibi sizin değişikliğinizle ilgisi olmayan olayları da içeriyordu. Yeni tanım yalnızca kendi yayınınızın yol açtığı arızayı sayar.

Değişiklik hata oranı (change fail rate): Yayın sonrasında acil müdahale gerektiren yayınların oranı. Geri alma, acil yama, sistemi kurtarmak için yapılan doğrudan düzeltme.

Yayın tekrar işi oranı (deployment rework rate): 2024'te eklenen beşinci metrik. Üretimdeki bir sorun yüzünden yapılan, planlanmamış yayınların oranı. Farkı şurada: değişiklik hata oranı yayının anında patlamasını sayar, tekrar işi oranı ise kullanıcının bulduğu bir hatayı kapatmak için ertesi gün çıkılan plansız yayını sayar. Birincisi düşük görünüp ikincisi yüksekse, ekip acil durum yaşamıyor ama sürekli arkasını topluyor demektir.

İlk üçü akışı (throughput), son ikisi kararsızlığı (instability) ölçer. Bu ayrım önemli, çünkü tek başına bir akış metriğini iyileştirmek kolaydır: testleri kapatın, yayın sıklığı artar.

Bu sayıların verisi zaten sistemlerinizde duruyor

Yeni bir araç satın almadan önce elinizdekine bakın. Yayına alma sıklığı, dağıtım hattınızın (pipeline) üretim işlerinin kaydından çıkar. Değişiklik teslim süresi, o yayına giren commit'lerin zaman damgalarıyla yayın anının farkından çıkar. Kalan üçü için olay ve geri alma kaydı gerekir.

Tıkanma genelde son üçünde olur ve sebebi araç eksikliği değil, tanım eksikliğidir. Bir yayının hangi durumda "başarısız" sayıldığını tek cümleyle yazmadıysanız, iki mühendis aynı olayı farklı sayar ve ay sonunda çıkan oran hiçbir şey ifade etmez. En basit kural şu: yayından sonra planlanmamış bir müdahale (geri alma, acil yama, bayrak kapatma) gerekiyorsa o yayın başarısızdır. Aynı şekilde plansız yayını da etiketleyin; dağıtım hattına eklenecek tek bir alan, tekrar işi oranını aylar sonra elle hesaplama derdinden kurtarır. Metrik tanımlarının nerede saklanacağı ve kimin sahibi olduğu konusuna raporların neden tutmadığı yazısında ayrıca girmiştik.

Kapsam konusunda DORA'nın kendi uyarısı net: metrikleri uygulama ya da servis düzeyinde uygulayın, birden fazla ekibin ya da uygulamanın sayılarını tek potada toplamayın. Haftada bir çıkan bir muhasebe entegrasyonu ile günde beş kez çıkan bir web uygulamasının ortalamasını almak, iki ekip hakkında da yanlış bilgi üretir.

"İyi" rakam nedir?

Kıyas tablolarına bakmak cazip ama ilk yılda yanlış iş. İki sebeple. Birincisi bağlam: gömülü yazılım, regülasyona tabi bir sistem ve bir SaaS ürünü aynı yayın ritmine sahip olamaz. İkincisi, dışarıdan alınmış bir hedefi kurum içinde dayatmak (örneğin "herkes günde birkaç kez yayın yapacak") DORA'nın açıkça uyardığı hatadır.

Daha sağlıklı yol, kendi taban çizginizi çıkarıp trendi izlemek. DORA'nın ücretsiz Quick Check aracı başlangıç noktası belirlemek için yeterli. Sonrasında bakacağınız şey mutlak değer değil, yön: teslim süresi üç ayda kısaldı mı, hata oranı yeni sürümlerle birlikte tırmanıyor mu, kurtarma süresi hep aynı serviste mi uzuyor?

Bir de şu testi yapın: rakam bir toplantıda kimseyi savunmaya geçirmiyorsa doğru kullanıyorsunuz demektir. "Neden teslim süremiz 11 gün?" sorusu bir suçlama değil, kuyruğun nerede olduğunu arayan bir sorudur. Cevap çoğu zaman kod yazma hızında değil, gözden geçirmeyi bekleyen pull request'lerde, elle yapılan yayın adımlarında ya da haftada bir toplanan onay kurulundadır.

Hız ile istikrar birbirinin rakibi değil

Yaygın varsayım, daha az yayın yapan ekibin daha güvenli olduğudur. DORA araştırmasının en eski ve en tutarlı bulgusu bunun tersini söylüyor: hızlı teslim eden ekipler aynı zamanda daha kararlı çalışıyor, çünkü ikisini birlikte getiren şey aynı uygulamalar.

En etkilisi parti büyüklüğü. DORA'nın küçük partiler halinde çalışma rehberi somut bir eşik veriyor: tamamlanması ve kontrol edilmesi bir haftadan uzun süren bir kod parçası çok büyüktür ve geliştiriciler değişikliklerini en az günde bir kez ana dala işlemelidir. Büyük parti demek, geri alması zor yayın, teşhisi zor arıza ve uzun kurtarma süresi demektir.

İkincisi onay süreci. DORA araştırması, harici bir değişiklik onay kurulunun (CAB) teslim performansını olumsuz etkilediğini ve daha resmî bir dış inceleme sürecinin hata oranını düşürdüğüne dair bulgu bulunmadığını söylüyor. Yerine önerilen şey geliştirme sırasında akran incelemesi, otomatik test ve iyi izleme. Onay kurulunun işi kod incelemek değil, koordinasyon ve süreç tasarımı olmalı.

Kalanı bilinen mühendislik işi: küçük ekipler için CI/CD hattını kurmak, test otomasyonunu piramide oturtmak, sıfır kesintili yayına alma ve geri alma yolunu hazırlamak, riskli değişiklikleri özellik bayraklarıyla kademeli açmak. Metrikler bu işlerin yerine geçmez; hangisinin en çok işe yaradığını gösterir.

Yapay zekâ bu sayıları hangi yöne itiyor

2025 DORA raporu yaklaşık 5.000 katılımcıya ve 100 saatin üzerinde görüşmeye dayanıyor ve tabloyu net çiziyor. Katılımcıların %90'ı işinde yapay zekâ kullanıyor, %80'den fazlası verimliliğinin arttığını söylüyor, buna karşılık %30'u ürettiği koda az güveniyor ya da hiç güvenmiyor. Rapor, yapay zekâ kullanımının teslim akışını yukarı, teslim istikrarını ise aşağı çektiğini buluyor.

Raporun ana tezi, yapay zekânın bir yükseltici olduğu: sağlam süreçleri olan kurumda iyileştirmeyi, dağınık süreçleri olan kurumda dağınıklığı büyütüyor. DORA'nın Mayıs 2026'da yayımladığı yatırım getirisi raporu buna iki kavram ekliyor. Biri doğrulama vergisi, yani üretilen kodu gözden geçirme yükünün ilk dönemde kazancı yemesi. Diğeri J eğrisi, yani benimseme döneminde önce bir düşüş yaşanması ve getirinin sonra gelmesi.

Uygulamaya çevirisi şu: ekibinize kod üreten bir asistan verdiyseniz, yalnızca yayın sıklığına bakıp sevinmeyin. Aynı çeyrekte değişiklik hata oranı ile tekrar işi oranı da yükseliyorsa kazandığınız hız, sonradan ödediğiniz düzeltme işine gidiyor demektir. Yapay zekâ ile yazılan kodu gözden geçirme yazısındaki kabul ölçütleri tam bu noktada devreye giriyor.

Beş metriğin görmediği şey

DORA metrikleri "işi doğru yapıyor muyuz" sorusunu ölçer, "doğru işi yapıyor muyuz" sorusunu değil. Kimsenin kullanmadığı bir özelliği günde üç kez yayına almak, bu tabloda mükemmel görünür.

Eksik parçayı kapatmak için iki tarafa daha bakmak gerekiyor. Birincisi güvenilirlik: yayın sıklığı yüksek ama kullanıcı yavaşlıktan şikâyet ediyorsa metrikler size bunu söylemez, SLO ve hata bütçesi söyler. İkincisi geliştirici deneyimi. 2021'de yayımlanan SPACE çerçevesi verimliliği tek bir sayıya indirmenin mümkün olmadığını söyleyip beş boyut öneriyor: memnuniyet ve iyi olma hâli, performans, faaliyet, iş birliği ve iletişim, verimlilik ve akış. Çerçevenin pratik kuralı da şu: ölçümü ekip düzeyinde yapın ve en az üç farklı boyuttan metrik seçin.

Üçüncüsü ürün tarafı: kullanım, dönüşüm, destek talebi hacmi, yenileme oranı. Teslim metrikleri iyileşirken bu sayılar kıpırdamıyorsa sorun mühendislik hızında değil, kapsam kararlarındadır (ilk sürüme ne girmeli).

Sayıyı bozmanın üç kolay yolu

Birincisi kişi bazlı pano. Geliştirici başına commit, PR ya da teslim süresi dağıtan bir pano, ölçümün ilk gününde ekibin davranışını değiştirir: kimse büyük refactor'e girmez, kimse başkasının kodunu gözden geçirmeye vakit ayırmaz, PR'lar yapay olarak bölünür. Ölçümü ekip düzeyinde tutun.

İkincisi ekipleri birbirine karşı sıralamak. Farklı ürünlerin, farklı mimarilerin ve farklı risk seviyelerinin sayıları yan yana anlamlı değil. Karşılaştırma yapılacaksa ekibin kendi geçmişiyle yapılır.

Üçüncüsü metriği prime, performans değerlendirmesine ya da tedarikçi cezasına bağlamak. Yayın sıklığına hedef koyduğunuzda boş yayınlar başlar, hata oranına hedef koyduğunuzda olaylar kaydedilmemeye başlar. İki kararsızlık metriğini birlikte okumanın bir sebebi de bu: tekrar işi oranı, kayıtlara girmeyen sorunların bir kısmını yine de görünür kılar.

Dışarıdan geliştirme alıyorsanız

Bu metrikler tedarikçi ilişkisinde de işe yarar, ama sözleşmeye eşik olarak değil görünürlük maddesi olarak girmeli. İsteyeceğiniz şey "haftada en az üç yayın" taahhüdü değil; yayın kayıtlarına, olay kayıtlarına ve dağıtım hattına erişim, aylık raporda beş metriğin aynı tanımla verilmesi ve bir arıza sonrası kısa bir değerlendirme notu.

Bu, aynı zamanda bir devir hazırlığıdır: kayıtların ve hattın sizde olduğu bir kurulumda ekip değiştiğinde ölçüm de tarih de kaybolmaz. Nelerin sözleşmede yazılı olması gerektiğini bakım ve destek sözleşmesi yazısında, riskin taraflar arasında nasıl dağıldığını sabit fiyat mı zaman-malzeme mi yazısında toparlamıştık.

Bir not daha: tedarikçinizin teslim süresi uzunsa sebebin sizde olma ihtimali yüksek. Onay bekleyen kararlar, geç verilen test ortamı, haftada bir toplanan yönlendirme kurulu. Metrik tek taraflı bir karne değil, iki tarafın ortak kuyruğunu gösteren bir ölçüdür.

Bu haftaya sığan üç adım

Bir: son 90 günün üretim yayınlarını bir tabloya dökün. Tarih, servis, yayına giren ilk commit'in zamanı, geri alma olup olmadığı. Bu tablo çıktığı anda beş metriğin üçü elinizde olur ve çoğu ekipte asıl sürpriz, yayınların takvimde nasıl kümelendiğidir.

İki: "başarısız yayın" ve "plansız yayın" tanımlarını birer cümleyle yazıp dağıtım hattında etiketleyin. Tanım olmadan toplanan veri, üç ay sonra yeniden yorumlanmak zorunda kalır.

Üç: tek bir servis seçin ve bir çeyrek boyunca hedef koymadan sadece izleyin. Taban çizgisi oluşmadan konulan hedef, iyileştirme değil sayı oynatma üretir.

Wedevit olarak ekiplerin teslim akışını mevcut kayıtlardan çıkarıyor, tanımları yazılı hâle getiriyor, dağıtım hattına ölçüm noktalarını ekliyor ve çıkan tabloyu ekip performansı karnesine değil darboğaz haritasına çeviriyoruz. Somut ilk soru şu: en son yayınınızın commit'i ne zaman yazılmıştı ve bu sayıyı bulmak kaç dakikanızı alıyor?