Agile Projelerde Tahminleme, Velocity ve DORA Metrikleri: Neyi Yanlış Ölçüyorsunuz?
Güncelleme tarihi: 17 Eyl
Kısaca Velocity bir takımın planlama aracıdır; bireyleri veya takımları karşılaştırmak için kullanılabilecek bir performans KPI’ı değildir. Yazılım teslimatını değerlendirmek için tahminleri DORA ve akış metrikleri gibi sistem odaklı ölçümlerle birlikte ele almak gerekir.
Agile Metrikler ve Tahminleme: Doğru Yolda Mıyız?
Agile metrikler ve tahminleme, çoğu organizasyonda yanlış anlaşılan kavramlardır. Velocity (Hız), bir takımın kapasitesini planlamak için kullanılan içsel bir veridir; bir performans göstergesi (KPI) değildir. Yazılım takımlarının gerçek sağlığını ve performansını ölçmek için DORA Metrikleri (Lead Time, Deployment Frequency, MTTR, Change Failure Rate) kullanılmalıdır.
Bu rehberde, "Bu iş ne zaman biter?" sorusuna verilen yanlış cevapları, tahminleme paradoksunu ve Agile dünyasında gereksinim yönetiminin (Requirements Engineering) nasıl olması gerektiğini inceleyeceğim.
1. Tahminleme Paradoksu: "Bana Kesin Bir Tarih Ver!"
Bir yazılım projesinin ne zaman biteceğini kesin olarak bilmenin tek bir yolu vardır: O projeyi bitirmek.
Yöneticiler genellikle kesin tarihler ister. Ancak yazılımda kesinlik arttıkça, tahmin için harcanan süre de artar.
Bir projenin %100 kesin tahminini istiyorsanız, onu kod satırlarına kadar ayırmanız gerekir. Bunu yaptığınızda zaten projeyi yazmış olursunuz.
Örnek: "Önümüzdeki 1000 yıl içinde öleceğim" tahmini %100 doğrudur ama kesin değildir (aralık geniştir). "Yarın 14:02'de öleceğim" tahmini çok kesindir ama muhtemelen yanlıştır.
Ders: Takımlarınız size kesin bir tarih yerine bir "zaman aralığı" (Range) veriyorsa onlara güvenin. Size günü gününe tarih verenler, muhtemelen sadece duymak istediğinizi söylüyordur.
2. Velocity (Hız) Tuzağı
Sektörde en sık yapılan hatalardan biri, takımları "Velocity" (Sprint başına tamamlanan Story Point) üzerinden yarıştırmaktır.
"Velocity'miz arttı mı?"
"Diğer takım 50 puan yaptı, siz niye 30 yaptınız?"
Bu sorular anlamsızdır. Velocity, takımın kendi iç planlaması içindir. Puanlar görecelidir ve manipüle edilebilir. Yöneticiler baskı yaparsa, takım 1 puanlık işe 5 puan demeye başlar ve velocity "kağıt üzerinde" artar.
3. Gerçek Performans: DORA Metrikleri
Eğer takımınızın performansını gerçekten ölçmek istiyorsanız, Google'ın DevOps araştırmaları sonucunda ortaya koyduğu DORA Metriklerine bakmalısınız:
Lead Time: Bir fikrin veya isteğin, müşterinin eline ulaşan çalışan bir yazılıma dönüşmesi ne kadar sürüyor? (Sadece kodlama süresi değil, toplam süre).
Deployment Frequency: Ne sıklıkla canlıya çıkıyorsunuz? (Ayda bir mi, günde on kere mi?)
Mean Time to Recovery (MTTR): Bir hata olduğunda sistemi ne kadar sürede ayağa kaldırıyorsunuz?
Change Failure Rate: Yaptığınız değişikliklerin yüzde kaçı hataya neden oluyor?
Yüksek Velocity değil; düşük Lead Time ve yüksek Deployment Frequency peşinde koşmalısınız.
4. "Agile'da Dokümantasyon Yoktur" Yalanı
Çevik dönüşümlerde yanlış anlaşılan bir diğer konu da analizdir. "Biz Agile olduk, artık analiz dokümanı yazmıyoruz, User Story yeterli" demek büyük bir hatadır. Hangi yöntemi kullanırsanız kullanın (Scrum, Kanban, Waterfall), işi yapacak yazılımcının önüne net gereksinimler koymalısınız.
Agile Software Requirements: Gereksinimlerin kaybolduğu değil, sadece daha küçük parçalar halinde ve tam zamanında (Just-in-Time) analiz edildiği bir yöntemdir.
Gereksinimleri düzgün ele almadığınızda, yazılımcılarınız kod yazmak yerine "Burada ne demek istemiş?" diye toplantı yapmak zorunda kalır.
5. Önceliklendirme Müşterinin Sorumluluğudur
Çoğunlukla IT ekipleri önceliklendirmenin öneminin farkındadır. Sorun iş birimlerindedir. Her Sprint araya "Acil" işler sokuşturuluyorsa, her şey "En Yüksek Öncelik" ise, orada hiçbir şey öncelikli değildir.
Müşteriye şunu net anlatmalısınız: "Her istediğiniz hemen yapılacak, işler 8 kat hızlanacak" diye bir dünya yok. Kapasite bellidir. Eğer yeni bir şey ekliyorsak, listeden neyi çıkarıyoruz? Bu kararı IT değil, iş sahibi vermelidir.
6. Veriye Dayalı Yönetim
Duygularla veya "Deadline doğum günüme yetişsin" gibi irrasyonel hedeflerle proje yönetilmez. Veriye, doğru metriklere ve sağlam analiz tekniklerine ihtiyacınız var. İş birimlerinizin, analistlerinizin ve proje yöneticilerinizin bu yetkinlikleri kazanması için eğitimlerimizi inceleyebilirsiniz.
Sonuç: Doğru Yolda Mıyız?
Agile metrikler ve tahminleme, yazılım geliştirme süreçlerinde kritik bir rol oynar. Ancak, bu kavramların doğru anlaşılması ve uygulanması gerekir. Aksi takdirde, projelerinizin başarısını tehlikeye atabilirsiniz. Unutmayın, doğru metrikler ve veriye dayalı yönetim, sizi hedeflerinize ulaştıracak en önemli araçlardır.
Bu yazı, Onur Özcan'ın "Nasıl Agile (Çevik) Olunmaz?" serisinin küçük bir bölümüdür. Toplamda 4 ayrı blog yazısı olacak şekilde paylaşılan bu serinin tamamını içeren e-kitabı buradan ücretsiz indirebilirsiniz.
Sıkça Sorulan Sorular
Agile projelerde bitiş tarihi nasıl tahmin edilir?
Kesin tek bir tarih vermek yerine geçmiş teslimat verileri, throughput ve cycle time gibi ölçümler kullanılarak olası bir zaman aralığı oluşturmak daha sağlıklıdır. Belirsizlik arttıkça tahmin aralığının da genişlemesi normaldir.
Story Point ile saat tahmini aynı şey midir?
Hayır. Story Point işin göreceli büyüklüğünü, karmaşıklığını ve belirsizliğini ifade eder; doğrudan saat karşılığı değildir. Story Point’i sabit bir saat dönüşümüne bağlamak yöntemin amacını bozabilir.
Takımların velocity değerleri neden karşılaştırılmamalıdır?
Her takım story point ölçeğini kendi bağlamında oluşturduğu için 30 puanlık bir takım ile 50 puanlık başka bir takım doğrudan karşılaştırılamaz. Velocity yalnızca aynı takımın kendi planlama geçmişi içinde anlamlıdır.
Agile’da deadline kullanılabilir mi?
Evet. Yasal zorunluluk, kampanya tarihi veya sözleşmesel teslim gibi gerçek deadline’lar olabilir. Önemli olan sabit tarih karşısında kapsam, risk ve kapasiteyi şeffaf biçimde yönetmek ve tahmini kesinlik gibi sunmamaktır.
Scrum takımının kapasitesi nasıl hesaplanır?
Geçmiş sprintlerde tamamlanan iş miktarı, ekipteki izinler, çalışma günleri ve yaklaşan dönemdeki olağan dışı koşullar birlikte değerlendirilir. Kapasite planlaması kesin üretim taahhüdü değil, sprint kapsamını daha gerçekçi belirlemek için kullanılan bir girdidir.
Agile ekiplerde performans hangi metriklerle ölçülmelidir?
Tek bir metrik yerine lead time, cycle time, deployment frequency, change failure rate, kalite ve ürün sonuçları birlikte değerlendirilmelidir. Amaç kişileri puanlamak değil, teslimat sisteminin nerede iyileştirilebileceğini anlamaktır.
