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 |
James Grenning |
Robert C. Martin |
Ç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/
