Mobil Geliştirmede Sprint: Özü, Süresi ve Planlaması

Geliştirmede Sprint Nedir?

Sprint, sonunda ekibin kullanıma hazır bir ürün artımı teslim ettiği sabit süreli bir zaman kutusudur (timebox). Sprint kavramı Scrum'ın temelidir, ancak diğer Agile çerçevelerinde de kullanılır. Mobil geliştirmede artım, bir cihaza kurulabilen, test edilebilen ve paydaşlara gösterilebilen bir uygulama derlemesidir (build). Bir sprint uzatılamaz — görevler tamamlanmazsa, bir sonraki sprinte taşınır.

Bir sprintin temel özelliği sabit süredir. Ekip, onaydan sonra sprint hedefini değiştirmez. Bu, öngörülebilirlik sağlar: paydaşlar sonucu ne zaman alacaklarını bilir. Sprint içinde ekip işin nasıl dağıtılacağına karar verir. Scrum Master, ekibi dış müdahalelerden korur — mevcut sprinte yeni görevler eklenmez. Scrum Guide 2025'e göre, sürdürülebilir bir geliştirme temposu sağlamanın tek yolu budur.

Bir sprint dört zorunlu etkinlikten oluşur: Sprint Planning, Daily Scrum (günlük senkronizasyon), Sprint Review (sonucun gösterilmesi), Sprint Retrospective (süreç analizi). Bunların arasında ana iş bulunur: görev uygulaması, test etme, kod incelemesi. Süre her etkinliğin sprint uzunluğuyla doğru orantılıdır: 2 haftalık bir sprint için Planning 4 saat, Review 2 saat, Retro 1,5 saat, Daily 15 dakikadır. Ritüeller toplamda sprint başına yaklaşık 8 saat sürer — ekibin çalışma süresinin %10'u.

Sprint'in Scrum Ritüelleri

Scrum ritüelleri (törenler/etkinlikler), sprint içinde yapılandırılmış ekip toplantılarıdır. Sprint Planning başlangıçta, Daily Scrum her gün, Sprint Review ve Retrospective sonda. Tüm etkinliklerin bir zaman kutusu vardır. Scrum Master, zaman kutusuna ve odaklanmaya uyulmasını sağlar. Her ritüele tüm Scrum ekibi katılır: Product Owner, Scrum Master, geliştiriciler. İstisna Daily Scrum'dır (yalnızca geliştiriciler katılır, PO ve SM isteğe bağlıdır).

Ritüellerin sprint aşamalarıyla bağlantısı: Planning yönü belirler (neyi ve nasıl yapacağımızı), Daily senkronize eder (kim ne yapıyor, hangi engeller var), Review sonucu gösterir (ne yapıldı, ne yapılmadı), Retrospective süreci iyileştirir (sonraki sprinti nasıl daha iyi yapabiliriz). Retrospective'i atlamak en yaygın ekip hatasıdır: teslim tarihleri sıkıştığında ilk feda edilen Retro olur. Bu, süreçlerin durağanlaşmasına ve aynı hataların tekrarlanmasına yol açar. Scrum.org (2025) araştırması, her 2 haftada bir Retro yapan ekiplerin hızı %35 daha hızlı artırdığını gösteriyor.

Sprint Planning: Yineleme Planlaması

Sprint Planning, sprint başlangıcında neyin ve nasıl yapılacağının belirlendiği bir ekip toplantısıdır. Product Owner, Product Backlog'dan öncelikli görevleri sunar. Ekip kapasiteyi (tatiller, toplantılar, teknik borç dikkate alınarak mevcut süre) tahmin eder ve sprint sırasında tamamlayabileceği görevleri seçer. Planning'in sonucu Sprint Goal (sprint hedefi) ve Sprint Backlog'dur (görev listesi). Sprint Goal kısa bir cümle olarak formüle edilir: “Sipariş ekranını ve SBP aracılığıyla ödeme entegrasyonunu uygulayın.”

