Yazan : Şadi Evren ŞEKER

Çevik yazılım çok daha önceleri literatürde olmasına karşılık esas yükselişini 2001 yılındaki 17 yazılımcının yayınladığı manifesto ile yapmıştır. Bu manifesto aşağıdaki şekilde tercüme edilebilir [1]:

1. Bireyler ve ilişkiler , süreçler ve araçlardan önemlidir
2. Çalışan bir yazılım, detaylı bir dokümandan önemlidir
3. Müşteri katkısı, kontrat görüşmelerinden önemlidir
4. Değişime cevap verebilmek, bir plana bağlı kalmaktan önemlidir

Yukarıdaki 4 maddeyi aşağıdaki şekilde yorumlamak mümkündür [2]:

1. Çevik geliştirmede kendi kendine yönetme yeteneği olan organizasyonların ve motivasyonların daha önemli olduğundan bahsedilebilir. Bu tip organizasyonel yönetim stratejileri, eş konumlama ve çift programlama gibi kavramları doğurmuştur.
2. Çoğu zaman, çalışan bir yazılım, müşteriler için de daha önemlidir. Müşterilere hatanın nereden kaynaklandığını, çok iyi hazırlanmış dokümanları veya müşteri ile olan toplantıları mükemmel şekilde yönetmek ve sonunda çalışmayan bir yazılım sunmaktansa çalışan bir yazılım her zaman için daha iyi karşılanacaktır.
3. Müşterilerin projelere dahil olması ise her zaman için en önemli şartlardan birisi olarak görülmüştür. Çoğu zaman müşterilerin ihtiyaçları belirlemede veya ne istediklerini bile bilmede problemleri olmaktadır. Dolayısıyla sürekli olarak müşterilerin ve paydaşların sürece dahil olduğu bir model daha tercih edilebilirdir.
4. Değişime cevap verebilmek ise çevik geliştirmenin sürekli ve hızlı cevap vermeye odaklanması olarak yorumlanabilir.

Çevik Prensipleri

Manifestonun ilanından sonra çevik yazılım geliştirme yöntemi ilerleme göstermiş ve yeni özellikler kazanmıştır. Bu gelişmiş prensipler güncel olarak 12 temel üzerine kuruludur ve bunlar aşağıdaki şekilde sıralanabilir [3]:

1. Müşteri memnuniyeti için kullanışlı bir yazılımın hızlıca geliştirilmesi
2. Değişiklik isteklerine açık olma (geç geliştirme aşamasında olunsa bile)
3. Çalışan bir yazılımın sürekli olarak teslim edilmesi (aylar süresinde teslimlerden se haftalar süresinde teslimlerin hedeflenmesi)
4. İş süreçlerindeki kişiler ile geliştirme sürecindeki kişiler arasında günlük bazda yakın ilişkinin kurulması
5. Projelerin güvenilir ve motive olmuş kişiler tarafından geliştirilmesi
6. Yüz yüze görüşmelerin tercih edilmesi
7. Sürecin ölçülmesinde çalışan bir yazılımın ana unsur olarak kabul edilmesi
8. Sürdürülebilir geliştirmenin sürekli sürece destek vermesi
9. Sürekli olarak teknik iyileştirmeye ve iyi tasarıma odaklanma avantajı
10. Basitlik
11. Değişen durumlara sürekli uyum sağlama avantajı
12. Projenin yanında geliştirme ekibinin de sürekli uyum sağlayan yapıda olması

Tarihsel Gelişimi

Tarihsel süreçte, çevik yazılım yaklaşımını, arttırımlı yazılım yaklaşımı (incremental software development) olarak ele alabiliriz. Bu yaklaşımda, bir yazılımın çalışması için gereken asgari özellikler tesis edildikten sonra, istenen her özellik zaman içerisinde bir arttırım (ilave) olarak ele alınır ve yazılıma eklenir. M. Weinberg 2003 yılında yayınlanan bir çalışmasında, bu konudaki ilk uygulamaları araştırmış ve 1957 yılında benzer uygulamalar olduğunu görmüştür [4]. E. A. Edmonds, Los Angeles, IBM’deki çalışma yaklaşımlarını arttırımlı yazılım olarak tanımlamaktadır. Kendisi de daha sonraları 1974 yılında uyumlu sistemler için yazılım geliştirme (A Process for the Development of Software for Nontechnical Users as an Adaptive System) başlıklı bir makale yayınlamıştır [5].

