📋 İçindekiler
- Şelale (Waterfall) Modelinin Çöküşü
- Agile Manifesto: 4 Değer, 12 İlke
- Yalın Girişim (Lean Startup)
- MVP: Minimum Çalışabilir Ürün
- Build-Measure-Learn Döngüsü
- Pivot mi Yoksa Devam mı
- Scrum Çerçevesi
- Sprint Döngüsü: Adım Adım
- Kanban vs Scrum
- Agile Metrikleri
- Ölçekleme: SAFe ve LeSS
- Vaka 1: Spotify Modeli
- Vaka 2: Üretim Sektöründe Agile
- Sonuç: Ne Zaman Agile, Ne Zaman Waterfall
1. Şelale (Waterfall) Modelinin Çöküşü
Sanayi devriminden gelen klasik proje yönetimi "Şelale (Waterfall)" modelidir:
| Aşama | Süre | Çıktı |
|---|---|---|
| 1. Gereksinim Analizi | 3-6 ay | 500 sayfalık spesifikasyon belgesi |
| 2. Tasarım | 3-6 ay | Mimari ve detay tasarım dokümanları |
| 3. Geliştirme (Kodlama) | 6-12 ay | Yazılım/ürün |
| 4. Test | 3-6 ay | Hata raporları |
| 5. Dağıtım (Deployment) | 1-3 ay | Canlı ürün |
| TOPLAM | 16-33 ay | 2 yıl sonra kullanıcıların görmesi! |
Standish Group CHAOS Raporu (2024):
Waterfall projelerinin sadece %14'ü başarılı. %52'si gecikmeli/bütçe aşımlı teslim, %34'ü tamamen iptal ediliyor!
Agile projelerinde başarı oranı: %42 (3× daha iyi).
Waterfall projelerinin sadece %14'ü başarılı. %52'si gecikmeli/bütçe aşımlı teslim, %34'ü tamamen iptal ediliyor!
Agile projelerinde başarı oranı: %42 (3× daha iyi).
2. Agile Manifesto: 4 Değer, 12 İlke
2001'de 17 yazılım geliştiricisi Utah'ta bir kayak tesisinde buluşarak Agile Manifesto'yu yazdı. 4 temel değer:
| Değer Verilen | Daha Az Değer Verilen | |
|---|---|---|
| Bireyler ve etkileşimler | → | Süreçler ve araçlar |
| Çalışan yazılım/ürün | → | Kapsamlı dokümantasyon |
| Müşteri ile işbirliği | → | Sözleşme müzakeresi |
| Değişime yanıt verme | → | Bir planı takip etme |
12 Agile İlkesinin Özeti:
1. Müşteri memnuniyeti en yüksek önceliktir
2. Değişen gereksinimler hoş karşılanır
3. Çalışan ürün sık sık teslim edilir (haftalar-aylar)
4. İş insanları ve geliştiriciler birlikte çalışır
5. Motivasyonlu bireyler — güven ve destek ortamı
6. En verimli iletişim: yüz yüze konuşma
7. Çalışan ürün = ilerlemenin ölçüsü
8. Sürdürülebilir tempo
9. Teknik mükemmelliğe sürekli dikkat
10. Sadelik (yapılmayan iş en iyi mühendisliktir)
11. Kendi kendini organize eden ekipler
12. Düzenli retrospektif — sürekli iyileştirme
1. Müşteri memnuniyeti en yüksek önceliktir
2. Değişen gereksinimler hoş karşılanır
3. Çalışan ürün sık sık teslim edilir (haftalar-aylar)
4. İş insanları ve geliştiriciler birlikte çalışır
5. Motivasyonlu bireyler — güven ve destek ortamı
6. En verimli iletişim: yüz yüze konuşma
7. Çalışan ürün = ilerlemenin ölçüsü
8. Sürdürülebilir tempo
9. Teknik mükemmelliğe sürekli dikkat
10. Sadelik (yapılmayan iş en iyi mühendisliktir)
11. Kendi kendini organize eden ekipler
12. Düzenli retrospektif — sürekli iyileştirme
3. Yalın Girişim (Lean Startup)
Eric Ries'in 2011'deki "The Lean Startup" kitabı, endüstriyel Yalın (Lean) felsefesini girişimcilik ve ürün geliştirmeye uyarlamıştır. Ana fikir: Kötü veya gereksiz bir özelliği mükemmelce geliştirmek, dünyanın en büyük mühendislik israfıdır.
| Kavram | Toyota (Yalın Üretim) | Lean Startup |
|---|---|---|
| İsraf (Muda) | Fazla üretim, stok, bekleme | Kimsenin istemediği özellik geliştirmek |
| Değer | Müşterinin para ödediği şey | Müşterinin problemi çözen şey |
| Akış | Malzeme + bilgi akışı | Fikir → MVP → Geri bildirim döngüsü |
| Çekme | Kanban ile talep bazlı üretim | Müşteri verisiyle yönlendirme |
| Mükemmellik | Kaizen — sürekli iyileştirme | Iteration — sürekli öğrenme |
4. MVP: Minimum Çalışabilir Ürün
MVP, yarım yamalak bir ürün değil — müşterinin temel problemini çözen en küçük çekirdek değerdir.
| Şirket | MVP | Test Ettiği Hipotez |
|---|---|---|
| Dropbox | 3 dakikalık animasyon videosu (kod yok!) | "İnsanlar dosya senkronizasyonu ister mi" |
| Zappos | Ayakkabı fotoğrafları çekip online satış (stok yok!) | "Online ayakkabı satın alırlar mı" |
| Airbnb | Kendi dairelerinin fotoğraflarını yayınlama | "Yabancıların evinde kalmak isterler mi" |
| Buffer | Sadece "fiyat planı" sayfası (ürün yok!) | "Bu hizmet için para öderler mi" |
5. Build-Measure-Learn Döngüsü
Build (Yap) → MVP veya özellik geliştir
⬇
Measure (Ölç) → A/B test, analitik, müşteri görüşmeleri
⬇
Learn (Öğren) → Hipotez doğrulandı mı Pivot mi devam mı
⬇
🔁 Tekrarla (bu döngü ne kadar kısa olursa o kadar iyi)
⬇
Measure (Ölç) → A/B test, analitik, müşteri görüşmeleri
⬇
Learn (Öğren) → Hipotez doğrulandı mı Pivot mi devam mı
⬇
🔁 Tekrarla (bu döngü ne kadar kısa olursa o kadar iyi)
5.1 Innovation Accounting (İnovasyon Muhasebesi)
| Gösterge Türü | Vanity Metric (Sahte) ❌ | Actionable Metric (Gerçek) ✅ |
|---|---|---|
| Kullanıcı | Toplam kayıt sayısı | Haftalık aktif kullanıcı (WAU) |
| Gelir | Toplam ciro | Müşteri Yaşam Boyu Değeri (CLV) |
| Büyüme | Sayfa görüntüleme | Dönüşüm oranı (conversion rate) |
| Maliyet | Toplam harcama | Müşteri Edinme Maliyeti (CAC) |
6. Pivot mi Yoksa Devam mı
Pivot, stratejinin bir bacağını değiştirip diğerini sabit tutmaktır — tamamen yeniden başlama değildir.
| Pivot Türü | Açıklama | Ünlü Örnek |
|---|---|---|
| Müşteri Segmenti | Aynı ürün, farklı hedef kitle | YouTube: flört sitesi → video platform |
| Zoom-In | Bir özellik tüm ürün olur | Instagram: check-in uygulaması → fotoğraf filtresi |
| Zoom-Out | Ürün bir özelliğe dönüşür | Flickr: online oyun → fotoğraf paylaşım |
| Platform | Uygulama → platform veya tersi | Apple: bilgisayar → ekosistem |
| İş Modeli | Gelir modeli değişir | Spotify: satış → abonelik |
| Kanal | Dağıtım kanalı değişir | Dell: perakende → doğrudan online satış |
7. Scrum Çerçevesi
Agile felsefenin en yaygın uygulama çerçevesi Scrum'dır. Dev projeyi "Sprint" adı verilen 2-4 haftalık kısa koşulara böler.
7.1 Scrum Rolleri
| Rol | Sorumluluk | Karar Alanı |
|---|---|---|
| Product Owner | Pazarı ve müşteriyi temsil eder; Product Backlog'u yönetir | NE yapılacak |
| Scrum Master | Engelleri kaldıran "hizmetkâr lider" (servant leader) | Sürecin düzgün işlemesi |
| Development Team | Çok disiplinli, kendi kendini organize eden 3-9 kişi | NASIL yapılacak |
7.2 Scrum Etkinlikleri
| Etkinlik | Süre | Amaç |
|---|---|---|
| Sprint Planning | 2-4 saat | Sprint hedefi belirle, backlog'dan item seç |
| Daily Standup | 15 dakika | 3 soru: Dün ne yaptım Bugün ne yapacağım Engel var mı |
| Sprint Review | 1-2 saat | Tamamlanan işi stakeholder'lara göster |
| Sprint Retrospective | 1-1.5 saat | Ne iyi gitti Ne kötü gitti Nasıl iyileştiririz |
8. Sprint Döngüsü: Adım Adım
Sprint (2 Hafta) Akışı:
📋 Pazartesi (Gün 1): Sprint Planning — Product Backlog'dan 5-8 User Story seç
📊 Her Gün: 15 dk Daily Standup + iş yapma
🔨 Geliştirme: Kod yazma, test, entegrasyon (Gün 2-9)
✅ Cuma (Gün 10): Sprint Review — çalışan ürünü göster
🔍 Cuma PM: Sprint Retrospective — süreci iyileştir
🔁 Sonraki Pazartesi: Yeni Sprint başlar!
📋 Pazartesi (Gün 1): Sprint Planning — Product Backlog'dan 5-8 User Story seç
📊 Her Gün: 15 dk Daily Standup + iş yapma
🔨 Geliştirme: Kod yazma, test, entegrasyon (Gün 2-9)
✅ Cuma (Gün 10): Sprint Review — çalışan ürünü göster
🔍 Cuma PM: Sprint Retrospective — süreci iyileştir
🔁 Sonraki Pazartesi: Yeni Sprint başlar!
8.1 User Story Formatı
"Bir [kullanıcı türü] olarak, [bir hedefe ulaşmak] istiyorum, çünkü [bir değer/fayda]."
Örnek: "Bir üretim müdürü olarak, gerçek zamanlı OEE dashboard'u görmek istiyorum, çünkü darboğazları anında tespit edebilmeliyim."
Kabul Kriterleri:
✅ Dashboard 5 saniye içinde yüklenmeli
✅ OEE, Availability, Performance, Quality ayrı ayrı gösterilmeli
✅ Son 24 saatlik trend grafiği olmalı
Örnek: "Bir üretim müdürü olarak, gerçek zamanlı OEE dashboard'u görmek istiyorum, çünkü darboğazları anında tespit edebilmeliyim."
Kabul Kriterleri:
✅ Dashboard 5 saniye içinde yüklenmeli
✅ OEE, Availability, Performance, Quality ayrı ayrı gösterilmeli
✅ Son 24 saatlik trend grafiği olmalı
9. Kanban vs Scrum Karşılaştırması
| Kriter | Scrum | Kanban |
|---|---|---|
| Kadans | Sabit Sprint (2-4 hafta) | Sürekli akış (zaman kutusu yok) |
| Roller | PO, SM, Dev Team (zorunlu) | Zorunlu rol yok |
| Planlama | Sprint başında planlama | Sürekli — Backlog'dan çekilir |
| WIP Limiti | Sprint kapasitesi ile dolaylı | Her sütun için açık WIP limiti |
| Tahta | Sprint sonunda sıfırlanır | Sürekli (kartlar akar) |
| Değişiklik | Sprint içinde değişmez | İstediğin zaman yeni iş ekleyebilirsin |
| En iyi kullanım | Ürün geliştirme, yazılım projeleri | Operasyon, destek, DevOps, bakım |
10. Agile Metrikleri
| Metrik | Ne Ölçer | Hedef |
|---|---|---|
| Velocity | Sprint'te tamamlanan story point toplamı | Stabil (artırma baskısı yapılmamalı!) |
| Sprint Burndown | Sprint içinde kalan iş miktarı trenidi | İdeal çizgiye yakın azalma |
| Lead Time | İş talebinden teslime geçen süre | Minimize et |
| Cycle Time | İş başladığında tamamlanana kadar süre | Minimize et |
| Cumulative Flow | WIP durumu görselleştirme (Kanban) | Düz ve stabil bantlar |
| Escaped Defects | Üretime kaçan hata sayısı | Sprint bazında azalma trendi |
11. Ölçekleme: SAFe ve LeSS
Scrum 3-9 kişilik ekipler içindir. 50-500 kişilik organizasyonlarda ölçekleme çerçeveleri gerekir:
| Çerçeve | Ölçek | Özellik |
|---|---|---|
| SAFe (Scaled Agile) | 50-1000+ kişi | En yaygın, en kapsamlı. PI Planning (10 haftalık döngüler) |
| LeSS (Large-Scale Scrum) | 10-50 kişi (2-8 takım) | Scrum'ı minimum eklemeyle ölçekler |
| Spotify Modeli | Değişken | Squad, Tribe, Chapter, Guild yapısı |
| Nexus | 3-9 takım | Scrum.org tarafından geliştirildi, entegrasyon odaklı |
12. Vaka Çalışması 1: Spotify Modeli
🎵 Spotify — Otonom Takımlar ile Ölçekleme
Spotify, geleneksel hiyerarşik yapıyı terk ederek matris organizasyon modeli kurdu:
| Yapı | Boyut | İşlev |
|---|---|---|
| Squad | 6-12 kişi | Otonom mini-startup — kendi ürün alanına sahip |
| Tribe | 40-150 kişi | İlişkili Squad'ların birleşimi (Dunbar sayısı!) |
| Chapter | Değişken | Aynı uzmanlık alanındaki kişiler (ör. tüm backend geliştiriciler) |
| Guild | Gönüllü | İlgi alanı toplulukları (ör. "web performansı" guilde) |
Sonuç: 2.000+ mühendis, haftada 200+ deploy, müşteri memnuniyetinde sektör lideri.
13. Vaka Çalışması 2: Üretim Sektöründe Agile
🏭 Otomotiv Yan Sanayi — Agile Ürün Geliştirme
Problem: Yeni bir fren kaliperi tasarımı 18 ayda tamamlanıyor, müşteri (OEM) değişiklik istediğinde yeniden başlamak gerekiyor.
Agile dönüşüm:
- 18 aylık plan → 3 haftalık Sprint'ler
- Her Sprint sonunda 3D baskı prototip + müşteri geri bildirimi
- Çapraz-fonksiyonel ekip: tasarım + simülasyon + test + üretim mühendisleri
- Dijital İkiz (Digital Twin) ile Sprint içinde simülasyon
| Metrik | Waterfall | Agile | İyileşme |
|---|---|---|---|
| Geliştirme süresi | 18 ay | 9 ay | %50 azalma |
| Tasarım değişikliği maliyeti | ₺2.5M | ₺400K | %84 azalma |
| Müşteri memnuniyeti | %65 | %92 | +27 puan |
| İlk seferde doğru (FTR) | %40 | %78 | +38 puan |
14. Sonuç: Ne Zaman Agile, Ne Zaman Waterfall
| Kriter | Waterfall ✅ | Agile ✅ |
|---|---|---|
| Gereksinimler | Sabit, değişmez | Belirsiz, değişebilir |
| Proje türü | Köprü, bina, uçak | Yazılım, ürün, hizmet |
| Geri bildirim | Sonuçta alınır | Her iterasyonda alınır |
| Risk | Düşük belirsizlik | Yüksek belirsizlik |
| Düzenleme | FDA, havacılık vb. uyumluluk | Hızlı pazar gereksinimi |
Altın Kural: Endüstri mühendisi olarak hibrit yaklaşımı benimseyin — planlama ve fizibilite Waterfall, geliştirme ve teslimat Agile. Asıl başarı, doğru aracı doğru bağlamda kullanmaktır.