21 Ocak 2015 Çarşamba

Sprint Sonlarında Çalışır Uygulama Teslim Etmek


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