DORA Metrikleri Nasıl Ölçülür? Yazılım Ekipleri İçin Uygulama Rehberi

Yazılım ekiplerinde metrik toplamak genellikle zor değildir.

Git geçmişinden commit'leri çıkarabilirsiniz. CI/CD sisteminden deployment sayılarını görebilirsiniz. Jira'dan cycle time hesaplayabilirsiniz. Incident kayıtlarından hata ve geri dönüş sürelerini bulabilirsiniz.

Asıl zor olan başka bir şeydir: Bu verilerin hangisinin gerçekten önemli olduğunu ve bize ne anlattığını bilmek.

Bir ekibin ayda 20 kez production'a çıkması iyi midir? Change Lead Time'ın iki gün olması hızlı mıdır? Change Fail Rate'in düşmesi gerçekten yazılım geliştirme sisteminin iyileştiğini mi gösterir? Bağlam olmadan bu soruların kesin bir cevabı yoktur. DORA metriklerinin değeri de yalnızca dashboard'a birkaç yeni sayı eklemelerinde değil, yazılım teslimat sisteminin nasıl çalıştığını anlamamıza yardımcı olmalarında ortaya çıkar.

Bu yazıda DORA'nın ne olduğundan çok, nasıl ölçülmesi, nasıl yorumlanması ve iyileştirme için nasıl kullanılması gerektiğine odaklanacağız. DORA, SPACE ve DevEx çerçevelerinin neyi ölçtüğüne dair genel bir başlangıç yapmak isterseniz önce “Modern Yazılım Geliştirme Ekiplerinde Üretkenliği Ölçmenin Yolları: DORA, SPACE ve DevEx” yazımızı okuyabilirsiniz.

DORA Metriklerini Ölçmeye Nereden Başlamalı?

DORA metriklerini kullanmaya başlayan organizasyonlarda ilk refleks genellikle sektördeki en iyi değerleri bulmak ve ekipleri bu rakamlarla karşılaştırmak oluyor.

Oysa başlangıç noktası bu olmamalı.

Öncelikle kendi yazılım teslimat sisteminizin mevcut durumunu anlamanız gerekir.

DORA da metriklerin belirli bir uygulama veya servis bağlamında değerlendirilmesini ve performansın zaman içerisindeki değişiminin takip edilmesini öneriyor.

Örneğin sürekli deployment yapan bir SaaS ürünüyle yılda birkaç kez regülasyon kontrollü release yapan bir sistemin aynı Deployment Frequency hedefini paylaşması anlamlı olmayabilir.

Bu nedenle ilk adım: “Sektörün en iyisi kaç?” sorusu değil, “Biz bugün neredeyiz?” sorusudur. Bir uygulama veya servis seçin, mevcut performansınızı ölçün ve bunu başlangıç seviyeniz yani baseline olarak kabul edin.

Bundan sonraki değerlendirmelerinizde asıl soru şuna dönüşür:

Yaptığımız değişiklikler yazılım teslimat sistemimizi gerçekten iyileştiriyor mu?

Güncel DORA Metrikleri Nelerdir?

DORA metrikleri yıllar içerisinde gelişti. Uzun süre dört temel metrikten söz edildi. Ancak güncel DORA modeli yazılım teslimat performansını beş metrik üzerinden değerlendiriyor ve bunları iki ana boyutta ele alıyor: throughput ve instability.

Boyut	Metrik	Temel soru
Throughput	Change Lead Time	Bir değişiklik production'a ne kadar sürede ulaşıyor?
Throughput	Deployment Frequency	Ne sıklıkla production'a değişiklik çıkarıyoruz?
Throughput	Failed Deployment Recovery Time	Problem yaratan bir deployment sonrasında ne kadar hızlı toparlanıyoruz?
Instability	Change Fail Rate	Deployment'larımızın ne kadarı müdahale gerektiren probleme yol açıyor?
Instability	Deployment Rework Rate	Deployment'larımızın ne kadarı kullanıcıyı etkileyen hataları düzeltmek için yaptığımız plansız işlerden oluşuyor?

Burada önemli olan tek tek metrikleri optimize etmek değildir. DORA'nın güncel yaklaşımında amaç, yazılım değişikliklerinin sistem içerisinde ne kadar hızlı hareket ettiğini ve bu değişikliklerin ne kadar istikrarlı olduğunu birlikte görmektir.

Deployment Frequency Nasıl Ölçülür?

