Az Çorba Az Çeviklik

Çevik metodoloji (agile) iyi güzel ama çeviklik herkesin her koşulda uygulayabileceği bir şey değil aslında. Bu yazıda konuya biraz olumsuz tarafından bakmak istiyorum. Çevik metodolojiler eğer iyi ve tam uygulanamazsa beklentilerin tam tersine sonuçlar doğurabilir.

Basitlik

SCRUM, Agile, Lean vb. günümüz metodolojileri basitlik üzerine kurulular. Çok az sayıda temel kuralları var. Metodolojiler, ekiplerin işini yapmayı durdurup ikide bir işi nasıl yaptığını kontrol etmeye zamanı olmadığını biliyor. Dolayısı ile karmaşık modelden basit modellere giderek proje planlama, yönetim, kontrol, dökümantasyon yükünü hafifletmeye çalışıyor. Metodolojiyi basitleştirmek bir yandan riskleri arttırırken diğer yandan basitliği sayesinde sağladığı süreklilik ve tutarlılık ile verim arttırmayı hedefliyor. Benim uyarım da burada başlıyor. Peki zaten aşırı basitleştirilmiş olan metodolojinin bütün prensip ve kurallarına gerçekten uyulabiliyor mu? Uyulması gereken 3–5 kurala da uyulamadığı zaman risklerini arttırmanın yanında metodolojisizlik sorunu ile karşı karşıya kalınılabilinir. Yüz kurallı bir metodolojiden 3–5 kurallı metodolojiye düşmemizin sebebi sadece en önemli ve olmazsa-olmaz olanları tutma niyetimizdi. Metodolojilerin basitleştirilmiş olması doğal süreci ya da üretilen şeyi basitleştirmedi. Dünya artık daha karmaşık, rekabet daha fazla, analiz yapmak, anlamak, anlatmak gittikçe zorlaşıyor. Örneğin bir arayüz ne kadar basit ise onun arka planı o kadar derin. Google’ı tek bir metin kutusu üzerinden çok kolay kullanıyor olmamız arka plandaki karmaşıklığı maskeliyor mesela.

Sıklıkla İhlal Edilen Çeviklik Kuralları

Çevikliğin sıkı kuralları yok, bir framework değil bir yaklaşım. Dolayısı ile kurallardan çok prensipleri var demek daha doğru. Ama bu prensipler gerçekten çok kritik. Örneğin yazılım kadar karmaşık bir fenomene uzun toplantı ve analizler sonucunda detaylı dökümantasyon yapmamak gibi bir “deliliği” sadece o prensipleri tam uygulayarak başarıya ulaştırabiliriz.

Çevikliği seçip riskleri arttırıp, ön analizleri kısaltmak uyulması çok kolay karar. Ama uyulması zor olan bazı çevik prensipleri iyice değerlendirmek gerekir. Bu maddeleri bildiğiniz agile manifestodan [1][2] seçerek yorumlayarak listeliyorum. Maddeleri yazılım özelinde örneklendireceğim:

