Yazılım Proje Yönetimi: Agile ve Scrum’a Giriş

Yazılım projelerinin gecikmesi neredeyse bir klişe haline geldi. "Üç ayda biter" denen proje bir yıl sürer; teslim edildiğinde ise müşterinin ihtiyacı çoktan değişmiş olur. Bu sorunun kökeninde çoğu zaman yanlış bir varsayım yatar: her şeyi baştan planlayıp sonra hiç sapmadan uygulayabileceğimiz varsayımı. Gerçek dünyada ihtiyaçlar değişir, belirsizlikler çıkar ve plan ilk temasla eskir. Çevik (Agile) yaklaşım, tam da bu gerçeği kabul ederek doğdu. Bu yazıda çevik felsefeyi ve onun en yaygın uygulaması olan Scrum'u sade bir dille ele alıyoruz.

Şelale Modelinin Sınırları

Geleneksel şelale (waterfall) modelinde proje ardışık aşamalardan geçer: önce tüm gereksinimler toplanır, sonra tasarım yapılır, sonra kodlanır, sonra test edilir ve en sonda teslim edilir. Her aşama bir öncekinin bitmesini bekler. Kağıt üzerinde düzenli görünür; ancak büyük bir zayıflığı vardır: müşteri çalışan ürünü ancak en sonda görür. O ana kadar biriken tüm yanlış anlamalar, işin sonunda toplu halde patlar.

Şelale modelinin sorunu planlamak değil, plana gerçeklikten daha fazla güvenmektir. Yazılımda tek kesin şey, ihtiyaçların değişeceğidir.

Çevik Felsefe: Değişime Uyum

Agile, 2001'de yayımlanan Çevik Manifesto ile bir isim kazandı. Temelinde birkaç basit ama güçlü değer vardır:

• Bireyler ve etkileşimler, süreç ve araçlardan önce gelir.
• Çalışan yazılım, kapsamlı dokümantasyondan önce gelir.
• Müşteri iş birliği, sözleşme pazarlığından önce gelir.
• Değişime yanıt vermek, bir plana körü körüne uymaktan önce gelir.

Dikkat edilirse bunlar "şunu yapma" demez; "önceliği şuraya ver" der. Dokümantasyon da plan da değerlidir; ancak asıl amaç, çalışan ürünü sık sık ortaya koyup gerçeğe göre yön düzeltmektir. Çevik yaklaşımda proje, büyük tek bir teslimat yerine kısa döngüler halinde ilerler ve her döngüde gösterilebilir bir değer üretilir.

Scrum: Çevikliğin En Yaygın Çerçevesi

Scrum, çevik felsefeyi somut bir çalışma düzenine dönüştüren bir çerçevedir. Kuralları azdır ama disiplinlidir. Temelinde "sprint" denen sabit uzunlukta döngüler (genellikle 1-4 hafta) vardır. Her sprintin sonunda, potansiyel olarak teslim edilebilir bir ürün parçası ortaya çıkar.

Scrum Rolleri

1. Ürün Sahibi (Product Owner): Neyin, hangi öncelikle yapılacağına karar verir. İş değerinin sesidir; müşteriyi ve pazarı temsil eder.
2. Scrum Master: Sürecin sağlıklı işlemesini sağlar, engelleri kaldırır ve ekibi korur. Bir yönetici değil, bir kolaylaştırıcıdır.
3. Geliştirme Ekibi: İşi fiilen yapan, kendi kendini örgütleyen çapraz fonksiyonlu ekip.

Scrum Olayları

• Sprint Planlama: Ekip, bu sprintte neyi tamamlayacağına birlikte karar verir.
• Günlük Scrum (Daily Standup): Kısa günlük buluşma; ne yapıldı, ne yapılacak, engel var mı?
• Sprint Değerlendirme (Review): Sprint sonunda çalışan ürün paydaşlara gösterilir, geri bildirim alınır.
• Sprint Retrospektifi: Ekip süreci değerlendirir: neyi iyi yaptık, neyi geliştirebiliriz?

Scrum Çıktıları (Artefaktlar)

• Ürün Biriktirme Listesi (Product Backlog): Yapılacak her şeyin önceliklendirilmiş listesi.
• Sprint Biriktirme Listesi (Sprint Backlog): Bu sprintte ele alınacak işler.
• Ürün Artışı (Increment): Sprint sonunda ortaya çıkan, çalışan ürün parçası.

Bu yapı, karmaşık projeleri yönetilebilir küçük parçalara böler. Her sprint sonunda somut bir çıktı görülmesi, hem müşteriye güven verir hem de yanlış gidişleri erken düzeltme fırsatı sunar.

Çeviklik Bir Kültürdür, Sadece Tören Değil

Çevikliğin en sık yapılan hatası, sadece törenleri (günlük toplantı, sprint) uygulayıp özünü kaçırmaktır. Ekip her gün toplanıp da geri bildirime kapalıysa, değişime direniyorsa; orada Scrum değil, "şelale modeli sprint kılığında" işler. Gerçek çeviklik, öğrenmeye ve uyum sağlamaya açık bir kültürden gelir.

Scrum tahtası asmak ekibi çevik yapmaz. Çeviklik, "yanılmış olabiliriz, öyleyse düzeltelim" diyebilme cesaretidir.

Berasoft olarak müşteri projelerinde çevik yaklaşımı benimsememizin nedeni budur: yazılım gelişirken ihtiyaçların değişeceğini biliriz ve süreci bu gerçeğe göre kurgularız. Her sprintte çalışan bir parça göstermek, projeyi hem şeffaf hem de yönlendirilebilir kılar. Böylece müşteri, projeyi sonunda değil, yol boyunca şekillendirir.

Agile Her Proje İçin mi?

Çeviklik güçlüdür ama evrensel bir reçete değildir. Gereksinimlerin kesin ve değişmez olduğu, düzenlemelerin katı olduğu bazı projelerde daha planlı yaklaşımlar uygun olabilir. Ancak belirsizliğin yüksek, ihtiyaçların değişken olduğu çoğu modern yazılım projesinde çevik yaklaşım, riskleri erken görünür kılarak büyük fark yaratır. Önemli olan, çerçeveyi körü körüne değil, projenin doğasına göre uyarlamaktır.

Sonuç

Agile ve Scrum, yazılım projelerinin en temel gerçeğini kabul eder: ihtiyaçlar değişir ve plan tek başına yetmez. Çözüm, her şeyi baştan kestirmeye çalışmak değil, kısa döngülerle ilerleyip sık sık gerçeğe göre yön düzeltmektir. Scrum'un rolleri, olayları ve çıktıları bu düzeni somutlaştırır; ama asıl motor, öğrenmeye ve uyuma açık bir kültürdür. Törenleri uygulamak kolaydır; çevik zihniyeti benimsemek ise projeyi gerçekten kurtaran şeydir. Doğru uygulandığında Agile, "geç ve yanlış" teslim eden projeleri "erken ve doğru" teslim eden projelere dönüştürür.