Şelale efsanesi

Sahadan bir an

Salı öğleden sonra, bilgi işlemin toplantı odası. Onur, tablet formu projesini anlatmak için küçük bir sunum hazırlamış. Ilgın ve Recep Bey dinliyor. Ekranda aşağı doğru basamaklanan kutular var: gereksinim, tasarım, kodlama, test, kullanım.

Onur: Bu, şelale modeli. 1970'te Royce adında biri önermiş. Her aşama bitince öbürüne geçilir, geri dönülmez. Biz böyle çalışmıyoruz; bu eski usul.

Recep Bey: Bizim fabrikada her şey böyle yürür ama. Önce tasarım, sonra kalıp, sonra deneme.

Onur: Yazılımda işe yaramadığı kanıtlandı. Royce'un kendisi bile sonradan vazgeçmiş diyorlar.

Ilgın: Haluk Bey'e bu modeli sormuştum. "Royce'un makalesini okudun mu?" dedi. Okumamıştım.

Onur: Ben de okumadım aslında. Herkes biliyor.

Onur'un sunumunda üç iddia var: Royce şelaleyi önerdi, şelale yazılımda işe yaramaz ve Royce sonradan vazgeçti. "Herkes biliyor" cümlesi de dördüncüsü. Ama Royce'un makalesine bakınca hikâye farklı çıkıyor ve farkın dersi, şelalenin kendisinden daha önemli: bir yöntemin hikâyesi, çoğu zaman kaynağı okunmadan, sunumdan sunuma taşınarak şekillenir. Şelalenin hikâyesi bunun en bilinen örneklerinden biri; burada onu kaynağına kadar izliyoruz. Herkesin bildiği şey, çoğu zaman kimsenin kendi gözüyle okumadığı şeydir; Onur'un son cümlesi bunu farkında olmadan itiraf ediyor.

Kavram

Proje ve yazılım dünyasında "şelale" kelimesi, belirli bir çalışma biçimini anlatmak için kullanılır.

Popüler anlatıda şelale modelinin kaynağı, Winston Royce'un 1970'te yayımlanan "büyük yazılım sistemlerinin geliştirilmesini yönetmek" üzerine makalesidir. Makalede gerçekten de basamaklı bir şekil vardır. Ama Royce o şekli bir öneri olarak değil, bir başlangıç noktası olarak çizer ve hemen ardından onun riskli olduğunu yazar.

Royce'un itirazı şuydu: doğrusal sırada, test aşaması en sonda gelir ve ancak orada, sistemin gerçekten çalışıp çalışmadığı görülür. Testte ortaya çıkan büyük bir sorun, tasarıma, hatta gereksinimlere geri dönmeyi gerektirebilir; o noktada bunun maliyeti çok yüksektir. Royce bu yüzden temel yaklaşıma beş özellik eklenmesini önerdi: tasarım çalışmasını erken başlatmak, tasarımı ayrıntılı belgelemek, sistemin bir ilk sürümünü yapıp ondan öğrenerek işi iki kez yapmak, testi planlamak ve izlemek ve müşteriyi sürece resmî olarak katmak. Bu beş özelliğin ortak noktası, doğrusal sırayı geri bildirim döngüleriyle desteklemekti.

Hikâyenin tersine çevrilmesi de bir o kadar dikkatli olmayı gerektirir. Royce'un önerdiği, bugünkü çevik yöntemler değildi. Belgeleme konusunda, Morgan'ın aktardığına göre, Royce'un görüşü "epey çok" belge, programcıların ve analistlerin çoğunun istediğinden fazlasıydı. Royce yinelemeyi ve müşteri katılımını savundu, ama bunu ağır bir tasarım ve belge disiplini içinde savundu. Onu şelalenin babası yapmak yanlıştır; onu çevikliğin habercisi yapmak da abartıdır.

