Agile Projelerde Tahminleme, Velocity ve DORA Metrikleri: Neyi Yanlış Ölçüyorsunuz?
- Onur Özcan
- 21 saat önce
- 2 dakikada okunur
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 inceledim.
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.
Sonuç: 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.
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şılmaya devam edecek. Serinin tamamını beklemek istemiyor ve hemen okumak istiyorsanız, hazırladığımız e-kitabı buradan ücretsiz indirebilirsiniz.
