Kurumsal veya kişisel anlamda bir proje geliştirirken belli süreçlerden yararlanırız. Bu süreçler geliştirdiğimiz projenin ihtiyaçlarına doğru bir şekilde yanıt verebilmelidir. Aynı şekilde bir yazılım projesi üzerinde çalışırken belli bir yaklaşımı benimser ve onun yolundan gitmeye çalışırız. Bu bize zaman, maliyet ve risk yönetimini daha akıllıca yapma imkanı sağlar. Yazılım projelerinde, bir yazılım yaşam döngüsünü açıklayan modellere yazılım geliştirme yaşam döngüsü (software development life cycle, SDLC) modelleri adı verilir. Bu modellerin hepsi genel olarak aşağıdaki resimde gördüğünüz aşamalardan meydana gelmektedir:
Gördüğünüz gibi genel olarak bu döngü 6 aşamadan meydana gelmektedir. Bu yazıda bu aşamalara girmeyeceğim. Çünkü bizim işimiz şu an o kısımda değil. Bunun bir döngü olmasının sebebi, yazılımların sürekli güncellemeye ve geliştirmeye ihtiyaç duymasıdır. Örneğin Andorid işletim sistemine sahip akıllı telefon kullanan herkes bilir ki Google Play Store’da her geçen gün telefondaki uygulamalarınıza güncelleme gelmektedir. Bunların çoğunun açıklamasına baktığınızda, uygulamalardaki hataların giderilmesi ile ilgili olduğunu görürsünüz. İşte yazılım dediğimiz şey zamanla kendini düzeltmeli ve geliştirmelidir. Bunu yapmayan yazılımlar gelişimin gerisinde kalıp kullanıcı kaybederler.
Az önce söylediğim SDLC modelleri de bu anlayış üzerine kurulmuş modellerdir. Klasik SDLC modellerinde genellikle bu 6 aşama birer birer takip edilerek sonuca ulaşılır. Örneğin planlama (planning) aşamasını bitirmeden analiz(analysis) veya tasarım (design) aşamasına geçemezsiniz. Bunun anlamı nedir? Yani şöyle bir örnek vereyim: Bir yazılım geliştirmek için plan yapıyorsunuz ve o yazılımın özelliklerini, maliyetini, kitlesini, kısacası her şeyini baştan düşünmek ve buna göre plan yapmak zorundasınız. Bunları bir dokümanda belirttikten sonra bu plan üzerinden diğer aşamaları gerçekleştirmelisiniz.
Bir projede yapacağını her şeyi baştan belirlemek ve buna uygun hareket etmek güzeldir. Fakat diyelim ki bu projenin yapımı 2 yıl sürdü. 2 yılda birçok teknoloji, insanların ihtiyaçları, pazar vs. değişir. Siz projenizi yaptığınız ilk baştaki plana göre çıkardığınızda, insanların artık ona ilgisi kalmayabilir. Geriye adım atabileceğiniz SDLC modelleri de var elbette… Fakat bunlarda da bazı problemler vardır. Örneğin siz bir programın tasarımını yaptınız ve analizini değiştirmek istiyorsunuz. Bu durumda yaptığınız tasarım çöpe gidecek ve yeni analize göre bir tasarım yapmak zorunda kalacaksınız. Bunun gibi problemler çok dinamik bir sektör olan yazılım sektöründe birçok soruna yol açmaktadır.
Bu problemlerin üstünde bir yazılımcı grubu bir süre kafa yordu. Aslında bazı firmaların proje geliştirme metodlarına baktıklarında, kendilerini yeniliklere çok çabuk adapte edebildiklerini fark ettiler. Daha sonra bunu yazılım alanında da uygulayıp uygulamayacakları hakkında düşündüler. Bu düşünce ile toplanan profesyonel 17 yazılım geliştirici, 2001 yılında 4 ana maddeden ve 12 prensipten meydana gelen "Agile Manifestosu"nu yayınladı. Bu manifestonun 4 temel maddesi şunlardı:
- Bireyler ve etkileşimler, süreçler ve araçlardan önce gelir.
- Çalışan yazılım, kapsamlı dokümantasyondan önce gelir.
- Müşteri ile işbirliği, kesin kurallara sahip sözleşmelerden önce gelir.
- Değişikliklere anında uyum sağlamak ve yanıt vermek, belirli bir planı takip etmekten önce gelir.
Manifestonun 12 prensibini ise "agilemanifesto.org" adresindeki Trükçe çeviriden aynen paylaşıyorum:
- En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.
- 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.
- Ç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.
- İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.
- 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.
- Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze iletişimdir.
- Çalışan yazılım ilerlemenin birincil ölçüsüdür.
- Ç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.
- Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.
- Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.
- En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.
- 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.
Bu maddelerden yola çıkarak oluşturduğumuz yazılım projelerini Agile (Çevik) Yaklaşım kullanarak geliştirmiş oluruz. Gördüğünüz gibi bu bir SDLC modeli değildir. Yani Agile kendi başına bir şey ifade etmez. Bu yaklaşımı kullanarak hazırlanan yazılım geliştirme modelleri bulunmaktadır. Bu modellerin ayrıntılarına girmeden, sadece isimlerini vermek istiyorum:
- Scrum
- Kanban
- Lean
- Extreme Programming (XP)
- Crystal
- Test-Driven Development
- Feature-Driven Development (FDD)
Bu modellerden en çok kullanılanı Scrum’dır. Bununla ilgili ayrıntılı olarak başka yazılarda konuşacağım. Şu an burada Agile yaklaşımın ne olduğundan ve hangi prensiblere dayandığından bahsettik. Şimdi de biraz yanlış anlaşılmalar üzerinde konuşalım. Agile yaklaşımını ilk duyan şirketlerin ilk korkusu, standart yaklaşımlardan çok farklı olduğu için onu bünyelerine adapte edemeyecekleridir. Fakat bunun aksine Agile, şirket üretimini artırmak ve kolay yönetimi sağlamak için oluşturulmuş bir yaklaşımdır.
Agile’ın kısıtlı bütçeye sahip projelerde kullanılamayacağı düşüncesi de bir yanlış anlaşılmadır. Gayet dinamik bir şekilde bütçe yönetimi yapılabilir. Aynı zamanda Agile’ın tahmin edilemezliği (her şeyin baştan belli olmaması) büyük bir problem olarak görülür. Halbuki yazılım projeleri genellikle tahmin edilemez projelerdir. İleride ne olacağını ve ne gibi sıkıntıların çıktığını müşterilerin geri dönüşleri belirler. Agile yaklaşım, müşterilere hızlı bir şekilde prototip göstermeyi amaçladığı için, yazılım geliştiricileri ile müşterilerin arasını sürekli sıkı tutar.
Sonuç olarak Agile yaklaşımı, müşterilerin ihtiyaçlarına hızlıca yanıt verilmesinin gerektiğini savunan bir yaklaşımdır. Peki bunu somut olarak nasıl yapar derseniz, yukarıda isimlerini verdiğim Agile yaklaşımını kullanan SDLC modellerini araştırabilirsiniz. Gerçekten harika bir mekanizmaya sahip olan Scrum modelini özellikle incelemenizi tavsiye ediyorum. Bu model Agile yaklaşıma sahip olan modeller arasıdaki en popüler ve en sık kullanılan modellerden biridir. Ben de başka yazılarımda bu modeller ile ilgili ayrıntılar vermeyi düşünüyorum.
Eline sağlık kardeşim, gayet açıklayıcı bir içerik olmuş. Daha detaylı ve kapsamlı bilgiye ulaşabilmemiz için referans vermen çok yerinde olmuş. Sonraki yazılarını sabırsızlıkla bekliyorum.
Eyvallah kardeşim… Desteklerinizi esirgemediğiniz için teşekkür ederim…