Çevik Yazılım Geliştirmede Risk
Çevik Yazılım Geliştirmede risk konusu üzerine birçok araştırma yaptım. Ne yazık ki paylaşabileceğim ya da bana bir şeyler katabileceğini düşündüğüm bir paylaşım bulamadım. Bu, Çevik Topluluğu için büyük bir kayıp. Özellikle geleneksel yöntemle proje geliştirenlerin savunduğu; “Çevik yaklaşımlar içinde risk yönetimi bulunmuyor; bu nedenle kullananların canı çok yanıyor!” iddialarına cevap niteliğinde birkaç yazı bulurum diye düşünüyordum.
Çeviklik hakkında bilgi edinmeye başladığınız ilk dönemlerde Çevikliğin değişen ortama adapte olmak ve değişime hızlıca cevap vermek olduğunu öğrenirsiniz. Derinlere inmeye başladığınızdaysa Çevikliğin aslında baştan sona riski yönetmek olduğunu öğreneceksinizdir. Çevik Yazılım Geliştirme Bildirisi’ndeki değerlerin ve ilkelerin üzerinden verdiğim örneklere devam etmek istiyorum. Çevik Yazılım Geliştirme Bildirisi’nde üçüncü değer der ki:
“Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine değer veririm.”
Geleneksel yöntemle geliştirilen projelerdeki en büyük risk uzun analiz, geliştirme, test adımlarından sonra kullanıcı kabulüne çıkıldığında müşterinin istemediği bir ürünü geliştirmektir. Müşteri, “benim istediğim bu değil ki, ben bu projeyi onaylamıyorum, istemiyorum ve ödeme yapmıyorum” der. Bu cümleleri geleneksel yöntemle proje geliştiren herkes duymuştur!
Duymadınız mı!
Çevik yaklaşımlar bunu duymamak için müşterileriyle, iş birimleriyle yakın olunması gerektiğini söyler. Geliştirilen her özelliği mümkün olan en kısa sürede müşterinizle, iş birimlerinizle paylaşın der. Her döngü sonunda geliştirilen özellik müşteriye gösterilir ve istediklerinin bu olup olmadığı sorulur. Eğer istedikleri özellik geliştirilmişse ne güzel! Eğer istedikleri özellik geliştirilmediyse kaybınız sadece bir döngülük zamandır. Bu döngü süresini siz belirlediğiniz için kaybınızı en aza indirmek, riski belirlemek sizin elinizdedir. Bu biraz uç nokta ama isterseniz günlük döngüler yapabilirsiniz.
Geleneksel yöntemde müşteri bir analiz aşamasında bir de kullanıcı kabul aşamasında projeye dahil olur. Bu nedenle yaptığınız yanlış bir yıl sonra ortaya çıkar. Bu da bir yıllık, emek, enerji, zaman ve para demektir.
Bir analistin müşteriyi yanlış anlaması, müşterinin kendini ifade edememesi, analiz dokümanında bir yanlışlık, yazılım geliştiricinin bunu anlamaması, yazılım geliştiricinin anlaması ama yanlış kodlaması, testçinin test senaryolarını gerçekleştirememesi -bu arada testlerinizi otomatize etmediğinizi varsayıyorum çünkü güzel ülkemde testleri otomatize etmek zaman kaybı olarak görülüyor- ne zaman ortaya çıkıyor? Projenin sonunda…bu mayınlarla dolu bir arazi değil mi?
Hepimiz insanız ve hata yapabiliriz. Hata yaptığımız için suçlu olmayız. Aksine yeni birşey öğrenmiş oluruz. Fakat bu hatayı en kısa sürede ortaya çıkarmak ve bunun çözümünü gerçekleştirmek çalıştığımız kuruma karşı görevimizdir.