Çevik(Agile) Yazılım Geliştirme Metodolojileri

         Agile Software Development(Çevik yazılım geliştirme), yazılım geliştirme süreçleri içerisinde(SDLC-Software Development Life Cycle) kabul edilen etkin bir yazılım geliştirme metodoloji türüdür. En iyi yazılım ürününü, en hızlı, en güvenli, yazılım geliştirme paradigmalarına en uygun olarak geliştirmek, SDLC nin ilk zamanlarından itibaren ortaya çıkan, şekillenen bir sorun olmuştur. Buna çözüm olarak, Waterfall, Spriral, … ve son olarak Çevik yazılım geliştirme methodolojisi 2000 li yılların başlarında bir grup software development influencer tarafından duyurulmuştur.  2001 yılında Utah, Snowbird'deki bir kayak merkezinde 17 kişilik software development influencer kendi aralarında çevik yazılım geliştirme yaklaşımları üzerinde hem fikir olup, çevik yazılım geliştirme manifestosu yayınlamışlardır(http://agilemanifesto.org). Ayrıca imzaladıkları manifestoyu, kendileri ile aynı fikirde olup imzalamak isteyenlere de açmışlardır(http://agilemanifesto.org/display/index.html).

Bu manifesto da;

Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
Kapsamlı dökümantasyondan ziyade çalışan yazılıma
Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine
Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye

            değer verdiklerini, çevik yazılım geliştirebilme açısından sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulduklarını ifade etmişlerdir.

Manifestonun detayında ise; 12 temel prensibi(http://agilemanifesto.org/principles.html) benimsemişler ve bunları da kayıt altına alıp imzalamışlardır. Bu prensipler;

1) En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.

2) 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.

3) Ç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.

4) İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.

5) 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.

6) Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze iletişimdir.

7) Çalışan yazılım ilerlemenin birincil ölçüsüdür.

8) Ç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.

9) Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.

10) Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.

11) En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.

12) 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.

