Waterfallda Karşımıza Çıkan Problemler
Bu yazımda son 40 yıldır yazılım geliştiren herkesin en az bir defa karşısına çıkan Waterfall’dan bahsedeceğim. İster küçük bir yazılım evinde ürün geliştiriyor olun ister kurumsal bir organizasyonda görev alın Waterfall size dokunmuştur. İster bir veri ambarı projesi yapın, ister bir B2B projesi geliştirin herkesin desteklediği ama bilgisinin olmadığı ve üzerine düşünmediği bir konudur, geleneksel yazılım geliştirme süreci.
40 yıldır bu yaklaşımla proje geliştiren kişilerin bu yaklaşımı savunmasını anlıyorum, anlayamadığım konu çalışmaya sadece birkaç yıl önce başlamış kişilerin adeta fanatik bir şekilde bu yaklaşımı savunmalarıdır. İlk önce analizi bitirmeliyiz analiz bittikten sonra geliştirmeye başlanabilir geliştirmeyi bitirdikten sonrada testçi arkadaşlar test etmeye başlayacak diye seslerini yükseltmelerini şaşkınlık içinde izlediğim çok olmuştur. Bu sahneleri izleyince Uğur MUMCU’nun şu sözü gelir aklıma “Bilgi sahibi olmadan fikir sahibi olunmaz!”. Gerçekten bilgi sahibi olmadan fikir sahibi olan bu arkadaşların fanatik yapısı neden kaynaklanmaktadır. İnsanoğlu neden öğrendiği ilk şeyin hep doğru olduğunu düşünür? İlk öğrendiğini benimser ve sahiplenir? Çünkü ego -psikoloji biliminde kullanılan anlamıyla- değişimin kötü olduğunu düşünür ve insan içgüdüsel olarak kendini koruması gerektiğini varsayar. Bu içgüdüsel yaklaşım bir savunma mekanizmasını tetikler ve değişime karşı yumruklar sıkılır.
Konuyu daha fazla ilginçleştirmeden ve dağıtmadan Waterfall ile geliştirilen ürünlerin geliştirme sürecinde karşıma çıkan problemleri anlatacağım. Sizinde karşınıza çıkan gözlemlediğiniz, yaşadığınız ve ilginç olduğunu düşündüğünüz problemleri duymayı çok isterim.
Plan, araç değil amaçtır
Yazılım projeleri geliştirilirken sürekli olarak duyduğumuz şey projenin tüm kapsamının zamanında ve bütçesi içerisinde belirlenen kalite standartlarında geliştirilmiş olması gerektiğidir. Bu şartları sağlayan projeler başarılı kategorisine girer. Bu kategoriye giren projelerin gerçekten başarılı olup olmadığı konusunu bir yana bırakarak bu sözde başarıya nasıl ulaşılmaya çalışıldığını konuşacağız. Başarılı projeler kategorisine girebilmek için deterministik, herşeyin önceden bilindiği ve hiç bir değişikliğin olmayacağı düşünülerek bir plan yapılır. Gerçekleşen bütün değişikliklere – kapsamda yapılan değişiklikler, çalışan kişilerin projeden ayrılması, geliştirme yapılan teknolojinin değişmesi, ortam değişiklikleri – rağmen sanki hiçbir değişim olmamışçasına başlangıçta oluşturulan plana uyulmaya çalışılır. Örneğin projeden ayrılan A kişisinin yerine B kişisi geldiğinde ikisininde kod yazma hızlarının aynı olduğu düşünülür ve planda herhangi bir güncelleme yapılmaz.
Çok önemli durumlarda proje planında güncellemeler yapılır ki aslında bu güncelleme de gerçeği yansıtmaz. Bunun yapılabilmesi için kontrat imzalayan tarafların anlaşması gerekir. Bu anlaşma sağlanıncaya kadar uzun ve anlamsız tartışmalara girilir. Çalışanlar-işi talep eden ve hizmeti veren kişiler- arasındaki iletişim bozulur ve en sonunda hiçbirşeyin değişmeyeceği anlaşıldığında, her iki taraf -hizmeti alan ve hizmeti veren- birbirini ikna ettiğini düşündüğünde yeniden bir anlaşma sağlanır ve planda güncelleme yapılır. Bu güncelleme hiç bir zaman gerçeği yansıtmaz. Waterfall ile yönetilen hiç bir projem ne zamanında ne bütçesinde ne de kapsamında ve beklenen kalitede olmadı. Bu tecrübeyi tek edinen ben değilim. Eğer yazılım geliştirme işiyle uğraşıyorsanız eminim 6 ay, 1 yıl, 2 yıl uzayan ve çay, kahve içerken arkadaşlarınızla konuştuğunuz “ne projeymiş bitmedi” dediğiniz oluyordur. İşin ilginç yanı Waterfall’ın babası Winston Royce, Waterfall’ın doğuşu kabul edilen araştırmasının sonucunda yayınladığı makalesinde şunları söyler:
“Bu yöntemle geliştirilen projeler zamanında ve kapsamında tamamlanmadı. Ayrıca belirlenen ilk bütçe hep aşıldı.”
Waterfall ile geliştirilen projelerin planlaması yapılırken Gantt şemasından yararlanılır. Şuan üzerinde çalıştığım projeninde Gantt şeması oluşturulmuş bunu bir ay kadar önce görme şansım oldu -ve biz bu projeyi geliştirirken Scrum yapıyoruz, Sprint’ler koşuyoruz-. Bu şemaya göre projenin 19 ayda tamamlanması öngörülüyor. Şemada gerçekleştirilecek her adım için belirli zaman aralıkları verilmiş. Gerçekleştirilecek 11 adım bulunuyor. Projenin 12. ayındayız fakat Gantt şemasında belirlenen adımlardan sadece 2’si tamamlanabilmiş ve buda Gantt şemasında 4 aylık bir zamana denk geliyor. Bu plana göre kalan 7 ay içinde Gantt şemasında belirlenen 17 aylık işi tamamlamamız gerekiyor. Eğer tamamlayabilirsek -buraya bir espri yazmak istedim ama olmadı- sanırım çok başarılı bir proje olmuş olacak!
Proje Başlangıcında Gantt Şeması
Gerçekte Projenin Bulunduğu Yer
Gantt şemasının bir diğer önemli özelliğiyse sadece % 90’a kadar tamamlanabiliyor olmasıdır. Hiç %100 tamamlanan bir Gantt şeması görmedim! Bu şaka değil gerçekten çok uzun süren projelerin içinde yer aldım. Proje Yöneticisi arkadaşlar Gantt şemasındaki ilerlemeyi hep %90’a kadar getirebildiler ve daha fazla ilerlemedi. Kalan %10’u tamamlamak başlangıçtaki %90’ı tamamlamaktan uzun sürdüğü bile oldu.
Bir sonraki adıma geçebilmek için önceki adım bitmelidir
Waterfall adından da anlaşılacağı üzere aslında belirli basamaklardan oluşur. Bir sonraki adıma geçebilmek için önceki adım bitmelidir. Royce’un basit model dediği ve basit model için çizdiği şemayı hatırlarsak “Coding” adımına geçmeden önce “Program Design” adımının tamamlanmış olması gereklidir.
Projenin sonuna kadar değer üretilmez
Geliştirilen projeden, üründen değer elde edilebilmesi için Waterfall modelindeki bütün adımların tamamlanmış olması gerekir. Sistem Gereksinimleri, Yazılım Gereksinimleri, Analiz, Program Dizayn, Kodlama, Test ve Operasyon adımından sonra değer üretilmeye başlanır. Örneğin oniki aylık bir projede ancak onikinci ayın sonunda değer üretilebilir. Halbuki proje daha küçük adımlara bölünürse pazara veya son kullanıcıya çok daha çabuk ulaşılabilir. Oniki ay beklemek yerine birinci ayın sonunda değer elde edilmeye başlanabilir.
Kullanıcı ile etkileşim proje başladığında ve sonlandığında vardır
Waterfall ile yönetilen projelerde kullanıcı, projeye ihtiyaçların belirlendiği aşama olan analiz aşamasında dahil olur. Daha sonra gelen geliştirme adımında ise uzunca bir süre kullanıcıyla görüşülmez ta ki kullanıcı kabul testleri yapılana kadar. Bu dönem içinde pazarda, dünyada, kurumda yaşanan değişiklikler dikkate alınmaz ve geliştirme tamamlanır. Kullanıcı kabul testleri başladığındaysa kullanıcı ile etkileşim tekrar başlar. Geliştirilen ürün kullanıcıya sunulur, kullanıcı testlerini yapar ve görüşlerini belirtir. Bu aşamada genellikle şu durumla karşı karşıya kalınır:
1 yıl önce analiz aşamasında projeye dahil olan müşteri ilk önce ne istediğini hatırlayamaz. Analiz dokümanları incelenir ve istenilen ürün hatırlanır. Daha sonra ise kullanıcı hayalinde oluşturduğu ürün ile geliştirilen ürünün birbirine hiç benzemediğini aslında çok daha farklı şeyler istediğini anlatmaya başlar. Bu dönemde farklı tartışmalar baş gösterir ve herkes birbirini suçlamaya başlar. Kullanıcı istediği ürünü geliştirmediği için geliştiriciyi, geliştirici ihtiyaçları doğru belirlemediği için analisti, analist ihtiyaçlarını tam olarak anlatamadığı için kullanıcıyı suçlamaya başlar. Sonuçta elde edilen şey; boşa harcanan emek, enerji, para, zaman ve istenilmeyen bir üründür. Ayrıca yazılım geliştirme işini yapan kişiler ile son kullanıcının arası bozulmuştur ve uzunca bir süre tekrar görüşülmeyecektir ta ki başka bir projeye başlanıncaya kadar. Tabi bu durumda son kullanıcının güveni sarsıldığı için artık projeyi kurum dışında sözde daha iyi olan bir firmaya yaptırmak yada var olan bir ürünü kullanmak-bu ürün isteklerini tamamıyla karşılamasa bile- ister. Bence bu çok büyük bir başarısızlıktır!
Değişikliğe açık değildir
Analiz ve tasarım adımları geçildikten sonra kapsamda gerçekleştirilmek istenen değişikliklerin maliyeti çok yüksektir. Aynı örnek üzerinden gidersek bir yıllık bir projenin ilk dört ayı analiz ve dizayn adımları gerçekleştirilir. Altıncı ayda kapsamda yapılan bir değişiklik bu dört aylık süreçte yapılan işlerin hepsinin gözden geçirilmesi demektir.
Hata tespiti uzun sürer ve düzeltmek pahalıdır
Test aşamasına gelinip bir hata tespit edildiğinde bu hatanın düzeltilmesi için yine analiz veya kodlama adımına dönülmesi gerekmektedir. Bu adımlara dönülüp hata tespit edilir. Eğer hata kodlama adımında yapılan bir hata ise ve büyük değişikliklere yol açmayacaksa kolay çözülebilir demektir. Fakat analiz aşamasında yapılan bir hata mimari anlamda değişikliklere yol açabilir. Çünkü geliştirme işi yapılan analiz baz alınarak gerçekleştirilmiştir ve temelinde bu analiz bulunmaktadır. Bütün bu geri dönüşlerin maliyetleri projenin bütçesini beklenenin üstüne çıkartır.
Yazılım geliştirme süreçlerini birbirinden ayırmak gerçekçi değildir
Yazılım geliştirme temelde soyut bir düşünceden -bir hayalden- kodlar ve bilgisayarlar yardımıyla çalışan bir ürün oluşturma işidir. Böyle soyut bir alanda çalışırken bir iki ay fikirleri kağıt üzerine dökmek daha sonra kağıt üzerindeki bu fikirleri toplayıp bir yapı oluşturmak ve bu yapıyı belirli bir mimariye oturtmak sonrasındaysa bu dokümanlardan ve mimariden yola çıkarak kod geliştirmek ve en sonda da beklenen sonucu elde etmek düşünüldüğü kadar kolay bir iş değildir! Hal böyleyken bütün bu adımlarda farklı birimlerdeki kişilerin farklı zamanlarda çalışması ise bu işi zorlaştıran bir başka etkendir.
Aşina olduğumuz bu sahnenin gözümüzde daha iyi canlanması için şunu hayal edin Analiz biriminde çalışan bir analist projenin ihtiyaçlarını belirler. Çözüm Mimarı bölümünden büyükler gelip dizayn yaparlar. Geliştirme biriminden birileri gelip işi geliştirir. Test biriminden birileri testi yapar ve kullanıcı olaya dahil edilir. Eğer Geliştirme biriminden gelen kişi analizde bir sorunla karşılaşıp analizi yapan kişiyi ararsa muhtemelen ulaşamayacaktır. Ulaştığındaysa o projenin analizini 3 ay önce yaptığını ve şuan sorduğu bölümle ilgili hiç birşey hatırlamadığını ama analiz dokümanının eksiksiz, tam ve doğru olduğuna dair hafif serzenişli bir karşılık alacaktır. Bu karşılığı verirken analistin herhangi bir suçu yoktur. 3 ay önce yapılan bir işi hatırlaması beklenemez. Farklı birimlerdeki farklı kişilerin farklı zamanlarda birbirinin devamı olan bir işi yürütmesi ve bu işin sonunda başarılı olunması mucize gibidir.
Yazılım geliştirip bu sahneyi yaşamayan var mı?
Her adımda doküman oluşturulur
Dokümantasyon, Royce’un makalesinde bahsettiği ve çok önem verdiği bir konudur. Makalesinde tam olarak şu ifade yer almaktadır;
“Bir örnek olarak karşılaştırma yapılabilmesi için şunu söylemek istiyorum. Beş milyon dolarlık bir donanımı temin etmek için yeterince detaylı otuz sayfalık bir şartname beklerim. Beş milyon dolarlık bir yazılımı temin etmek içinse bunu başarılı bir şekilde kontrol edebilmem için binbeşyüz sayfalık bir doküman beklerim.”
Peki projenin başarılı olabilmesi için gerçekten bu kadar detaylı dokümanlara ihtiyaç var mı? Bu kadar çok ve detaylı doküman oluşturmak için harcanan emek, para, zaman ve enerji çalışan yazılımın başarılı ve kaliteli olması için harcanması daha doğru değil mi?
Benim karşılaştığım problemler bunlar. Eminim ki bunlar ve benzeri durumlarla sizlerde karşı karşıya geldiniz. Bu durum zaten zor olan işi dahada zorlaştırdı. Sadece işi zorlaştırmakla kalmadı iş dışındaki yaşamınızıda etkiledi. Daha doğru daha başarılı ve daha mutlu projeler geliştirmek ve hayatın her alanında mutlu olmak için artık değişim başlamalıdır!