Hız (Velocity), sprint başına hikaye puanı (story point) cinsinden ölçülen ekip hızıdır. Son 3-5 sprintin ortalaması. Scrum.org (2025)'e göre, 5 mobil geliştiriciden (3 Android + 2 iOS) oluşan bir ekibin hızı, 2 haftalık sprint başına 25-40 SP'dir. Planning, hızı üst sınır olarak kullanır — öngörülemeyen görevler (kod incelemesi, olaylar, diğer ekiplere yardım) için %10-15 daha az alır. Kapasite ve Hız: kapasite “kişi-saat”, hız ise “hikaye puanı”dır. Kapasite, tatilleri, hastalık izinlerini, toplantıları dikkate alır. Tipik kayıp oranı, çalışma süresinin %25-30'unun kod dışı faaliyetlere harcanmasıdır.

Planning iki bölüme ayrılır: “ne” (PO görevleri tanımlar, ekip netleştirir) — 2 saat ve “nasıl” (ekip parçalara ayırır ve tahmin eder) — 2 saat. Mobil projeler için “nasıl” bölümünde şunlar tartışılır: Android/iOS sürümleriyle uyumluluk, feature flag gereksinimi, APK/IPA boyutuna etki, yeni izinler. Planning Poker tekniği tahmin için kullanılır: her geliştirici hikaye puanı (1, 2, 3, 5, 8, 13) cinsinden tahminini verir. 2 birimden fazla fark, nedenlerin tartışılmasını tetikler. Bu, sprint ortasında değil, planlama aşamasında gizli riskleri ortaya çıkarır.

Sprint Yürütme: Daily Standup ve İzleme

Daily Scrum (Standup), ekip senkronizasyonu için günlük 15 dakikalık bir toplantıdır. Her katılımcı üç soruyu yanıtlar: “Dün ne yapıldı?”, “Bugün ne yapmayı planlıyorum?”, “Hangi engellerim var?” Daily, yönetici için bir durum raporu değil, ekip öz-örgütlenmesi için bir araçtır. Daily sırasında iki geliştiricinin aynı görev üzerinde çalıştığı ortaya çıkarsa — bu bir yeniden yapılanma sinyalidir. Önemli: Daily sorunları çözmez, onları belirler — çözüm için Daily'den sonra ayrı bir toplantı düzenlenir.

Scrum Board (sprint panosu), Sprint Backlog'un görselleştirilmesidir. Sütunlar: To Do / In Progress / In Review / Done. Her görev tahta üzerinde hareket eder. Burndown Chart, sprint günlerine göre kalan işin grafiğidir. İdeal burndown, toplam SP'den 0'a doğru düz bir çizgidir. Gerçek burndown, görev tamamlamalarını yansıtan basamaklı bir grafiktir. İdeal çizginin altına düşen bir burndown, geciktiğimiz anlamına gelir. Sorun sinyali: sprint ortasında görevlerin %30'undan azı tamamlanmışsa — ayarlama gerekir. Riskler dikkate alınmamış veya görevler fazla tahmin edilmiş olabilir.

