Hangi Projede Hangi Metodoloji? — 18 Yıllık Bir Geliştiricinin Notları
Waterfall mı, Agile mı, Hybrid mi? Soru yanlış. 18 yıllık production tecrübesinden bir karar matrisi, üç gerçek vaka ve metodoloji dininden çıkış.
Bir keresinde, aynı toplantıda iki proje yöneticisinin kavga ettiğini gördüm. Biri “Agile’a geçmeliyiz, bu Waterfall bizi yıkıyor” diye direniyordu. Diğeri “Agile bizi mahvedecek, müşterimiz sabit fiyat istiyor” diye direniyordu.
İkisi de haklıydı. İkisi de aynı dilden konuşmuyordu çünkü ikisi de soruyu yanlış soruyordu.
Yazılım metodolojisi tartışmalarının %80’i bu yanlış soruyu cevaplamaya çalışıyor: “Hangisi daha iyi?” Doğru soru hiçbir zaman bu değil. Doğru soru şu: “Hangi proje, hangi takım, hangi müşteri için hangisi?”
Bu yazıda doğru soruyu kuralım, cevaplayalım, ve metodoloji dininden — savunduğun yöntemi kimliğin sayma huyundan — çıkalım.
Soruyu Doğru Sormak
Bir metodoloji üç değişkenin kesişiminde yaşar:
- Proje tipi — gereksinimleri ne kadar net? Erken yanlış kararın maliyeti ne?
- Takım büyüklüğü — 3 kişi mi, 30 kişi mi, 300 kişi mi?
- Müşteri/paydaş tipi — sürekli geri bildirim verebilen biri mi, yoksa “ben şunu istiyorum, üç ay sonra teslim et” diyen biri mi?
Üçü hakkında düşünmeden bir metodoloji seçmek, takım elbisesini ölçü almadan biçmek gibi. Sonra “bu metodoloji çalışmıyor” denir — ama çalışmayan metodoloji değil, yanlış kullanım.
Bu üç değişkenden üçüncüsü en sık atlanan ve çoğu zaman en belirleyici olan. Bir sonraki bölümde göreceksin.
Üç Metodolojinin Asıl Niyetleri
Tanımları herkes biliyor, atlıyorum. Asıl niyetlerine bakalım — çünkü orada hata yapılıyor.
Waterfall, Royce’un Eleştirisiyle Başladı
Çok az insanın bildiği bir nokta: Winston W. Royce’un 1970’teki orijinal makalesi Waterfall’ı savunmak için değil, eleştirmek için yazıldı. Royce bu modeli tarif ederken aslında “böyle yaparsanız başarısız olursunuz, iteratif olmalı” diyordu. Sonraki yıllarda makaleden ilk diyagram alındı, eleştirisi unutuldu, ve “Royce’un Waterfall’ı” diye yarım yüzyıl yanlış aktarıldı.
Bu önemli çünkü saf Waterfall’ı kimse savunmuyor. Savunulan şey “plan yapma disiplini” — ki bu Agile karşıtı değil.
Asıl niyet: Gereksinim belirsizliği sıfıra yakın olduğunda, planlamanın getirisi maksimumdur. Savunma, havacılık, finans regülasyonu, NASA’nın bir uydu yazılımı — bu projelerde “isterleri sprint sonunda gözden geçirelim” denmez. İstenenler önceden bellidir, sapma cezası ölümcüldür.
Agile, Küçük Takım İçin Tasarlandı
Agile Manifesto 2001’de 17 kişi tarafından yazıldı. Hepsi küçük takım/işbirliği savunucusuydu. Manifesto’nun ruhu: “Şu an bildiğimizden fazlasını bildiğimizi varsaymayalım, kısa döngülerde öğrenelim.”
Sonra Agile enterprise’a satıldı. SAFe, LeSS, DAD gibi enterprise scaling framework’leri çıktı — Agile’ın orijinal niyetinin neredeyse tersi: katmanlı, dokümantasyon ağır, üst-yönetim odaklı yapılar. “Scaled Agile” deyimi, “scaled küçük takım disiplini” gibi bir oksimoron.
Asıl niyet: Gereksinim belirsizliği yüksek ve takım küçük olduğunda, iteratif öğrenmenin getirisi maksimumdur. Startup MVP, ürün-pazar uyumu aranan SaaS, müşterinin “tam ne istediğini bilmediği” projeler.
Hibrit — Gerçek Dünyanın Adı
Saf Waterfall hiç yapılmaz, saf Agile da çok nadir. Gerçek dünyada çoğu projenin metodolojisi WaterScrumFall denen şey: üstte Waterfall (sözleşme, gereksinim dokümanı, sabit fiyat), altta Scrum (sprint, daily stand-up, retro). Müşteriye Waterfall gösteriliyor, takıma Agile yaşatılıyor.
Bu kötü değil — sadece dürüstçe adlandırılması gerekiyor. “Biz Agile’ız” demek, gerçekte WaterScrumFall yapıyorsan kendini kandırmak.
Asıl niyet: Belirsizlik ve kontrat ihtiyacı karışık olduğunda, hibrit gerçekçi tek seçenek. Tek koşulu var: bunu açıkça kabul etmek.
Karar Matrisi
| Senaryo | Önerilen Yaklaşım | Neden |
|---|---|---|
| Bir devlet ihalesi, yıllık 50 sayfa şartname | Waterfall | İstenenler donmuş, sapma cezalı |
| Yeni bir ürün için MVP, 3 kişilik takım, kurucunun “şunu test etmek istiyorum” yaklaşımı | Agile (sade Scrum/Kanban) | Gereksinim sürekli değişecek, küçük takım |
| Bir agency, sabit fiyatlı müşteri projesi, 6 ay teslim | Hibrit (üst kontrat + alt sprint) | İki dünyanın gerçeği |
| 100+ kişilik bir kurumsal ürün ekibi | Trunk-based + feature flag (technical) + Lightweight Agile (process) | Scaling problemi |
| Mobile uygulama, App Store yayın takvimi | Release-train (Agile + Waterfall’ın release planı) | Yayın takvimi sabit, ama sprint içeriği esnek |
| Bir kütüphane / SDK, sürümlü dağıtım | Semantic versioning + Waterfall benzeri release | API stabilitesi kritik |
| Bir hackathon, 48 saat | Hiçbiri — gerek yok, sadece çalış | Metodoloji overhead’i değer üretmez |
Anti-örnek: Bunları karıştırmak. “Hem develop branch’ımız var, hem sprint yapıyoruz, hem her özellik release branch’le çıkıyor, hem feature flag’ımız var” diyen takım, bütün disiplinlerin yarısını uygular, hiçbirinin avantajını alamaz. Bu konu özelinde Git workflow seçimi yazımda daha somut ele aldım.
Yaşadığım Üç Vaka
Vaka 1: Sabit Fiyatlı Projede Agile Dayatması
Bir agency’deydim. Müşteri sözleşmede “şu 28 özellik, şu tarihte teslim, şu fiyat” yazmıştı. Proje yöneticisi yeni almıştı SAFe sertifikasını, “Agile yapacağız” dedi.
İlk 2 sprint güzel gitti. Üçüncü sprint review’da müşteri “şunu da görmek isterdim” dedi. Yöneticimiz “tamam, backlog’a ekleyelim” dedi. Birkaç sprint sonra backlog 40 özelliğe çıktı. Sözleşme hâlâ 28 diyordu, bütçe sabit, takvim sabit.
Sonuç: ya kapsam taşması ile bütçe aşıldı (müşteri kabul etmedi), ya kalite çöktü (her şeyi yetiştirelim derken bug yığını), ya da takım yandı (akşam-hafta sonu çalışma). Üçü de oldu.
Ders: Agile’ın çalışması için scope’un değişebilir olması gerekir. Sabit fiyat + sabit kapsam + sabit takvim = Agile’ın temel önermesinin çiğnenmesi. Bu projede doğru yaklaşım Hibrit’ti — sözleşmeyle Waterfall sınırı çizilip, içeride sprint’lerle çalışılırdı. Ama “Agile yapıyoruz” iddiası, hibrit gerçeğinin kabul edilmesine engel oldu.
Vaka 2: Startup’ta Waterfall Denemesi
Erken aşama bir startup. Kurucu “6 aylık net bir plan yapalım, sonra başlayalım” dedi. Önce gereksinim analizi (3 hafta), sonra tasarım (2 hafta), sonra geliştirme başladı. 5. ayda lansmana yaklaşırken kurucu “aslında müşterilerle konuştum, asıl istedikleri X değil Y” dedi. 5 aylık iş, kurucunun kendi düşüncesindeki bir ürün için yapılmıştı; gerçek müşterinin istediği ürün için değil.
Ders: Gereksinim belirsizliği müşteri tarafında ise Waterfall imkânsızdır. Çünkü Waterfall’ın işlemesi için “doğru gereksinim önceden biliniyor” varsayımı şart. Startup’ta bu varsayım yapısal olarak yanlış. Kurucu kendi ürününü ne kadar bilse de, kullanıcının ne istediğini bilmiyor — onu ancak iteratif öğrenmeyle keşfeder.
Vaka 3: Hibrit’in İşe Yaradığı Bir Proje
Bir ihale projesi: müşteri devletti, sözleşme istiyordu, ama biz teknik tarafta gereksinimlerin yarısının net olmadığını biliyorduk.
Önerimiz: ilk 6 hafta discovery sprint’leri — gereksinimleri netleştirmek, prototip göstermek, müşteriyle birlikte iyileştirmek. Bu sürenin sonunda tam scope ve fiyat belirledik, sözleşmeyi imzaladık, sonra Scrum’la inşaata geçtik.
İki sözleşme imzaladık aslında: birincisi “discovery” için T&M (time & materials), ikincisi “build” için fixed scope. Müşteri her ikisinde de güvende hissetti çünkü ne için ne ödediğini biliyordu.
Ders: Hibrit “kararsızlık” değil. Hibrit, projenin bilinen ve bilinmeyen kısımlarını ayrı disiplinlerle yönetme kararı. Doğru kurulduğunda iki dünyanın da en iyi yanlarını alabilirsin — ama ön koşulu “biz Agile/Waterfall yapıyoruz” diyerek karar vermemek; dürüstçe karar haritası çıkarmak.
Hiçbir Metodoloji Saf Hâlinde Uygulanmıyor
Bir gerçeği kabul edelim: 2026’da “biz tam saf Scrum yapıyoruz” diyen şirketin %90’ı aslında daily stand-up + sprint planning yapıyor, üzerine de PO/PM kararıyla scope değişiyor.
“Tam saf Waterfall” da yok. En katı regülasyon altında çalışan finansal kurumlarda bile, geliştirme sürecinde küçük iterasyonlar var.
Metodolojiler birer prensip koleksiyonu. Sen her prensibi tek tek alıp projene uygun olanı uygulamakla yükümlüsün. “Scrum’ı tam uygulamıyoruz çünkü daily stand-up yerine haftalık yapıyoruz” demek bir başarısızlık değil — bu adaptasyon. Adaptasyonu kabul etmek ve adlandırmak başarısızlık değil; adapt etmediğini iddia etmek başarısızlık.
Senior bir geliştiricinin işi metodoloji uygulamak değil, sorun çözmektir. Metodoloji bir kutu alettir. Sen elindeki kutu aletine göre marangoz olamazsın, marangoz olarak kutudan istediğini alırsın.
Kapanış: Metodoloji Bir Araçtır, Kimlik Değil
Genç developerlarda sık görüyorum: “ben Agile’cıyım” der, “Waterfall pis bir şey” der. Tartışmalarda da metodoloji savunması yapar — savunduğu metodoloji bir takım rengi gibi. :)
Eminim 15 yıl sonra aynı geliştirici, “bu projeye Waterfall daha uygun” veya “bu takımda Scrum çalışmaz, Kanban deneyelim” diyecek. Çünkü artık bir aracı savunmaya değil, bir sorunu çözmeye odaklanmıştır.
Soru “hangisi daha iyi” değil. Soru: karşımdaki proje, takım ve müşteri için, üç metodolojiden hangisinin prensipleri daha çok işe yarar? Bu soruyu cevaplayabiliyorsan, hangi etiketi kullandığının önemi yok. Cevaplayamıyorsan, en sevdiğin metodolojiyi kullansan da çıkmaz sokaktasın.
Metodoloji yöntemdir. Sen yöntemi seçen kişisin. Tersini iddia eden herkes, sana bir şey satmaya çalışıyordur.