1990’lı yıllara gelindiğinde özellikle 90’ların ortasında çok sayıda çevik yazılıma öncü olarak kabul edilebilecek yaklaşımdan bahsetmek mümkündür. Bunlar tarihsel süreçte aşağıdaki şekilde sıralanabilir:

1994 Akılcı Birleştirilmiş Süreç (Rational Unified Process)

1995 Scrum

1995 Dinamik Sistemler Geliştirme Metodu (Dynamic Systems Development Method, DSDM)

1995 Crystal Clear

1996 Uç Programlama (Extreme Programming)

1997 Uyumlu Yazılım Geliştirme (Adaptive Software Development)

1997 Özellik Güdümlü Geliştirme (Feature Driven Development)

Yukarıdaki listeye çok sayıda farklı yaklaşımın da eklenmesi mümkündür. Bu yaklaşımların genel olarak çıkmasının ana sebebi, şelale modeline karşı yükselen eleştirilerdir.

Çevik Yazılımın Felsefesi

Tarihsel süreçten de görüleceği üzere çevik yazılım geliştirme süreci, klasik yazılım geliştirme süreçlerine tepki olarak doğmuş ve yazılım geliştirme sürecine daha çok aşağıdaki felsefi yaklaşımları kazandırmıştır:

1. Yazılım geliştirmenin uyum (adaptive) / tahmin (predictive) ikileminde, uyuma yakın olması [6].
2. Yazılım geliştirmenin tekrarlı (iterative) / şelale (waterfall) ikileminde tekrarlıya yakın olması.
3. Kod ve doküman ikileminde ise koda yakın olması [7].

Eleştiriler

Çevik yazılım, yapısal olarak bir tepki şeklinde doğmuş olsa da kendisine karşı da zaman içerisinde gelişmiş eleştiriler bulunmaktadır. Öncelikle çevik yazılım geliştirmenin doğru alanda uygulanması büyük önem arz eder. Örneğin zaman içerisinde gelişme ihtiyacı duyan ve ardışık yapıda olmayan projeler için daha uygun olduğunu söylemek gerekir. Bu açıdan bakıldığında çoğu organizasyonda tam çevik yazılım geliştirme yaklaşımı yerine karma bir yaklaşım ile problemlere yaklaşıldığı söylenebilir [8].

Çevik yazılım ile ilgili bir eleştiri noktası, “çevik” kelimesinin doğru kullanılmadığı ile ilgilidir. Yazılım geliştirme süreçlerinin gelmiş olduğu noktadan bakıldığında geliştirme ile ilgili ulaşılan bütün iyi ve olumlu kazanımların tek bir “çevik” ismi altında toplanarak “her bedene tek ölçü” şeklinde bir yaklaşım geliştirildiği iddia edilmektedir.

Referanslar

[1] Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. Retrieved 14 June 2010.

[2] Jim Highsmith (2001). "History: The Agile Manifesto". agilemanifesto.org.

[3] Beck, Kent; et al. (2001). "Principles behind the Agile Manifesto". Agile Alliance. Archived from the original on 14 June 2010. Retrieved 6 June 2010.

[4] Gerald M. Weinberg, as quoted in Larman, Craig; Basili, Victor R. (June 2003). "Iterative and Incremental Development: A Brief History". Computer 36 (6): 47–56. doi:10.1109/MC.2003.1204375. ISSN 0018-9162.

[5] Edmonds, E. A. (1974). "A Process for the Development of Software for Nontechnical Users as an Adaptive System". General Systems 19: 215–18.

[6] Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 0-321-18612-5. Appendix A, pages 165–194

[7] Rakitin, Steven R. (2001). "Manifesto Elicits Cynicism: Reader's letter to the editor by Steven R. Rakitin". IEEE Computer 34: 4.

[8] Barlow, Jordan B.; Justin Scott Giboney; Mark Jeffery Keith; David W. Wilson; Ryan M. Schuetzler; Paul Benjamin Lowry; Anthony Vance (2011). "Overview and Guidance on Agile Development in Large Organizations". Communications of the Association for Information Systems 29 (1): 25–44.