Mobil geliştirme için sprint izleme, belirli faktörlerden etkilenir: derleme süresi (CI'da Android proje derlemesi 30+ dakika sürebilir), App Store / Google Play onayı bekleme (TestFlight aracılığıyla test kullanıcılarına derleme yayınlanması gerekiyorsa), farklı cihazlarla uyumluluk (10+ modelde test etme zaman alır). İpucu: son testler ve sürüm derlemesi için sprint sonunda 1 gün tampon ayırın. Bu, Mind the Product (2025)'e göre tamamlanmamış sprint riskini %40 azaltır.

Sprint Review ve Retrospective

Sprint Review, artımın paydaşlara gösterilmesidir. Ekip, slaytlar değil, çalışan bir uygulama derlemesi gösterir. 2 haftalık sprint için süre 2 saattir. Product Owner, Acceptance Criteria'ya uygunluğu kontrol eder. Paydaşlar, Product Backlog'u etkileyebilecek geri bildirim sağlar. Review bir rapor değil, bir diyalogdur: paydaşlar soru sorabilir ve değişiklik önerebilir. Ana kural: Sprint Review süreçle değil, ürünle ilgilidir. Ne başarıldığını gösterin, nasıl yapıldığını değil.

Sprint Retrospective, geçmiş sprinti analiz etmek için dahili bir ekip toplantısıdır. Biçim: Start Doing (ne yapmaya başlamalı), Stop Doing (ne yapmayı bırakmalı), Continue Doing (ne yapmaya devam etmeli). 2 haftalık sprint için süre 1,5 saattir. Retrospective, sorunları tartışmak için güvenli bir alandır. Kural: Retro'da teknik detaylar tartışılmaz (bunun için teknik toplantılar vardır). Yalnızca süreç, iletişim, araçlar, kültür. Scrum Master toplantıyı kolaylaştırır ve her katılımcının konuşmasını sağlar.

Retrospective'in sonucu, sonraki sprint için 1-3 iyileştirmedir. Ekip “Kod incelemesi çok uzun sürüyor” sorununu belirlediyse — eylem maddesi: “İnceleme için SLA belirleyin — 4 saat. İnceleme zamanında yapılmazsa — geliştirici Slack'te hatırlatır.” Eylem Maddeleri spesifik, ölçülebilir ve belirli bir kişiye atanmış olmalıdır. Atlassian (2025)'e göre, Retro eylem maddelerini uygulayan ekipler hızı 3-4 sprintte %15-25 artırır. Uygulamayanlar — yerinde sayar.

Sprint Süresi Nasıl Seçilir

2 hafta mobil geliştirme için standarttır. Öngörülebilirlik ve esneklik arasında optimal denge. Planlama, 3-5 orta özellik uygulama, test etme, sonuçları gösterme için yeterli zaman. 1 hafta, yüksek süreç olgunluğuna ve CI/CD'ye sahip ekipler içindir. Hızlı kararlar, minimum bürokrasi gerektirir. Hızlı deney yapması gereken erken aşama startuplar için uygundur. Dezavantaj: ritüellerde yüksek ek yük (her hafta Planning + Review + Retro = 7,5 saat).

3-4 hafta, donanım entegrasyonu (giyilebilir cihazlar, IoT, BLE cihazları), uzun mağaza onayı veya büyük geçişler (örneğin, RxJava'dan Coroutines'e geçiş) içeren karmaşık projeler içindir. Uzun sprintler test için daha fazla zaman sağlar ancak “şelale etkisi” riskini artırır — ekip Agile esnekliğini kaybeder. Scrum Guide Tavsiyesi: 1 ayı geçmeyin. Sprint daha uzunsa, Review'de çok fazla bağlam olur ve paydaşlar kaliteli geri bildirim sağlayamaz.

Sprint'lerin Tipik Sorunları

Sorun 1: Kapsam Genişlemesi (Scope Creep). Sprint ortasında, Product Owner yeni bir “acil ve önemli” görev ekler. Ekip kabul eder — ve sprint başarısız olur. Çözüm: Sprint Goal bir sözleşmedir. Herhangi bir değişiklik, Sprint Goal'ün yeniden değerlendirilmesini gerektirir ve bu yalnızca acil durumlarda mümkündür. Yeni görev Product Backlog'a ve sonraki sprinte gider. Görev gerçekten kritikse — eski Sprint Goal iptal edilir, sprint yeniden planlanır, ancak bu bir istisnadır, uygulama değildir. 3 sprintte bir defadan fazla kapsam genişlemesi, zayıf bir Product Owner'ın işaretidir.

Sorun 2: Tamamlanmamış Görevler. Sprint sonunda, görevlerin %50'si In Progress, %20'si In Review, yalnızca %30'u Done. Nedenler: fazla tahmin edilen kapasite, eksik tahmin edilen karmaşıklık, planlanmamış hatalar. Çözüm: Retro'da nedeni analiz edin. Sistematik olarak yetişemiyorsanız — Planning'de görev sayısını artırmayın, azaltın. %20 daha az görev alan ekipler daha yüksek tamamlama oranı gösterir (%80+ karşısında %50-60). Planning için kontrol listesi: her görev için Acceptance Criteria, Definition of Ready ve diğer görevlerle bağımlılığı kontrol edin.

Sorun 3: Biçimsel Retro. Ekip, sırf görüntü olsun diye Retro yapar — 15 dakika, genel ifadeler, eylem maddesi yok. Çözüm: her Retro'nun biçimini değiştirin. Yöntemler: Sailboat (neyin yavaşlattığı, neyin hızlandırdığı), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Son tarih ve sorumlularla eylem maddeleri atayın. Sonraki Retro'nun başında, önceki eylem maddelerinin tamamlanmasını kontrol edin. Atlassian (2025)'e göre, farklı Retro biçimleri kullanan ekipler %50 daha fazla yararlı içgörü üretir.