Tahminler Neden Başarısız Olur (ve Neden Hâlâ Gereklidir)

• Yazılım geliştirmede iş tahmini karmaşık sistemler (Complex) alanına girer; ekip ne kadar deneyimli olursa olsun özünde tam isabetli tahmin yapmak mümkün değildir
• #NoEstimates hareketi, tahminlerin performans hedefi olarak kötüye kullanılması gerçeğine karşı haklı bir tepkiydi; ancak tahminin kendisini reddetmek, organizasyonun koordinasyon yeteneğini ortadan kaldırır
• Tahminin temel değeri geleceği öngörmek değil, belirsizlik altında iletişim ve koordinasyon sağlamaktır; dış sözleşmeler, takımlar arası bağımlılıklar ve ROI değerlendirmeleri için vazgeçilmezdir
• Steve McConnell’ın Belirsizlik Konisi (Cone of Uncertainty) kavramına göre projenin başında tahmin hatası 4 kata kadar çıkabilir ve aralık ancak öğrenmeyle daralır
• Tahmini taahhüde dönüştüren örgütsel alışkanlıkları değiştirmek ve kapsam temelli, varsayımları açık, kademeli düzeltmeye dayalı bir tahmin yaklaşımı benimsemek gerekir

---

#NoEstimates hareketinin gerçekten çözdüğü sorun

• Ekiplerden, problem hakkında neredeyse hiçbir şey bilinmezken tahmin istenir; sonra bu sayı roadmap’e girer ve müşteriye söz olarak verilir; bu döngü sürekli tekrar eder
• Gerçeklik tahminden sapınca ekip, "deadline’ı kaçırdı" diye suçlanır; oysa o tarih baştan ekip tarafından onaylanmış bir tarih değildir
• Asıl patoloji, tahminin bir öngörü olmaktan çıkıp taahhüde (commitment) dönüşmesidir
• "Tahmin yapmayalım" çözümü, bozuk bir termometreye tepki olarak sıcaklık kavramının kendisini reddetmeye benzer
• Maarten Dalmijn’in ifadesiyle tahmin, gerçek iş miktarını değiştirmez; bir özelliğin geliştirilmesi ne kadar sürüyorsa o kadar sürer
  • Tahminin etkilediği şey işin kendisi değil, onun etrafındaki beklentilerdir (expectations)
  • Beklentileri dürüst ve net biçimde yönetmek, kesinlikle değerli bir iştir

Organizasyonların neden gerçekten tahmine ihtiyaç duyduğu

• #NoEstimates tartışmalarında çoğu zaman gözden kaçan nokta şu: tahminler işi yapan ekip için değil, o ekibin etrafındaki organizasyon için gereklidir

• Tahminin kaçınılmaz olduğu üç durum vardır

• Dış taahhütler (External commitments): müşteri sözleşmeleri, pazarlama kampanyalarıyla bağlantılı lansmanlar, regülasyon son tarihleri gibi durumlarda yapılabilirliği değerlendirmek için iş süresine dair bir model gerekir

  • "Biz tahmin yapmıyoruz" müşteriye verilebilecek bir yanıt değildir; sözleşmenin kaybedilmesine yol açabilir

• Takımlar arası bağımlılıklar (Inter-team dependencies): Takım B, Takım A’nın bitirmesini bekliyorsa ve Takım A hiçbir öngörü vermiyorsa, Takım B plan yapamaz

  • Kabaca bir sinyalin ("muhtemelen 6 hafta, en fazla 8 hafta") sessizlikten sonsuz derecede daha faydalı olması, kontrol değil aşağı akıştaki ekip üyelerine duyulan saygıdır

• ROI hesabı: Özellik X ile Özellik Y arasında seçim yapabilmek için göreli bir maliyet modeline ihtiyaç vardır

  • Her şey bilinemez denirse rasyonel trade-off yapmak imkânsızlaşır; madem tahmin edilecek, o halde varsayımları açıkça belirtilmiş yapılandırılmış bir tahmin daha iyidir

Joseph Pelrine’in gösterdiği tahminin özsel zorluğu

• Joseph Pelrine, Avrupa’nın ilk Certified Scrum Trainer unvanına sahip kişilerden biridir ve yazılım çevikliğini sosyal karmaşıklık bilimi merceğinden inceler
• Çevik yazılım geliştirmede çalışan 300’den fazla kişiyle, günlük iş aktivitelerini Cynefin framework’ünün (Dave Snowden’ın sensemaking modeli) alanlarına yerleştiren bir deney yürüttü
  • Cynefin, problemleri Clear, Complicated, Complex ve Chaotic olmak üzere dört alana ayırır
