Mobil projeler için tahmin — nedir, görev değerlendirme yöntemleri

Tahmin nedir?

Tahmin (İngilizce estimate — değerlendirme), bir görevi tamamlamak için gereken zaman veya iş gücü miktarının öngörüsüdür. Mobil geliştirmede tahminler saat, gün, story point veya parasal terimlerle ifade edilebilir. Bir tahminin amacı kesin bir tahmin değil, karar verme için belirsizliği azaltmaktır.

Tahmin taahhütten nasıl farklıdır

Tahmin, hata payı olan bir öngörüdür. Taahhüt, bir görevi belirli bir tarihe kadar tamamlama sözüdür. Fark kritiktir: tahmin “muhtemelen 5 gün” der, taahhüt “5 günde yaparız” der. Yöneticiler genellikle bu kavramları karıştırır ve tahmini hata payı olmayan bir son teslim tarihine dönüştürür.

Bir iletişim aracı olarak tahmin

Tahmin süreci, sonucu kadar önemlidir. Ekip bir görev tahminini tartıştığında, gizli gereksinimler, bağımlılıklar ve riskler ortaya çıkar. Nihai sayı hatalı olsa bile, tartışma tüm katılımcılara görev hakkında bir anlayış kazandırır. Bu nedenle kolektif tahmin yöntemleri (Planning Poker) bireysel olanlardan daha etkilidir.

Geliştirmede tahmin yöntemleri

Projenin farklı aşamaları ve detay seviyeleri için uygun birkaç tahmin yöntemi vardır. Yöntem seçimi, mevcut verilere ve gereken doğruluğa bağlıdır.

Planning Poker

Planning Poker, Agile'da en popüler tahmin yöntemidir. Her geliştirici Fibonacci sayıları (1, 2, 3, 5, 8, 13, 21) içeren bir kart destesi alır. Görevi tartıştıktan sonra, herkes aynı anda kartını gösterir. Tahminler farklıysa, en düşük ve en yüksek tahmine sahip geliştiriciler mantıklarını açıklar, ardından yeniden oylama yapılır. Bu yöntem otorite yanlılığını ortadan kaldırır ve daha doğru bir tahmin sağlar.

T-Shirt sizing

T-Shirt sizing, tişört boyutuna (XS, S, M, L, XL, XXL) göre kabaca bir tahmindir. Bu yöntem, ayrıntıların bilinmediği erken aşamalarda büyük görevlerin (epik) hızlı tahmini için kullanılır. Daha sonra, bu tür görevlerin her biri ayrıştırılır ve Planning Poker'de tahmin edilir. T-Shirt sizing, görev başına 5-10 dakika sürer ancak yalnızca bir büyüklük sırası sağlar.

Üç nokta tahmini (PERT)

PERT üç tahmin kullanır: iyimser (O), kötümser (P) ve en olası (M). Nihai tahmin şu formülle hesaplanır: (O + 4M + P) / 6. Bu yöntem belirsizliği hesaba katar ve tek bir tahminden daha gerçekçi bir sonuç verir. PERT özellikle yüksek riskli veya yeni teknolojili görevler için kullanışlıdır.

Tahmin doğruluğu: beklentiler vs gerçeklik

Tahmin doğruluğu, projenin aşamasına ve bilinen bilgi miktarına bağlıdır. Tahmin ne kadar erken yapılırsa, hata payı o kadar büyük olur — bu normaldir ve planlamada dikkate alınmalıdır.

Belirsizlik konisi

Belirsizlik konisi (Cone of Uncertainty), proje ilerledikçe tahmin hatasının nasıl azaldığını açıklayan bir modeldir. Kavram aşamasında hata payı %400'tür (bir görev 1 ila 4 ay sürebilir). Sprint aşamasında bu oran %20'dir (1-1,2 ay). Bu modeli anlamak, erken aşamalarda kesin tahminler talep etmemeye yardımcı olur.

Doğruluğu etkileyen faktörler

• Görev karmaşıklığı — yeni bir teknoloji mi yoksa bilinen mi? Bilinmeyen, hata payını 2-3 kat artırır.
• Görev boyutu — küçük görevler (2 güne kadar) büyük olanlardan daha doğru tahmin edilir. Ayrıştırma doğruluğu artırır.
• Ekip deneyimi — 6+ aydır birlikte çalışan bir ekip, yeni bir ekipten %30-50 daha doğru tahmin yapar.
• Geçmiş veriler — velocity metrikleri ve döngü metriği verileri, tahmin doğruluğunu artırır.

Göreceli vs mutlak tahmin

