Cycle Time: Velocity Değil, Müşterinin Beklediği Süre

Sahadan: rekor sprint ve 47 gün

O review’dan bir gün önce ekip kanalına “Rekor sprint, tebrikler” yazmıştım. Velocity son altı sprintte 34, 38, 41, 44, 47 ve 52 olmuştu. Bu grafiği her review’da gösteriyordum ve her seferinde biraz daha gururlanıyordum.

Ece’nin sorusuna o an cevap veremedim. Review’dan sonra Ayşe ile oturduk. Ayşe o çeyrek ekibin süreç ölçümünü tutuyordu ve Jira’dan her işin durum geçmişini çekebiliyordu. Önce Ece’nin işine baktık. 47 gün şöyle geçmişti:

47 günün 4,5 günü iş yapılarak geçmişti. Kalan 42,5 gün, iş bir yerde birini bekliyordu. Hiçbir satır velocity grafiğinde görünmüyordu, çünkü velocity bir işin ne kadar beklediğini değil, sprint sonunda kaç puanın “Bitti” sütununa girdiğini sayar.

Sonra velocity’nin neden arttığına baktık. Cevap hoş değildi. Son altı sprintte bitirilen işlerin giderek daha büyük kısmı iç işlerdi: refactoring, küçük teknik işler, ekibin kendi önerdiği iyileştirmeler. Kısa, net ve puanlıydılar. Müşteri talepleri ise daha belirsizdi, operasyon kabulü gerektiriyordu, bu yüzden sprint’e daha az çekiliyordu. Puanların bir kısmı da şişmişti; bunun nasıl olduğunu story point yazısında anlattım, burada tekrar etmeyeceğim. Velocity’yi büyüten işler, müşterinin beklediği işler değildi.

Üç saat: nereden başlıyor, nerede bitiyor?

İlk toplantıda yarım saat tanım tartıştık, çünkü herkes “lead time” derken başka bir şeyi kastediyordu. Mühendislik metrikleri yazısında DORA’nın lead time’ını anlatmıştım: ilk commit’ten canlıya. O sayı bizde Kasım’dan beri üç günün altındaydı. Kodun canlıya giden yolu hızlıydı. Sorun o yoldan önce ve iki PR arasındaydı. Tanımları kâğıda yazdık:

Cycle time’ın bitiş noktası önemli. Bizde “Bitti”, Definition of Done’daki gibi canlıda ve operasyon tarafından kabul edilmiş demek. “Kod merge edildi” bitiş sayılırsa cycle time güzel görünür ama Ece için hiçbir şey değişmez. Başlangıç noktası da önemli: iş “Devam ediyor” sütununa çekildiği an saat başlar ve işi geri “Yapılacaklar”a atmak saati sıfırlamaz. Aksi hâlde bekleyen işi geri atmak sayıyı güzelleştirmenin en kolay yolu olur.

Bu yüzden WIP limiti yazısındaki 4,5 günü bu yazıdaki sayılarla yan yana koyma. O ölçüm Kasım’daydı ve “Bitti” o zaman test ortamında doğrulanmış demekti. Aralık’ta Definition of Done’a canlı katmanı girince aynı saat haftalık sürüm trenini, 24 saatlik izlemeyi ve operasyon kabulünü de saymaya başladı. İş yavaşlamadı; saatin bitiş çizgisi ileri taşındı.

Ortalama neden yalan söylüyor?

Ayşe ilk tabloyu ortalamayla getirdi: Ocak ve Şubat’ta biten 29 işin ortalama cycle time’ı 11,4 gün. Kimse bu sayıyla bir şey yapamadı. Sonra Mart’ta biten son 10 işe tek tek baktık:

2  3  3  4  5  6  8  9  14  41

ortalama  = 95 / 10          = 9,5 gun
medyan    = (5 + 6) / 2      = 5,5 gun   # p50: islerin yarisi bundan kisa
p85       = 10 isin 9.'su    = 14 gun    # islerin %85'i bu surede ya da once biter

# tek bir 41 gunluk is (operasyon kabulunde unutulmus)
# ortalamayi 9,5'e cekiyor. o is olmasa: 54 / 9 = 6 gun.

Cycle time dağılımı çarpıktır. İşlerin çoğu kısa sürer, birkaçı çok uzun sürer. Ortalama bu birkaç işi herkese dağıtır ve iki yanlış mesaj verir: tipik iş olduğundan uzun görünür, uzun iş ise görünmez olur. Oysa asıl konuşulması gereken şey o 41 günlük işti.

Bu yüzden iki sayı kullanıyoruz. p50 tipik işi anlatır. p85 ise müşteriye söylenebilen bir cümle üretir: “Başladığımız işlerin %85’i 14 gün içinde bitiyor.” Ece’ye “ortalama 9,5 gün” demek bir şey vaat etmez; “%85 ihtimalle 14 gün” demek eder.

Flow efficiency: iş ne kadar çalışılıyor, ne kadar bekliyor?

Ece’nin işi tek örnekti. Genel bir tablo için Şubat’ta biten 10 işi aynı şekilde aşamalarına ayırdık. Toplam cycle time 90 gündü; bunun 25 günü aktif çalışmaydı. Flow efficiency, yani aktif sürenin toplam süreye oranı, %28 çıktı.

Bu oranın kesin bir “doğru” değeri yok ve ölçmesi zahmetli: aktif süreyi insanlara sorarak ya da durum geçmişinden tahmin ederek buluyorsun. Biz bu yüzden sürekli değil, ayda bir 10 işlik örneklemle ölçüyoruz. Ama tek bir ölçüm bile yetti: işin dörtte üçü beklemede geçiyorsa, daha hızlı kod yazmak cycle time’ı neredeyse hiç değiştirmez. Kuyrukları kısaltmak değiştirir.

