Daily dan stand-up — apa itu, aturan pertemuan harian dan manfaat

Apa itu daily dan stand-up?

Daily Standup (stand-up harian, daily) — pertemuan singkat tim Scrum, dilakukan pada waktu dan tempat yang sama setiap hari kerja. Timebox — 15 menit. Dikenal dengan berbagai nama: Daily Scrum (di Scrum Guide), sinkronisasi pagi, morning circle, daily. Tujuan — menyinkronkan tim, mengidentifikasi blocker, dan menyesuaikan rencana harian. Daily bukan laporan untuk manajer, melainkan alat organisasi mandiri tim. Tim memutuskan bagaimana menstruktur pertemuan, bukan manajer.

Asal usul istilah “stand-up” — dari praktik berdiri selama pertemuan secara harfiah: peserta berkumpul di papan dan tidak duduk. Ini menciptakan rasa sementara — tidak ada yang ingin berdiri lebih dari 15 menit. Stand-up fisik masih digunakan di 60% tim (menurut data Scrum.org 2025), sisanya beralih ke format jarak jauh melalui Zoom, Slack Huddle, atau Teams. Dalam format jarak jauh, menjaga disiplin penting: kamera menyala, tidak ada multitasking, kesiapan memikirkan jawaban sebelumnya.

Scrum Guide 2025 mendefinisikan Daily Scrum sebagai acara untuk Developers (pengembang). Product Owner dan Scrum Master boleh hadir, tetapi tidak wajib. Jika PO atau SM hadir — mereka tidak memimpin pertemuan. Tim sendiri memilih struktur: tiga pertanyaan klasik atau board walk. Kunci: daily tentang inspeksi kemajuan menuju Sprint Goal, bukan tentang status setiap task. Jika pertemuan berubah menjadi daftar task di papan — tim kehilangan fokus pada Sprint Goal.

Tiga pertanyaan Daily Standup

Pertanyaan 1: “Apa yang saya lakukan kemarin untuk mencapai Sprint Goal?” — daftar singkat tugas yang diselesaikan. Bukan “saya mengerjakan APP-123”, tetapi “menyelesaikan layar login, PR dikirim ke review”. Rumusan “untuk mencapai Sprint Goal” tidak kebetulan — menghubungkan pekerjaan sehari-hari dengan tujuan umum sprint. Jika pengembang tidak melihat hubungan tugasnya dengan Sprint Goal — itu sinyal bahwa tugas tidak diperlukan di sprint saat ini. Dalam pengembangan mobile, hasil kemarin bukan hanya kode, tetapi juga tes, dokumentasi, konfigurasi CI/CD.

Pertanyaan 2: “Apa yang saya rencanakan hari ini untuk mencapai Sprint Goal?” — rencana untuk hari ini. Tidak lebih dari 2-3 poin. Pengembang dapat mengatakan: “Hari ini saya menyelesaikan ViewModel untuk layar profil, menulis unit test, menjalankan build di perangkat nyata”. Jika rencana sama dengan “kemarin” — itu sinyal bahwa tugas terlalu besar dan perlu didekomposisi. Aturan dua hari: jika tugas tidak selesai dalam 2 hari kerja — harus dipecah menjadi subtugas, jika tidak akan macet di In Progress selama berminggu-minggu.

Pertanyaan 3: “Blocker apa yang menghambat kemajuan saya?” — pertanyaan terpenting. Blocker adalah sesuatu yang tidak bisa diselesaikan pengembang sendiri: menunggu review (jika SLA review telah habis), emulator tidak berfungsi, API belum siap, perlu akses ke repositori. Penting: blocker harus disebutkan, tetapi tidak diselesaikan di daily. Setelah pertemuan, pengembang dan Scrum Master / manajer menyepakati solusi blocker. Menurut Scrum.org (2025), 70% blocker tim mobile terkait dengan: menunggu review (30%), tidak tersedianya perangkat tes (20%), ketergantungan pada backend (20%).

Cara melakukan stand-up dengan benar

