Yazılım Projelerinde Efor ve Süre Nasıl Tahmin Edilir
Yazılım projelerinde efor ve süre tahmini: görev kırılımı, göreli tahmin, story point, aralıklı tahmin, akış verisi, risk payı ve paydaşlara iletişim yöntemi.
Efor tahmini neden zordur?
Yazılım işi, doğası gereği belirsizlik taşır. Gereksinimler yazılırken netleşir, teknik riskler çoğu zaman kodlamaya başlayınca görünür olur, bağımlılıklar ve kesintiler planı bozar. Bu yüzden tahmin, kesin bir söz değil bilgiye dayalı bir öngörüdür. Tahmin hatalarının yaygın nedenleri iyimserlik eğilimi, ihmal edilen görevler (test, entegrasyon, dağıtım, dokümantasyon), net olmayan kapsam ve geçmiş veriyi kullanmamaktır.
Önce kavramları ayırmak gerekir. Efor, işin gerektirdiği çalışma miktarıdır. Süre, işin takvimde ne kadar yer kapladığıdır; kesintiler, paralel işler ve bekleme süreleri yüzünden eforla aynı değildir. Taahhüt ise tahmine dayanarak verilen sözdür. Tahmini taahhüde dönüştürürken risk payı ve belirsizlik aralığı açıkça paylaşılmalıdır.
Önce kapsamı kırın: iş kırılımı
Büyük işi bütün olarak tahmin etmek, hatanın en büyük kaynağıdır. İşi, her biri anlaşılır ve tamamlanabilir parçalara bölmek (iş kırılımı) hem unutulan görevleri ortaya çıkarır hem de küçük parçaların tahminini daha isabetli kılar. Kırılım yapılırken yalnızca kodlama değil, şu işler de listeye girer: • Çözüm tasarımı ve teknik araştırma • Test yazımı ve hata düzeltme • Entegrasyon ve ortam kurulumu • Kod gözden geçirme ve dokümantasyon • Dağıtım ve canlı sonrası destek
İşin tanımı net değilse önce netleştirme sorularını yazın: kabul ölçütü nedir, kapsam dışı olanlar neler, hangi sistemlere bağımlı? Net olmayan işi tahmin etmeye çalışmak yerine, önce kısa bir araştırma çalışması (spike) planlayıp belirsizliği azaltmak daha sağlıklıdır.
Tahmin teknikleri
Farklı teknikler farklı durumlara uygundur. • Uzman görüşü: deneyimli kişilerin tahmini. Hızlıdır, fakat bireysel yanlılığa açıktır. • Benzerlik (analoji) tahmini: geçmişte tamamlanmış benzer işlerle kıyaslama. Geçmiş veri tutulduysa isabetlidir. • Alttan yukarı tahmin: kırılımdaki küçük görevlerin tahminini toplamak. • Aralıklı tahmin: her görev için iyimser, olası ve kötümser değerleri belirleyip ağırlıklı ortalama almak. Belirsizliği görünür kılar. • Göreli tahmin: işleri mutlak süre yerine birbirine göre büyüklükle ölçmek. Çevik ekiplerde story point bu amaçla kullanılır; ekipler genellikle Fibonacci benzeri bir ölçek ya da giysi bedenleriyle çalışır. • Planning poker: ekip üyeleri aynı anda kendi tahminini açar, farklar tartışılır ve ortak anlayışa varılır.
Bir tekniğe bağlı kalmak yeterli değildir; kırılım yapıp alttan yukarı tahmin etmek, sonucu benzer geçmiş işlerle çapraz kontrol etmek güven artırır.
Story point ve hız: ne anlama gelir, nasıl yanlış kullanılır?
Story point, bir işin göreli büyüklüğünü ifade eden birimsiz bir ölçüdür. Büyüklük; iş miktarı, karmaşıklık ve belirsizliği birlikte yansıtır. Bir ekibin bir iterasyonda tamamladığı toplam puan ekibin hızı (velocity) olur ve ileriye dönük planlama için kaba bir gösterge sağlar.
Bu araçlar sık yanlış kullanılır. Puan saate çevrilmeye çalışılırsa göreli tahminin avantajı kaybolur. Hız, ekipleri karşılaştırmak ya da performans ölçmek için kullanıldığında ekipler puanları şişirir ve ölçü anlamını yitirir. Puan; ekip, ürün ve teknolojiye özgüdür, başka ekibin puanıyla kıyaslanamaz. Hız yalnızca ekibin kendi planlaması için kullanıldığında yararlıdır. Ayrıca puan, işin tamamlanmış tanımına (test ve gözden geçirme dahil) göre verilmelidir.
Akış verisi, risk ve olasılıksal tahmin
Tahminlerin sürekli sorgulanması yerine, ekibin gerçek geçmiş verisinden yararlanmak daha güvenilirdir. Bir işin başlangıçtan bitişe geçirdiği süre (çevrim süresi) ve belirli bir zamanda biten iş sayısı (verim) kayıt altına alındığında, benzer işlerin ne kadar süreceği gözlemlenen dağılımdan okunabilir. Bir sayı yerine "bu iş büyük olasılıkla şu aralıkta biter" ifadesi dürüst bir tahmindir.
Bu veriyle olasılıksal öngörü yapılır: kalan iş adedi ve ekibin geçmiş verimi kullanılarak simülasyonla farklı bitiş tarihleri için olasılık çıkarılır. Yaklaşımın avantajı, tahmin toplantılarını azaltması ve belirsizliği aralık olarak göstermesidir. Riskler ise ayrıca yönetilir: bilinen riskler listelenir, her biri için olasılık ve etki değerlendirilir ve plana risk payı eklenir. Risk payı sezgisel eklenen sabit bir oran yerine, tanımlı risklere dayandırılmalıdır.
Tahmini paydaşlara nasıl iletirsiniz?
Tahminin sorunu çoğu zaman hesapta değil iletişimdedir. Yönetici bir tarih bekler, ekip ise bir aralık verebilir. İletişimde şu ilkeler işe yarar: • Tarih yerine aralık ve güven düzeyi paylaşmak: "çoğu ihtimalle bu aralıkta, belirli koşullarda daha geç" • Varsayımları yazılı belirtmek: kapsamın sabit olduğu, bağımlılıkların zamanında geleceği gibi • Tahmini yeni bilgi geldikçe güncellemek ve değişikliği nedenleriyle birlikte paylaşmak • Kapsam değişikliğinde tahminin değişeceğini baştan netleştirmek • Tahmini baskı aracı olarak kullanmamak; tahmini düşürmeye zorlamak yalnızca gizli risk yaratır
İyi iletişim, tahminin kesinliğini iddia etmek değil, belirsizliği yönetilebilir ve görünür kılmaktır. Bu şeffaflık güveni artırır.
Sık hatalar ve geliştirme yolu
Sık yapılan hatalar: • Test, entegrasyon ve dağıtım işlerini tahmine katmamak • Geliştiricinin kendi tahminini kesintisiz çalışma varsayımıyla vermesi; toplantı, destek ve bağlam geçişlerini hesaba katmamak • Tahmin ile hedefi karıştırmak; ulaşılmak istenen tarihi tahmin olarak sunmak • Geçmiş tahmin ile gerçekleşenleri kıyaslamamak, yani öğrenmemek • Belirsiz işi kesin bir sayıyla ifade etmek • Her şeyi aynı ayrıntı düzeyinde tahmin etmeye çalışmak; uzak işler kaba, yakın işler ayrıntılı tahmin edilir
Geliştirme yolu basittir: kırılım yapmayı öğrenin, birkaç teknik arasında çapraz kontrol yapın, tahmin ile gerçekleşeni her iterasyonda kaydedin ve farkın nedenlerini ekipçe konuşun. Zamanla ekip kendi sapma örüntüsünü görür ve tahminleri buna göre kalibre eder.
Mindset programlarında tahminleme
Mindset'in Yazılım Tahminleme ve Efor Kestirimi eğitimi şu modülleri içerir: görev kırılımı ve kapsam netliği, tahmin teknikleri, akış verisi, risk ve iletişim. Modül sırası, kırılımdan tekniğe, tekniğten veri ve iletişime uzanan akışı izler.
Son modül, tahminin akış verisiyle desteklenmesini, riskin hesaba katılmasını ve sonucun paydaşlara iletilmesini kapsar.
İlgili Mindset programı
Yazılım Tahminleme ve Efor Kestirimi
Sık sorulan sorular
Story point ile saat tahmini arasındaki fark nedir?
Saat tahmini mutlak bir süre verir ve kişiden kişiye değişir. Story point ise işlerin birbirine göre büyüklüğünü ifade eden göreli bir ölçüdür ve karmaşıklık ile belirsizliği de içerir. Puanı saate çevirmek, göreli tahminin sağladığı avantajı ortadan kaldırır.
Planning poker ne işe yarar?
Ekip üyeleri tahminlerini aynı anda açar, böylece birbirinin etkisinde kalmaz. En düşük ve en yüksek tahmini veren kişiler gerekçesini anlatır; bu tartışma gizli varsayımları ve unutulmuş işleri ortaya çıkarır. Amaç ortalama almak değil ortak anlayışa ulaşmaktır.
Tahminler neden hep gerçekleşenden kısa çıkar?
İyimserlik eğilimi, test ve entegrasyon gibi işlerin unutulması, kesintilerin hesaba katılmaması ve belirsizliğin kesin bir sayıyla ifade edilmesi başlıca nedenlerdir. Geçmiş verilerle kalibrasyon yapmak, risk payı eklemek ve aralık vermek bu sapmayı azaltır.
Çevik ekipler tahmin yapmaz mı?
Yapar, fakat yaklaşım farklıdır. Ayrıntılı uzun vadeli tahmin yerine yakın işler için göreli tahmin yapılır, uzak işler kaba bırakılır ve plan öğrenildikçe güncellenir. Ekip verisi, bitiş tarihi öngörüsünde temel dayanak olur.
Süre tahmini ile efor tahmini aynı şey midir?
Hayır. Efor, işin gerektirdiği çalışma miktarıdır; süre ise bunun takvimdeki karşılığıdır. Kesintiler, paralel işler, bekleme ve ekip büyüklüğü nedeniyle aynı efor farklı sürelerde tamamlanabilir. Planlamada ikisi ayrı ele alınmalı ve takvim hesabına kesinti payı eklenmelidir.
İlgili rehberler
Kategori: Proje Yönetimi ve Çeviklik, Yazılım Geliştirme