• Sürekli teknik mükemmellik: Ön analizi basit tut ama sadece çok yüksek kalitede kod yazacaksan demek istiyor. Zamanının önde gelen (state-of-the-art ) güncellenebilirlik ve genişletebilirlik yöntemlerini kullanacağın varsayılıyor mesela. Bu yöntemler her zaman problem alanı, teknoloji ya da fonksiyonel olmayan hedeflere göre değişmekle birlikte OOP, DDD, TDD, AOP, DRY vb. gibi üç harflilerle ifade edilebilir. En önemlisi uygulayıcıların bu seçilen yöntemleri layıkıyla uygulayabilir durumda olması önşartı var. Bu maddeyi gözardı edip agile yapıyorum dediğinde, iş riskleri arttırmanın ötesine gitmeyebilir. Burada teknik beceri konusunda sürekli bir idealizme ihtiyaç vardır ve bu idealizme pek az insan ve ekip sahiptir. Mesela test yazıyorsan iyi testin nasıl yazıldığını da bilmelisin. Dinamik bir dille yüzbin satır kod yazmaya kalkıp test yazmıyorum diyemezsin. Kalite hep yüksek ve sabit olmalıdır. Bunlar bir bütündür, bütün halinde biliniyor ve benimseniyor olmalıdır.
• Güven ve sorumluluk: Uygulama projesindeki tüm paydaşların işlerini mümkün olduğunca layıkıyla yapmaya çalıştığını biliniyor ve güveniliyor olmalıdır. Bu güvenin bir şekilde oluşamadığı ortamlarda yetki, sorumluluk ve insiyatif hakkı verilemez. Eğer bu ortam oluşmadıysa risk daha da yükseliyor olabilir. Güven ortamını oluşturmak zordur. Güven ilişkisi çok yönlüdür, harika bir ortama ve ahenge ihtiyaç duyar. Güvensizlik, büyük protokoller, sözleşmeler, kayıtlar, kanıtlar, imzalar, emirler gerektirir. Bunlar çevik geliştirmenin ruhuna uymaz.
• Kendi kendine organize olabilme ve iletişim: Özellikle ülkemizde organize olma yeteneğinin çok düşük olduğunu düşündüğümden bu bizlerin en fazla dikkat etmesi gereken konu diye düşünüyorum. İş hayatında çok amatörüz, tartışma kültürümüz zayıf, tartışma ile polemik, argüman ile safsatayı [3] birbirinden ayıramıyoruz. İnsanlar duygularını adeta özel hayatlarında değil iş yerlerinde yaşıyor. Sevgi, entrika, nefret, alınma, söylenme hepsi iş hayatında. Mesai çıkışı işten çıkıldığında ilk iş yeni iş dedikoduları anlatmak, onun bunun hakkında yüzeysel çözümlemeler yapmak oluyor. İşte profesyonelce davranıp işi işte bırakamıyoruz. İyi iletişim ve organizasyon yeteneğini de iyi arkadaş olabilmek, kankalığa, insanlarla iyi geçinmeye indirgiyoruz. Agile, kişiler arasında çok iyi iletişim olduğunu ve bu insanların sürekli yüzyüze çalışması gerektiğini ifade eder. Paydaşlar birbirine küs, tavırlı kişiler ve ekipler ile doluysa bunu sağlayamazsınız. Aksine en güçlü yanınızın iletişim olması gerekir. Herkes bir an önce bilgisayarının başına dönmek istiyorsa çeviklikten pek bahsedemezsiniz. İletişim bulanık değil çok berrak olmalıdır:

Kişi “bu kod çalışmıyor” dediğinde sadece “bu kod çalışmıyor” demek istiyor ve karşı taraf sadece “bu kod çalışmıyor” olarak algılıyor olmalıdır.

• İş insanları ile uygulamacıların gün içinde birlikte çalışması: Ön analiz ve dökümantasyonları azaltırken aslında buna güveniliyor. Yani iş birimlerinden her gün güncel iş üzerindeyken daha fazla geribildirim alınacağı varsayılıyor. Proje başında bir kereliğine çok yoğun bilgi yağmuruna maruz kalmak yerine, yeri geldiğinde çalışan yazılım üzerinden sürekli bilgi akışı sağlanması, anlamayı ve tasarlamayı kolaylaştırır diye düşünülüyor. Bu çok mantıklı olmakla birlikte bence bir projenin en büyük politik riskidir [4]. İş insanları bu sürece gerektiği kadar hatta bazen hiç katılmayabilirler/katılamayabilirler. Katılsalar bile “bitsede gitsek” tarzı bir tavır ile geliştirici ekibe sokakta zorla anket yapıyorlarmış gibi davranabilirler. Analiz bilgisini elde etmek (requirement elicitation) başlı başına bir uzmanlık alanı. Geleneksel literatürde bu konuyla ilgili çok fazla yazılıp çizilmiştir [5]. İş insanı her istediğinde erişilebilir olsa bile bilgiyi sorunsuz aktarabilme ihtimali çok düşüktür. Kişiler arasındaki terminoloji problemi, yöntem eksikliği ve işi yapmasına rağmen formalize edememesi gibi onlarca problem sayılabilir. Bu varoluşsal problemler bir yana en büyük riskin iş insanlarının kendilerini projenin parçası görmemeleri olduğunu düşünmekteyim. Kağıt üstünde “Product Owner takımın parçasıdır” yazınca iş bitmiyor. “Parasını, bütçesini, takvimini ben ayarlıyorum, gerisi onların işi” kültürü hakim olabilir. Çünkü problemleri öyle çözmeye alışmışız. Arabanı tamir ettirdiğinde servisin sana yaptığı açıklamayı anlamak zorunda değilsin, parasını öder arabanı alırsın. Gerisi servisin işidir. Bu soyutlama kültüre yerleşmiştir. İnsanlar kendilerinin içinde bulunmalarının ne kadar değerli olduğunu bilmez, bilse de benimsemezler. Burada atlanan şey şudur; araba bitmiş bir üründür, bir de sadece kendinize yeni ve özel bir araba yaptırdığınızı düşünün. Bir şeyleri tarif etmek asla küçümsenmemesi gereken bir faaliyettir. Bu konuda aklıma hep “spor salonuna o kadar para verdim, sporu da ben mi yapacağım” esprisi geliyor.

