Scrum uygulanırken
zorlanılan konulardan biri de her sprint sonunda çalışır uygulama teslim etmek.
Bu konuya basitçe sprintin sonunda yaptığımız geliştirmelerin hatasız çalışır
olması olarak dar çerçevede bakmamak lazım. Kullandığımız eski Waterfall yönteminin
hepimizde yer ettiği projelere bütün olarak bakma alışkanlığı bu konuda bizi rahat
bırakmıyor maalesef. Eski yöntemlerimizi Scrum’a göre dönüştürüp aynı şekilde
uygulamaktan vaz geçmeliyiz.
Şimdi hayali olarak bir
proje takımına dâhil olalım: Proje için bir araya geldik ve oturup yapılacakları
iyice anlamak için Grooming toplantıları yaptık. Analizler, tasarımlar havada
uçuşuyor. Deneyimli arkadaşlar çok güzel bir şekilde ne yapılması gerektiğini
açıklıyor. Artık projenin sonuna kadar ne yapacağımızı ve nasıl yapacağımızı
büyük oranda biliyoruz. Ve ilk sprinti bitirdik. İlk Review toplantısında
ilgili paydaşlara yaptığımız analiz ve teknik tasarımları gösterdik. İlerde
bizi bekleyen güzel günlerden bahsettik. Onlarda (eskiden kalma alışkanlıkla)
hepimizi canı gönülden tebrik ettiler. Başarılı 1-2 sprintin ardından tasarımımız artık mükemmel. Bir sonraki sprint’in planlamasına geçtik. Product
Owner’ımızın planlamaya getirdiği maddelerden birini konuşuyoruz. Daha yeni
tamamladığımız bir ekranda ek düzenlemeler isteniyor. Derken talep sahibi hiç
beklemediği bir dirençle karşılaşıyor. Neden? Çünkü eğer orada bir düzenleme
yaparsak, güzelim tasarımın birçok yerini yenilememiz gerekecek. Hâlbuki o
kadar emek vermiştik.
Bu durumda doğal olarak
değişime direnmeler ve neden baştan söylenmediler başlıyor. İstek sahibine eğer
isteği gerçekleştirilirse ne kadar maliyete girileceği ve projenin ne kadar
uzayacağı anlatılarak isteğinden vaz geçmesi sağlanıyor. İşte tam o anda can
alıcı soru geliyor: “Hani Scrum değişime açıktı?”. Bir yerde yanlış yaptık
değil mi?
Burada yaptığımız en
büyük hata, eskiden olduğu gibi projeyi bir bütün olarak düşünüp bu bütünü
tasarlamak oldu. Projenin bütünü yerine varılmak istenen noktaya ve hep bir sonraki
adımımıza odaklanmalıydık. Groomingler bir sonraki adımlara, Review
toplantıları ise hedefe doğru ilerleyişimize ışık tutuyor olmalıydı. Projeyi
parçalarken, sadece birleştirildiğinde anlamlı hale gelecek parçalar
oluşturmaktan ziyade, projenin çok basit ve temel özelliklerinden oluşan bir parça
ve her sprintte daha gelişmiş ve daha çok işe yarar parçalar haline getirmemiz
lazım. Böylece her Review toplantısında çalışan uygulama, yani projenin ta
kendisi değerlendirilir. Hedeflenen haline ne kadar yaklaştığı incelenir ve
talepler buna göre şekillendirilir.
Bu hali ile aslında
proje, üretime geçmiş ve sonradan gelen küçük istekler ile sürekli gelişen,
mükemmelleşen, yeni ihtiyaçlara en kısa zamanda cevap veren bir uygulamadan pek
de farklı olmayacaktır.
Hiç yorum yok:
Yorum Gönder