“Ne Zaman Biter?”: Tek Tarih Değil, Olasılık Aralığı

Sahadan: 27 Mart nereden çıktı?

O sabah koridorda cevabı kafamda hesapladım. Hesap açma akışı 41 işe bölünmüştü, toplam 196 puan. Son sprint’in velocity’si 34’tü ama yükseliyordu; “40 tutar” dedim. 196 bölü 40, 4,9 sprint. Yukarı yuvarladım: beş sprint. 19 Ocak’ta başlarsak beşinci sprint 27 Mart Cuma biter. Pay koymadım, çünkü velocity artıyordu.

Bu hesapta söylemediğim üç varsayım vardı. Sonradan hepsini gerçekle yan yana koydum:

İlk satır en acısı. Velocity varsayımım tuttu ama işe yaramadı. Velocity ekibin bütün puanını sayıyordu; bu projenin puanını değil. Puanların nereden geldiğini cycle time yazısında anlattım: iç işler kısa ve netti, müşteri işleri beklerken onlar bitiyordu. Puanı tarihe çevirmenin neyi bozduğunu da story point yazısında anlatmıştım. Kasım’da o yazıyı ben yazmıştım ve aynı hatayı yine ben yaptım.

27 Mart’ta 47 işin 31’i bitmişti. Kalan 16 iş dört hafta daha sürdü; son iş 24 Nisan’da bitti, sürüm treni ve operasyon kabulüyle 5 Mayıs’ta canlıya çıktık. Riski ne zaman ve nasıl söylediğim ayrı bir konu. Bu yazı tarihin kendisiyle ilgili: o tarihi nasıl ürettiğimle.

Neden tek tarih çalışmıyor?

Bir yazılım işinin bitiş tarihi tek bir nokta değil, bir dağılım. Bazı haftalar 2 iş biter, bazı haftalar 6. Bazı işler bir günde kapanır, bazıları kabulde üç hafta bekler. Bu belirsizliği tek bir tarihe sıkıştırdığında iki şeyden birini yapıyorsun: ya çok iyimser bir nokta seçiyorsun ya da gizli bir pay ekliyorsun. İkisinde de karşındaki kişi ne kadar risk aldığını bilmiyor.

En yaygın hata ortalamayla hesaplamak. “Haftada ortalama 3,8 iş bitiriyoruz, 42 iş var, 11 hafta.” Bu hesap sana yaklaşık %50 ihtimalli bir tarih verir. Yani yazı tura. Aşağıda kendi verimizle bunu göstereceğim.

Bir not: sprint içinde bu sorun yok. Sprint planning’de iki haftalık bir taahhüt veriyorsun ve velocity o soruya yetiyor. Sorun, aynı aritmetiği on haftalık bir işe uzattığında başlıyor. İki haftada küçük görünen sapmalar on haftada birikir ve tek tarih bunların hiçbirini göstermez.

Puan değil, adet: throughput

Monte Carlo için gereken tek veri şu: son birkaç haftada, her hafta kaç iş bitti? Puan değil, adet. Bunun iki sebebi var. Birincisi, adet tahmin gerektirmiyor; Jira’da “Bitti”ye giren iş sayısı tartışmasız. İkincisi, işleri benzer büyüklükte kırıyorsan adetin varyansı küçülüyor. Bizim ekipte işlerin çoğu iki ile beş adam-gün arası. Bir işin 5 puan mı 8 puan mı olduğu, tahminin sonucunu neredeyse hiç değiştirmiyor.

Bir ayrım önemli. Tek bir işin ne zaman biteceğini soruyorsan cevap cycle time’ın p85’i: “Başladığımız işlerin %85’i 10 gün içinde bitiyor.” Birçok işin, yani bir projenin ne zaman biteceğini soruyorsan cycle time yetmez. İşler paralel ilerler, sırayla değil. Orada throughput ve simülasyon gerekiyor.

Monte Carlo: 20 satırlık hesap

Nisan başında sıradaki proje geldi: kart başvuru akışı, 36 iş. Bu sefer koridorda cevap vermedim. “Cuma’ya iki sayı getireceğim” dedim. Kapsam büyümesi için ilk projenin oranını kullandım: 36 × 1,15 = 41,4, yukarı yuvarladım, 42 iş. Sonra şu hesabı yaptım:

import random

gecmis = [3, 5, 2, 4, 6, 3, 4, 5, 2, 4]  # son 10 hafta: her hafta biten is sayisi
kalan  = 42                               # 36 is + %15 kapsam buyumesi payi
deneme = 10000

sonuclar = []
for _ in range(deneme):
    biten, hafta = 0, 0
    while biten < kalan:
        biten += random.choice(gecmis)    # gecmisten rastgele bir hafta cek
        hafta += 1
    sonuclar.append(hafta)               # bu denemede kac hafta surdu

sonuclar.sort()
for p in (50, 85, 95):
    print(p, sonuclar[int(p / 100 * deneme) - 1])

# cikti:
# 50 11
# 85 13
# 95 13

Mantık basit. Geleceğin her haftası, geçmiş haftalardan biri gibi olacak diye varsayıyoruz ama hangisi olacağını bilmiyoruz. O yüzden rastgele seçiyoruz ve iş bitene kadar sayıyoruz. Bunu on bin kez yapınca “kaç haftada biter” sorusunun bir cevabı değil, on bin cevabı oluyor. Sonra bu cevapları sıralayıp okuyoruz. Proje, hesap açma akışının son işleri bitince, 27 Nisan Pazartesi başlayacaktı. Haftaları tarihe çevirince tablo şu oldu:

