Şelale modeli: sıralı aşamalarla ilerleyen proje yaklaşımı

Şelale modeli nedir?

Şelale (waterfall) modeli, bir işin birbirini izleyen aşamalarla yürütüldüğü sıralı yaklaşımdır. Her aşama bir öncekinin çıktısı üzerine kurulur ve akış, suyun basamaklardan akması gibi tek yönde ilerler. Geleneksel proje yönetimi denince çoğunlukla bu yapı kastedilir.

Model yazılımla anılsa da fikir yazılıma özgü değildir: inşaat, üretim ve donanım projeleri de gereksinimden teslime sıralı ilerleyen planlarla yürür. Planın büyük bölümü baştan yapılır ve çalışma bu plana göre ilerlediği için yaklaşım plan odaklı diye de adlandırılır.

Aşamalar nasıl ilerler?

Anlatımlara göre aşama adları ve sayısı değişse de çekirdek sıra aynıdır. Önce sistem ve yazılım gereksinimleri çıkarılır ve onaylanır. Ardından çözümün tasarımı yapılır; tasarımın üzerine geliştirme, yani kodlama ya da üretim gelir. Sonra birleştirilen ürün test edilir ve doğrulanır. Son olarak ürün devreye alınır, işletilir ve bakımı yapılır.

Her geçişte genellikle bir onay noktası bulunur. Bu onaylar belgelenmiş bir iz bırakır: kim neyi ne zaman onayladı sorusunun yanıtı hazırdır. Bu özellik, sözleşme ve denetim gerektiren işlerde şelaleyi çekici kılar.

Nerede işe yarar?

Şelale, gereksinimlerin baştan iyi bilindiği, kapsamın büyük ölçüde sabit olduğu ve sonradan değişikliğin pahalı olduğu işlerde güçlüdür. Bir binanın yapısal tasarımı bitmeden temel atılmaz; bir donanım parçası üretime girdikten sonra tasarım değişikliği zor ve maliyetlidir. Böyle işlerde sıralı plan, bütçe ve takvim tahminini kolaylaştırır.

Çok sayıda tarafın, tedarikçinin ya da düzenleyicinin bulunduğu projelerde belgelenmiş aşamalar ortak dil sağlar. Yeni katılan biri belgelere bakarak projenin nerede olduğunu anlayabilir. Bu yüzden şelale, inşaat gibi sektörlerde hâlâ konuşulan bir yaklaşımdır.

Sınırları nelerdir?

Şelalenin temel sorunu geri bildirimin geç gelmesidir. Müşteri çalışan ürünü çoğu zaman en sonda görür; gereksinimin yanlış anlaşıldığı ya da zamanla değiştiği o zaman ortaya çıkarsa düzeltme pahalıya patlar. Analiz ile tasarımı kesin çizgiyle ayırmak da pratikte zordur, çünkü uygulama başladıktan sonra tasarımın göremediği ayrıntılar belirir.

Belirsizliğin yüksek olduğu, ürünün keşfederek şekillendiği işlerde bu yapı bir engele dönüşebilir. Bu nedenle bu tür işlerde çevik yaklaşımlar ya da ikisini birleştiren hibrit yapılar tercih edilir. Hangisinin uygun olduğu, ayrıntılı bir karşılaştırma gerektiren ayrı bir sorudur.

Royce'un makalesi aslında ne diyor?

Şelale modelinin kaynağı olarak sık anılan makale, Winston Royce'un büyük yazılım sistemlerinin yönetimi üzerine yazdığı metindir. Makalede sıralı akış temel bir çerçeve olarak gösterilir ama Royce hemen ardından bu uygulamanın riskli olduğunu ve başarısızlığa davetiye çıkardığını söyler. Gerekçesi, sistemin gerçek davranışının ancak test aşamasında görülmesi ve orada çıkan sorunların büyük bir yeniden tasarım gerektirebilmesidir.

Royce riski azaltmak için beş ek özellik önerir: ön program tasarımı, tasarımın ayrıntılı belgelenmesi, işi iki kez yapmak (ilk sürümü erken bir benzetim gibi kullanmak), testi planlamak, denetlemek ve izlemek ve müşteriyi resmî biçimde sürece katmak. Makalede waterfall sözcüğü geçmez. Başka bir deyişle sıralı akışı savunmaktan çok, tek geçişli sıralı akışın neden yetmediğini anlatır.

Proje yönetimi programlarında yeri

Şelale mantığını bilmek, hangi yaklaşımın ne zaman seçileceğini anlamanın ön koşuludur. Mindset'in Hibrit Proje Yöneticiliği Sertifika Programı proje yönetimi temellerini ve şelale disiplinini, ardından hibrit yaklaşım ve metodoloji seçimini işler. IT Proje Yönetimi Sertifika Programı ise yazılım projelerinde planlama, kalite güvencesi ve test yönetimi gibi konulara odaklanır.