Agile(Çevik) Modelleme ve Çevik Yazılım Geliştirme
Çevik modelleme (agile methods, yazılım sistemlerini etkili ve verimli bir şekilde modellemeye ve dokümantasyonunu yapmaya yönelik pratiğe dayalı yöntemlere verilen genel addır. Yazılım geliştirme amacıyla üretilen bu modelleme biçimi, kapsadığı değerler, prensipler ve pratikler sayesinde geleneksel modellemelere metotlarına göre yazılımlara daha esnek ve kullanışlı biçimde uygulanabilir.
Çevik modellemenin başlıca özelliği veri modelleri ve ara yüzü modelleri gibi modelleme tekniklerinin neler olduğunu ve bunların ayrıntılarını söylemek yerine bu tekniklerin nasıl uygulanması gerektiğini söylemesidir. Mesela; yapılan projelerin test edilmesi gerektiğini belirtse bile nasıl test hazırlanacağına değinmemesi gibi. O sadece bir yöntemler biçimidir ve bir projenin etkili,hızlı bir şekilde ortaya çıkarılmasında, müşterinin ihtiyaçlarını karşılamasında ve aynı zamanda da her türlü değişikliğe kolayca adapte olabilmesinde geliştiricilere yol gösterir.
Ayrıca Hızlı bir geliştirme sürecine sahip, kaliteli ürünlerin ortaya çıkması için uygulanan bir geliştirme yöntemidir. Agile geliştirme yöntemlerinde en önemli sonuç kriteri müşteri memnuniyetidir. Asıl amaç müşteriyi memnun eden bir ürün ortaya koyabilmektir. Ortaya çıkan ürünün çalışan ve müşterinin ihtiyaçlarını tam olarak karşılayabilen bir ürün olması en temel amaçlardan biridir.
Hangi Durumlarda Kullanılabilir?Bu metotların kullanılmasının en uygun olduğu durumlar şunlardır:
•Projenin yazılım evresinde müşteriden gelebilecek talep değişikliklerinin tahmin edilemez olması
•Projenin parçalarının önce tasarlanıp ardından hemen geliştirilmesinin gerekmesi ve önceden ne yapılacağını, detaylı yol haritasını ve tasarımını tahmin etmenin çok güç olması
•Analiz, tasarım ve test etme süreçlerinin ne kadar zaman alacağının önceden bilinememesi
•Yazılım ekibinin birlikte çalışmak, hiyerarşiye önem vermemek, sağlam iletişim kurmak gibi özelliklere sahip olması
Elbette bazı durumlarda çevik programlamadan vazgeçilmesi gerekebilir. Örneğin; çok kişinin dahil olduğu projelerde çevik metotlar ile proje geliştirmek mümkün olmayabilir ya da aynı yerde bulunmayan takım arkadaşları ve hiyerarşik yapının her an hakim olduğu şirket ortamlarında klasik yöntemler daha uygun olabilir. Zaten, düşünülenin aksine, bu metotları kullanarak programlama ve modelleme yapılmasını öneren insanlar bu gibi durumlarda klasik yöntemlerin kullanılmasına karşı değildir.
Çevik programlama metotlarının özellikleri:
Çevik metotlar tam bir yazılım süreci değildir ama kapsamlı yazılım geliştirme yöntemlerini tamamlayıcı niteliktedir. Başlıca çevik süreç modelleri:
•Sınırsal programlama(Extreme Programming-XP)
•Çevik Birleştirilmiş Süreç (Agile Unified Process)
•Scrum
•Test Güdümlü Geliştirme (Test-driven Development)
•Çevik bilgi Metodu (Agile Data Method)
•Özellik güdümlü geliştirme (Feature-Driven Programming)
Çevik (Agile) Programlama Süreci
Çevik yazılım geliştirme, takım çalışmasını desteleyen liderlik vasıflarını, sorumluluk alabilme ve kendi kendini organize edebilme özelliklerini ve nitelikli ve yeterince hızlı yazılım geliştirmeye yarayan mühendislik uygulamalarını destekleyen proje yönetim sürecini kapsar. Bu yönetim süreci hem müşteri taleplerini hem de şirket amaçlarını düzenleyerek olumlu bir geliştirme ortamı ve yaklaşım sunar.
Çevik modelleme işleri kısa vadeli planlar ve küçük gelişmeler halinde yapmayı uygun görür. Kısa vadeli planlar yineleme (iteration) olarak bilinir. Her yineleme sürecinde belli bir takım yazılım ya da modelle üzerinde çalışır ve bu süreç planlama, talep analizi, tasarım, kodlama, birim testi ve kabul testi gibi süreçleri kapsar. Yineleme süreci değişikliklere uyum sağlamayı kolaylaştırırken genel riski de azaltır. Tek bir yineleme bir ürünü piyasaya sürmek için ona yeterli işlevsellik katmayabilir ancak amaç her yineleme sonunda en az sorunla çalışan mevcut bir sürüm elde edebilmektir. Bir ürünü sürüm olarak piyasaya sürmek ve yeni özellikler eklemek için birden çok yineleme gerekir.
Çevik programlama ve modellemede dokümantasyon da yapılır. Ancak dokümantasyon ürünün kullanılabilirliği ve verimliliğinin önüne geçmez. Aksine dokümantasyon sadece gerekli görülen yerlerde yapılır. IBM ’de çalışan ve aynı zamanda da “Effective Practices for Modeling and Documentation” kitabının yazarı olan scott ambler’e göre; geliştiricilerin tahtada yazıp çizdikleri modeller uzun uzadıya yazılan dokümanlardan daha kullanışlıdır ve insanların aylarca dokümantasyon yapmasının önlenmesi gerekmektedir.
Çevik projedeki takım yapısı çoğunlukla iş değişimine dayanan ve kendi kendini organize eden bir yapıdır. Firma içindeki hiyerarşik durumlar takım içinde göz ardı edilir ve çalışmalar bu şekilde yürütülür.
Bir çok projeden insanlar daha ilerideki işler için önceden çalışmaya başlarlar. Örneğin; gelecekte yapılacak işler için karmaşık altyapılar geliştirmek ve modelleme yapmak. Bu durum çok büyük bir zaman kaybına yok açar ki, taleplerde bir değişiklik olması durumunda bu çalışan insanlara fazladan emek ve iş gücü olarak geri döner. Çevik modeller ihtiyaç olmadan herhangi bir şeyin yapılmasına ve boşa zaman kaybedilmesine karşıdır.
Proje aşamasında test süreci, önemli bir yer kaplar. Tüm testlerin son ana bırakılması yanlış anlaşılmaların projeyi çok farklı yerlere götürmesine sebep olabilir. Henüz yapım aşamasındayken, yapılan kısmı farklı kişilerin test edip geri bildirimde bulunması, bu açıdan hayati bir süreçtir. Bu sayede yanlış henüz yeni yapılmışken tespit edilip ortadan kaldırılır. Çevik programlama ve modelleme geliştiricilerin her an yan yana bulunarak bu iletişimde olmasını ve aynı zamanda da müşteri ile iletişim içinde bulunmasını öngörerek bu sorunu aşar. Kabul testleri ise müşteri tarafından en son aşamada yapılacak testlerdir. Burada geri dönülen hatalar yeniden modellemeye aktarılabilir. Çevik modellemede en son yapılan değişiklikler bile olumlu karşılanır.
Agile Yazılım Geliştirme’de, takım çalışması,güven,iletişim gibi insanlar ile olan etkileşim çok önemli. Sürekli bilgi alışverişi ve beyin fırtınalarına dayanan bir geliştirme süreçi olduğundan bu kavramların bilincinde olmak geliştirme sürecine artılar katabiliyor. Geliştirme sırasında ya da öncesindeki analiz kısımlarında sürekli yüz yüze bir iletişim ile gereksinim ve ihtiyaçların sürekli üzerinden geçilmesi daha sağlıklı sonuca ulaşmak için kaçınılmaz ihtiyaç.
Agile yazılım geliştirme süreçlerinde her zaman çalışan bir yazılım aranan bir kavram. Zaten soyut kavramlardan oluşan yazılım dünyası, bu dünyaya uzak olan müşteri için pek bir şey ifade etmeyecektir. Bu yüzden bazı şeyleri biraz daha somutlaştırmak adına çalışan bir yazılım her zaman aranan bir kavramdır. Uygulamaların nasıl çalışacağına ya da ne yapacağına dair uzun ve karışık dökümanlardan çok müşteriye çalışan bir uygulama göstermek her zaman daha faydalı olacaktır.
Agile’ın altını çizdiği bir başka husus da müşteri ilişikileri.Belli bir sözleşme yerine sürekli müşteri ile işbirlik halinde olunmasının daha faydalı olacağı manifestoda söylenen diğer bir şey. Müşterinin ihtiyaçlarını sürekli sorgulamak ve işi onunla beraber yapmak ortaya çıkacak ürünün kalitesi adına önemli bir nokta. Bu noktada, ihtiyaçların sürekli sorgulanmasından dolayı da ortaya çıkacak değişiklik taleplerine de açık olmak gerekmekte.Bu değişikliklerin yönetilmesi sayesinde ürünlerin canlılığı ve tam olarak ihtiyaca uygun olması sağlanabiliniyor.
Tarihçe
Uygulanabilir bir yazılım geliştirme süreci ilk önce 1974 te Edmonds tarafından kaleme alınmıştır. Bundan sonra daha çok yeni bir yöntem olan çevik yazılım geliştirme ve modelleme 1990ların ortasında diğer (“heavyweight”) zor uygulanan, aşırı kuralcı waterfall model tipi geliştirmeye tepki olarak ortaya çıkmıştır. Bu tip bir gelişim modelinin usta yazılım geliştiricileri için fazlasıyla bürokratik, yavaş ve tutarsız olduğu düşünülmüştür. Bunun üzerine bu süreci hızlandırıp kolaylaştıracak çevik metotlar hafif metotlar -“lightweight methods” olarak ortaya çıkmıştır. Daha sonra 2001’de, yazılımın önde gelen isimleri Snowbird Utah’ta buluşarak bu metotlara çevik metotlar -“agile mehtods” – ismini vermişlerdir. Aynı kişiler “Agile Alliance” diye kar amacı gütmeyen ve bu sistemin gelişmesine destek veren bir organizasyon kurmuşlardır.
En önemli çevik programlama süreçleri Clear, Exreme Programming (XP-1996), uyarlanabilir yazılım geliştirme, özellik bazlı gelişim ve DSDM’dir (1995). Bunlar çevik yöntembilimleri olarak 2001’de yayınlanan Çevik Yazılım Yaklaşımı Manifestosu’nu yayımlamışladır.
Çevik program geliştirme alanındaki önde gelen 17 isim 2001 yılında Snowbird, Utah’ta buluşarak bir yazılımı nasıl daha hızlı, basit ve insan merkezli yaratabileceklerini tartışmışlar ve sonucunda imzaladıkları manifesto ile bu süreci anlatmışlardır. Bu manifestoyu imzalayanlar 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’tır.
Bundan sonra 2005 yılında ise Alistair Cockburn ve Jim Highsmith yönetim uzmanlarını toplayarak bu manifestoya bir ek yazmıştır. PM Decleration of Interdependence adı verilen bu manifesto 6 madde ile Çevik Yazılım Yaklaşımı Manifestosu’nu günümüze daha iyi uyarlanabilir hale getirmişlerdir.
Çevik Metotların Prensipleri:
Yukarıda isimleri geçen topluluk, manifestoda, nasıl daha iyi bir yazılım geliştirdiklerini ve bunu yapmak isteyenlere yol gösterecek maddeler listelemişlerdir. Genel olarak kabul edilen yöntem 4 maddede sıralanabilir:
•Bireyler ve onlar arasındaki etkileşimi süreç ve araca tercih etmek
•Çalışan bir yazılımı detaylı bir dokümantasyona tercih etmek
•Müşteri ile işbirliğini, anlaşma görüşmelerine tercih etmek
•Değişikliklere istenildiği anda cevap verebilmeyi sınırları belirli bir plana tercih etmek
Agile manifestosunun ardındaki başlıca ilkeler ise:
•Hızlı, devamlı ve kullanışlı yazılım üreterek müşteri memnuniyeti sağlamak amaçlardandır.
•Çalışan yazılım gelişimin en önemli ölçüsüdür.
•Taleplerdeki geç değişikliklerin de memnuniyetle karşılanır.
•Yüz yüze görüşme iletişimin en güzel yoludur.
•Geliştiriciler ile iş adamları arasında günlük ve yakın işbirliği bulunmalıdır
•Basitlik önemlidir. (Yada sadellik güzelliktir)
•Kendi kendini organize eden takım yapısı gereklidir.
Çevik Metotların Diğer Metotlardan Farkı:
Çevik metotlar bazen planlı ve disiplinli olmaması ile eleştirilse de bu doğru değildir. Açıklamak gerekirse; bir projenin ortaya çıkarılmasında 2 tip metot kullanılabilir. Biri uyarlanabilir olan, bir diğeri de tahmin edilebilir olandır. Değişime tepki verebilecek şekilde tasarlanmıştır. Mesela, projenin gereksinimleri değişirse, projenin takımı da bu değişikliğe ayak uydurur ve değişir. Bu takım bize 1 hafta sonra hangi işlerin yapılacağını söyleyebilir ancak 1 ay sonra ne yapacaklarını belirtemez. Yani projede planlanan tarih ne kadar uzaksa o tarihte yapılacak işler de bir o kadar belirsizdir. Tahmin edilebilir olan metotların takımları projenin tamamlanma süresi içindeki tüm değişikliklerin ve gelişmelerin tarihini önceden bilir, bu plan çerçevesinde iş yapar. Değişiklik olduğunda tüm plan iptal olur ve yeni bir program yapılır. Yeni programda ise sadece en önemli olan değişikler seçilip projeye dahil edilir. Çevik metotlar uyarlanabilir olanlara dahildir. Yani değişime açıktır ve uyarlanabilirdir. Uyarlanabilir olduğu için bu kadar net bir şekilde planlanmayan proje müşterinin isteklerine göre şekil alır ve istenilen başarıyı gösterir.
Çevik metotların bir diğer özelliği de; diğer yinelemeli geliştirme metotlarında (iterative development methods) zaman dilimi ay olarak alınırken, çevik metotlarında bu süre haftaya kadar düşer. Bu kısa süre içinde küçük ilerlemeler şeklinde ve her adımda müşteriden geri bildirim alınarak yazılım ortaya çıkarılır.
Günümüzde kullanılan bir diğer model de Waterfall modelidir. Waterfall modeli 2008 yılında dahi geçerliliğini koruyan bir modeldir ve çevik modellemeden farklılık gösterir. Bu model yazılım projesini baştan sona planlar. Gelişim ise sunulabilir işler açısından ölçülür: talep açıklamaları,tasarım dokümanları, test planları, kod incelemeleri vb. Bu durum belli aralıklara bölünmeye uygun değildir ve ilerideki değişikliklere uyum gösterilemez. Ancak çevik metotlar ise her şeyi küçük parçalar halinde yapıp haftalık olarak sunar ve gerekirse o parça üzerinde gerekli değişiklikleri rahatlıkla uygular.
Cowboy coding’in çevik modellemeden farkı metottan yoksun olmasıdır. Proje takımındakiler kendilerine nasıl uygun gelirse o şekilde çalışırlar. Çevik programlamada yüz yüze görüşme ve her an iletişimde olmak ön plandadır. Ayrıca önceden belirlenmiş kısa bir süreç içinde çalışmalar yürütülür.
Sonuç olarak; bugün yazılım ve teknoloji dünyası büyük bir hızla gelişmekte ve yeni sistemler yeni talepler ortaya çıktıkça aynı zamanda yeni modellemelere de gereksinim duyulmaktadır. Bunun en açık göstergesi ise bilişim projelerinin ortalama 1 yılda bitiriliyor olmasıdır. Artık projelerin daha etkin ve hızlı bir şekilde bitirilmesi beklenmektedir. Bu amaca yönelik olarak ortaya çıkan çevik programlama modelleri modelleme ve programlama konusunda geliştiricilere yol göstermekte ve alternatif bir model oluşturmaktadır.
Kaynaklar
http://jamshidhashimi.com/2010/08/23/agilecevik-modelleme-ve-cevik-yazilim-gelistirme
http://en.wikipedia.org/wiki/Agile_Modeling
http://en.wikipedia.org/wiki/Agile_software_development
http://e-bergi.com/2008/Ekim/Cevik-Modelleme-ve-Cevik-Yazilim-Gelistirme
http://www.minepla.net/2008/10/agilecevik-yazylym-gelithtirme