Manifestoyu ilk imzalayanlar(http://agilemanifesto.org/authors.html);

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

            Çevik Yazılım Geliştirme Manifestosu ve arkasındaki 12 ilkede ifade edilen değerleri uygulayan şirket, kurum veya organizasyonlar kendilerine özgün uygulama şekillerine göre bu metodolojiden avantaj sağlarlar. Tabiiki dezavantajlı durumlar da söz konusudur. Bu metodolojinin; 

Avantajları;

·         Kısa planlanmış döngüler, değişen gereksinimler ve ani ortaya çıkabilecek değişiklikler için agile metodoloji, kullanan organizasyonlara esneklik imkânı sağlar.

·         Nihai hedefin açıkça tanımlanmadığı yazılım projeleri için faydalıdır. Yazılım projesi ilerledikçe hedefler ortaya çıkacak ve yazılım ürünü bu gelişen gereksinimlere kolayca adapte olabilecektir.

·         Müşterilerin yada proje sahiplerinin ürünlerini oluşturmak ve bu ürünlerle ilgili çıkan problemleri kolayca çözebilmek için müşteri yada proje sahiplerinden aktif bir şekilde geribildirim alınabilmesini sağlar.

·         Ekip katılımına öncelik verilerek kurulan iletişim sayesinde yazılımsal sorunların daha hızlı ve etkin çözülmesini sağlar.

·         Yazılım projeleri hızla ilerlerken ortaya çıkan her problem, bir sonraki döngüde daha iyi bir çözüm için önceki döngüleri basamak olarak kullanabilir. Her yineleme (sprint) sırasında test yapmak, hataların daha hızlı tanımlanmasına ve çözülmesine katkı sağlar. Yazılım projeleri; bu yöntem ile daha tutarlı ve art arda yinelenen adımlarla daha hızlı yazılım ürününü ortaya çıkartabilmeyi sağlar.

·         Müşterilerin, teslim edilen işi görmeleri, girdilerini paylaşmaları ve son ürün üzerinde daha etkili olabilmeleri için çok fazla fırsatları vardır. Müşteriler, yazılım proje ekibiyle çok yakın çalıştıklarından yazılım ürününe olan sahiplik duyguları ve motivasyonları da daha fazladır.

Dezavantajları;

·         Ürün gereksinimleri sürekli değişebileceğinden maliyetler peşinen tahmin edilemez.

·         Müşteriler geri bildirim vermek istediklerinde, akıllarına gelebilecek yeni istekler ek fazları ortaya çıkarır. Agile software development, belirli süreli yinelemeli çıktılara dayalı olduğundan ve proje yöneticileri genellikle görevleri tekrarlamakta olduğundan, başlangıçta teslimat için planlanan bazı öğelerin zamanında tamamlanamaması olasıdır. Yani, projenin herhangi bir anında yeni bir sprint eklenebilir. Bu gibi durumlarda yazılım projelerinin maliyetlerinin artması ve belirlenen bitirme sürelerinin uzaması söz konusudur.

·         Müşterilerden, proje sahiplerinden sürekli geri bildirim almak çalışma ekiplerini alaşağı edebilir ya da bazı müşterilerin zamanı ve hiç ilgisi olmayabilir.

·         Yazılım projelerinin başarısı için gerekli olan dökümantasyon ihmal edilebilir; Agile Manifesto, kapsamlı bir dokümantasyon yerine çalışan yazılımı tercih eder, bu nedenle bazı ekip üyeleri, dokümantasyona odaklanmayı daha az önemli gibi hissedebilirler. Kapsamlı dokümantasyon, proje başarısına yol açmamakla birlikte, çevik takımlar dokümantasyon ve çalışan yazılım arasındaki doğru dengeyi mutlaka bulmalıdırlar. Yani dökümantasyonu olmayan yazılım kaliteli yazılım değildir. Dökümantasyon ile ilgili çok detaylı kapsamdan uzaklaşmak başarıyı artırır önerisi vardır.(“Büyük harita” deyimi)

·         Çevik yazılım projeleri ilk başlarda kesin bir plana sahip olmayabilir, bu nedenle nihai ürün başlangıçta tasarlanandan çok farklı görünebilir. Agile software development çok esnek olduğu için, değişen müşteri geri bildirimlerine dayanarak yeni iterasyonlar eklenebilir. Bu da çok farklı bir hedefe gitmeye yol açabilir. Yazılım projesinin başında hedeflenmiş olan ürün ile proje bitiminde sonuçlanan ürün arasında çok fark olması, müşterileri ve proje sahiplerini olumsuz etkileyebilmektedir.

·         Agile metodolojisini; müşteri ile iletişimi zor olan büyük kurumsal yapılarda uygulamak zor olabilir. Bunun için Agile dönüşüm danışmanlığı veren firmalardan destek alınması yada şirket, kurum yada organizasyon içerisinde bir birim kurup ilgili yetkin personelleri istihdam etmek gerekebilir.

·         Agile methodolojisini uygulamak tek başına yazılım ekiplerinin, sadece bir takımın yada bir kişinin uygulayabileceği bir pratik değildir. Eğer müşteri ile beraber organizasyondaki yönetim, alt yönetim ekipleri ve yazılım geliştirme ekipleri ile birlikte çevik yazılım geliştirme metodolojisi uygulanamazsa yazılım projelerinin çevikliğinden bahsetmek söz konusu olamaz. Yani bu durumda SDLC süreci daha da hantallaştırılmış olur.

Sonuç : Agile metodolojiler 2001 yılında fiilen duyurulmuş olsada, bu ilk başlangıç adımı olarak nitelendirilmiştir. Agile manifesto sunu imzalayanlar “Agile Alliance(çevik ittifak)” isminde bir gönüllü topluluk da oluşturmuşlardır(www.agilealliance.org). “Manifesto for Agile Software Development'ın” orijinal yazarları; “Agile Manifesto'yu yazarak ve Agile Alliance'ı başlatarak Agile yazılım geliştirme gemisini inşa edip denize bıraktıklarını, ancak geminin yelken açmasına ve çevik gelişim liderliğinin bu geminin çok ötesine yayılmasına izin vermekten mutlu olduklarını” ifade etmişlerdir.

Çevik yazılım geliştirme frameworkleri ve yöntemleri olarak; Extremming Programming, Lean Software Development(LSD), Feature-Driven Development(FDD), Adaptive System Development(ASD), Dynamic Systems Development Method(DSDM), Cristal Clear, Test-Driven Development, Rapid Application Development, Emprical Control Method, Scrum, Kanban, Scrumban, … gibi framework ve yöntemler günümüzde tercih edilmektedir. Ancak çeviklik yaklaşımında öyle bir açık kapı ifadesi bırakılmıştır ki her yazılım geliştirme ekibine göre özgün olarak uygulama pratiği söz konusudur. Bu yüzden çevik yazılım geliştirme frameworkleri ve yöntemleri her geçen gün çeşitlenmeye devam etmektedir. Cevik yazılım geliştirme prensiplerinin bir adım ötesini arama çabası olarak, “çıtayı yükseltmek” mottosuyla, 2009 yılında “Software Craftsmanship manifestosu(https://manifesto.softwarecraftsmanship.org/)” bir grup developer community tarafından duyurulmuş ve imzaya açılmış bulunmaktadır. Dolayısıyla, çeviklik metodolojisinin yeni implementation(uyarlama)ları ilerleyen zaman içinde daha da gelişip çeşitlenmeye, evrim geçirmeye devam edecek gibi gözükmektedir.

Not: Çevik yazılım geliştirme metodolojisi ile ilgili, literaturde olan yayınlanmış kaynakları tarayarak bu notları yazmış bulunmaktayım. Özellikle avantaj ve dezavantajlar somut tecrübe isteyen yorumlar olacağından, deneyim ve gözlemlerime göre makaleyi güncellemeyi planlamaktayım.

Kaynaklar:

• https://www.pem360.com/blog/Agile/Agile-Yontemlerin-Avantajlari-ve-Dezavantajlari/183
• http://agilemanifesto.org
• http://agilemanifesto.org/iso/tr/principles.html
• http://manifesto.softwarecraftsmanship.org/#/tr
• https://www.bukrek.com/artilari-ve-eksileri-ile-agile-yontemler
• https://www.agilealliance.org/agile101/
• https://www.agilealliance.org/the-alliance/
• https://www.acmagile.com/agile-nedir/
• https://www.acmagile.com/googlein-basarili-takimlarinin-sirri-psikolojik-guvenlik/