Recep Bey'in itirazı da haklı bir noktaya dokunuyor. Fabrikada bir kalıbın önce tasarlanıp sonra işlendiği, sonra denendiği doğrusal sıra kendi başına yanlış değildir; bir kalıbı yarı tasarlayıp işlemeye başlamak çoğu zaman pahalı bir hatadır. İlk derslerde gördüğümüz gibi, doğrusal sıra, ne yapılacağının baştan bilindiği ve sonradan değişmesinin pahalı olduğu işlerde iyi çalışır. Royce'un itirazı da sıranın kendisine değil, büyük yazılım sistemlerinde, yani ne yapılacağının tam bilinmediği bir alanda, test edilmeden sona kadar gidilmesine yönelikti. Efsane bu bağlamı silip bir yöntem kavgası yarattı.

Efsanelerin bu biçimde şekillenmesi yalnızca yazılıma özgü değildir. Bir mahalle derneğinin her yıl düzenlediği şenliğini düşün. Yıllardır "kurucular böyle istemişti" denerek şenlik hep aynı biçimde yapılıyor. Biri sonunda derneğin kuruluş tutanağını açtığında, kurucuların aslında şenliğin her yıl değiştirilmesini ve gençlere bırakılmasını önerdiğini görüyor. Kimse yalan söylememiş; hikâye, tutanağı okumayan kuşaklar boyunca yavaş yavaş tersine dönmüş.

Perde arkası

Royce'un makalesine bu ders için doğrudan ulaşılamadı; yazının kaynağı olarak elimizde, makaleden geniş alıntılar yapan sonraki bir değerlendirme var. Bu yüzden Royce'un sözleri aşağıda o değerlendirme üzerinden aktarılıyor.

Bu kanıt kartının kendisi de dersin konusunu tekrar ediyor: bir kaynağı, kendisine ulaşamadığımızda, başka birinin aktarımıyla okuyoruz. Fark şu ki bunu açıkça söylüyoruz. Efsaneler, aktarımın aktarım olduğu unutulduğunda doğar.

Yaygın yanılgılar

İki sürüm

Toplantıdan sonra Onur, sunumunun o sayfasını yeniden yazmaya karar veriyor. Aynı sayfa, iki sürüm.

Zayıf sürüm

Başlık: Şelale modeli

Kaynak: Royce, 1970

Not: Royce'un önerdiği doğrusal model; yazılımda işe yaramadığı kanıtlandı, Royce da sonradan vazgeçti.

Güçlü sürüm

Başlık: Doğrusal geliştirme sırası

Kaynak: Royce, 1970; Royce bu sırayı çizip hemen ardından "riskli ve başarısızlığa davetiye çıkarır" diye yazmış.

Royce'un önerisi: Erken tasarım, ayrıntılı belge, işi iki kez yapmak, planlı test ve müşteri katılımı.

Bizim projemiz için anlamı: Tablet formunu tek seferde teslim etmek yerine bir ilk sürümü bir vardiyada deniyoruz; Royce'un "iki kez yap" önerisine yakın.

Not: Makalenin aslı henüz okunmadı; alıntılar ikincil bir kaynaktan.

Zayıf sürüm, Onur'un sözlü anlatımını yazıya döküyor ve üç yanlış iddiayı bir kaynak satırının arkasına yerleştiriyor. "Kaynak: Royce, 1970" satırı, okuyana makalenin bunu söylediği izlenimini veriyor; oysa makale tersini söylüyor. Güçlü sürüm birkaç şeyi değiştiriyor. Başlıktan "şelale" etiketini çıkarıp ne anlatıldığını adlandırıyor. Royce'un asıl görüşünü ve önerilerini kısaca aktarıyor. Bunu kendi projelerine bağlıyor: ilk derslerde tasarladıkları tek vardiyalık deneme, Royce'un önerilerinden birine yakın. Son satır belki en önemlisi: Onur, kaynağı kendisinin okumadığını sayfaya yazıyor. Bu bir zayıflık değil; bir sonraki okuyucunun aynı aktarımı bir gerçek sanmasını önleyen bir dürüstlük.

Bağlam notu

Efsaneleri düzeltmenin de bir tuzağı var: her düzeltme, yeni bir efsane doğurabilir. "Royce şelaleyi önerdi" yanılgısını düzelten biri, "Royce aslında çevikti" diye ters bir yanılgıya savrulabilir. Bir yöntemin tarihini doğru anlatmak, onu bugünkü tartışmada bir tarafın silahı yapmaktan kaçınmayı gerektirir.

