Daily Standup — nedir, günlük toplantı kuralları ve faydaları

Daily Standup Nedir?

Daily Standup — Scrum ekibinin her iş günü aynı saatte ve yerde gerçekleştirdiği kısa bir toplantıdır. Zaman sınırı — 15 dakika. Farklı isimlerle bilinir: Daily Scrum (Scrum Kılavuzu'nda), sabah senkronizasyonu, morning circle, daily. Amaç, ekibi senkronize etmek, engelleri belirlemek ve günlük planları ayarlamaktır. Daily, yönetici için bir rapor değil, ekibin kendi kendini organize etme aracıdır. Toplantının yapısını ekip belirler, yönetici değil.

"Standup" teriminin kökeni, toplantı sırasında kelimenin tam anlamıyla ayakta durma pratiğinden gelir: katılımcılar tahtanın etrafında toplanır ve oturmazlar. Bu, geçicilik hissi yaratır — kimse 15 dakikadan fazla ayakta durmak istemez. Fiziksel standup hala ekiplerin %60'ı tarafından kullanılmaktadır (Scrum.org 2025'e göre), geri kalanı Zoom, Slack Huddle veya Teams aracılığıyla uzaktan biçime geçmiştir. Uzaktan biçimde disiplini korumak önemlidir: kameralar açık, çoklu görev yok, cevapları önceden düşünme hazırlığı.

Scrum Kılavuzu 2025, Daily Scrum'ı Geliştiriciler için bir etkinlik olarak tanımlar. Product Owner ve Scrum Master katılabilir ancak zorunlu değildir. PO veya SM katılırsa, toplantıyı yönetmezler. Ekip kendi yapısını seçer: klasik üç soru veya board walk. Anahtar nokta: daily, Sprint Goal'e yönelik ilerlemeyi incelemekle ilgilidir, her görevin durumuyla değil. Toplantı, tahtadaki görevlerin sıralanmasına dönüşürse, ekip Sprint Goal'e odaklanmayı kaybetmiştir.

Daily Standup'ın Üç Sorusu

Soru 1: "Sprint Goal'e ulaşmak için dün ne yaptım?" — tamamlanan görevlerin kısa bir özeti. "APP-123 üzerinde çalıştım" değil, "giriş ekranını bitirdim, PR incelemeye gönderildi". "Sprint Goal'e ulaşmak için" ifadesi bilinçlidir: günlük çalışmayı sprint'in genel hedefine bağlar. Bir geliştirici, görevi ile Sprint Goal arasında bağlantı görmüyorsa, bu, görevin mevcut sprint'te gerekli olmayabileceğinin bir işaretidir. Mobil geliştirmede, dünün sonuçları yalnızca kodu değil, aynı zamanda testleri, belgeleri ve CI/CD yapılandırmasını da içerir.

Soru 2: "Sprint Goal'e ulaşmak için bugün ne yapmayı planlıyorum?" — mevcut günün planı. En fazla 2-3 madde. Bir geliştirici şöyle diyebilir: "Bugün profil ekranı için ViewModel'i bitirecek, birim testleri yazacak ve gerçek bir cihazda derleme çalıştıracağım." Plan "dün" ile eşleşiyorsa, bu, görevin çok büyük olduğunun ve ayrıştırılması gerektiğinin bir işaretidir. İki gün kuralı: bir görev 2 iş günü içinde tamamlanmazsa, alt görevlere bölünmelidir, aksi takdirde haftalarca In Progress'te takılı kalır.

