Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Yazılımda Tahmin Neden Yanılır? Estimate, Target ve Commitment Farkı, Cone of Uncertainty ve Planning Fallacy
Tahmin yanılır çünkü çoğu zaman tek sayı olarak, işin en belirsiz anında ve iyimser bir senaryodan verilir; dürüst cevap bir aralık, bir güven seviyesi ve varsayımlardır. Estimate, target ve commitment farkını, cone of uncertainty'yi ve planning fallacy'yi Bookstore ekibinin 12 feature'lık gerçek tahmin geçmişini işleyen C# koduyla görüyoruz.
Story Point ve Relative Estimation: Planning Poker, T-shirt Sizing ve Story Point'in Tartışmalı Mirası
Story point işe yarar çünkü işleri birbiriyle karşılaştırmak süre tahmin etmekten kolaydır; zarar verdiği yer, point'in saate çevrildiği, ekipler arasında karşılaştırıldığı ya da performans hedefi yapıldığı yerdir. Planning poker, t-shirt sizing ve #NoEstimates'i Bookstore ekibinin 10 sprint'lik verisiyle görüyoruz: point ile story sayısı 0,81 korelasyonlu, ama yeni epic'in story'leri büyük olduğu için sayma yöntemi iyimser kalıyor.
Point Dışında Tahmin Yöntemleri: Three-point/PERT, Wideband Delphi, Work Breakdown ve Reference Class Forecasting
Belirsiz bir işi tahmin etmek için işi parçalara böl, her parçaya üç nokta ver, toplamı tek tek toplamak yerine simüle et ve sonucu benzer geçmiş işlerin sapmasıyla dışarıdan kontrol et. Bookstore'un toplu sipariş dilimi için C# simülasyonu, en olası sürelerin toplamının (21 gün) yalnızca %3,1 ihtimalle tuttuğunu, %85 değerin 28 gün, geçmiş epic'lere göre düzeltilmiş değerin 34 gün olduğunu gösteriyor.
Release Planning: Aralıklı Velocity, Burn-up, Sabit Tarih mi Sabit Kapsam mı?
Release tarihi tek bir velocity ortalamasından değil, geçmiş sprint'lerden çıkan bir aralıktan verilir; tarih sabitse kapsam MoSCoW katmanlarıyla esnetilir. Bookstore'un 130 point'lik Kurumsal Sipariş planı 12 Şubat ile 12 Mart arasına düşüyor; 1 Mart'ta Must kapsamı kötü senaryoda bile sığıyor. Aynı soruyu Monte Carlo ile de cevaplayıp iki yöntemin neden farklı sonuç verdiğini görüyoruz.
Yazılım Projesinde Risk Yönetimi: Pre-mortem, Risk Register, Olasılık × Etki ve Riski Erken Azaltmak
Riski yönetmek, onu pre-mortem ile erken görünür kılmak, olasılık × etki ile buffer'la karşılaştırmak ve en riskli işi planın başına almaktır. Bookstore'un Kurumsal Sipariş register'ında toplam exposure 21,6 gün çıkıyor ve kapsam buffer'ını aşıyor; ERP spike'ı ve eşli çalışma ile üç sprint'te 4,9 güne iniyor. ROAM, risk burndown ve risk ile issue farkını C# koduyla görüyoruz.
Tahmini İletmek ve Plan Kaydığında: Güncelleme, Kötü Haberi Erken Vermek ve Yeniden Planlamak
Plan kaydığında yapılacak ilk şey, kötü haberi seçenekleriyle birlikte hemen vermek; karar kapsam, tarih ya da kişi ekleme arasında iş tarafınındır ve geç kalmış projeye kişi eklemek çoğu zaman tarihi kurtarmaz. Bookstore'un üç sprint sonraki güncellemesi, kapsamın 142 point'e büyüdüğünü ve tam kapsamın 26 Mart'a kaydığını gösteriyor; C# koduyla seçenekleri hesaplayıp tek sayfalık tahmin notunu yazıyoruz.