Waktu dan tempat. Daily dilakukan pada waktu yang sama setiap hari — biasanya di awal hari kerja (9:00-10:00). Untuk tim terdistribusi, dipilih waktu yang nyaman untuk semua zona waktu. Durasi — ketat 15 menit. Timer — wajib. Jika tim tidak muat — masalahnya bukan di daily, melainkan di proses: terlalu banyak peserta, atau tugas didiskusikan alih-alih hanya disebutkan. Aturan ping-pong: setiap peserta berbicara tidak lebih dari 60 detik. Setelah menjawab, memberikan giliran ke peserta berikutnya.

Format “board walk”. Alternatif untuk tiga pertanyaan: tim secara bergiliran memindahkan tugas di papan Scrum, mengomentari perubahan. Pengembang mengambil task dari To Do, memindahkan ke In Progress dan berkata: “Saya ambil APP-123 — layar pesanan, menambahkan bidang kode promo”. Board Walk memberikan pemahaman visual tentang kemajuan dan mengungkap task “terlupakan” — yang tidak bergerak selama 3+ hari. Board Walk lebih disukai untuk tim terdistribusi dengan Jira/Linear — semua orang melihat papan, tidak mendengarkan monolog.

Untuk tim jarak jauh: kamera wajib menyala — menurut Microsoft Research (2025), kamera menyala meningkatkan keterlibatan sebesar 40%. Gunakan layar bersama dengan papan tugas (Jira, Linear, Miro). Tulis blocker di chat — ini menciptakan catatan tertulis. Dorong emoji reaksi (kecuali perintah pengguna — emoji tidak digunakan) — jempol untuk pesan rekan kerja. Setelah daily — 2-3 menit untuk “parking lot”: topik yang memerlukan diskusi terpisah dicatat dalam daftar pertemuan tindak lanjut. Keterampilan kunci Scrum Master: menghentikan diskusi di daily dan memindahkannya ke parking lot.

Kesalahan umum saat melaksanakan

Kesalahan 1: laporan status untuk manajer. Pengembang bergiliran membaca apa yang tertulis di Jira, manajer mengajukan pertanyaan klarifikasi, pertemuan berlangsung 45 menit. Solusi: ingatkan bahwa daily untuk tim, bukan untuk manajer. Manajer dapat mengetahui status dari papan. Jika manajer bertanya — pindahkan ke 1:1. Tim yang mengubah daily menjadi laporan kehilangan 2-3 jam per minggu untuk semua peserta. Dengan 8 pengembang, itu 16-24 jam-orang per bulan — kehilangan satu sprint penuh per tahun.

Kesalahan 2: menyelesaikan masalah di tempat. Pengembang berkata “Saya punya bug dengan GRPC — proyek tidak bisa di-build” dan seluruh tim mendiskusikan solusi selama 20 menit. Solusi: catat blocker ke parking lot, lanjutkan daily. Setelah pertemuan — kumpulkan yang berkepentingan (pengembang + seseorang yang dapat membantu) untuk diskusi 10 menit. Menurut Basecamp (Shape Up), hanya 20% masalah yang ditemukan di daily memerlukan diskusi seluruh tim. Sisanya diselesaikan oleh beberapa pengembang dalam 10 menit.

Kesalahan 3: keterlambatan dan ketidakhadiran. Seseorang datang 5 menit setelah mulai — harus mengulang. Solusi: tetapkan aturan “daily dimulai tepat waktu, yang terlambat tidak masuk” atau “yang terlambat membayar denda” (kopi untuk tim). Lebih tegas: daily dilakukan pada waktu yang sama, jika seseorang terlambat secara sistematis — ini masalah disiplinnya, diselesaikan di 1:1. Daily adalah sinkronisasi hari. Jika pengembang melewatkannya — dia tidak sinkron dan berisiko melakukan pekerjaan yang tidak dibutuhkan tim.