Ortalamayla hesaplasaydım: 42 / 3,8 = 11,05, yani 11 hafta, 10 Temmuz. Tablodaki karşılığı %53. Ocak’taki hatamın aynısını daha düzgün bir aritmetikle tekrar edecektim.

Ekipten gelen üç itiraz

Hesabı ekibe ilk gösterdiğimde üç soru geldi. Üçü de haklı sorulardı ve cevapları modelin sınırlarını da gösteriyor.

“10 hafta az değil mi?”

Mehmet’in sorusuydu. Az, ama sandığın kadar değil. Geçmiş listede en kötü hafta 2, en iyi hafta 6. Gelecek hafta bu aralığın dışına çıkabilir, ama çıkma ihtimali düşük. Daha uzun geçmiş kullanırsan eski ekibi ve eski süreci de modele katmış olursun. Biz son 10 haftayı kullanıyoruz ve her hafta en eski haftayı atıp en yenisini ekliyoruz. Ekipte büyük bir değişiklik olduğunda, örneğin biri ayrıldığında, o haftadan önceki veriyi tamamen bırakıyoruz.

“Neden 10.000 deneme?”

Sayı sihirli değil. 1.000 denemede sonuçlar koşudan koşuya bir hafta oynayabiliyordu; 10.000 denemede oynamadı. Hesap bir saniyeden kısa sürüyor, o yüzden daha az denemeyle uğraşmadık. Önemli olan deneme sayısı değil, girdinin kalitesi: yanlış throughput verisiyle bir milyon deneme yapmak da yanlış bir aralık üretir, sadece daha kesin görünür.

“İşlerin büyüklüğü aynı değil ki?”

Ayşe’nin sorusuydu ve en önemlisiydi. Aynı değil, ama geçmiş haftalardaki işler de aynı değildi. Model “gelecekteki işler, geçmiş işlerle benzer bir karışımda” diye varsayıyor. Bu varsayım, işleri refinement’ta benzer şekilde kırdığın sürece tutuyor. Kart projesinin ilk listesinde iki iş bir haftadan uzun görünüyordu; onları başlamadan önce böldük. 36, bölündükten sonraki sayı. Bölmeseydik model o iki işin riskini hiç görmeyecekti.

Aralığı yönetime nasıl anlattım?

İlk denemem kötüydü. 10 Nisan Cuma, genel müdür yardımcısına yukarıdaki dört satırlık tabloyu ve bir histogram gösterdim. Beş dakika sonra şunu duydum: “Tamam, 3 Temmuz diyelim.” Tablonun ilk satırı, yani %18 ihtimalli tarih, onun gözünde söz olmuştu. Histogramdaki en uzun sütun ise 11. haftaydı; “en yüksek” sütunu “en olası tarih” diye okudu. İkisi de benim hatamdı: fazla sayı, açıklamasız grafik.

Bir hafta sonra aynı bilgiyi tek bir kartla götürdüm:

Soru değişti. “Hangi tarihi söyleyeyim?” diye sordu. “Dışarıya söz vereceksen %85’i. İçeride planı %50’ye göre yapalım, kayarsa arada iki hafta var” dedim. Dışarıya 24 Temmuz söylendi. İçeride hedef 10 Temmuz oldu.

Asıl kazanç “her Pazartesi” satırıydı. Tek tarih bir kere söylenir ve ondan sonra herkes o tarihi savunur. Aralık ise her hafta yeni veriyle yeniden hesaplanır. Kayma varsa son hafta değil, haftalar önce görünür ve karar vermek için hâlâ zaman olur.

Bugün: 31 Mayıs

Beş hafta geçti. 17 iş bitti, haftada 3,4. Modelin varsaydığı 3,8’in altında; iç işler beklediğimden fazla yer aldı. Kapsam 36’dan 38’e çıktı. Kalan 21 iş, üstüne %15 payla 24. Bu sabah hesabı yeniden koştum:

%50 bir hafta kaydı. İçerideki 10 Temmuz hedefinin ihtimali %41’e indi ve bunu yarın sabah genel müdür yardımcısına ben söyleyeceğim, sorulmasını beklemeden. Ama dışarıya söylenen 24 Temmuz hâlâ güvende; o tarihe kadar bitme ihtimali %98. Ocak’ta bu konuşmayı 27 Mart geçtikten sonra yapmıştım. Bu sefer hedef tarihten altı hafta önce yapıyorum.

Nasıl bozuluyor?

Kontrol listesi

Sonuç

12 Ocak’ta koridorda “27 Mart” dediğimde yanlış bir tarih söylemedim. Yanlış türde bir cevap verdim. Karşımdaki kişi bir olasılık sordu, ben ona bir söz verdim ve olasılığını saklamıştım, kendimden bile.

Şimdi aynı soruya cevabım iki tarih ve bir gün: “%50 ihtimalle şu, %85 ihtimalle şu, Pazartesi güncellerim.” Daha uzun bir cevap ama daha az toplantı üretiyor. Tek tarih güven verir. Aralık güven kazandırır.