6 Haziran 2014 Cuma

Çevik Yöntemleri Uygulayabilmek

Son yıllarda özellikle BT sektöründe çokça duyulan ve popüler olan terimlerden biri de çevik (agile) yöntemler. Çıkışı 1950'lere dayanan bu yaklaşım 1960'larda 1-2 haftalık iterasyonlar ve kısmi çözümlerle hızlı  sonuçlar alınması şeklinde uygulanıyor.  1980'lerde Scrum ortaya çıkıyor. Burada da rugby oyunundaki toplu hücum toplu savunmadan esinlenilerek toplucu tüm işin yapılması temel felsefeyi oluşturuyor. 1990'lara gelindiğinde XP (extreme programming, ilgili makale: XP Nedir?), DSDM (Dynamic Systems Development Method) ortaya çıkarak çeşitli yerlerde kullanılmaya başlıyor. 2001'e gelindiğinde ünlü Çevik Manifesto yayınlanıyor, özetle:
  • Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
  • Kapsamlı dökümantasyondan ziyade çalışan yazılıma
  • Sözleşme ve pazarlıklarından ziyade müşteri ile işbirliğine
  • Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye
önem verilmesi olarak belirtiliyor. Scrum, XP, DSDM, FDD (Feature Driven Development), Crystal, LSD (Lean Software Development) ve diğer çevik yöntemler detayda bazı farklılıklar gösterseler de genel olarak yukarıdaki manifestoya uygun yaklaşımlardır.  

Temel itibariyle tüm projelerde çevik yöntemler uygulanabilir. Yukarıdaki manifestoyu baz alarak yaklaştığınız sürece tüm projeleri çevik tipte ele alabilirsiniz. Projeleri birkaç haftalık iterasyonlar olarak küçük parçalara bölerek yönetirseniz ve iterasyon sürelerini sabit tutarsanız (time-boxing) çevik yaklaşımın temel prensiplerini kullanabilirsiniz. Peki nasıl uygulayabiliriz? Aklınıza gelen bazı temel engelleri ve bunlara çevik dünyanın verdiği yanıtları alttaki şekilde özetleyebiliriz:
Çevik yöntemlerde dokümantasyonu nasıl yaparım? İterasyonlar içinde teslimatlar arasında dokümanları da tanımlayabiliriz. Dokümantasyonda aşırıya kaçmamak asgari yeter seviyede (barely sufficient) yapmak çevik yöntemlerin tercihidir. İstenirse dokümantasyon için ayrıca bir iterasyon (hand-off) ayrılabilir.
Kalite süreçlerini nasıl işletirim? Kalite süreçlerinde istenenleri, iterasyonlar içinde iş maddesi veya iterasyon sonunda kabul kriteri olarak planladığımızda kalite ekibiniz de memnun olacaktır.
Şirketimiz çağlayan modeli ile çalışılmasını tercih ediyor, ne yapabilirim? Çağlayan modelinde istenen çıktıları verdiğimiz sürece ekip içinde çevik yöntemlerle ilerlememize engel bir durum yoktur. Mümkün olduğu kadar müşterimizi işin içine katarak işbirliğini artırdığımızda çevik yaklaşımın meyvelerini yiyebiliriz.
Çevik yöntemlerde direkt kodlama yapabilir miyim? Çevik yöntemler kovboy kodlaması (cowboy coding) değildir. İşleri esnek bir plan dahilinde önceliklendirerek  yürütmemiz beklenmektedir. 
Çevik yöntemde kapsam, bütçe, zaman nasıl dengelenir? Sabit bütçe ve zaman olduğu varsayılarak kapsam serbest bırakılır. Müşterinin kapsamı yönetmesine izin verilir. Müşteri de kapsamı değiştirebildiği için mutlu olur. Çağlayan modelinde proje esnasında gelen değişiklik isteklerinin (change request) yerini ürün iş listesi (product back-log) alır.
Çevik yaklaşımda kapsam kontrolü nasıl yapılır? Ürün iş listesi ve bunun önceliklendirilmesi ile kapsam yönetilir. Burada kritik konu müşterinin fikrinin değiştirip iş listesinde henüz iterasyonu ve yazılım süreci başlamamış maddelerin önceliğini ve içeriği değiştirebilmesidir.  Eğer yeni madde ilave edilecekse karşılığında bir maddeyi çıkarmasını isteriz. Müşteri de vazgeçebileceği bir şey bulup bizi bu yükten kurtarır.
Ürün nasıl son haline getirilir? Ürünü toparlamak ve gerekli yerlerini düzenlemek için özel bir iterasyon (hardening, refactoring) planlayabiliriz.
Çevik yöntemlerde proje yöneticisi var mıdır? Elbette vardır, yöntemlere bağlı olarak adı değişebilir, örneğin Scrum Master, XP Koçu gibi. Klasik proje yönetiminden en büyük farkı ekibin işini kolaylaştırmak amacıyla ekibin önündeki engelleri ve bürokrasiyi kaldırmaya çalışır, ekibe yöneticilik yerine liderlik yapar. Sorun veya risk olan noktalarda devreye girer. Seçilen çevik yöntemin doğru uygulanmasını sağlar.

Çevik yaklaşımlardan maksimum fayda elde edilebilmesi için kurum olarak bu yöntemlerin benimsenmesi, üst yönetimin bu yolda tam destek sunması oldukça önemlidir. Müşterinin çalışmalara aktif katılımı da sonucu etkileyecektir.

Tüm projeler gibi çevik yaklaşımla yönetilen projeler de başarılı olmayı hedeflerler. Çevik yöntemlerde başarılı olabilmek için bol uygulama ve tecrübe çok önemlidir. Uygulama sayısı arttıkça hız kazanılması, eksikliklerin giderilmesi mümkün olur. Başarıyı etkileyen konular genel olarak diğer projelerle benzerlik gösterir (ilgili makale:Proje Başarı Kriterleri ve Proje İhtiyaç Analizi). Çevik yaklaşımın kendine özgü başarı anahtarları da vardır (ilgili makale: Çevik Yazılım Projelerinde Başarının Anahtarları Nelerdir?). 

1 yorum:

  1. Çevik yaklaşım küçük ideal olarak 5 i geçmeyen ve çok tecrübeli yazılımcılardan oluşan ekipler için uygun olup kaotik/değişken projeler için uygundur. Hiyerarşi yok denecek kadar az olup scrum master hesap sorucu değil (yapılanlar gruba anlatılır scrum master da araya oturup anlatır) sorun çözücü olarak çalışır ve aktarımlar gruba yapılır şu 3 soruya cevap aranır: (haftalık oturum ise) -geçen hafta ne yaptın?-bu hafta ne yapacaksın?-seni bloke eden bir engel veya beklediğin bir iş var mı? Bu grup içi iletişimi arttırdığı gibi oturumlar kısa tutulduğu için verimlidir (hatta bazen oturmak yasaklanır toplantı ayaktadır :) .

    YanıtlaSil