• İş tahmini, tutarlı ve tekrar tekrar Complex alanına yerleştirildi
• Buradaki kilit fark, Complicated ile Complex arasındaki ayrımdır:
  • Complicated alanda neden-sonuç ilişkileri anlaşılabilir durumdadır, uzmanlar bunları izleyebilir ve uzmanlık güvenilir tahminler üretebilir
  • Complex alanda ise neden-sonuç ilişkileri yalnızca sonradan anlaşılabilir; sistem fazla iç içe geçmiş, bağlama bağımlı ve küçük değişimlere hassastır
• Yazılım geliştirmenin üretimden farklı olmasının nedeni budur: çoğu zaman daha önce hiç var olmamış bir şey, kendine özgü bir codebase üzerinde ve kendine özgü ekip dinamikleriyle inşa edilir
  • Marangoz benzetmesinin işe yaramamasının nedeni de budur: dolaplar kabaca birbirine benzer ama özellikler başka özelliklere kabaca benzemez
• Çok iyi ekipler bile ancak ortalama düzeyde tahmin yapabilir; bu bir beceri eksikliği değil, Complex alandaki doğruluğun özsel sınırıdır
• Amaç tahmini tutturmak değil, özündeki isabetsizliğe rağmen faydalı kararlar alabilmektir

Belirsizlik Konisi’nin anlattığı şey

• Steve McConnell’ın Belirsizlik Konisi kavramına göre projenin erken safhasında tahmin hatası her iki yönde 4 kata kadar çıkabilir; yani toplam aralık 16 kata ulaşabilir
• Proje ilerledikçe bilinmeyenler çözülürse (gereksinimlerin netleşmesi, mimarinin belirlenmesi, zor problemlerin keşfedilip çözülmesi) koni daralır
• İroni şu: tahminin en doğru olduğu an, tamamlanmaya en yakın andır; ama o an tahmine en az ihtiyaç duyulan andır
  • En faydalı olduğu başlangıçta (henüz yön değiştirme veya projeyi durdurma şansı varken) en az şey bilinir
  • Çoğu organizasyon ise tam da bu erken aşamada en güçlü taahhütleri verir
• Bundan çıkan iki ek sonuç daha vardır:
  • Koni, iyi tahmin yapan ekipler için en iyi senaryoyu temsil eder; çoğu ekip bunun da altında kalır
  • Fikir aşamasında tarih kesinleştirmek plan yapmak değil, dilek tutup takvimi ona göre ayarlamaktır
  • Koni, zaman geçtikçe değil, belirsizliği ortadan kaldıran kararlarla daralır
  • Kapsamın netleşmesi, mimarideki bilinmezlerin çözülmesi, gerçek kod yazılması ve darboğazların keşfedilmesi koniyi daraltır; 3 hafta toplantı yapmak daraltmaz
• Paydaşlara açıkça şu söylenmelidir: "Tahminin kalitesi, koninin neresinde olduğumuza bağlıdır"
  • İlk haftada 2 haftalık kesin bir sayı verilemez; ama bir aralık verilip bunu daraltmak için hangi bilgilerin doğrulanması gerektiği anlatılabilir
  • Çoğu paydaş, koni açıklandığında bunu kabul eder; mesele, onlara aralık istemenin mümkün olduğunun hiç söylenmemiş olmasıdır

Neden Fibonacci ölçeği kullanılır

• Fibonacci ölçeğinin (1, 2, 3, 5, 8, 13, 21) doğrusal olmayan yapısı, epistemik bir işlev görür
• 2 ile 3 arasındaki fark "kabaca fark sezme" düzeyindeyken, 8’den 13’e sıçrama belirsizlik bandının tahminin kendisinden daha geniş olduğunu kodlar
  • 13 puanlık bir story, "tam olarak 13" değil, "8’den belirgin biçimde daha belirsiz ama 21 kadar da değil" kategorisi anlamına gelir
• Fibonacci sayıları arasındaki aralık, karmaşıklığın gerçekte büyüme biçimini yansıtır
  • Küçük işler aşağı yukarı tahmin edilebilir; büyük işlerde ise bilinmeyenler, entegrasyon noktaları ve beklenmedik durumlar arttıkça öngörü geometrik olarak zorlaşır
  • 21 (veya 13) ve üzeri story’ler genelde "bu işi henüz yeterince anlamıyoruz, parçalara ayırmalıyız" demektir