Göreceli tahmin (story point cinsinden), mutlak tahminden (saat cinsinden) daha doğrudur çünkü insanlar zamanı tahmin etmektense görevleri karşılaştırmada daha iyidir. “Bu görev, diğerinin iki katı karmaşık”, “bu görev 8 saat sürecek” ifadesinden daha güvenilir bir yargıdır. Göreceli tahminler belirli bir geliştiriciye bağlı değildir ve sorumlu kişi değiştiğinde doğruluğu korur.

Tahmin doğruluğu nasıl artırılır: en iyi uygulamalar

Tahmin doğruluğu, sistematik bir yaklaşım, kolektif tartışma ve geçmiş hataların analizi yoluyla artırılabilir. Kanıtlanmış birkaç uygulama vardır.

1-2 güne ayrıştırma

2 günden fazla tahmin edilen herhangi bir görev, alt görevlere ayrıştırılmalıdır. İlke: bir görev %50'den fazla doğrulukla tahmin edilemiyorsa, çok büyüktür. Her biri anlaşılabilir ve tahmin edilebilir adımlara bölün. Ayrıştırmadan sonra, toplam tahmin genellikle ilk tahminden 1,5-2 kat daha büyük olur.

Geçmiş veriler ve metrikler

Bir tahmin geçmişi tutun ve gerçek iş gücüyle karşılaştırın. Örneğin: “3 story point olarak tahmin edilen görevler ortalama 4 gün sürer, 2 gün değil”. Tahmin için ekip velocity'sini kullanın: ekip sprint başına 20 story point tamamlıyorsa, 30 planlamayın. Geçmiş tahmin doğruluğunu analiz etmek, tahmin becerisi için en iyi eğitimdir.

Çıpalama ve kalibrasyon

Çıpalama, ilk söylenen tahminin tüm katılımcıları etkilediği psikolojik bir etkidir. Planning Poker'de çıpalamayı önlemek için herkes sırayla değil, aynı anda kartlarını gösterir. Kalibrasyon, tahminlerin gerçek sonuçlarla düzenli olarak karşılaştırılmasıdır: 10-20 sprintten sonra ekip, geri bildirim yoluyla daha doğru tahmin yapmayı öğrenir.

Risk ayarlı tahmin

Her görev gizli riskler içerir: geliştirici hastalığı, API sorunları, gereksinim değişiklikleri. Tahmininize risk ayarlı bir faktör ekleyin: yüksek riskli görevler için 1,5-2 çarpanı; düşük riskli için 1,1-1,2. Hangi risklerin hesaba katıldığını ve bunların zaman çizelgelerini nasıl etkilediğini müşteriye şeffaf bir şekilde gösterin.

Tahminde yaygın hatalar

Tahmin hataları, olgunluklarına bakılmaksızın çoğu ekipte tekrarlanır. Bu hataları bilmek, düzeltmenin ilk adımıdır.

İyimserlik yanlılığı

En yaygın hata, en iyi senaryoya göre tahmin yapmaktır: “her şey mükemmel giderse, 3 günde yaparız”. Gerçekte hiçbir şey mükemmel gitmez: hatalar, gereksinimlerle ilgili sorular, bağımlı görevler. Çözüm: iyimser değil, en olası senaryoya göre tahmin yapın. Değişkenliği hesaba katmak için PERT kullanın.

Baskı altında tahmin

Bir yönetici “Cuma gününe kadar lazım” dediğinde, geliştirici bilinçaltında tahmini bu son teslim tarihine göre ayarlar. Baskı altında tahmin her zaman düşük olur ve teslim tarihlerinin kaçırılmasına yol açar. Çözüm: tahmin, son teslim tarihinden önce gelmelidir, tersi değil. Önce ekip tahmin yapar, sonra taraflar zaman çizelgeleri üzerinde anlaşır.

Karmaşıklık ve zamanı karıştırmak

Görev karmaşıklığı (ne kadar düşünmek) ve zaman (ne kadar yapmak) farklı metriklerdir. Bir görev basit ama zaman alıcı olabilir (10 ekran oluşturmak) veya karmaşık ama hızlı olabilir (eski kodda hata bulmak). Story point'ler genellikle karmaşıklığı tahmin ederken, zaman ekip velocity'sinden türetilir.

Bağlam değiştirmeyi görmezden gelmek

Bir geliştirici tek bir görev üzerinde 8 saat boyunca kesintisiz çalışmaz: toplantılar, kod incelemeleri, meslektaşlara yardım ve idari işler, çalışma süresinin %30-50'sini tüketir. Bağlam değiştirme tahminde dikkate alınmalıdır: gerçekte, bir geliştirici günde 3-4 saat kod yazar.