D eployment Frequency en basit görünen DORA metriğidir: Belirli bir zaman içerisinde production ortamına kaç deployment yapılıyor?

Örneğin bir ekip:

• ayda iki kez,

• haftada birkaç kez,

• günde bir kez,

• ihtiyaç oldukça günde birden fazla kez

deployment yapıyor olabilir.

Ancak burada önemli bir ayrım vardır.Deployment sayısı tek başına bir performans hedefi değildir.

Bir organizasyona:

“Artık haftada 10 deployment yapacağız.”

demek, yazılım teslimat sisteminin gerçekten iyileştiği anlamına gelmez.

Ekip aynı değişikliği yapay şekilde küçük deployment'lara bölebilir veya anlamlı olmayan release'leri artırabilir. Asıl bakılması gereken şey, organizasyonun küçük ve güvenli değişiklikleri ihtiyaç duyduğunda production'a çıkarabilme yeteneğidir.

Deployment Frequency özellikle zaman içerisindeki trendi anlamak açısından daha değerlidir. Örneğin son altı ay içerisinde deployment sıklığı giderek düşüyorsa bunun altında büyüyen batch'ler, zorlaşan release süreçleri, manuel onaylar veya artan sistem bağımlılıkları olabilir. Metrik problemi gösterir.Problemin nedenini ise ayrıca araştırmanız gerekir.

Change Lead Time Nasıl Ölçülür?

Change Lead Time, bir kod değişikliğinin version control sistemine commit edilmesinden production ortamında başarılı biçimde çalışmasına kadar geçen süreyi ifade eder.

Basitçe: Commit → Production arasındaki süredir.

Örneğin bir geliştirici değişikliği pazartesi günü saat 10.00'da commit etmiş ve bu değişiklik salı günü saat 16.00'da production'a çıkmışsa Change Lead Time yaklaşık 30 saattir.

Ancak bu metriğin asıl değeri ortalama sürenin kendisinden çok, değişikliğin nerede beklediğini anlamaya başladığımızda ortaya çıkar. Bir değişiklik üzerinde aktif çalışma yalnızca iki saat sürüyor olabilir.

Fakat ardından:

12 saat code review,

8 saat CI/CD kuyruğu,

bir gün test ortamı bekleme,

iki gün release onayı

gerekiyorsa problemin kaynağı geliştiricinin çalışma hızı değildir. Sistemde ciddi bir bekleme süresi vardır.

Bu nedenle Change Lead Time yükseldiğinde:

“Geliştiriciler neden yavaş?”

sorusunu sormak yerine:

“Değişiklikler sistem içerisinde en fazla nerede bekliyor?”

sorusunu sormak daha değerlidir.

Change Fail Rate Nasıl Hesaplanır?

Change Fail Rate, production ortamına yapılan değişikliklerin ne kadarının müdahale gerektiren bir probleme yol açtığını gösterir. Basit bir örnek düşünelim.

Bir ay içerisinde 100 deployment yapıldı ve bunların 8'i:

• rollback,

• hotfix,

• fix-forward

• veya başka bir acil müdahale

gerektirdi.

Bu durumda Change Fail Rate yaklaşık:

8 / 100 = %8 olacaktır.

Buradaki önemli nokta her hatayı change failure olarak değerlendirmemektir.

Ölçüm tanımının organizasyon içerisinde açık olması gerekir. Aksi halde bir ekip yalnızca production outage'larını kaydederken başka bir ekip küçük hotfix'leri bile failure kabul edebilir.

Bu durumda iki takımın Change Fail Rate değerlerini karşılaştırmak yanıltıcı hale gelir.

Metrik kullanmaya başlamadan önce “failure bizim için ne demek?” sorusunun cevabı ekipler arasında netleştirilmelidir.

Failed Deployment Recovery Time Nasıl Ölçülür?

DORA'nın eski anlatımlarında bu alanda sıklıkla MTTR — Mean Time to Restore/Recover kavramıyla karşılaşılıyordu. Ancak DORA metriği zaman içerisinde daha spesifik hale getirildi ve günümüzde Failed Deployment Recovery Time olarak tanımlanıyor. Buradaki amaç herhangi bir sistem kesintisini ölçmek değildir.

Ölçülen şey: Production'a yapılan bir değişiklik sistemi bozduğunda, sistemi tekrar sağlıklı hale getirmek ne kadar sürüyor?

