Agile Manifesto’nun 12 prensibi halen geçerli mi?
Çevik yazılım geliştirme manifestosu 2001 yılında aralarında Kent Beck, Martin Fowler, Alistair Cockburn gibi tanınan isimlerin de olduğu 17 vizyoner ismin yayınladığı 12 maddelik bir bildiridir. Aynen kutsal kitaplarda yer alan 10 emir misali, çevik yazılım geliştirme paradigmasının temel kurallarını koymayı amaçlar.
20 yıl uzun zaman. Gelin bu manifestonun 12 prensibini gözden geçirelim ve halen geçerli olup olmadığına bakalım.
1- Yazılımın erken ve devamlı teslimini sağlamak
İlk prensip bize şöyle diyor.
En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.
Yazılım geliştirme pahalı bir süreçtir ve çalıştığınız kurum bu faaliyet için hatırı sayılır paralar ödemektedir. Bu durum 2001 yılında da böyleydi, bugün de böyle. Müşteriler her zaman sabırsızdı, bugün de sabırsız. Harcadığı paranın ilk çıktısını 6 ay sonra görebilecek olmak endişe verici bir deneyim olduğu kadar, risklidir de. O nedenle her seferinde küçük adımlar atarak, her teslimatta (scrum kullanılıyorsa 2 haftada bir yapılan sprint süresince) müşteri için değerli bir şeyleri masaya koyarak müşterinin de, sizin de durumdan memnun olacağınız bir çalışma ortamı yaratılmalıdır.
2- Değişimi kucakla
İkinci prensipte şöyle bir cümle sarf ediliyor.
Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.
Waterfall yönteminde yazılım geliştirme, uzunca bir analizin ardından yapılan bir süreçtir. Yazılım geliştirme ekibi analizi inceler ve bir teslim zamanı taahhütünde bulunur. Kulağa hoş gelse de, müşteri açısından bariz bir dezavantajı var. Ortada el sıkışılmış bir zaman taahhütü olduğu için, proje başladıktan sonra kapsamda değişiklik yapmak kontratın bozulması anlamına gelir ve kesinlikle tercih edilmez.
Bugün bu yaklaşım ticari dünyanın gerçeklerle uyuşmuyor. Gereklilikler sürekli değişiyor, artık 6 ay-1 yıl bir çıktı almadan yazılımın hazır olmasını beklemek kurumlar için mümkün değil. Bu süreler o kadar uzun ki, o esnada sektör değişiyor, rekabet kızışıyor. Yapılan ürün artık ihtiyaçları karşılamaz hale de gelebilir. Daha çevik olmak zorundayız. Bu durum 20 yıl önce de böyleydi, bugün de böyle.
3- Sık teslimat
Sıradaki prensip ise hepimizin aşina olduğu sprint kavramını bize tanımlıyor.
Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.
Bu madde birinci maddenin tekrarı gibi duruyor ama ilk maddede en kısa sürede bir teslimat yapmak ön plandayken burada sık teslimat yapılması ön plana geliyor.
Eğer Scrum kullanıyorsanız, bu maddeye zaten aşinasınızdır. Kısa sprint’ler daha sık teslimat, daha az bug ve daha çok müşteri geribildirimi almak demektir. Tabii bu sıklığı çok abartırsanız da süreç verimsiz hale gelir. Genel kabul gereği, 2 haftalık bir tekrarlanan zaman aralığı çoğunlukla makuldur.
4- İş süreçlerinin sahipleri ve yazılımcılar birlikte çalışmalıdır
Manifesto’nun en provakatif prensiplerinden bir tanesi muhtemelen budur.
İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.
Biz bunu, geçmişte müşterinin yazılımcılarla birlikte tüm gün masada oturması şeklinde anladık. Tabii pratikte çok az işletme bunu bu hali ile uygulayabildi. Gerçek hayatta ise ürün sahibi rolü (product owner) bu sorumluluğu üstlendi.
Bu prensip doğrudan iletişime cesaretlendirse de teknik analist rolü halen çoğu şirket için geçerliliğini koruyor. İş biriminden gelen talepleri yazılımcıların olduğu gibi anlayıp uygulaması maalesef her zaman mümkün olmuyor.
Durum böyleyken, kulaktan kulağa iletişim her zaman hataya açıktır. Uzaktan çalışılıyor olsa dahi, teknik analist rolü olsa dahi, yine de iş birimleri ile yazılımcıların günde en azından 1 kez bir araya gelip, neyin nasıl gittiğini tartışması sağlanmalı.
5- Motive olmuş bireyler
Yöneticiliğin en temel prensiplerinden bir tanesi bu maddede aktarılıyor.
Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.
Bu madde 20 yıl önce geçerliydi, muhtemelen 200 yıl sonra da geçerli olacak. Neticede yaptığımız iş insanla. Çalışırken işini seven bir bireyle, mesai saati dolduran bir birey asla aynı çıktıyı üretmeyecektir. 21. yüzyılda yöneticilerin asli görevi, ekibinin önünü açmak ve işlerini layığıyla, mutlu bir şekilde yapabilecekleri ortamı onlara sunmaktan ibarettir.
6- Yüz yüze iletişim
Sıradaki maddeye dikkatli bakalım.
Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze iletişimdir.
İnsanlar sadece kelimelerle iletişim kurmaz. Konuşurken karşımızdakinin gözlerine veya dudaklarına bakarız. Yüzlerindeki yüzlerce kasın hareketleri onların düşünceleri hakkında inanılmaz ipuçları bize verir.
Pandemi sürecinde uzaktan çalışmayı çok güzel öğrendik. Ama kameralarımızı kapalı tuttuğumuz sürece insanlığın 200 bin yıllık “mimik” okuma yeteneğinden mahrum kalıyoruz. Slack, Telegram, WhatsApp iletişimi anlık sorunları çözmekte yeterli geliyor olabilir ama uzun vadeli bir projede daha fazla etkileşime, insanların birbirini görmesine ihtiyaç olduğunu düşünüyorum. En azından kameraları açık tutmak işe yarayacaktır.
7- Çalışan yazılım
Kısa, öz ve anlamlı bir prensip geliyor sırada.
Çalışan yazılım ilerlemenin birincil ölçüsüdür.
Ardı arkası gelmeyen toplantılar, duvarlarda rengarenk post-it’ler, janjanlı mockup’lar, alengirli iş akış diagramları çalışan bir yazılım ortaya koymadığınız takdirde hiç bir anlam ifade etmez. Müşterinin derdini çözmediğiniz sürece bunlar boşa giden para ve gereksiz elegan eylemler olarak adlandırılır.
Çalışan yazılım, bugün canlıya alındığı an itibariyle müşterinin bir veya bir kaç sorununu çözecek olan yazılım demektir. Testleri yapılmamış, code review yapılmamış, corner case’ler handle edilmemiş bir kod, çalışan kod değildir.
8- Sürdürülebilir geliştirme
Benim en çok sevdiğim prensip kesinlikle budur. Yöneticilerin özellikle dikkat etmesini öneriyorum.
Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.
Aylarca fazla mesai yapan ekipler, proje takvimine uyabilmek için haftasonları bile çalışan yazılımcılar mutsuz ve yaptığı işe inanmayan bir ekip yaratır. Elbette ki istisna dönemler olur, tüm ekip inandıkları amaç uğruna daha fazla efor sarf etmek isteyebilir. Ama siz yöneticileri olarak insanların sosyal zamanlarından onlara bu durumu dikte ederek pay almayı hak olarak görüyorsanız aşağıdaki iki ihtimalden birisi doğrudur:
- Proje planlamayı bilmiyorsunuz
- İnsanlara değer vermiyorsunuz
şahsi kanaatimce ikisi de birbirinden kötü meziyetler.
İdeal olan;
- ölçülebilir
- her gün tekrarlanabilir
bir yoğunlukta maksimum performans seviyesini yakalama amacına tüm takımı ikna ve motive etmektir. 1 gün tam kapasite çalışıp ertesi gün pert olan bir ekip aslında 2–3 gün çerçevesinde bakıldığında verimsiz çalışmıştır, üstelik de mutsuzdur.
9- Teknik mükemmeliyet
Bir sonraki maddemiz teknik mükemmeliyet arayışı ile alakalı.
Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.
Kurumlar zaman baskısı altında. Çoğunlukla ürünü hızlı çıkmak kaliteli bir ürün yapmanın önüne geçiyor.
Bildiğiniz üzere yukarıdaki 3 faktörün (hız, kalite ve maliyet) hepsine birden sahip olamazsınız. 2 tanesini seçmeniz gerekir. Kapsamı sabit tutarak, daha hızlı olmak istiyorsanız denklem basittir. Ya kaliteden feragat edersiniz, ya da maliyetten. İkisinden birden feragat edemiyorsanız bu durumda kapsamı daraltırsınız. Yapacak başka bir şey yok.
Martin Fowler’in Tasarım Dayanıklılık Hipotezinde teknik mükemmellik (kalite) için yapılan yatırımın küçük projelerde geri dönüşünün zor, ama proje büyüdükçe katlanarak arttığını şu grafik ile açıklıyor.
10- Sadelik
Sadelik üzerine felsefik bir prensip ile devam ediyoruz.
Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.
Bu durum kültürümüzde “parça arttırmak” diyerek karikatürize edilmiştir. Hakikaten yazılımınızda mümkün oldukça fonksiyonaliteyi bozmadan, kaliteden ödün vermeden, müşterinin de hemfikir olduğu parçaları atmak, ürünü olabildiğince sade, kullanışlı ve estetik yapmak en temel amaçlarımızdan birisi olmalıdır.
11- Kendi kendini örgütleyen takımlar
Yine bir yönetim tavsiyesi ve yöneticilerin dikkat etmesi gereken bir prensip var sırada.
En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.
Yetki ve sorumluluk bir arada bulunması gereken bir ikilidir. Bir takım insanın bir arada vakit geçirmelerini, motive olmalarını ister ve onlara ürünü sahiplenme sorumluluğunu verirken, en temel gereksinim ve tasarımlarda yeterli özgürlüğü ve yetkiyi vermediğiniz takdirde o ekipten en iyi performansın alınması mümkün değildir.
Bir CTO’nun ve diğer teknik yöneticilerin görevi, kurum içinde bir harmoni olması için elzem olan en temel prensipleri belirleyip takipçisi olmak ve takımları, bu prensiplere uyduğu sürece diğer tüm kararlarında serbest bırakmaktır.
12- Sürekli iyileşen ve gelişen takımlar
Son prensip aslında 11. maddeyle direkt ilişkili ve bir manada onun devamı niteliğinde.
Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.
Takım sıklıkla bir arada neyi iyi, neyi kötü yaptığını konuşabilmelidir. Bu sayede sanki tek bir metabolizmaymışçasına kendisini tanır ve daha iyi olmak için çaba sarf eder. Bu prensip bugün retrospective buluşmalarında vücut buluyor.
Sonuç olarak, aradan 20 yıl geçmesine rağmen çevik yazılım geliştirme manifestosunun 12 prensibi bugün halen geçerliliğini ilk günkü gibi koruyor. Pandeminin iş yapış tarzımızı değiştirmiş olmasının yarattığı nüanslar haricinde tahmin ediyorum önümüzdeki onlarca yıl daha da bu prensiplerin peşinden gitmeye devam edeceğiz.
