İçeriğe geç
Yazılım Geliştirme Yaşam Döngüsü Tasarımı (SDLC)

Yaklaşım

İyi bir SDLC, “süreç” değildir; akıştır. Bir talep ne zaman değer üretir? Üretim hatası ne zaman saatler değil dakikalar içinde çözülür? Bu sorulara verdiğimiz cevap, kuruluş büyüklüğüne göre değişir ama prensipler aynıdır.

Mevcut süreçlerinizi haritalandırırız: talep, geliştirme, test, sürüm, üretim, destek. Her geçişte bekleme süresini ölçeriz; toplam akış süresinin %60-80’i bekleme olduğunu görmek şaşırtıcıdır.

Çalışma şekli

  • 4 hafta — durum tespiti ve önerilen hedef
  • 8–12 hafta — pilot ekiple kurulum + ölçüm
  • 6 ay — yaygınlaştırma + denetim
  • Sürekli — kuartal bazında durum incelemesi

İlgili teknolojilerimiz

Sürecimiz

  1. 1

    Akış haritalama

    2-3 hafta

    Mevcut talep → geliştirme → test → sürüm → üretim akışı haritalanır. Her geçişteki **bekleme süresi** ölçülür (genelde toplam akışın %60-80'i bekleme).

  2. 2

    Hedef akış + araç seçimi

    1-2 hafta

    Hedef akış belirlenir; gerekli araçlar (issue tracker, VCS, CI, scan, registry, deploy, observability) seçilir veya optimize edilir.

  3. 3

    Pilot ekiple kurulum

    8-12 hafta

    1-2 uygulama ekibi pilot olarak yeni akışa geçer. Mono ekibi yan yana çalışır; runbook + post-mortem disiplini yerleşir.

  4. 4

    Yaygınlaştırma

    3-6 ay

    Diğer ekipler kademeli geçer. Her geçişte 1-2 hafta Mono mentörlüğü. Çeyrek sonu metric inceleme oturumları.

  5. 5

    Denetim ve evrim

    Yıllık

    DORA metric'leri (deploy frequency, lead time, change failure rate, MTTR) takip edilir. Yıllık güncelleme + iyileştirme sprintleri.

Sıkça sorulan sorular

DORA metric'leri neden önemli?
Bilimsel kanıta dayalı dört temel ölçü: deploy sıklığı, değişiklik teslim süresi, başarısızlık oranı, ortalama kurtarma süresi. Yüksek performanslı ekipler bu dörtlüde kat kat öndedir. Mono SDLC kurulumlarımızda bu metric’ler ilk haftadan ölçülmeye başlar.
Trunk-based development mı GitFlow mu?
Trunk-based + short-lived feature branches modern ekipler için varsayılan. GitFlow karmaşıklığı sürüm yönetimi için tasarlanmış; CI/CD ile sıkça deploy eden ekipler için fazla katmanlı. Mono önerisi: trunk-based + feature flag + canary deploy.
Güvenlik taraması yavaş yapıyor pipeline'ı?
Aşamalı tarama çözümdür: PR’da hızlı SAST + secret detection (1-3 dk); merge sonrası tam DAST + dependency scan (paralel); haftalık tam kapsamlı (compliance reporting). Hızdan ödün vermeden kapsam korunur.
Olay (incident) yönetimi nasıl kurulur?
Severity tanımı, on-call rotasyonu (PagerDuty/Grafana OnCall), incident commander rolü, post-mortem şablonu (no-blame, kanıta dayalı), eylem öğelerinin takibi. İlk 90 gün dış destek, sonra iç ekip yürütür. Kritik metrik: ortalama MTTR < 1 saat.

Bir sonraki dönüşümü birlikte planlayalım.

Ekibimiz teknik gereksinimlerinizi anlamak ve hızlıca prototip çıkarmak için hazır.