Hayır, bundan daha da az çaba gerektiriyor
(smartguess.is)- Geliştirme ekibi dışından, yeni bir olgu olmadan tahmini düşürme baskısı gelirse, tahmin müzakere konusu gibi görülmeye başlar; bunun sonucu olarak hem güven hem de çevik planlamanın kalitesi birlikte bozulur
- Gerçek iş yükü çoğunlukla geliştirme ekibinin keyfine göre azaltabileceği bir şey değildir; ekip, ekip hızı, tamamlanmış story verileri ve mevcut throughput’a dayanarak beklenen çabayı hesaplar
- Daha düşük tahmine uymak için süreçleri atlamak veya kaliteyi düşürmek, kısa vadede takvimi kısalmış gibi gösterebilir; ancak bunun daha sonra daha büyük bir maliyetle geri dönme olasılığı yüksektir
- Daha üretken konuşma “daha düşük tahmin verin” değil; bütçe, çok zaman alan kısımlar, büyük bilinmezler, alternatifler, story bölme ve erken doğrulamayı birlikte ele almaktır
- Sabit bir özellik kapsamı içinde sadece sayıları düşürmek, müşteride teslim zamanı konusunda yanlış beklentiler yaratır; yüksek çaba gerektiren ve düşük değer üreten özellikleri çıkarma tartışması gerekir
Yeni olgular olmadan tahmine baskı yapılmasının yarattığı çarpıklık
- Geliştirme ekibi dışındaki paydaşların, teknik bilgi veya kod tabanı anlayışı sınırlıyken “Hayır, bundan daha da az çaba gerektiriyor” diyerek tahmini düşürmeye çalıştığı durumlar sık görülür
- Görünüşte “daha iyi bir tahmin” istenir, ama gerçekte çoğu zaman istenen şey daha düşük bir tahmindir
- Tahminleri pazarlık edilebilir rakamlar gibi ele almak, hem paydaşların hem de geliştirme ekibinin memnun olmadığı uzlaşmalara yol açar ve iş tarafı, müşteriye yazılımın ne zaman teslim edilebileceği konusunda kötü beklentiler oluşturur
- İlgili alıntı kaynağı olarak Is tasking developers with creating detailed estimates a waste of money? bağlantısı veriliyor
Tahmin, kontrolden çok öngörüye yakındır
- Tahmine itiraz edilebilecek durumlar vardır
- Geliştirme ekibi kendi içinde story’yi tartışırken
- Gerçek iş yükünü etkileyen yeni olgular olduğunda
- Uygulama ayrıntılarını anlamayan veya yeni bilgi sunmayan dış paydaşların daha düşük tahmin istemesi, meteoroloğa “yarınki tahminin yanlış, hava daha iyi olacak” demeye benzer
- Meteorolog havayı kontrol etmez; bilgi ve gözlem verilerine dayanarak tahminde bulunur
- Geliştirme ekibi de gerçek iş yükünü neredeyse hiç kontrol edemez; bilgi ve verilere dayanarak beklenen çabayı hesaplar
Geliştirme ekibinin kontrol edebildikleri ve edemedikleri
- Geliştirme ekibi tahmin yaparken yerleşik ekip hızını, tamamlanan story’lerin gözden geçirilmiş verilerini ve her sprint’te iyileşen süreçleri kullanır
- İş yükünü azaltmak için bazı süreçleri atlayıp düşük kaliteli yazılım teslim etmek mümkündür
- Bu önerilen bir yaklaşım değildir
- Çoğu zaman daha sonra daha büyük bir bedel ödenir
- Ekibin hızını artırma alanı olabilir, ancak tahmin anında ölçüt, beklenen gelecekteki throughput değil mevcut throughput olmalıdır
- Şirkette “daha uzun çalışırız olur biter” türü konuşmalar geçiyorsa, bu tür bir ortam neredeyse felaket reçetesidir
- İlgili deneyim örnekleri olarak 3 Reddit yorumu bağlanıyor:
Sayıları kırpmak yerine yapılması gereken konuşmalar
- Yazılım geliştirme karmaşıktır ve çoğu zaman insanların düşündüğünden daha uzun sürer
- Paydaşlar yalnızca belli bir miktar harcayabileceklerini düşünüyorsa, tahmini düşürmek yerine şunlar konuşulmalıdır
- Bu story için ne kadar harcanabileceği
- Story’nin hangi kısmının en çok zamanı aldığı
- En büyük bilinmezlerin nerede olduğu
- Zaman alan kısımlar ve bilinmezlerle başa çıkmak için hangi alternatiflerin olduğu
- Doğrulama ve teslim yaklaşımını değiştiren seçenekler de birlikte değerlendirilmelidir
- Story’yi bölerek birkaç parçada teslim etmek
- Her parçayı mümkün olduğunca erken doğrulamak
- Mümkünse prototip ile doğrulamak
- Özellikle çok çaba gerektirip en düşük değeri üreten özellikleri story’den çıkarmanın yolları aranmalıdır
Takvim sorularını daha faydalı hale getirmek
- Tahmini düşürmeye dönük sorulardan ziyade, özellik ile takvim/kapsam arasındaki ilişkiyi netleştiren sorular daha üretkendir
- Ayrı bir yazıda ele alınacak şu sorulara bağlantı veriliyor
- Feature A ne zaman teslim edilebilir
- Gelecek çeyreğin sonuna kadar neler teslim edilebilir
- Feature A gelecek çeyreğin sonuna kadar teslim edilebilir mi
- Bağlantılı yazı: converting story points to hours
2 yorum
Makalenin orijinal başlığını DeepL ile çevirince şöyle oluyor:
"Hayır, o kadar da çaba gerektirmiyor!" diyen biri var mı?
Hacker News yorumları
“Satış temsilcilerine satış hacmini/kotalarını artırmaları için baskı yapmak, meteorologdan güneş ışığı istemek gibidir” benzetmesi bu bağlamda pek de haksız görünmüyor
Gerçekte ise aynı işi daha hızlı bitirmeleri için daha etkili çalışmalarını istemeye daha yakın
Satış temsilcilerinden kotalarını kendilerinin belirlemesi istenirse, anlaşma kapatmada çok fazla karmaşıklık ve bilinmez olduğundan, başarısız görünmemek için makul şekilde ulaşılabilir bir sayı seçerler
Ama bu sayı işletmenin ihtiyaç duyduğu seviyeden düşük olabilir; bu yüzden daha yüksek bir kota verilir ve biraz zorlayarak da olsa buna ulaşmaları sağlanır
Özellikle ödüllendirme o sayıya ulaşmakla doğrudan bağlantılıysa bu daha da önemlidir
Buna rağmen satış temsilcileri sürekli “kendi belirledikleri kota kutsaldır, bunu yalnızca satış temsilcileri belirlemelidir ve daha yüksek performans isteyen yönetim cahildir” diye yazılar yazmaz
Satış ekibi belirli bir anlaşma için “kapanma olasılığı %70, yıllık yinelenen gelir yaklaşık 5 milyon dolar” dediğinde yönetimin “Bunu %80 ve 7 milyon dolar yapabilir miyiz?” diye yanıt vermesi daha yakın bir benzetme olur
Kapanma olasılığını artırırken fiyatı da yükseltmek mümkün olabilir, ancak bir özelliği yarı zamanda bitirmekte olduğu gibi bir yerlerde büyük bir değişiklik ya da taviz gerektirir
Ancak tahminleri temenni hedeflerine çevirmektense, tahminden daha erken bitirmek çok daha iyidir
En iyisi, öncelikleri ve ön koşulları yansıtacak şekilde işleri sıraya koymak, geliştirmeye hazır yeterince story bulundurmak ve acil durumlarda uzun vadede ekip yetkinliklerinin dengesizleşmesi maliyetini göze alarak ticket’ları stratejik biçimde atamaktır
Zaman baskısı varsa tüm özelliklerdeki “olsa iyi olur” kısımlar kaldırılmalı ya da backlog’un altına indirilmeli; başka ekiplerden ya da dış uzmanlardan danışmanlık alınacaksa buna sıkı zaman sınırları konulmalıdır
Gereksiz toplantılar ve kesintiler kaldırılmalı, geliştiricilerin toplantıları reddetmesine ya da takvimlerini kapatmasına izin verilmeli; refactoring çıtası, yalnızca teslim tarihinden önce maliyet-fayda etkisi net olduğunda yapılacak şekilde yükseltilerek gelecekteki zamandan borç alma yaklaşımı benimsenmelidir
Ancak bu yaklaşımı standart çalışma biçimi hâline getirmemek için çok dikkatli olunmalıdır
Lead’lerin %10’unu dönüştürebiliyorsanız, 4 yerine 5 dönüşüm gerektiğinde kabaca 10 kişiyi daha aramanız yeterli olur
Yazılımla daha iyi bir karşılaştırma, hiç deneyiminiz olmadığı ve karşılaşacağınız sorunları da iyi bilmediğiniz bir durumda yeni türde bir bina, örneğin jeodezik kubbeli bir ev inşa etmektir
Buna rağmen sizden kesin bir tahmin istenir, ardından da bunu daha da düşürmeniz için baskı yapılır; durum buna daha yakın
En önemlisi müşteriye karşı aldatıcı davranış; burada yalnızca “şirket için iyi olan sıradan abartılardan” söz etmiyorum
Şirketin tutamayacağı sözler vermek ya da kalite ve sürdürülebilirliği feda eden death march’ler gerektiren gelecekteki özellikleri satmak gibi
C-level yöneticiler bunu görmese bile sonuçlar ortaya çıkar
Bu, geliştirici tahminlerine kayıtsız şartsız inanmak gerektiği anlamına gelmez; ama o daha büyük bir tavşan deliği, şu anda içine girmek yorucu
Yalnızca takvime ilişkin anlayış daha gerçek dışı hâle gelir
Aynı problemi çözen farklı yaratıcı çözümler bulmak ya da hedefe uymak için kapsamdan nelerin çıkarılabileceğini anlamak elbette mümkündür
Ama bu, “tam olarak aynı işi sadece daha hızlı yap” demekten tamamen farklıdır
Tahmin konusu açıldığında geliştiriciler çoğu zaman iş tarafının yerine neredeyse hiç geçip bakmıyor; tahmine neden ihtiyaç duyulduğunu ve neden kısa olanın uzun olandan her zaman daha iyi olduğunu anlamaya çalışmıyorlar
Bunun yerine yazılım geliştirmenin kutsal alanını korumaya çalışıyor, mühendislerle “diğer herkes” arasındaki farkı daha da büyütüyorlar
Bu noktada sinizm ve alaycılık ortaya çıkıyor ve sonuçta gerçekçi olmayan tahminlere yol açıyor
Geliştirici, PO, yönetici, direktör, CTO olarak çalıştım; yine de çoğu geliştiricinin değer sunma ve zaman faktörü gerçeğinden bu kadar kopuk olması hâlâ beni şaşırtıyor
Bir geliştirici olarak ne kadar süreceğinin sorulması; açıklama yapma, itiraz etme ve tahmini savunma fırsatı bulmak aslında bir şanstır
Üzücü gerçek şu ki geliştiriciler çoğu zaman iş seviyesindeki sohbetlere katılıp PM’lerin ve yöneticilerin işin karmaşıklığını görmesini, sağlıklı bir maliyet/fayda tartışması yapmasını sağlayacak düşünce, fikir, endişe ve önerilerini ifade etmekte zayıf kalıyor
Kıdemli geliştiricinin iş toplantılarına katılıp katılmadığına; geliştirme ekibinin rakamları ve bütçeyi görüp yol haritasına birlikte katılıp katılmadığına, kullanıcı araştırması ve özellik beyin fırtınasını iş/UX insanlarıyla birlikte yapıp yapmadığına bakmak gerekir
Aksi hâlde geliştiricilerin işi anlamasını beklemek zordur
Geliştirme/iş ayrımı, herkes kendi silosundayken başka uzmanların kendi problemini iyi bilmesini beklemesine yol açar ve yazılım geliştirmenin kutsallaştırılmasını doğurur
Birçok şirket, aşırı derecede silolaşmış rollere rağmen sadece bir şekilde yürüyüp gidiyor; para gelmeye devam ettiği için de bu yöntemin iyi olduğunu sanıyor gibi görünüyor
Çoğu zaman birileri örgüt içi politika için hazırladığı PowerPoint’e sayı koymak istiyor sadece
Bazen A mı yapılsın B mi karar vermeye çalışıyorlar; o durumda da haklı olarak ihtiyaç duyulan şey mutlak tahmin değil, yalnızca göreli tahmindir
Ara sıra gerçek bir son tarih oluyor; o zaman da gereken şey tahmin değil, “bu tarihe yetişebilir miyiz” ya da daha faydalı biçimiyle “o tarihe yetişmek için ne yapmalıyız” sorusudur
İş tarafına mümkün olduğunca yakın çalışmak iyidir; zaten yazılımı kullanma nedenimiz de genellikle bir iş ihtiyacını çözmektir
Ama tahmin söz konusu olduğunda çoğu zaman gerçekten onlar yanılıyor, biz haklı oluyoruz
Kısa olan her zaman daha iyiyse artık tüm tahminlere 1 gün diyelim; bu daha mı iyi olur?
Bir geliştirici kod yazabiliyor, tahmin yapabiliyor ve iş takvimine göre teslim edebiliyorsa o kişi çalışan değil, kurucudur
İstenen şey, kurucu gibi teslimat yapan ama kârdan pay almayan saf insanlar
Sizin ya da benim çabam ne kadar çok olursa olsun bebek daha hızlı doğmaz
Belirsiz bir taraf yok
Şikâyet, geliştirici bitiş zamanını bilebilirmiş gibi sorulmasında
Birinin hızlı değer sunma becerisi, ne kadar süreceğini tahmin etme becerisinden ayrıdır
Tahmini tamamen yanlış olsa da büyük değer sunabilir
Yazılım işinin süresini tahmin etmenin gerçekten bir yolu olsaydı şirketler ürün ekipleri kurdukları gibi profesyonel tahminciler işe alırdı
Bunu geliştiriciye yaptırmak için bir neden yok
Elbette başka kimse de yapamıyor; geliştirici en azından alt sınırı tutturduğu için onu rahatsız etmeye devam ediyorlar, ama sürecin kendisi apaçık aptalca
Bir işin ne kadar süreceğini bilmek için o işi yapmanın tüm adımlarını listelemek gerekir; yazılım geliştirmede bu imkânsızdır
Geliştirici verilen gereksinimler için bir alt sınır çıkarabilir ve hiç beklenmedik bir şey olmazsa doğru bir tahmin de mümkün olabilir; ancak projelerin %95~98’inde tahmin gerçekte olduğundan kısa çıkar
Sonuçta “geliştirici tahmini”, geliştiricinin bu projeye ne kadar tampon koymak istediğinin ölçüsüne dönüşür
Tahmin istemek, konuşmanın çerçevesini tamamen yanlış kurar
Asıl soru, işin şu anda sahip olduğu problem, 6 ay sonra ortaya çıkması muhtemel problem ve bu problemi çözmenin maliyetine karşı etkisi hakkında geliştiricinin girdisi olmalıdır
Bundan sonra riski azaltacak yönde nitel kararlar alınmalıdır
Yazılım tahmininin en iyi sonucu, herkesin onu görmezden gelip unutmasıdır; diğer tüm sonuçlar iş değerini yok eder
Demek istediğini anlıyorum; sorumsuz tarafların olduğu organizasyonlarda gerçek risk de büyük
Ancak meteorolog benzetmesi pek iyi değil
Meteoroloğun asıl işi havayı tahmin etmektir; oysa tipik bir geliştirici o havanın içinde çalışan kişidir ve doğru tahmin deneyimi görece daha azdır
Bir paydaş olarak sinir bozucu olan, çalışma süresiyle başlayıp gerçekçi bir süreyle de bitmeyen saçma tahminlerdir
Özellikle mikro iş düzeyinde bu daha da böyle; erişim yetkim olsa bizzat daha hızlı yapabileceğim, en fazla 30 dakikalık bir iş için haftalar süren tahminlerin döndüğü oluyor
Operasyona ciddi maliyet çıkarsa ve “her şeyi durdurup ele alınması gereken” kategoriye girse bile böyle
Elbette 30 dakikalık bir iş, test ve dokümantasyon yüzünden gerçekten yalnızca 30 dakika sürmez; ama tahmin saçmalığa ne kadar yaklaşırsa güven ilişkisi de o kadar zarar görür
Belirli bir işin fiili çalışma süresini mi soruyorsunuz, yoksa şu andan dağıtıma çıktığı ana kadar geçen süreyi mi? Bunlar farklı şeyler
Neredeyse tüm ekiplerde, her iki durumda da işin bir şeyleri beklediği süre baskındır; ama ikincisinde bu özellikle ağır basar
Gerçekten klavyeye basılan süre, genellikle koordinasyon ve takvimlemeyle kıyaslandığında yuvarlama hatası gibidir
Ekip, sezgilere ters düşen çalışma biçimlerine emek vermediyse, ortalama bir ticket fiili çalışmadan ezici biçimde daha uzun süre bekler
Üstelik ekip bu dengesizliği hiç görmez ve bunun önemli olduğunu da fark etmez
Hızla düzeltip devretmek istiyorsunuz
Sorun şu ki tamamen otomatik sürekli dağıtım yoksa 30 dakika, 30 dakika değildir
O 30 dakikalık işin başka departmanları etkileyip etkilemediği incelenmeli; takvim koordinasyonu, duyuru ve dağıtım gerekir, ayrıca 2-3 kişi daha işin içine girebilir
Planlı bir işse birkaç kişiye yayılmış şekilde 2 saate yaklaşır; hotfix ya da destek ticket’ı ise otomatik testlerin ötesinde bir QA süreci varsa 4-6 saatlik üretkenlik kaybına dönüşür
Buna ek olarak şirketteki başka insanlara etkisi belirsiz “30 dakikalık işler” isteyen 6 kişi daha varsa hiçbir şey bitmez
Bizim ekipte hotfix akışı var, ama bunun gerçekten şirket operasyonunu durduran acil bir durum olması gerekir
Çok bariz durumlar dışında talebin departman müdürü veya daha üstü tarafından yapılması gerekir
Tüm acil ticket’ları hemen ele alamamanın zararı, bir kişi için yapılan düzeltmenin birden fazla kişiye sorun çıkarmasından ya da stratejik açıdan önemli büyük projelerin bitirilememesinden çok daha küçüktür
Organizasyonda gerekli erişim yetkilerini vermenin bir yolu vardır
Cevap “benim işim değil”e yakınsa, o organizasyon katı sorumluluklara sahip, birbirine bağlı parçaları önemseyen bir yapıdır
Böyle bir organizasyonda iletişim maliyetinin çıktı performansını tamamen domine etmesi doğaldır
İyi koordine edilirse kalite yüksek olur; görevler netse iş hacmi de yüksek olabilir, ama düşük gecikme süresi asla elde edilemez
Çünkü yanıt süresi başka şeyler uğruna feda edilmiştir
Basit bir işe 1 haftalık tahmin verilmesi de böyle bir yapıdaysa beklenebilir bir şeydir
Takvim doluyken yeni iş muhtemelen ancak birkaç hafta sonrasına atanır; ince bölünmüş sorumluluklar yüzünden iki ya da daha fazla kişi gerekiyorsa bekleme süreleri üst üste eklenir
Bu işe uymuyorsa, organizasyonun kendisi o işe uygun değildir
İlgili herkes için verimsizdir
Bizim ekibin özerkliği yüksek; zamanımız sayılmaz ya da üretkenliğimiz dışarıdan izlenmez, ama gerektiğinde kodu toparlayacak zamanımız yok
“30 dakikalık” bir iş görürsem sabah incelemesine taşırım ve o konuya el atarken yakındaki işleri de yapıp yapmayacağımızı sorarım
Hiç yoksa bile bir gün ayırırım; çok iyi bildiğimiz bir projeyse yarım gün ayırırım
Yarım günü kodu gözden geçirmeye, kalan yarım günü küçük yorumlar, sürüm yükseltmeleri, kod iyileştirmeleri, değişken adı değiştirme gibi güncellemelere harcarım
Bireysel katkı verenleri de böyle yapmaya zorlamanın zaman açısından daha verimli olduğunu düşünüyorum
Yeni gelen bireysel katkı verenler bu süre sayesinde eski kodu öğrenir ve sonuçta büyük değişiklikler yapmadığımız sürece legacy sorunları da azalır
Yazılım geliştirmede tek sihirli değnek gereksinimleri basitleştirmektir
Gereksinimler her zaman yanlıştır
Ya fazla geniştir, ya fazla muğlaktır ya da yanlış varsayımlara dayanır
Gerçekten üstün yetenek, bazı varsayımları bırakıp basitleştirilmiş bir çözüm önermektir
Takvimi kısaltmanın en iyi ve tek yolu budur
Gereksinimler basit olduğunda daha eksiksiz ve doğru olmaları kolaylaşır, ama gerçek gereksinimler basitleştirilemez de olabilir
Bu durumda gereken şey daha iyi bir şartnamedir
Shuttle yazılım grubunu anlatan “They write the right stuff” temelde böyle bir işi anlatıyor: https://www.fastcompany.com/28121/they-write-right-stuff
Yazılım hatalarının çoğu aslında gereksinim hatasıdır ve iyi gereksinimler olduğunda yazılım üretme hızı akıl almaz derecede artar
Tamamen net ve değişmeyen gereksinimlerle boş bir depodan 2 ayda production dağıtımına kadar giden bir proje gördüm
Tersine, muğlak ve sürekli değişen gereksinimler yüzünden yaklaşık 30 satırlık bir özelliğin aylarca sürüklendiğini de gördüm
Şu anda yalnızca onlarca öğe vardır ama birkaç yıl sonra binlerce olacağını söylerler
Tasarımcı, 20 sayfalık ürün gereksinimleri belgesine dayanarak tüm arama akışını tasarlar; tüm planlama ve hazırlık bittikten sonra ancak mühendisliği çağırıp story yazdırır ve iş için tahmin ister
Genellikle yeterli alan bilgisine sahiptirler ve bu bağlamda neyi inşa etmek için ne gerektiğini bilirler
Paydaşlara uygun maliyet/getiri dengesi için kapsamın nasıl değiştirileceğini tartışmak değerlidir
Geliştiricilerin çok fazla iş gerektiğini varsaydığı durumları da gördüm; geliştirici olmayanların süreyi uzatan kritik kısımları göz ardı ettiği durumları da
Bazen genelleştirilmiş bir çözüm üretmeye çalışılır, oysa gerçekte gereken şey birinin bir gün boyunca elektronik tablonun başına oturup işi halletmesi olabilir
Tahminin çok yüksek olduğu sorgulanır ama çok düşük olduğu neredeyse hiç sorgulanmaz; planning poker’ın ele almaya çalıştığı nokta da bu
Fikir şu: Herkes birbirinden etkilenmeden işin zorluğunu söyler, beklentiler uyuşmazsa tartışılır
Büyük olasılıkla birileri bir şeyi kaçırıyordur
Benim bir şeyi basit sanmamın nedeni de sorunun karmaşık kısmını kaçırmam ya da daha temiz bir çözüm görebilmem olabilir
Müşterinin matematiksel ya da fiziksel olarak imkânsız taleplerde bulunması buna iyi bir örnek
Bu tür bir istek için bütün gün planning poker yapsanız da yine imkânsız bir uzlaşmaya varabilirsiniz
Freelancer olduğum dönemde, soruna dair ayrıntılı bir açıklama dinlemeyi; gerekirse o sorunu o anda çözen kişinin omzunun üzerinden süreci izlemeyi; sonra birkaç gün ortadan kaybolup en zarif ve güvenilir biçimde çözebileceğimi düşündüğüm tasarımı getirmeyi tercih ederdim
Karmaşık sorunlarda çok deneyimli biri değilse, çoğu kişi kendi sorununu açıklamakta fena değildir ama çözüm öneremez
Çünkü çözümler her zaman kişinin bildiği sınırlı şeyleri model alır
Aslında kimsenin istemediği, birden fazla kişinin varsayımlarını birbirine eklemesiyle oluşmuş tuhaf gereksinimler çok gördüm
Örneğin on iki dahili kullanıcının verileri Excel elektronik tablosu olarak indirmesini sağlamak için sonsuz ölçeklenebilir bir mikroservis mimarisi ve eksiksiz bir tek sayfa uygulaması yapmak gibi
Takımın tüm özellik kümesine yeterince aşina olduğu ve A’nın X sürede, B’nin X*3 sürede yapması gibi kaçınılmaz farkları ele alan sistemi nasıl kullanacağını bildiği varsayılır
Scrum’ın kötü işletildiğine dair tartışmalara bakmak bile bu varsayımların hiç garanti olmadığını gösterir
İşten ayrılmalar ve yeni özellikler yüzünden takımın herhangi bir anda bu varsayımların dışına çıkabileceği de hesaba katılmaz
Fazla sık şekilde insanlar sadece birbirine kaş kaldırır ve sonunda “X yapacak, o yüzden X’in tahmini geçerli” olur ya da ortalama/en düşük değer seçilir ve daha yüksek tahmin yapan kişi dezavantajlı duruma düşer
Böyle olacaksa baştan poker yapmanın anlamını bilmiyorum
Bu, ondan daha Makyavelistçe
Aracı kişi yazı gelirse ben kazanırım, tura gelirse sen kaybedersin türü bir anlaşma ister
Kendi tarafındaki muhatabı ikna etmek için düşük bir sayı sunup fayda elde etmek ister
Bu yüzden geliştiricinin kendi istediği sayıyı söylemesini sağlamak için türlü teknikler kullanır ama bunun emir ya da zorlama gibi görünmesini istemez
Öyle görünürse o sayı kendi sayısı olur ve oyun bozulur
Ama iş kaçınılmaz olarak çok daha uzun sürerse, geliştiricinin verdiği sayıyı gösterip sadece duyduğunu aktardığını, sorumluluğu olmadığını söyleyebilir
Bu tiplerin anladığı tek dil, tahmin “gözden geçirme” isteklerinin sonucunu her zaman yukarı çıkararak mesaj vermektir
Birincisi, tahmin işin uyum sağlayabilmesi için faydalı olmalı; ama gerçekte hiçbir uyum yok
PM, kendi üstünden yaklaşık son tarihe kadar bitirme baskısı alıyor
Zaten benim tahminimi umursamayacaksan neden tahmin yapıyoruz?
İkincisi, takımın gerçekçi tahmin yapması için bir teşvik yok
Doğru çıkarsa madalya mı veriliyor? Gerçekte tüm teşvikler, tahminler üzerinden iş miktarını şişirme yönünde
Üçüncüsü, bütün bu tahmin dansı ve ritüeli, yöneticilerin gerçekte olduklarından daha etkili ve nüfuzlu görünmek için benimsediği bir şeyden ibaret
Mühendisken “bunu daha hızlı yapmanın yolu yok, duymak istediğin sayıyı almak için baskı yapma” diye net konuşurdum
Biterse biter; sağlam ve iyi durumda yaparım, yeter ki önümden çekilin yaklaşımındaydım
Ama yönetici olarak daha küçük bir tahmin için bastırdığımda, iş gerçekliği açısından belirlenen süre içinde bir şey teslim etmek kritik olduğu içindi
İskambilden ev kurmak ve köşeleri kesmek gerekse bile, en azından o sorunu daha sonra ele alacak kadar hayatta kalmalıydık
O sırada mühendislikten, ben o konumda olsaydım muhtemelen vereceğim türden bir tepki geldi
Bunun korkunç bir fikir olduğu, gelecekte başarısızlığa yol açacağı ve sonraki acıyı önlemek için şimdi emek harcamak gerektiği yönünde bir tepkiydi
Tekrar mühendisliğe döndüm ama yöneticilik deneyimi bu tür uçurumları yönetirken oldukça işe yarıyor
Bunlar “11’e kadar çıkan” insanlar
Spinal Tap’in amfisi gibi normal maksimum çıkışı 9’a ayarlarsanız, onlar istediğinde bir kademe daha artıracak yer kalır
Elbette bu durumda normalden daha yavaş çalışırsınız
Ama “11’e kadar çıkan” bir geliştirici istiyorsanız, işe yarayan tek yöntemin bu olduğu açık
Müşteri beklediği için değil, kendi üstüne iyi görünmek için keyfi teslim tarihleri dayatan yöneticim ve onun üstündeki yönetici tam olarak böyle
Tahmin kaçınılmaz olarak başarısız olunca herkes ellerini kaldırıp kendi kötü tahminlerini gerekçe göstererek insanları performans iyileştirme planına almaya başlıyor
Bir mühendis olarak bu sürekli stresin içinde yaşayıp, aile ve arkadaşlarla geçirilecek zamanı kaçırarak elde edilen şey ne?
Sadece kendi yöneticinin beceriksiz tahmininin iyi görünmesini sağlamak
Eski numaralardan biri, bir vizyon oluşturup söz verdikten sonra “Ben işimi yaptım, şimdi mühendislik kendi işini yapsın” demektir
Bir release’i kapatırken, bazen saatler kala hiç haber vermeden özellik ekleyen bir yönetici aklıma geliyor
Zaten bitmiş release’lere bile özellik eklerdi
Kafasında, özelliği release’e iliştirince hemen bitiyormuş gibi görünüyordu sanırım
En büyük zorluk, proje daha yalnızca tek paragraflık bir açıklamayken insanların hemen tahmin istemesi.
Üstelik her zaman “koda baktıktan sonra ne kadar teknik borç olduğuna bağlı” gibi hissettiriyor.
Şimdiye kadar verdiğim tek makul yanıt şuydu: “Gereksinimleri sağlamlaştırmanız için sizi zorlamaya, başlamadan önce de kod tabanını durdurup denetleyerek riskleri bulmaya 1-2 gün gerekir.”
Burada daha iyi yapılabilecek bir şey var mı?
Amaç mükemmel kartlar oluşturmak değil, projede yapılması gerekiyormuş gibi görünen her iş için en az bir ticket oluşturmaktı.
Böylece “toplu oluşturma API endpoint’i yapmak”, “mevcut tablodan yeni tabloya veri migrate etmek” gibi tek satırlık birkaç kart ortaya çıkıyor.
Kart sayısı 5’ten fazlaysa
((kart sayısı / geliştirici sayısı) * kart başına tahmini iş günü) + tahmini tatil günleriile tahmin ediyorum.Kesin doğru olmayabilir ama PM ve yöneticisi o anki tahminin düşünülmüş ve makul olduğu hissine kapılıyor.
Daha sonra gecikme gerekirse “tüm kartların benzer gün sayısı alacağını varsaydık ama bu iki kart beklenenden büyük aykırı değerlerdi” diye açıklamak kolay oluyor.
Genelde sprint sürecine benziyor ama sprint velocity’yi sezgiden öte takip etmeye gerek yok.
Şirket yönetimi, neredeyse hiç bilgi yokken tahmin istiyor; daha fazla araştırmam ve kod tabanına bakmam gerektiğini söylediğimde de “sadece” bu işe onay verip vermeyeceklerine ve projeyi yapıp yapmayacaklarına karar verecek bir tahmine ihtiyaçları olduğunu söylüyorlar.
Böyle dönüp dolaşıp büyük bir tahmin vermek zorunda kalıyorum; kapsamını bile bilmediğimiz şeyler dahil tüm bilinmeyenler yüzünden sayı büyük çıkıyor.
Sonra da yönetim için fazla büyük ve fazla pahalı oluyor.
Agile terimleriyle bu 3 puanlık bir spike ticket; çıktısı da değerlendirilmiş ödünleşimlerle birlikte ayrıntılı gereksinimler, teslimatlar ve tahminler olur.
Tamamen normal bir yöntem.
Spike’tan önce tahmin verebilirsin ama mümkün olduğunca çok şart eklemelisin.
Örneğin “%60 güvenle 3 haftadan az, %80 güvenle 5 hafta, %90 güvenle 6 hafta” diyebilirsin.
Genel olarak 1-2 haftayı aşan teslim tarihi tahminlerini reddeder, mümkün olduğunca parça parça tahmini tercih ederim.
Mesela “bu proje, her biri 1-2 günlük iş sürecek 7 teslimattan oluşuyor” gibi.
Bir iş 10 günlük mühendislik işi olabilir ama önceliklerin değişmesi gibi nedenlerle teslim tarihi hesabı fiilen anlamsızlaşabilir.
“Yöneticiler” bunu anlamıyorsa ne yazık ki huzurlu olmak zor.
Kod borcunu ve kaliteyi umursamadan, zar zor çalışan bir şeyi aceleyle çıkarmak.
O zaman memnun olurlar.
Tipik aksiyon filmi hackleme sahnesi şöyle olur:
Lider: “Mainframe’i hacklemek ne kadar sürer?”
Teknisyen: “Karşı hacker gerçekten çok iyi, en az 2 saat.”
Lider: “Sana 1 saat veriyorum. Yap.”
Sonra 3D dosya sisteminde uçar dururlar.
Böyle sahneleri her gördüğümde teknisyenin iç sesini kafamda şöyle anlatırım:
“Gerçek tahmin 20 dakikaydı. Muhtemelen 50. dakikada bitiririm, liderin tuhaf fikirler üretmemesi için de 10 dakika daha 3D dosya sisteminde meşgul görünerek uçarım.”
Tam olarak doğru değil.
Pek çok özellik, çok iskelet bir yaklaşımdan tamamen altın kaplama bir yaklaşıma kadar çeşitli seviyelerde yapılabilir.
Bazen bir geliştirici arkadaşım, bana göre en fazla bir günlük bir özelliğe 2 hafta tahmin veriyor; çünkü aslında istenmemiş birçok ek özelliği varsaymış oluyor ya da benim gerekli olduğunu bilmediğim bir kısmı biliyor oluyor.
Tahmini değiştirmen istendiğinde bunu, gereksinimleri ve önerilen uygulamayı biraz daha tartışmaya davet olarak görmek gerekir.
%90’a ulaştıran çok daha basit bir çözüm mümkün ve kabul edilebilir olabilir.
Meteorologların böyle bir seçeneği yok.
Standart bir combo box/select box koymak ile duruma daha iyi uyan çok daha iyi bir özel UI öğesi yapmak arasındaki fark, IT dışındaki insanlara pek iyi aktarılamaz.
Çizimle anlatabilirsiniz ama paydaş görüp dokunmadığı için yine de ne olduğunu bilmez.
Bu yüzden çoğu zaman gerçekten çalışır hale getirip göstermek gerekir.
“Mümkün olan en basit şekilde yapın” deyip, prototip GUI ile tamamlanmış tasarım GUI’sini ve ardından prototipi gösterdiğinizde ilk ikisini hiç görmeden onaylayan müşteriler var.
Sıkıştırdığınızda prototipi kurcalayıp “iyi, devam edelim” derler; sonra test sunucusunda gerçekten çalışan şeyi kurcaladıktan sonra “bizim kastettiğimiz bu değildi” derler.
İki kişilik karı-koca dükkânından, bölge direktörü ve global CTO’nun fikir belirttiği Fortune 500 şirketlerine kadar bunu yaşadım.
Bu ön yüz tarafı; arka uç ve DevOps ise bambaşka sorunlar ama orada da iskelet yapmakla altın kaplama yapmak arasında büyük fark var.
Artık bu oyunu bildiğim için, bugünlerde bu bozuk süreçten iyi para kazanıyorum.
Fred Brooks 1975’te şöyle yazmıştı:
“Kaç kadın görevlendirirseniz görevlendirin, bir çocuk doğurmak 9 ay sürer.”
Bundan daha iyi bir ifade yok.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Her ek kişi işi daha uzun sürdürür.
En hızlı teslimat, tek başına çalışan geliştiriciyi rahatsız etmeden işini yapmasına izin vermektir.