Ne değiştirdik?

16 Mart’tan itibaren beş değişiklik yaptık. Hiçbiri daha hızlı çalışmak değildi.

1. Bekleme sütunları. Tahtaya “Review bekliyor”, “Test bekliyor” ve “Kabul bekliyor” sütunları eklendi. Beklemek artık “Devam ediyor”un içinde saklanamıyordu.
2. Yaşlanan iş kuralı. Devam eden her işin yaşı tahtada görünüyor. Yaşı p85’i (o zaman 17 gün) geçen iş daily’de ilk konuşulan madde oluyor.
3. Kabul penceresi. Operasyon kabulü artık rastgele değil; Ece’nin ekibi Salı ve Perşembe öğleden sonra bir saat ayırıyor.
4. WIP limitini sıkılaştırdık. Nasıl ayarladığımızı WIP limiti yazısında anlattım. Burada tek fark, limiti bekleme sütunlarına da uyguladık.
5. Velocity review’dan çıktı. Planning’de kapasite konuşmak için duruyor. Review’da artık cycle time grafiği ve yaşlanan işler var.

Üç sprint sonra, 24 Nisan’da tablo şuydu:

Velocity düştü ve ilk hafta bu beni rahatsız etti. Sonra throughput satırına baktım: haftada biten iş sayısı düşmemiş, hafifçe artmıştı. Puan azalmıştı, çünkü müşteri talepleri daha belirsiz olduğu için tahminleri daha temkinliydi ve bekleyen iç işleri ikinci sıraya almıştık. Ekip daha az puan, daha çok değer teslim ediyordu.

Bir yan etkisi de oldu. Sprint’imiz on iş günü, yani iki takvim haftası. p85 17 gün iken sprint’e çekilen işlerin önemli bir kısmı daha baştan sprint’e sığmıyordu ve sonraki sprint’e taşınıyordu. Sprint hedefini kaçırmamızın bir kısmı buradan geliyordu ve biz bunu tahmin hatası sanıyorduk. p85 10 güne inince sprint’e çekilen iş büyük ihtimalle sprint içinde bitiyor. Cycle time, sprint’in kendisinden daha kısa olmalı.

Lead time p85 hâlâ 39 gün. Bunun büyük kısmı backlog’da, işe başlanmadan önce geçiyor. O kısım ekibin değil, önceliklendirmenin sorusu ve onu PO ile ayrıca konuşuyoruz. Cycle time ekibin kontrolündeki kısmı ölçer; lead time ise ekibin kontrolünde olmayan kısmı da gösterir. İkisine birden bakmazsan ya ekibi haksız yere suçlarsın ya da müşteriyi unutursun.

Bende işe yaramayanlar

Tablo güzel görünüyor ama oraya düz bir yoldan gelmedik. Üç şeyi denedim ve geri aldım.

1. Cycle time’ı hedef yapmak

İlk hafta ekibe “p85 10 güne insin” dedim. İkinci haftanın sonunda sayı gerçekten düşmeye başladı. Sonra Ayşe tahtada bir şey fark etti: “Yapılacaklar” sütununda duran üç iş aslında başlamıştı. Branch’leri açılmış, ilk PR’ları yazılmıştı. İnsanlar işi “Devam ediyor”a geç çekiyordu, çünkü saat o an başlıyordu. Kimse hile yapmıyordu; herkes ölçülen şeyi optimize ediyordu. Hedef sayıyı kaldırdık ve yerine tek bir soru koyduk: “İş nerede bekliyor?” Bunu DORA’da zaten öğrenmiştim. Yeni sayıda yeniden öğrendim.

2. Velocity’yi tamamen kaldırmak

İkinci tepkim velocity’yi tahtadan silmek oldu. Bir sprint sonra planning’de kapasite konuşacak hiçbir şeyimiz kalmadı. Ekip “bu sprint’e ne sığar?” sorusunu histen cevaplamaya başladı. Velocity’yi geri getirdik, ama yalnızca planning’e. Yanlış olan sayının kendisi değildi; onu müşteriye cevap gibi göstermemdi.

3. Flow efficiency’yi her işte ölçmek

Aktif süreyi doğru bulmak için herkesten her işe saat girmesini istedim. Üç gün dayandılar. Dördüncü gün kayıtların yarısı eksikti, beşinci gün kimse girmiyordu. Ölçüm maliyeti bilgi değerinden büyük olunca ölçüm ölür. Ayda bir, 10 işlik örneklem ve yarım saatlik bir konuşmaya geçtik. Daha az kesin ama her ay yapılıyor.

Nasıl bozuluyor?

En tehlikelisi üçüncü madde. Cycle time’ı kişiye bağlarsan insanlar zor işi çekmeyi bırakır ya da işi küçük parçalara böler. Bunun ne kadar hızlı olduğunu kişi başı PR panomuzda görmüştüm. Cycle time bir ekip sayısıdır; bir iş, birden çok kişinin elinden geçerek biter.

Ne izlemeli?

Kontrol listesi

Sonuç

13 Mart’ta ekrana açtığım 52 puan gerçekti. Ekip gerçekten çok çalışmıştı. Ama o grafik benim sorduğum soruya cevap veriyordu: “Ekip ne kadar üretiyor?” Ece’nin sorusu başkaydı: “Ben ne kadar bekliyorum?”

Artık review’da ilk açılan grafik cycle time. Velocity planning’de kaldı, kapasite konuşmak için. Ece son review’da bir şey sormadı. Sadece kabul penceresinin saatini değiştirmek istedi. Müşteri beklemediğinde rekor sormuyor.