Çevik süreçler yukarıda sayılan öncelik ve prensipleri içeren manifestoyu kabul eden ve çalıĢma yöntemlerini çeviklik bakıĢ açısıyla oluĢturmuĢ süreçlerdir. Zaman içinde, bir meta model olarak kabul edebileceğimiz çevik süreci implemente eden değiĢik çevik süreç türleri oluĢmuĢtur. Bunların çoğu çevik manifestodan sonra oluĢmuĢtur. Ama bazıları çevik manifesto öncesi de mevcuttu ve kullanılmaktaydı. ġuanda yaygın olarak kullanılan en önemli çevik süreç türleri Ģunlardır:
Scrum
Scrum seksenli yıllarda Jeff Sutherland tarafından uygulanmıĢ ve Kent Schwaber ve tarafından da detaylandırılmıĢ bir çevik süreçtir[32]. Sutherland ve Schwaber daha sonra birlikte çalıĢmıĢ, Microsoft, Borland ve Hewlett-Packard’da oluĢan yöntemsel deneyimlerle birlikte endüstriyel kontrol yöntemlerini uygulayarak Scrum’ı yeniden ĢekillendirmiĢlerdir. Aslında Scrum, Rugby oyununda kullanılan bir terimdir. Oyuncular kısa bir süre için bir araya gelerek, bir sonraki oyun hamlesi hakkında fikir alıĢ veriĢinde bulunurlar, yani kısa bir toplantı yaparlar. Scrum daha çok proje yönetim ve planlama ile ilgili değerlere ve pratiklere konsantre olmaktadır. Yazılımın nasıl yapılması gerektiği hakkında detay ihtiva etmez. Bağımsız bir çevik yöntem olarak algılanmamalıdır. Birçok projede Scrum, Extreme Programming (XP) ya da Unified Process (UP) ile desteklenir[33].
Extreme Programming (XP)
XP, doksanlı yılların sonunda Kent Beck, Ron Jeffries ve Ward Cunningham tarafından[31] Chrysler için yapılan bir proje sonrasında oluĢmuĢ bir çevik süreçtir. XP Scrum’dan esinlenilerek geliĢtirilmiĢtir. Ama XP Scrum’ın aksine daha çok yazılım geliĢtirme pratiklerine konsantre olmaktadır. Bu sebepten dolayı Scrum ve XP projelerde birlikte kullanılabilir. Özellikle gereksinimlerin belirsiz, değiĢimin hızlı olduğu küçük ve orta büyüklükte yazılım geliĢtirme takımları için çözümler sunar. Ana amacı müĢterinin ihtiyaçlarını karĢılayan yüksek kalitede ürünü sağlayarak müĢterinin güveni kazanmaktır. Genellikle test pratikleri ile dikkat çeker. Test Güdümlü GeliĢtirme (Test Driven Development), Sürekli Entegrasyon (Continuous Integration), Otomatik Test (Test Automation) konusundaki uygulamalar XP’nin çığır açan pratikleridir. Bu pratiklerin çevik model karakterinde olmayan projelerde bile kullanılması yararlar getirecektir.
Agile Modeling (AM)
AM, yazılım sistemlerinin modelleme ve etkili dokümantasyon iĢlerini kolaylaĢtırmak üzere bu iĢleri iĢ ürünü olarak fazla dikkate almayan ve önemsemeyen diğer çevik yöntemleri tamamlayan bir yapıdır. Yazılım
mühendisleri tarafından uygulanacak bazı prensip ve değerlerin belirlediği pratikler kümesidir. Tamamen detaylandırılmıĢ özel bir süreç modelleme yöntemi tanımlamaz. Sadece modellemenin daha etkin olması için tavsiyelerde bulunur. AM gereksinimler, mimari ve tasarım modelleme iĢlerinde kullanılabilir [34].
IXP
XP’den doğan IXP’nin (Industrial XP5) amacı XP yi geliĢtirmek ve XP’de yer alan metot ve tekniklerin daha büyük organizasyonlar için adapte etmektir.
Evo
Tom Gilb tarafından oluĢturulmuĢ en eski çevik yöntemdir[35]. Gilb 1976’da yinelemeli geliĢtirme ve evrimsel yönetim konularıyla ilgilenmeye baĢladı ve 1981’de bu konuları detaylı inceleyen “Evolutionary Development(Evrimsel GeliĢtirme)” kitabını yayınladı. Doksanlarda Gilb kısaca “Evo” denilen ve XP, Scrum hatta UP gibi yöntemleri etkileyen bu çevik yöntemi geliĢtirmeye devam etti. Bugün bu modelin 5 ana elemanı vardır: hedefler, değerler ve maliyetler, çözümler, güçlü tahminler, evrimsel plan ve fonksiyonlar.
Dynamic Systems Development Model (DSDM)
Ġngiltere kaynaklı hızlı uygulama geliĢtirme(RAD) için geliĢtirilmiĢ bir çerçevedir[38]. XP, Scrum gibi süreçlerin iĢleyiĢi ile karĢılaĢtırıldığında daha fazla detay içerir ve genelde devlet ihaleleri gibi yazılım projelerinde sıklıkla kullanılır. Katı zaman kuralları gerektiren projelerde iĢ çözümleri sunar. XP, UP ya da diğer çevik yöntem kombinasyonları ile tamamlanabilir.
Crystal Metholodogies
Alistair Cockburn tarafından geliĢtirilmiĢ bir yöntemler topluluğudur[36]. Bu yöntemler yazılım geliĢtirme ile diğer mühendislik süreçleri arasında karĢılaĢtırma yaparak yazılımın özellikleri ve modelleri, tamamlanması, doğruluğu ve çalıĢması konularına yoğunlaĢır. Crystal Methodologies’de 4 farklı
ana yöntem vardır. Biri en fazla 8 kiĢilik takımlara uygulanabilen Crystal Clear’dir. CC en çok dokümante edilmiĢ Crystal yöntemidir. Sarı yöntem 8 ile 20, Turuncu yöntem 20 ile 50, Kırmızı yöntem ise 50 ile 100 kiĢi arasındaki takımlara uygulanır. Bu yöntemler kahverengi, mavi ve mor diye devam eder.
XP gibi süreçlere nazaran daha esnektir ve geliĢtirme pratikleri konusunda kısıtlar koymaz. Sabit fiyat (Fixed price) projeler ile ilgili çözümler sunar. Orta düzeyde kritik küçük projelerde kullanılabildiği gibi bazı eklemelerle kritik projelerde de uygulanabilir.
Feature Driven Development (FDD)
Jeff DeLuca tarafından doksanlı yılların sonunda geliĢtirilmiĢ bir çevik süreç türüdür. Diğer çevik yöntemlerden farklı olarak tüm yazılım hayat döngüsünü kapsamaz. Tasarım ve geliĢtirme bölümleri için çözümler sunar. FDD, yazılım özelliği (feature, function) güdümlü çalıĢır. Sisteme yeni bir özellik kazandırılmadan önce, detaylı bir tasarım çalıĢması yapılarak bu özelliği kapsayan mimari yapı oluĢturulur. Bu yüzden FDD daha çok tasarım odaklı iĢleyen bir çevik süreçtir. Alan modellemesi, yazılım özellikleri çevresinde ekiplerin oluĢturulması, tanımlı kilometre taĢları gibi daha detaylı çözümler içerir. Önemli kritik projelerde uygulanabilir[37].
Adaptive Software Development (ASD)
Büyük ve karmaĢık sistemlerin geliĢtirmesi konusunda oluĢan problemlere yoğunlaĢır. Bu artırımlı ve yinelemeli yöntem, prototip geliĢtirme Ģeklinde uygulanır.
Bu çevik yöntemlerden en yaygın kullanılanları birbirini tamamlayan Scrum ve XP’dir ve genelde de birlikte kullanılırlar.
4.BÖLÜM
SCRUM