Çevik Yazılım Geliştirmede Risk

Çevik Yazılım Geliştirmede Risk

Bu konu ü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’ninde üçü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ı kabulune çı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 Yazılım Geliştirmede Risk
Çevik Yazılım Geliştirmede Risk

Ç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ı enaza 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.

 

80total visits,10visits today

Leave a Reply

Your email address will not be published. Required fields are marked *