• Fibonacci ile tahminin bir başka küçümsenen işlevi de tahmin konuşması sırasında olan bitendir
  • Biri 3, diğeri 13 diyorsa sayıların kendisi neredeyse önemsizdir; asıl önemli olan, aynı ekibin aynı story’yi neden bu kadar farklı gördüğüdür
  • Taraflardan biri bir bağımlılığı fark etmiş ya da ticket’ta yazmayan teknik bir kısıtı biliyor olabilir
• Tahminin en büyük değeri, sayı değil ortak anlayışın oluşup oluşmadığını test etmesidir
  • Bu zorlayıcı mekanizma kaldırılırsa, ortak anlayış çoğu zaman biri işin 3. gününde gizli karmaşıklıkla karşılaşana kadar oluşmaz
• "Tahmin toplantıları israftır" diyen #NoEstimates görüşüne bu yüzden katılmak zordur: iyi yönetilirse o konuşmada hizalanma (alignment) sağlanır
  • Kötü yönetilen toplantıların cevabı, toplantıları tamamen iptal etmek değildir

Taahhüt tuzağı (Commitment Trap) ve bundan kaçınma yolları

• #NoEstimates hareketinin tepki verdiği en derin işlev bozukluğu şu: tahminin mantıkla değil, sosyal baskıyla taahhüde dönüştürülmesi
• İlgili bir başarısızlık modu da şudur: işi yapmayan kişiler timeline üretip bunu ekibe attığında, isabetsiz tahmin + sayıya sahip çıkmayan ekip gibi en kötü kombinasyon ortaya çıkar
  • Gerçeklik bundan sapınca sorumlunun kim olduğu belirsizleşir ve herkes birbirini suçlar
  • İşi yapanlar tahmine her zaman sahip çıkmalıdır; başkalarının ekibe tahmin dayatması iyimserlik değil, suçlama oyununun habercisidir
• Deadline takıntısı yerleştiğinde her konuşma "bu deadline’ı nasıl tuttururuz?" sorusuna sıkışır ve doğru şeyi yapıp yapmadığımız sorusu görünmez olur
• Çoğu organizasyonun birbirine karıştırdığı üç şeyi ayırmak gerekir:
  1. Tahmin (Estimate): mevcut belirsizlik düzeyinde olasılıksal bir öngörü; yanında aralık ve varsayımların açık ifadesi olmalıdır
     • Örnek: "Gereksinimler değişmez ve API sorularının yanıtını gelecek cuma alırsak bunun 4 ila 6 hafta süreceğini düşünüyoruz"
  2. Plan (Plan): sonuca değil, sürece verilen taahhüttür
     • Örnek: "2 hafta çalıştıktan sonra ilerlemeyi gözden geçirip güncellenmiş bir tahmin vereceğiz"
  3. Taahhüt (Commitment): sonucu da içeren söz; nadiren ve yalnızca koni yeterince daraldığında verilmelidir
     • Fikir aşamasında taahhüt vermek cesaret değil, pervasızlıktır
     • Taahhüt vermeye zorlanıldığında zaman çizelgesine değil önceliklere dair taahhüt vermeyi deneyin; bu da olmazsa güven düzeyini taahhüdün parçası haline getirin
• Tahmin söylendiği anda onu taahhüt gibi ele alan organizasyonel alışkanlık, işlev bozukluğunun asıl kaynağıdır
  • #NoEstimates’in siyasi çözümünü, yani sayıları hiç telaffuz etmemeyi anlamak mümkün; ama bunun bedeli, organizasyonun kaynak dağıtma, bağımlılıkları sıralama ve dış paydaşlarla dürüst konuşma yeteneğini kaybetmesidir
• Daha iyi çözüm, Belirsizlik Konisi’ni öğretmek, paydaşları eğitmek ve her sayı verildiğinde tahmin ile taahhüt arasındaki farkı açıkça belirtmektir
  • Bu, tahmini tamamen reddetmekten daha zor ve zaman alıcıdır; ama güvenin kırılabileceği durumları kaçınmak yerine güven inşa eder

İyi tahmin için uygulanabilir pratikler

• Geç tahmin edin: Koni ancak öğrenmeyle daralır; bu yüzden önce spike yapın, keşif amaçlı kod yazın, entegrasyon yapılacak ekiplerle konuşun
  • Anlamlı sayılar üretmeyi sağlayacak öğrenme gerçekleşmeden sayı verme baskısına direnmek gerekir