Örneğin saat 14.00'te yapılan deployment kullanıcıların ödeme işlemini tamamlayamamasına yol açtı. Problem 14.12'de fark edildi. Fix-forward deployment'ı 14.40'ta tamamlandı ve sistem normale döndü. Bu durumda recovery time, problemin kaynağı olan deployment ile sistemin tekrar sağlıklı hale geldiği an arasındaki süre üzerinden değerlendirilir.

Bu metrik organizasyonun yalnızca hata yapıp yapmadığını değil, hata yaptığında ne kadar hızlı toparlanabildiğini anlamamıza yardımcı olur. Çünkü karmaşık yazılım sistemlerinde bütün hataları önlemek gerçekçi değildir. Güçlü organizasyonların farklarından biri, problemleri hızlı fark edip güvenli şekilde toparlanabilmeleridir.

Deployment Rework Rate Nedir ve Neden Önemlidir?

DORA'nın güncel modelindeki önemli değişikliklerden biri Deployment Rework Rate metriğinin eklenmesidir. Bu metrik, plansız şekilde yapılan ve production'da kullanıcıyı etkileyen bir problemi düzeltmeyi amaçlayan deployment'ların oranına bakar.

Örneğin bir ekip ay boyunca 50 deployment yaptı. Bunların 10'u roadmap üzerindeki planlı çalışmalar değil, production'da ortaya çıkan kullanıcı sorunlarını düzeltmek için yapılan plansız deployment'lardı. Deployment Rework Rate yaklaşık %20 olacaktır.

Bu oran yükseldiğinde önemli bir sinyal ortaya çıkar:

• Ekip yeni değer üretmek için ayırabileceği kapasitenin giderek daha büyük bölümünü geçmişte oluşan problemleri düzeltmeye harcıyor olabilir.

• Bir takım dışarıdan çok aktif görünebilir.

• Çok sayıda ticket kapatıyor, çok sayıda commit yapıyor ve sürekli deployment gerçekleştiriyor olabilir.
  

Ancak bu hareketliliğin önemli kısmı rework ise yüksek aktivite, yüksek üretkenlik anlamına gelmez.

DORA Dashboard'unda Sadece DORA Metrikleri mi Olmalı?

Her zaman değil.

DORA metriklerini bir arabanın gösterge panelindeki uyarı ışıkları gibi düşünebiliriz.

Bir problemin varlığını gösterebilirler ancak her zaman problemin nedenini açıklamazlar.

Örneğin Change Lead Time yükseliyor.

Neden?

DORA metriği size bunu doğrudan söylemez. Bu noktada daha operasyonel teşhis metriklerine ihtiyaç duyabilirsiniz:

• Pull Request Review Time, değişikliklerin review aşamasında bekleyip beklemediğini gösterebilir.

• CI Pipeline Duration, build ve test süreçlerinin darboğaza dönüşüp dönüşmediğini gösterebilir.

• Queue Time, işin aktif olarak çalışılmadığı bekleme sürelerini görünür hale getirebilir.

• Batch Size, yapılan değişikliklerin gereğinden fazla büyüyüp büyümediğini anlamaya yardımcı olabilir.

Bunlar DORA metriklerinin yerine geçmez. DORA'nın işaret ettiği problemi teşhis etmek için ikinci seviyede kullanılan metriklerdir. İyi bir dashboard bu nedenle mümkün olduğunca fazla veri gösteren dashboard değildir. Doğru sorunun cevabını verebilen dashboard'dur.

DORA Metriklerini Yorumlarken Yapılan En Büyük Hata

En tehlikeli kullanım şekillerinden biri DORA metriklerini bireysel veya takım performans skoruna dönüştürmektir.

Örneğin:

Takım A haftada 20 deployment yapıyor, Takım B yalnızca 5 yapıyor. O halde Takım A dört kat daha üretken.

Bu çıkarım doğru değildir.

İki takım:

• farklı ürünlerde,

• farklı teknoloji stack'lerinde,

• farklı regülasyon koşullarında,

• farklı kullanıcı riskleriyle,

• farklı sistem bağımlılıklarıyla

çalışıyor olabilir.

DORA da metriklerin uygulama veya servis bağlamında değerlendirilmesine özellikle dikkat çekiyor. Bu nedenle DORA skorlarını organizasyon içerisinde bir lig tablosuna dönüştürmek yerine ekiplerin kendi sistemlerini zaman içerisinde geliştirmelerine yardımcı olacak göstergeler olarak kullanmak gerekir.