Gelişigüzellik

Bilgiyi elde etmek zaten bu kadar zorken, iş birimlerinin projelere destek vermemesi proje sürecini kaosa, ürünü ise yanlış varsayımlarla dolu bir yap-boz tahtasına çevirebilir. Agile’ın sürekli geribildirime dayanan iteratif yapısından dolayı evrime ya da makine öğrenmesine benzetmek ilk bakışta keyiflidir ama hiçbir projenin 4.5 milyar yıl beklemeye zamanı olduğunu sanmıyorum. Çeviklik sayesinde bir ahenk ile tasarlanması gereken ürün, bu süreçler aksadığında gelişigüzel bir yapıya bürünebilir. Bu gelişigüzel yapı oluşturan hep kısa vadeli çözümü uygulayan sürece kluge (kluuj okunur) adı veriliyor [6]. Kluge hayatın her yerinde var ama her zaman faydalı değil. İnsan vücudu bir kluge ürünü mesela. Milyonlarca yıl boyunca hep o günün lokal ortamında hayatta kalabilmeyi maksimize ederek gelişmiş çok kompleks bir sistem. Bu yüzdendir sırt ve bel ağrılarımız, ya da kullanmadığımız garip organlarımız. Gelişigüzel yapı yeniden yapmadan düzeltilemiyor, yama yapılabiliyor sadece. Bu işin doğasında var. Yazılım projelerindeki kluge’lar 2-3 yıl sonra yeniden geliştirme gerektirir, büyük bakım ve genişletebilme sorunları üretir.

Hayat uzun vadeli idealist planlar ve tasarımlar için çok kısa olabilir ama hep gelişigüzel yüzeysel çözümlerle geçmeyecek kadar da uzun.

Umursamazlık

En çözümsüz problemi sona sakladım. Bunun manifestoyla, analizle, politik riskler ile falan pek ilgisi yok. Bu bir idealizm eksikliğidir. Yaşamak dışında hiç bir entellektüel meraka ya da tutkuya sahip olmama durumudur. “Hocam bu matematik hayatta bize ne zaman lazım olacak” faydacı kültürüdür. Bu kültür sorgulayamaz, üretemez, öğrenemez. Bu kültürü, adeta salgın bir hastalık gibi yayılması kolay ama durdurması çok zor bir felaket olarak görüyorum. Sonuç olarak, idealin ne olması gerektiği her zaman tartışmaya açık olsa da, ne olmaması gerektiğinin bu olduğunu düşünüyorum.

https://dilbert.com/strip/2007-11-26

Kaynakça

[1] Manifesto for Agile Software Development
[2] Principles behind the Agile Manifesto
[3] Safsata Savar — İlker Canikligil, Yalın Alpay
[4] Yourdon, Edward. Death march. Pearson Education, 2003.
[5] Van Lamsweerde, Axel. Requirements engineering: From system goals to UML models to software. Vol. 10. Chichester, UK: John Wiley & Sons, 2009.
[6] Gary Marcus, Kluge: The Haphazard Construction of the Human Mind