• Başlamadan önce aşırı parçalamayın: Belirsizlikle karşılaşınca işi daha küçük parçalara bölme isteği doğar; ama yeterince parçalamak tek başına güvenilir tahmin üretmez
  • Aşırı ayrıntılı ön planlama katılaşır ve gerçekliği yansıtmayı bıraktığı noktadan sonra bile ekibin ona tutunmasına neden olur; bu da sonunda sapmayı daha kafa karıştırıcı hale getirir
  • Ayarlaması kolay, basit bir planla başlamak gerekir
• Nokta tahmini değil aralık verin: "3–5 hafta", "4 hafta" demekten daha dürüsttür ve pratikte neredeyse aynı derecede uygulanabilir
  • Tek sayı vermek şart koşuluyorsa aralığın orta değerini verin, ama bunun orta değer olduğunu mutlaka belirtin
  • Paydaşlarla Belirsizlik Konisi’nin kullanılacağı konusunda anlaşın ve her tahminde buna referans verin
• Varsayımları görünür kılın: Tahmin, ancak dayandığı varsayımlar kadar iyidir; bu yüzden kapsam değişmeyecek varsayımı, belirli teknik yaklaşım varsayımı, başka bir ekibin belli tarihte teslim edeceği varsayımı gibi noktaları açık yazın
  • Zihinde kalan varsayımlar, en kötü anda ortaya çıkan yanlış anlamalara dönüşür
• Doğruluğu takip edin ama cezalandırmayın: amaç suçlamak değil, kalibrasyon yapmaktır
  • 6 ay birlikte tahmin yapıp isabet düzeyini gözden geçiren ekipler, hangi durumlarda sistematik olarak fazla ya da düşük tahmin yaptıklarına dair ortak bir sezgi geliştirir
  • İsabetsiz tahmini cezalandırmak, ekiplerin savunmacı biçimde tahminleri şişirmesine yol açar; şişirilmiş tahminler, dürüst ama belirsiz tahminlerden daha az kullanışlıdır
  • Complex alandaki yanlış tahmin, karakter kusuru değil alanın bir özelliğidir
• 8’in üzerini bölün: Fibonacci’de 13 ya da 21 puanlık story’ler neredeyse her zaman henüz görünmemiş gizli karmaşıklıklar barındırır
  • Bölme eylemi, gerçekte neyi bildiğinizi açıkça ifade etmeye zorlar
  • Çoğu zaman 3 alt story’den 2’sinin küçük olduğu, tüm belirsizliğin ise tek bir parçaya yığıldığı görülür

Her iki taraf için de rahatsız edici gerçek

• Tahmin, hesaplama değil bir iletişim biçimidir; amacı geleceği tutturmak değil, belirsizlik altında koordinasyonu ve karar almayı desteklemektir
• Tahminin başarısızlık biçimleri rastgele değil, sistematiktir: çok erken tahmin yapmak, aralığı tek nokta gibi ele almak, tahmini taahhüt gibi görmek, Belirsizlik Konisi’nin epistemik konumunu göz ardı etmek ve tahmini işi yapana dayatmak
• Dalmijn’in sözünü ettiği Karmaşık İş Tahmini Safsatası (Complex Work Estimation Fallacy) şudur: daha sık tahmin ederek, süreci iyileştirerek ve daha uzun süre birlikte çalışarak sonunda kesin tahminlere ulaşılacağına inanmak
  • Complex alandaki tahmin doğruluğunun sınırı, ekip olgunluğunun değil alanın kendisinin bir fonksiyonudur
  • Daha iyi olunabilir ama tam doğru olunamaz; bu ikisini karıştırmak, organizasyonların ekipleri aslında kontrolleri dışında olan şeyler için cezalandırmasına yol açar
• Tahmini reddetmek, aslında koordinasyon oyunundan çekilmektir
  • Tam bağımsız çalışan, sürekli dağıtım yapan ve dış taahhütleri olmayan ekiplerde bu mümkün olabilir; ama kariyerlerin çoğu böyle bağlamlarda geçmez
• Seçenek "kötü tahmin" ile "hiç tahmin yok" arasında değildir; seçenek, siz olsanız da olmasanız da organizasyonun üreteceği örtük ve düşük kaliteli tahminler ile açık, alçakgönüllü, aralık temelli ve varsayımları görünür tahminler arasındadır
• İş tahmini Complex alanda yer aldığı için buna karmaşıklık zihniyetiyle yaklaşmak gerekir: keşfet, gözlemle, yanıt ver, tahmin et, takip et, düzelt; sonra tekrar et
• Koni bekleyerek değil, öğrenerek daralır