Metrik Hedefe Dönüştüğünde Ne Olur?

• Bir metriği doğrudan performans hedefi haline getirdiğiniz anda davranışlar da o metriğe göre değişmeye başlayabilir.

• Deployment Frequency KPI olursa ekipler daha fazla deployment yapmanın yollarını bulur.

• Story Point KPI olursa story point'ler büyüyebilir.

• Commit sayısı ölçülürse daha fazla commit yapılabilir.

• Ticket kapatma sayısı hedeflenirse ticket'lar küçülebilir.

• Dashboard iyileşirken gerçek sistem aynı kalabilir.

Bu durum ölçüm sistemlerinde sık karşılaşılan Goodhart Yasası probleminin bir örneğidir. Bu nedenle: Metrikler hedef değil, sinyal olmalıdır. Bir metric kötüleştiğinde amaç sorumlu kişiyi bulmak değil, sistemde neyin değiştiğini anlamaktır.

Örnek: Change Lead Time Yükseliyorsa Ne Yapmalıyız?

Bir takımın Change Lead Time değerinin üç ay içerisinde iki günden beş güne çıktığını düşünelim.

İlk tepki:

“Takım yavaşladı.”

olmamalıdır.

• Önce akış parçalanmalıdır.

• Kod geliştirme süresi değişti mi?

• Pull Request'ler ne kadar bekliyor?

• Code review kapasitesi yeterli mi?

• Test pipeline'ları uzadı mı?

• Release için manuel onay sayısı arttı mı?

• Takımlar arası bağımlılıklar oluştu mu?

• Değişikliklerin büyüklüğü arttı mı?

Bu sorular incelendiğinde örneğin geliştiricilerin aktif çalışma süresinin değişmediği ancak PR'ların ortalama 36 saat review beklemeye başladığı görülebilir. Bu durumda çözüm geliştiricilerin daha hızlı kod yazması değildir. Review sistemindeki darboğazı çözmektir.

İyi ölçüm sistemini kötü ölçüm sisteminden ayıran temel fark budur. Kötü sistem rakam gösterir. İyi sistem doğru soruyu sordurur.

DORA Metrikleriyle İyileştirme Döngüsü Nasıl Kurulur?

DORA metriklerinden değer elde etmek için onları aylık yönetim raporunda göstermek yeterli değildir. Ölçümün bir öğrenme döngüsünün parçası olması gerekir. Önce mevcut performansınızı belirleyin. Ardından en büyük darboğaz olduğunu düşündüğünüz alanı seçin.

Örneğin Change Lead Time yüksekse bunun altında yatan nedeni araştırın.

Diyelim ki CI pipeline'ın 45 dakika sürdüğünü ve gün içerisinde ekipte ciddi bekleme oluşturduğunu tespit ettiniz. Bu durumda iyileştirme hipoteziniz şöyle olabilir:

“Pipeline süresini 45 dakikadan 15 dakikanın altına indirirsek Change Lead Time azalacak.”

Sonrasında gerekli teknik değişikliği yapın ve birkaç hafta boyunca sonucu gözlemleyin.

• Change Lead Time gerçekten düştü mü?

• Deployment Frequency değişti mi?

• Change Fail Rate kötüleşti mi?

• Developer Experience iyileşti mi?

Ölçümün gerçek değeri burada ortaya çıkar: Bir değişikliğin gerçekten işe yarayıp yaramadığını anlayabilirsiniz.

Yapay Zekâ Destekli Yazılım Geliştirmede DORA Metrikleri Daha da Önemli mi?

Üretken yapay zekâ ve AI coding araçlarının yazılım geliştirme süreçlerine girmesiyle birlikte yeni bir soru ortaya çıktı:

AI geliştiricileri gerçekten daha üretken hale getiriyor mu?

Bu soruya yalnızca üretilen kod miktarına bakarak cevap vermek yanıltıcı olabilir. AI sayesinde geliştirici daha fazla kod üretebilir. Fakat aynı zamanda code review yükü artıyorsa, daha fazla rework oluşuyorsa veya change failure yükseliyorsa toplam sistem performansı aynı oranda gelişmeyebilir.

Bu nedenle AI araçlarının etkisini değerlendirirken yalnızca:

“Ne kadar daha fazla kod yazıldı?”

sorusuna değil,

“Yazılımı kullanıcıya daha hızlı ve daha güvenilir ulaştırabiliyor muyuz?”

