Dünya bir önceki gün olmadığı gibi, işlerimizi yapış şeklimiz de ister istemez zamana ayak uyduruyor. Teknoloji genelinde ve yazılım geliştirme özelinde durum farklı değil. Zamanın ruhu, değişimlere daha hızlı uyum sağlamayı zorunlu kılıyor. Bir yazılım projesini konuşurken var olan gereksinimler, daha yazılım geliştirme sürecinin başında değişmeye başlıyor.
Bu hızdaki değişimi yönetmek, geleneksel proje yönetim methodolojilerinde bizi zorluyor. Çünkü bildiğimiz ve bugüne kadar uyguladığımız, waterfall olarak bilinen yazılım geliştirme yaklaşımında, gereksinimleri ve iş analizini ta en başında yapıyoruz ve müşteri ile mutabık kalındıktan sonra ürün geliştirme sürecine başlıyoruz. Tabi ürün geliştirme aşamasında başta belirlediğimiz ve müşteri ile üzerinde anlaştığımız ürün/proje kapsamında daha sonra yapılacak değişikliklere genelde pek sıcak bakılmıyor. Bu, en başta yaptığımız maliyet/süre tahminlerini etkileme riski oluşturduğu gibi, aynı zamanda projenin zamanında ve bütçesinde tamamlanamama riskini de oluşturabilir. Dolayısıyla başta belirlenen proje kapsamı, zorunlu olmadıkça değiştirilmez, ve bunun için çoğunlukla istenilen değişikliklere öncelik puanı verilmesi gibi bir prosedür kullanılır. Bu sayede istenilen değişikliğin katacağı değere göre önceliklendirilmesi ve yalnızca yapılması gerekli görülen değişikliklerin (örneğin yasal değişiklikler her zaman yüksek önceliklidir) kapsama dahil edilmesi mümkün olabilir.
Geleneksel yazılım projelerinin yönetiminde her ne kadar kapsam değişikliğini kontrollü bir şekilde yapacak prosedürlerimiz olsa da, ürün geliştirmesi bittiğinde zamanı yakalayamama riski her zaman oluyordu. Özellikle uzun süren projelerde, proje bittikten sonra ortaya çıkan ürün, o anki gerek duyulan fonksiyon ve özelliklerin tamamını karşılayamayabiliyor. Bu da ürüne yatırılan onca paranın geri dönüşümünü olumsuz etkiliyor, beklenilen faydayı tam olarak sağlayamıyor, yani fayda/maliyet oranında istenmeyen bir düşüşe sebep olabiliyor.
İşin sonunda para ve pazar kaybına yol açabilecek geleneksel yazılım proje yönetimi modelleri yerine, özellikle göreceli uzun sürebilecek ve karmaşık yazılım projelerinde farklı yöntemler aramaya başladık. Günümüzde aslında çok yeni bir kavram olmasa da Çevik (Agile) Proje Yönetimi modellerinin hızla popüler olması da aslında sürpriz olmadı. Ortada belirgin bir ihtiyaç olunca, o ihtiyaca cevap verecek çözümler için arayış girmek de gayeet doğal.
Biraz uzun bir giriş oldu, ama yukarıda anlattığım arka planı bilmeden Agility/Çeviklik ne demek anlamak zor olacaktı diye düşünüyorum. Yazılım projelerinde hızlı ve aynı zamanda daha iyi fayda/maliyet oranı sağlamanın daha iyi bir yolu olmalı arayışıyla 2001 yılını Şubat ayında 17 kişilik bağımsız bir gurup, ABD’nin Snowbird/Utah kasabasında bir araya gelirler. Bir yandan kayak yaparak eğlenen bu küçük gurup, başta yazılım projelerinde olmak üzere iş yapış şeklimizde önemli değişiklik yaratacak olan “Agile Manifesto”yu yayınladılar. Muhtemelen bunun etkisinin bu kadar büyük olacağını ve sınırları aşacağını kendileri de tahmin etmemişlerdir. Bu arkadaş gurubu, aslında var olan sıkıntıların bir resmini çekmişler ve daha iyisi için nelerin yapılması gerektiğini veya bir başka deyişle, projelerde nelere daha çok değer verilmesi gerektiğini sadece 4 maddede özetlemişler. Ve buna bir isim vermek gerektiğinde “Agile”, yani çevirisi “Çevik” kelimesini uygun bulmuşlar.
Çevikliğin 4 değeri kısaca şunlar:
1-Süreçler ve araçlardan daha çok bireylere değer vermek:
Bunun anlamı, Agile yöntemlerin süreç bazlı değil insan bazlı oluşudur. Yani açıkça insanlara daha çok yetkilendirmeyi, kendi kendine karar almayı teşvik etmeyi ve daha az bürokrasiyi savunur. Böylece değişimlere daha hızlı yanıt vermek mümkün olabilecektir.
2-Detaylı dokümantasyonlara vakit harcamaktansa bir an önce çalışan bir yazılım geliştirmeye değer vermek:
Projelerin başında yoğun emek ve para harcayarak oluşturulan detaylı gereksinim dokümanlarıyla uğraşıp değerli zamanımızı harcamak yerine, bir an önce en azından yüksek öncelikli ve katma değeri yüksek fonksiyon ve/veya özellikleri geliştirip kullanıma hazır hale getirmeye çalışmaktır. Elbette bu, Agile yöntemlerde hiç dokümantasyon olmayacak demek değil. Sadece gerektiği kadar detay bilgiye sahip, genellikle “User Story” (Kullanıcı Hikayesi) dediğimiz formatta hazırlanan dokümantasyonlar olur. Ve daha önemlisi, tüm ürün için gerekli dokümantasyon projenin başında tamamlanmak zorunda da değildir.
3-Müşteriyle sözleşme pazarlığı yerine müşteriyle devamlı iş birliğine önem vermek:
Müşteri, proje konusunda sözleşme aşamasında yoğun olarak etkileşimdedir. Çoğunlukla bir kez sözleşme imzalandı mı, proje bittikten ve kullanıcı kabul testi aşamasına gelene kadar, proje sürecine pek fazla bir katkısı olmaz. Agile yöntemlerde ise burada çok önemli yapısal bir değişiklik var, artık müşteri proje ekibinin aktif bir üyesi olarak karşımıza çıkıyor. Müşteri, en popüler Agile methodu olan Scrum’da “Product Owner” olarak geliştirilen üründen azami faydanın sağlanması, geliştirme ekibinin sorularına yanıt vererek ürün geliştirmeyi yönlendirmek gibi kritik sorumluluklar üstlenir.
4-Proje planını katı bir şekilde izlemek yerine değişimlere karşılık vermek:
Proje kapsamını en başta belirlediğimizden ve bunun çok gerekmedikçe değiştirilmediğinden bahsetmiştim. Agile/Çevik yöntemler ise değişime açıktır, hatta projenin son aşamasında değişim talebi gelse bile. Sonuçta amaç, klasik anlayışla “projeyi başta belirlediğimiz kapsamda hele bir tamamlayalım da, gerisi çok da önemli değil” yaklaşımı yerine, “asıl olan hızlı bir şekilde kısmi bir ürün ortaya çıkartarak o anki gereksinimleri ve müşterinin bu üründen beklediği faydayı en üst düzeyde sağlamaya çalışmak”. Yani aslında, yazılımı geliştiren proje ekibi, klasik “müşteri ve tedarikçisi” anlayışı yerine, birbirlerinin “iş ortağı” durumuna gelmekte. Dahası, müşterinin performans metrikleri (KPI) aynı zamanda proje iş ortağının da gözettiği ve değer verdiği metrikler olmakta; “müşteri kazanırsa biz de kazanırız, sonuçta aynı ekibiz” felsefesi hayatımıza girmekte.
Agile Manifesto yayınlandıktan bir süre sonra buna birde tamamlayıcı olarak 12 adet Agile prensibi eklendi. Bu prensiplere daha sonra başka yazı değiniriz.
Bu 4 Agile değeri, organizasyonlarda iş yapış ve düşünce geleneğinde ciddi bir değişiklik yapılmasını gerektiriyor. Yılların alışkanlığından hemen kurtulmak öyle kolay değil. Üstelik yalnız projeleri geliştiren teknik birim ve ekiplerin değil, aynı zamanda müşteri konumunda olan paydaşların da bu Agile dönüşümü desteklemesi şart. Yeni projelerde bunun için müşteri ile diyaloğa büyük önem vermeliyiz ve onları proje süresince proje ekibine dahil etmeliyiz.
Aslında çeviklikte işin özü, bu manifestoda bahsedilen değerler ve müşterinin projeye başından sonuna kadar katılımında yatıyor.
Also published on Medium.