Kesalahan 4: terlalu banyak peserta. Tim 15+ orang, masing-masing berbicara satu menit — total 20+ menit. Solusi: bagi tim menjadi subgrup berdasarkan fitur/modul. Setiap subgrup melakukan daily-nya sendiri (5-7 orang). Satu perwakilan dari subgrup dapat hadir di stand-up lintas tim umum (jika diperlukan sinkronisasi antar tim). Alternatif: stand-up asinkron melalui Slack/GeekBot, di mana setiap orang menulis apa yang dilakukan/direncanakan/blocker.

Stand-up asinkron: alternatif

Stand-up asinkron — format di mana peserta menulis jawaban mereka di chat (Slack, Telegram, Teams) atau bot khusus (GeekBot, Standuply, Status Hero) alih-alih pertemuan lisan. Cocok untuk tim terdistribusi dengan perbedaan zona waktu 3+ jam. Setiap peserta menjawab tiga pertanyaan yang sama hingga waktu tertentu (misalnya, hingga pukul 11:00). Bot mengumpulkan jawaban dan mempublikasikan ringkasan di saluran umum. Kelebihan: fleksibilitas, catatan tertulis, tidak ada masalah keterlambatan.

Kekurangan format asinkron: tidak ada komunikasi langsung — sinyal nonverbal hilang, lebih sulit mengidentifikasi blocker (pengembang mungkin tidak menulis tentang masalah). Blocker yang ditulis di chat mungkin tidak terlihat hingga akhir hari. Menurut GitLab (2025), 40% tim yang beralih ke async standup kembali ke lisan dalam 3 bulan. Rekomendasi: gunakan hibrida — 3 hari stand-up lisan (Sen, Rab, Jum), 2 hari asinkron (Sel, Kam). Atau: stand-up lisan 1-2 kali seminggu, di hari lainnya — asinkron.

Alat untuk stand-up asinkron: GeekBot (Slack) — mengajukan tiga pertanyaan, mempublikasikan ringkasan; Standuply — dengan integrasi Jira, pelacakan otomatis; Status Hero — mengumpulkan status dan membuat laporan mingguan untuk manajemen. Pemilihan alat tergantung pada budaya tim: di startup, bot di Slack sudah cukup, di enterprise mungkin diperlukan Standuply dengan integrasi ke proses korporat. Aturan penting: terlepas dari format, jawaban harus terlihat oleh seluruh tim, bukan hanya manajer. Transparansi — nilai kunci Agile.

Kekhususan daily untuk tim mobile

Tim mobile di daily menghadapi blocker spesifik. Utama: membangun proyek di CI (Gradle build bisa memakan waktu 20+ menit — jika rusak, pengembang kehilangan satu jam untuk diagnosis), menunggu TestFlight / Firebase App Distribution (publikasi build untuk tester memakan waktu 30-60 menit), masalah dengan emulator dan simulator (Android Emulator memerlukan KVM/HAXM, iOS Simulator hanya di Mac). Daily tim mobile harus mencakup pemeriksaan cepat status build: “Apakah build berhasil? Semua tes hijau?”

Untuk proyek lintas platform (Flutter, React Native) daily dapat mencakup pertanyaan tentang status kode bersama. Jika dua pengembang secara bersamaan mengedit file Dart yang sama dan salah satu menggabungkan perubahan — yang kedua akan mengalami konflik. Saran: gunakan Board Walk di papan dengan pembagian per platform (Android / iOS / Shared). Ini membantu melihat siapa bekerja di mana dan apakah perubahan tumpang tindih. Untuk proyek Flutter — papan dengan kolom Platform Channel, BLoC/Cubit, UI, Tests.

Kesiapan rilis — poin spesifik lain untuk pengembangan mobile di daily. 3-5 hari sebelum rilis tambahkan pertanyaan: “Apakah build siap untuk rilis? Semua metadata (ikon, tangkapan layar, deskripsi) diperbarui?” Ini mencegah situasi di mana pengembang menyelesaikan kode pada hari rilis, dan pembuatan serta publikasi memakan waktu 3-4 jam lagi. Pelacak rilis — papan terpisah dengan daftar periksa: pembaruan versionCode/versionName, pemeriksaan ProGuard, penandatanganan AAB, unggah ke konsol pengembang, catatan rilis.