sorusuna bakmak gerekir.

DORA metrikleri tam da bu noktada değerli bir perspektif sağlar. Ancak yine aynı kural geçerlidir: DORA bütün resmi tek başına göstermez. Geliştirici deneyimi, bilişsel yük, kalite ve ürün çıktıları da değerlendirilmelidir.

DORA Metriklerini Kullanırken Ne Amaçlamalıyız?

DORA metrikleri bir performans karnesi değildir. Bir ekibin başka bir ekipten “daha iyi” olduğunu ispatlamak için de tasarlanmamıştır. Asıl amaç yazılım teslimat sisteminin davranışını görünür hale getirmektir.

• Bir değişiklik production'a neden üç gün içerisinde ulaşıyor?

• Neden deployment sayımız azalıyor?

• Hatalardan neden yeterince hızlı toparlanamıyoruz?

• Ekip kapasitemizin ne kadarı plansız düzeltmelere gidiyor?

Bu sorulara cevap vermeye başladığımızda ölçüm, raporlama faaliyetinden çıkıp sürekli iyileştirme aracına dönüşür. Sharpware olarak yazılım ekiplerinin ölçümlenmesinde en önemli prensiplerden birinin şu olduğunu düşünüyoruz: İnsanları ölçmeye çalışmak yerine, insanların iyi yazılım üretmesini kolaylaştıran veya zorlaştıran sistemi ölçün. Metrikler ancak bu bakış açısıyla kullanıldığında gerçek değer üretir.

Sık Sorulan Sorular

DORA metrikleri nasıl ölçülür?

DORA metrikleri çoğunlukla version control, CI/CD, deployment ve incident yönetim sistemlerindeki veriler kullanılarak ölçülür. Önemli olan yalnızca veriyi toplamak değil, metriklerin organizasyon içerisinde aynı tanımlarla ve belirli bir uygulama veya servis bağlamında hesaplanmasıdır.

DORA metrikleri takım performansını ölçmek için kullanılabilir mi?

DORA metrikleri bireysel geliştiricileri veya ekipleri sıralamak için kullanılmamalıdır. Daha doğru kullanım, yazılım teslimat sisteminin zaman içerisindeki değişimini takip etmek ve iyileştirme alanlarını belirlemektir.

DORA metrikleri kaç tanedir?

DORA'nın güncel yazılım teslimat performansı modeli beş metrikten oluşur: Change Lead Time, Deployment Frequency, Failed Deployment Recovery Time, Change Fail Rate ve Deployment Rework Rate.

DORA metrikleri hangi araçlardan alınabilir?

Veriler Git tabanlı sistemler, CI/CD platformları, deployment araçları, observability sistemleri ve incident management araçlarından elde edilebilir. Kullanılan teknoloji kadar metrik tanımlarının tutarlı olması da önemlidir.

DORA metrikleri tek başına yeterli midir?

Hayır. DORA ağırlıklı olarak yazılım teslimat performansını gösterir. Developer Experience, ekip işbirliği, ürün çıktıları ve kullanıcı değeri gibi farklı boyutları anlamak için DevEx, SPACE veya organizasyona özgü başka ölçümlerle birlikte değerlendirilmesi daha sağlıklıdır.

Ölçmenin Amacı Daha Fazla Sayı Üretmek Değildir

Yazılım organizasyonlarının büyük bölümü ihtiyaç duyduğundan çok daha fazla veri üretiyor. Sorun çoğu zaman veri eksikliği değil, hangi verinin hangi kararı desteklemesi gerektiğinin belirsiz olmasıdır. DORA metrikleri bu karmaşayı azaltmak için iyi bir başlangıç noktası sunar. Fakat değer, dashboard'daki rakamlardan değil; bu rakamların arkasında doğru sorular sorabilmekten gelir.

• Neredeyiz?

• Nerede bekliyoruz?

• Nerede yeniden iş yapıyoruz?

• Yaptığımız iyileştirme gerçekten sistemi değiştirdi mi?

Bu sorular düzenli olarak soruluyorsa ölçüm sistemi amacına ulaşmaya başlamış demektir.

Sharpware'ın Yazılım Takımları için Metrikler ve Ölçümleme Danışmanlığı kapsamında organizasyonunuza uygun metrik modelini oluşturabilir, mevcut yazılım teslimat akışını görünür hale getirebilir ve metrikleri sürekli iyileştirme sisteminin bir parçasına dönüştürebilirsiniz.