Konuk yazarımız Birge Elif Basık, VNGRS ekibinin Agile Coach'udur. Sağlıklı yazılım yaşam döngüsü, süreç iyileştirme, ürün geliştirme ve yazılım takımlarının verimli çalışması gibi konularda çalışmalar yapmaktadır.
Yazılım dünyasında son bir kaç yıldır yeni bir rüzgar esiyor: Agile (Çevik) yazılım geliştirme. Google’ı açıp “Agile Development” yazdığınız zaman önünüze bu yeni yazılım geliştirme sisteminin ne kadar verim arttırdığı, yazılımcıların işini kolaylaştırdığı ve ürününüze gözle görülür katkıyı çabucak yaptığı ile ilgili binlerce makale dökülüyor. Uzmanların makaleleri size bu dönüşümün yazılım geliştirme dünyasının olmazsa olmazı olduğunu anlatıyor, acilen “Agile” uygulamaya başlamazsanız başınızın dertte olduğuna dair sizi uyarıyor.
Bu rüzgara kapılan firmalar aldıkları danışmanlıklarla veya takımlarına ekledikleri yeni proje yöneticileri ile içlerinde pilot programlar uyguluyor, yazılım ekiplerinin odaları renkli postit’ler ile doluyor, bir heves herkes sabahları 15 dakikalığına toplanıp günlük “Scrum” toplantısını yapıyor. Ama bir kaç ay sonra, yetişmeyen iterasyonlar ve bol hatalı sürümler, mutsuz yazılımcılar ve şikayetçi yönetim kadrosu yaratıyor. Agile yazılım geliştirme suçlanıyor ve bu zamana kadar yapılmış değişiklikler bir kenara atılıyor. Agile yüzünden daha da karışmış bir sistemle, ekipler eskiye dönüyor.
Peki neden agile yazılım geliştirme bu kadar değerli olduğu halde firmalarda çalışmıyor?
Son bir kaç yıldır, Türkiye’de ve yurtdışından farklı firmaların içlerinde barındırdığı 20’den fazla takımla çalıştım. Dünyanın her yerinde dağınık bulunan takımların da, Türkiye’de aynı odada çalışan ekiplerin de yaptıkları hatalar hemen hemen birbirinin aynısı. Bu bağlamda, yukarıdaki sorumun bir kaç tane temel cevabı olduğunu deneyimledim.
Öncelikle, “Agile Yazılım Geliştirme” sadece bir sistem olarak algılanıyor. Ancak agile, bir sistem değil, kendisine ait manifestosu olan bir felsefedir. Bu felsefe bütünüyle firmanın tamamı tarafından benimsenmeden, sadece yazılım ekibini zorlayarak yapılmaya çalışılan değişiklikler yürümüyor. Bu arada şunu da belirtmekte fayda görüyorum, teknoloji temelli olsun olmasın IT ekipleri bir çok firmanın kalbi haline gelmiş durumda.* Bu bağlamda değişime başlanacak en doğru yer IT olmakla birlikte, diğer departmanların da bu değişime hazır olması gerekiyor. Muhasebe veya pazarlama birimleri, “Çok acil!!!” başlıklı emaillerle yazılımcıları taciz edip işlerini bölmeye devam ettiği sürece, söz verilen özelliklerin ürüne eklenmesi imkansız hale geliyor. Bu sebeple geçici bir süre için yazılım ve diğer departmanların arasına bir kalkan koymak, diğer departmanlara “Hayır” veya “Daha sonra” diyebilecek kötü bir adam seçmek, genelde bu dönüşümün daha pürüzsüz olmasına yardım ediyor.
Agile felsefesinin temelinde, tamamlanması düşünülen işlerin düzgün bir şekilde ufak ve anlamlı parçalarına ayrılması, bununla birlikte geri dönüşü en yüksek olacak şekilde sıralanması yatar. Böylece, hata yaptığınız takdirde, kaybınız az, aldığınız ders çok olur. İşlerin uygun şekilde bölünebilmesi ve "yapılacaklar listesi”nin hazırlanması tecrübe ve emek isteyen bir süreçtir. Bu süreci yönetecek kişinin doğru seçilmiş olması, ürünü iyi tanıması ve ileriyi bir parça öngörebilmesi, agile dönüşümün başarısını doğrudan etkiliyor. Ürün sahibinin, tamamlanması planlanan özellikler konusunda seçiçi olmaması, her şeyi aynı anda yapmaya çalışması, sürekli fikir değiştirmesi veya müşteriden gelen geribildirimleri dikkate almaması sadece agile dönüşümü değil aynı zamanda ürünü de tehlikeye atıyor.
Agile dönüşüm planlanırken, sadece proje yönetiminin değil, aynı zamanda kalite anlayışının da değişeceğini öngörmek gerekiyor. Agile, yapısı gereği “Çalışan Ürün”ü her zaman önde tutar. Ürünü hızlı çıkarırken, kaliteden de ödün verilmemesini şart koşar. Kalite standartını belirli bir eşikte tutabilmek için, ürünün piyasaya çıkmadan önce belirli testlerinin tamamlanmış ve hatalarının onarılmış olması gerekmektedir. Hatalı çıkan ürünler, firmalara müşteri ve itibar kaybettirmektedir. Fakat çoğu firma, oldukça yoğun efor gerektiren kalite kontrol sürecini pahalı bulmakta ve arka plana atmaktadır. Ülkemizde yeterli sayıda kalite mühendisinin olmaması da başka bir handikaptır. Firmalar kendileri yapamasalar bile, dışarıdan alınacak bir danışmanlıkla kalite kontrol sistemlerini (agile) dönüşüme uygun hale getirmelidir. Agile proje yönetimi ve kalite kontrol, asla birbirinden ayrı anılmaması gereken iki temel olgudur.
Agile dönüşümden bahsederken, “release” süreçlerini atlamak da büyük hata olur. Müşterilerin sizden bekledikleri ürününüzün yeni özelliklerini çabucak geliştiriyor olabilirsiniz ama bu yenilikleri canlıya almanız günlerce, hatta haftalarca sürüyorsa, “agile” dönüşümü tamamlamış sayılmazsanız. Gözlemlerime göre, yazılımcıları paradan daha çok mutlu ve motive eden şeylerden birisi de yazdıkları kodu çabucak canlıda görebiliyor olmaları. Sık ve hızlı release çıkmanın yolu da düzgün bir DevOps yapısından geçiyor. Kalite kontrol / test mühendisliği kısmındaki sıkıntılar burada da geçerli. Yetersiz kaynaklar, otomatize canlıya alma sistemini hayal kılıyor. Hele kaynak kodda da problemler varsa, ürün üzerinde kritik değişiklik yapmak iyice kabus oluyor. Yazılımcı, ürün geliştirmeye odaklanmak yerine, ürünü canlıya almakla daha çok uğraşabiliyor.
Son olarak yazılımcı mutluluğuna değinmek istiyorum. Agile yazılım geliştirmenin gizli kalmış ve çok bahsedilmeyen noktalarından biri de, mutlu yazılımcıların daha üretken olduğu gerçeğini desteklemesidir. Mutlu yazılımcılar firmanızda daha uzun süre sizinle beraber çalışırlar. Süreçleri bilirler, ürünü sahiplenir ve ileriye götürürler. Agile sanılanın aksine, sizin geleceği planlamanıza ve önünüzü daha net görebilmenize yardım eder. Yazılımcıların, kendilerini geliştirmeye harcayacakları süreyi fazla mesaiye gömmelerini engeller. Fakat, başarısız agile denemeleri yazılımcıyı süreçten de üründen de soğutur. Sürekli hatalı ürün çıkmak, hatta aylarca çıkamamak, yazılımcının kendisini başarısız hissetmesine neden olur ve kendine daha verimli çalışabileceği yeni bir firma aratır.
Özetlemek gerekirse, sadece Agile seramonilerini uygulayarak yapılmaya çalışan bir agile dönüşüm başarısız olur. Agile, sisteminizdeki hataları su yüzüne çıkartır, ancak sizin de bu hataları görüp düzeltmek için çaba harcamanız gerekmektedir. Hiç bir şey önünüze gümüş tabakta sunulmaz, sadece günlük toplantı yapıyorsunuz diye de düzelmez. Firma, bütünüyle agile felsefesini benimsemedikçe; ürün yönetimi, kalite kontrol ve canlıya çıkma süreçlerinin dönüşümünü de planlamadıkça “agile” olunmaz. Sadece boşa vakit ve para harcanmış olur.
Kapak görseli: 2nix Studio/Shutterstock
