Ülkemizde teknoloji geliştirme merkezleri bir başka isimlendirmeyle teknoparkların sayısı arttıkça, yazılım evlerinin de sayısı hızla çoğalmakta. Dikkatinizi çekmiştir, teknoparklardaki şirketlerin birçoğu yazılım geliştiriyorlar. Zaten yazılım, günümüz teknolojisine ile iç içe öyle bir girmiştir ki, elinize geçen son teknoloji ürünlerinin hemen hepsinde bir yazılım koşmaktadır. Kısacası, bizde bu alanda çalışanlar olarak ‘bu işi daha verimli ve sistematik şekilde nasıl yapabiliriz?’ diye daha çok düşünmeye başladık. Size bir örnek vereyim. ‘Extreme Programming (XP)’ dediğimde, yazılım geliştirmeyle ilgileniyorsanız bunu bildik bir kelime olarak anımsayacaksınızdır. Hatta yazılım geliştirme hayat döngüsünün analiz ve tasarım safhaları size sadece sıkıcı dokümantasyon işlerini hatırlatıyorsa, mutlaka kısaca XP olarak adlandırılan bu yöntemi araştırmışsınızdır. Ben size bu yöntemin temel aktivitelerinden bu yazıda bahsetmeyeceğim. Siz zaten bu bilgilere internette yapacağınız küçük bir araştırma sonucunda rahatlıkla ulaşabilirsiniz. Ben daha çok bu yöntemi de içeren bir üst yapıdan, yani Atik Yazılım Geliştirme (Agile Software Development) yaklaşımından bahsetmek istiyorum.

Atik yaklaşımın resmiyet kazanmasının ilginç bir öyküsü var, 2001 senesinde bir manifesto ile hayat buldu. 11-13 Şubat tarihleri arasında Utah’ta yazılım mühendisliği alanında ciddi şekilde kafa yoran 17 uzmanın buluşmasının sonucunda ortaya çıkan bir metin tüm dünyaya internet üzerinden yayınlandı. Bu metini kısaca özetlersek; yazılım geliştirmenin daha iyi yollarını bulmak için yaptıkları çalışmaların ortak alanında temel sayılacak bazı değerlere ulaştıklarını söylediler. Bireyler ve iletişime, süreçler ve araçlardan; çalışan yazılım ürününe, kapsamlı yapılmış dokümantasyondan; müşteri işbirliğine, sözleşme görüşmelerinden; değişime tepkiye, plan takibinden daha fazla değer verdiklerini ilan ettiler. Ayrıca 12 ortak prensibi de bu doğrultuda açıkladılar.

Bu 12 prensibe genel olarak baktığımızda ise; müşteri memnuniyetinin öne çıktığını, geliştirme sürecinin süresinin mümkün olduğunca kısaltılmaya çalışıldığını, daha dinamik bir süreç yaşandığını ve ortaya son ürün olarak bir takım işi çıkarılma çabası içinde olunduğunu fark ediyorsunuz. Aslında bu özellikler hiçbir yazılım organizasyonunun hayır diyemeyeceği özellikler. Örnek olarak; müşteri tarafından yazılım gereklerinde yapılacak değişikliklere hangi organizasyon hızlı cevap verebilmek istemez ki?

Bu temeller etrafında bir araya gelebilen birçok yazılım geliştirme yöntemi vardır, bunların birçoğu 17 kişilik grupta yer alan uzmanlar tarafından şekillendirilmiştir. XP, SCRUM, Crystal, Feature-Driven ve bu günlerde tartışmaları yoğun bir şekilde devam eden BDD (Behaviour-Driven Development) yöntemleri atik yazılım geliştirme yaklaşımının yöntemlerinden bazıları ve en bilindikler arasında yer alanlardır. Ülkemizde de en çok ilgiyi çeken yöntem XP olarak göze çarpmaktadır. XP, Kent Back tarafından 1980’lerin sonlarında tasarlanmaya başlanmış ve ilk ciddi deneyimini 1996 yılında kazanmıştır. XP gelişimini hala sürdürmektedir. Yöntem kullanıcıları tarafından ve uygulamalardan gelen geri beslemeler ile geçtiğimiz sene güncellenmiştir. Dikkat çeken bir örnek olarak, ilk versiyonunda yer alan ve bireylere verilen değer temelinden yola çıkarak oluşturulan haftalık 40 saatlik çalışma sınırlaması, yenilenen versiyonda pratikler arasından çıkartılmıştır.

Genel olarak XP’nin geliştirme tarafında değil de yönetim tarafındaki pratiklerinde güncellemelere gidilmiştir. XP’nin bu öne çıkışıyla birlikte XP üzerinden atik geliştirme yaklaşımı da dünyada tartışılmış, ve tartışılmaya da devam etmektedir. Atik yazılım geliştirme yaklaşımı, sonuca yani son ürüne hızlı şekilde ulaşmayı vaat ettiği için ilgi görmekte, bununla birlikte süreç ve kalite alanlarındaki belirsizlikler bu yaklaşımın yumuşak karnı olarak dikkat çekmektedir. Planlama, proje takibi ve değerlendirme konularında ciddi tartışmalar devam etmektedir. Bu durum, atik yaklaşımın bir diğer adlandırılmasında kullanıldığı gibi ‘hafif’ (light) bir tasarım, hızlı ürün çıkarmak adına kullanılmayan destek süreçleri, son üründeki kabiliyetlerde eksiklik şüphelerini arttırmaktadır. Hali hazırda yoğun tartışmaların sürdüğü bu ortamda, organizasyonların çekinceleri bu yöntemlerde bahsedilen pratiklerinin uygulanabilirlikleri üzerine yoğunlaşmaktadır. Bu kadar çok yöntemin bulunduğu yaklaşım için organizasyonların eğilimlerinin, pratikler arasından kendileri için uygun gördüklerini belirleyerek hayata geçirme yönünde olduğu gözlenmektedir. Atik yaklaşımı destekleyenler yöntemlerini geleneksel yaklaşımla özellikle şelale yöntemi ile karşılaştırarak desteklemek eğilimdeler. Yazılım geliştirmede gelinen noktada hiçbir organizasyonun şelale yöntemini savunması pek mümkün gözükmemektedir.

Zaten geleneksel yaklaşımcılar karşı karşıya kaldıkları sorunların üstesinden gelebilmek amacı ile çeşitli çıkış yolları üretmektedirler. Bence, atik yaklaşım işte bu aranan çözüm yollarının bulunabileceği yöntemlere sahip. Uzun lafın özeti, şu anda benim için en doğrusu, atik ile klasik yaklaşımlar arasındaki gri alanda atik yaklaşıma yakın durmak gibi gözüküyor.

Merak uyananlar için, atik manifestosunun yayınlandığı resmi internet sitesinin adresi: www.agilemanifesto.org, iyi kaynaklar olarak XP için www.xprogramming.com ve www.extremeprogramming.org, SCRUM için ise www.controlchaos.com adreslerini ziyaret etmenizi öneririm.

En iyi dileklerimle,