Neyle bileceğiz? Bir yöntemin kökeni hakkındaki bir iddiayı sınamanın yolu, mümkünse birincil kaynağa gitmek, gidemiyorsak bunu açıkça söylemektir. Bu ders, Royce'un makalesine doğrudan ulaşamadığını ve onu bir başkasının alıntıları üzerinden okuduğunu açıkça belirtti. Makaleye ulaşabilen bir okur, buradaki aktarımı aslıyla karşılaştırmaya her zaman davetlidir. Bir sunumda, bir raporda ya da bir toplantıda aynı dürüstlük, "herkes biliyor" cümlesinin yerini alabilir: "Ben aslını okumadım, şu kaynaktan aktarıyorum."

Uygulama

Retro sorusu

Son kez bir toplantıda "herkes biliyor" diye anlattığın bir şeyin kaynağını kendin okumuş muydun?

Kapanış

1. Royce 1970'te doğrusal geliştirme sırasını çizdi, ama onu riskli bulduğunu yazdı ve beş ek özellik önerdi; şelalenin mucidi sayılması bir efsanedir.
2. Ters yöndeki efsane de yanlıştır: Royce yineleme ve müşteri katılımı istedi, ama ağır bir tasarım ve belge disiplini içinde.
3. Bir yöntemin hikâyesini birincil kaynağa götürmek, gidemiyorsak bunu açıkça söylemek, "herkes biliyor" cümlesinin yerini almalıdır.

Beş soru

1. Onur'un sunumundaki "Royce şelaleyi önerdi" iddiası neden yanlıştır?
2. Royce'a göre doğrusal sıranın asıl riski neydi?
3. Royce'un önerdiği beş özellikten hangisi Ilgın'ın tablet formu için tasarladığı tek vardiyalık denemeye en çok benziyor?
4. Bir dernekte yıllardır "kurucular şenliğin hep aynı yapılmasını istemişti" deniyor. Bu cümleyi nasıl sınarsın?
5. Bu dersin perde arkasında Royce'un makalesine doğrudan değil, bir başkasının alıntıları üzerinden dayanıldığının açıkça söylenmesi neden önemlidir?

Yanıtlar

1. Çünkü Royce doğrusal sırayı çizdikten hemen sonra onun riskli olduğunu ve başarısızlığa davetiye çıkardığını yazdı; makalenin geri kalanı bu riski azaltacak beş özelliği anlatır. Bir eleştiriyi bir öneri gibi okumak efsaneyi doğurdu.
2. Testin en sonda gelmesi: sistemin gerçekten çalışıp çalışmadığı ancak orada görülür ve büyük bir sorun tasarıma ya da gereksinimlere geri dönmeyi gerektirirse bunun maliyeti çok yüksektir.
3. "İşi iki kez yap": sistemin bir ilk sürümünü yapıp ondan öğrenmek. Çekici yanlış cevap "müşteriyi kat" olurdu; o da ilgili ama tek vardiyalık deneme her şeyden önce bir ilk sürümden öğrenme fikridir.
4. Derneğin kuruluş tutanağına ya da kurucuların yazılı bir belgesine bakarak; belge yoksa hâlâ ulaşılabilen bir kurucuya sorarak. Ulaşılamıyorsa cümleyi bir aktarım olarak anlatmak ve bir kural gibi uygulamamak gerekir.
5. Çünkü efsaneler, aktarımın aktarım olduğu unutulduğunda doğar. Kaynağın ikincil olduğunu açıkça söylemek, okura nüansların farklılaşabileceğini hatırlatır ve dersin kendisinin bir sonraki efsanenin kaynağı olmasını önler.

Sonraki derse köprü

Royce'un makalesi, büyük yazılım projelerinin neden zorlandığını soran bir dönemin ürünüydü. O dönemin bir adı vardı: yazılım krizi. 2.7, 1960'ların sonundaki bu krizden 2001'de yazılan Çevik Manifesto'ya uzanan yolu ve yinelemeli geliştirmenin uzun tarihini izliyor.