Soru 3: "İlerlememi engelleyen engeller neler?" — en önemli soru. Engel, geliştiricinin kendi başına çözemeyeceği bir şeydir: inceleme beklemek (inceleme SLA'sı aşıldıysa), çalışmayan bir öykünücü, hazır olmayan bir API, depoya erişim ihtiyacı. Önemli: engeller belirtilmeli ancak daily sırasında çözülmemelidir. Toplantıdan sonra, geliştirici ve Scrum Master / yönetici engelin çözümünü düzenler. Scrum.org (2025)'e göre, mobil ekip engellerinin %70'i şunlarla ilgilidir: inceleme beklemek (%30), test cihazlarının bulunamaması (%20) ve backend bağımlılıkları (%20).

Standup Doğru Şekilde Nasıl Yapılır

Zaman ve yer. Daily her gün aynı saatte yapılır — genellikle iş gününün başında (9:00-10:00). Dağıtık ekipler için, tüm zaman dilimleri için rahat bir saat seçilir. Süre — kesinlikle 15 dakika. Zamanlayıcı zorunludur. Ekip zamanında bitiremezse, sorun daily'de değil süreçtedir: ya çok fazla katılımcı vardır ya da görevler sadece adlandırılmak yerine tartışılmaktadır. Ping-pong kuralı: her katılımcı en fazla 60 saniye konuşur. Cevap verdikten sonra sözü bir sonraki kişiye devreder.

Board Walk biçimi. Üç soruya bir alternatif: ekip sırayla Scrum tahtasındaki görevleri taşır ve değişiklikleri yorumlar. Geliştirici, görevini To Do'dan alır, In Progress'e taşır ve şöyle der: "APP-123'ü alıyorum — sipariş ekranı, promosyon kodu alanı ekliyorum." Board Walk, ilerlemenin görsel olarak anlaşılmasını sağlar ve "unutulmuş" görevleri — 3+ gündür hareket etmeyenleri — ortaya çıkarır. Board Walk tercih edilir Jira/Linear kullanan dağıtık ekipler için — herkes monolog dinlemek yerine tahtayı görür.

Uzaktan ekipler için: kameralar açık olmalıdır — Microsoft Research (2025)'e göre, kameranın açık olması katılımı %40 artırır. Görev tahtası (Jira, Linear, Miro) ile paylaşımlı ekran kullanın. Engelleri sohbete yazın — bu yazılı bir kayıt oluşturur. Tepki emojilerini teşvik edin (kullanıcı talimatı hariç — emojiler kullanılmaz) — bir iş arkadaşının mesajına beğeni. Daily'den sonra, park yeri için 2-3 dakika ayırın: ayrı tartışma gerektiren konular, takip toplantı listesine yazılır. Scrum Master'ın temel becerisi: daily sırasında tartışmayı durdurmak ve park yerine taşımak.

Toplantılarda Tipik Hatalar

Hata 1: yönetici için durum raporu. Geliştiriciler sırayla Jira'da yazılanları okur, yönetici açıklayıcı sorular sorar ve toplantı 45 dakika sürer. Çözüm: daily'nin ekip için olduğunu, yönetici için olmadığını hatırlatın. Yönetici durumu tahtada görebilir. Yönetici soru sorarsa, bunları 1:1 toplantılara taşıyın. Daily'yi durum raporuna dönüştüren bir ekip, tüm katılımcılar arasında haftada 2-3 saat kaybeder. 8 geliştirici ile bu, ayda 16-24 kişi-saattir — bir yılda tam bir sprint kaybı.

Hata 2: sorunları yerinde çözmek. Bir geliştirici "gRPC'de bir hata var — proje derlenmiyor" der ve tüm ekip çözümleri tartışmak için 20 dakika harcar. Çözüm: engeli park yerine kaydedin ve daily'ye devam edin. Toplantıdan sonra, ilgili kişileri (geliştirici + yardım edebilecek kişiler) 10 dakikalık bir tartışma için bir araya getirin. Basecamp (Shape Up)'e göre, daily'de keşfedilen sorunların yalnızca %20'si tüm ekibin tartışmasını gerektirir. Geri kalanı iki geliştirici tarafından 10 dakikada çözülür.

Hata 3: gecikme ve devamsızlık. Birisi başlangıçtan 5 dakika sonra gelir ve her şey tekrarlanmak zorunda kalınır. Çözüm: "daily zamanında başlar, geç kalanlar katılmaz" veya "geç kalan ceza öder" (ekip için kahve) kuralını koyun. Daha katı: daily sabit bir saatte yapılır; birisi sistematik olarak geç kalıyorsa, bu 1:1'de çözülen bir disiplin sorunudur. Daily, günün senkronizasyonudur. Bir geliştirici bunu kaçırırsa, senkronize olmaz ve ekip için yanlış işi yapma riski taşır.

Hata 4: çok fazla katılımcı. 15+ kişilik bir ekip, her biri bir dakika konuşur — toplam 20+ dakika. Çözüm: ekibi özellik/modüle göre alt gruplara ayırın. Her alt grup kendi daily'sini yapar (5-7 kişi). Her alt gruptan bir temsilci, ekipler arası bir standup'a katılabilir (ekipler arasında senkronizasyon gerekiyorsa). Alternatif: herkesin ne yaptığını / planladığını / engellerini yazdığı Slack/GeekBot aracılığıyla eşzamansız standup.

Eşzamansız Standup: Alternatifler

Eşzamansız standup — katılımcıların sözlü toplantı yerine bir sohbete (Slack, Telegram, Teams) veya özel bir bota (GeekBot, Standuply, Status Hero) cevaplarını yazdığı bir biçimdir. 3+ saat saat dilimi farkı olan dağıtık ekipler için uygundur. Her katılımcı, belirli bir zamana kadar (örneğin, saat 11:00'e kadar) aynı üç soruyu yanıtlar. Bot yanıtları toplar ve ortak kanalda bir özet yayınlar. Avantajlar: esneklik, yazılı kayıt, gecikme sorunu yok.

Eşzamansız biçimin dezavantajları: canlı etkileşim yok — sözel olmayan sinyaller kaybolur, engelleri belirlemek daha zordur (bir geliştirici bir sorun hakkında yazmayabilir). Sohbete yazılan bir engel, günün sonuna kadar fark edilmeyebilir. GitLab (2025)'e göre, eşzamansız standup'a geçen ekiplerin %40'ı 3 ay içinde sözlüye geri döndü. Öneri: hibrit kullanın — haftada 3 gün sözlü standup (Pzt, Çar, Cum), 2 gün eşzamansız (Sal, Per). Veya: haftada 1-2 kez sözlü standup, kalan günlerde eşzamansız.

Eşzamansız standup araçları: GeekBot (Slack) — üç soruyu sorar ve bir özet yayınlar; Standuply — Jira ile entegre olur ve otomatik izleme sağlar; Status Hero — durumları toplar ve yönetim için haftalık raporlar oluşturur. Araç seçimi ekip kültürüne bağlıdır: startup'larda bir Slack botu yeterlidir; kurumsal ortamlarda, kurumsal süreç entegrasyonuyla Standuply gerekebilir. Önemli kural: biçimden bağımsız olarak, yanıtlar yalnızca yöneticiye değil, tüm ekibe görünür olmalıdır. Şeffaflık, Agile'ın temel bir değeridir.

Mobil Ekip Daily'sinin Özellikleri

Mobil ekip, daily sırasında belirli engellerle karşılaşır. Başlıcaları: CI'da proje derlemesi (Gradle derlemesi 20+ dakika sürebilir — bozulursa, geliştirici hata ayıklamada bir saat kaybeder), TestFlight / Firebase App Distribution bekleme (test uzmanlarına derleme yayınlamak 30-60 dakika sürer), öykünücü ve benzetim sorunları (Android Emulator KVM/HAXM gerektirir, iOS Simulator yalnızca Mac'te). Mobil ekip daily'si, hızlı bir derleme durumu kontrolü içermelidir: "Derleme geçiyor mu? Tüm testler yeşil mi?"

Platformlar arası projeler (Flutter, React Native) için daily, paylaşılan kodun durumu hakkında bir soru içerebilir. İki geliştirici aynı anda aynı Dart dosyasını düzenliyor ve biri değişiklikleri birleştirirse, ikincisi çakışmalarla karşılaşacaktır. İpucu: platforma (Android / iOS / Shared) göre bölünmüş bir tahtayla Board Walk kullanın. Bu, kimin nerede çalıştığını ve değişikliklerin örtüşüp örtüşmediğini görselleştirmeye yardımcı olur. Flutter projeleri için Platform Channel, BLoC/Cubit, UI ve Tests sütunları olan bir tahta kullanın.

Sürüm hazırlığı, daily'de mobil geliştirmeye özgü başka bir noktadır. Sürümden 3-5 gün önce şu soruyu ekleyin: "Derleme sürüm için hazır mı? Tüm meta veriler (simge, ekran görüntüsü, açıklamalar) güncellendi mi?" Bu, geliştiricilerin sürüm gününde kodlamayı bitirirken derleme ve yayınlamanın 3-4 saat daha sürmesi durumunu önler. Sürüm izleyici — kontrol listesi olan ayrı bir tahta: versionCode/versionName güncelleme, ProGuard kontrolü, AAB imzalama, geliştirici konsoluna yükleme, sürüm notları yazma.