Apa Itu Sprint 0 (dan yang Bukan)
Sprint 0 adalah satu-dua minggu di awal proyek mobile ketika tim tidak menulis kode fitur, melainkan membuat keputusan arsitektur yang mahal untuk diubah kemudian. Ia bukan periode desain tak berujung, juga bukan formalitas sebelum “ngoding sungguhan”. Pada aplikasi lapangan GIS yang kami bangun - dipakai surveyor di area tanpa sinyal dengan puluhan ribu titik koordinat - hampir seluruh keberhasilannya ditentukan oleh enam keputusan yang dibuat di sprint nol.
Output Sprint 0 yang baik berbentuk dokumen pendek (5–8 halaman) bernama Architecture Decision Record: setiap keputusan mencatat konteks, pilihan alternatif, dan alasan. Dokumen ini menjadi penentu saat debat teknis muncul di bulan ketiga.
Enam Keputusan Arsitektur
1. Strategi offline-first. Pertanyaannya bukan “apakah butuh offline?” melainkan “seberapa banyak kerja harus tetap bisa dilakukan tanpa sinyal, dan bagaimana konflik diselesaikan?” Untuk aplikasi lapangan, jawaban kami: seluruh form dan capture data tersimpan lokal (SQLite/MMKV), sinkronisasi dua arah dengan antrian per-record, dan aturan last-write-wins plus log konflik. Keputusan ini mengubah skema database sejak awal - mustahil ditambahkan belakangan tanpa refactoring besar.
2. State management yang bisa dites. Pilih satu pola terprediksi (Redux Toolkit, Zustand, atau Riverpod/Bloc di Flutter) dan tulis aturannya: tidak ada server call dari komponen UI. Tim kecil sering melewatkan ini, lalu membayar dengan regression test yang mustahil otomatis.
3. Penyimpanan kredensial. Token akses dan refresh token hidup di secure storage native (iOS Keychain / Android EncryptedSharedPreferences), bukan di AsyncStorage biasa. Rotasi refresh token dan deteksi perangkat baru dirancang sekarang, bukan setelah insiden.
4. Skema sinkronisasi & versi data. Setiap record punya updated_at, device_id, dan status sync. API menerima batch delta, bukan full-sync. Tanpa standar ini sejak tabel pertama, sinkronisasi akan menjadi sumber bug paling lama dalam hidup produk.
5. Pipeline rilis & feature flag. CI yang membangun build internal distribution (TestFlight / Play Internal Testing) sejak pekan pertama, plus flag untuk mematikan fitur bermasalah tanpa rilis darurat. Waktu setup: dua hari; nilai penyelamatan: satu rilis kacau saja sudah lunas.
6. Definisi metrik sukses v1. Tiga sampai lima angka yang menentukan aplikasi “berhasil” - waktu penyelesaian tugas lapangan, tingkat kegagalan sinkronisasi, crash-free rate ≥ 99,5% - dipasang sejak build pertama, bukan ditambahkan saat investor bertanya.
Enam jam debat di Sprint 0 tentang strategi sinkronisasi menghemat enam pekan refactor setelah pengguna pertama bekerja di basement gedung tanpa sinyal.
Estimasi Durasi per Aktivitas
| Aktivitas Sprint 0 | Durasi | Output |
|---|---|---|
| Workshop keputusan arsitektur (6 keputusan) | 2–3 hari | Architecture Decision Record |
| Setup repo, CI/CD, distribusi internal | 1–2 hari | Build otomatis dari commit |
| Proof of concept offline sync | 2–3 hari | Demo CRUD + sync pada skenario sinyal buruk |
| Desain sistem auth + secure storage | 1 hari | Flow login/refresh/logout terdokumentasi |
| Metrik & monitoring dasar (crash, sync health) | 1 hari | Dashboard crash-free rate aktif |
Total realistis: satu setengah hingga dua minggu untuk aplikasi dengan komponen lapangan; kurang untuk aplikasi online-only sederhana.
Tiga Jebakan Umum
Jebakan pertama: menganggap “nanti ditambahkan offline” sebagai opsi. Sinkronisasi bukan fitur - ia fondasi data. Kedua: memilih library berdasarkan stars GitHub tanpa uji pada kasus konflik nyata; buat proof of concept 200 baris untuk skenario terburuk Anda. Ketiga: meremehkan biaya kepatuhan platform - review App Store, kebijakan permission lokasi/kamera, dan persyaratan target API Android memakan waktu riil yang harus masuk roadmap sejak awal.
Skenario Uji Proof of Concept Sinkronisasi
PoC sinkronisasi di Sprint 0 harus menjawab skenario terburuk, bukan demo kondisi ideal. Lima kasus yang kami wajibkan lolos sebelum keputusan arsitektur ditandatangani: (1) create-offline-then-sync - record dibuat tanpa sinyal, tersinkron utuh beserta foto/lampiran saat online; (2) edit-bentrok - record sama diedit di dua perangkat, aturan resolusi berjalan dan konflik tercatat, bukan hilang senyap; (3) kill-and-resume - aplikasi dimatikan paksa di tengah upload besar, dilanjutkan tanpa duplikasi; (4) server-reject - server menolak satu record dari batch sepuluh, sembilan lainnya tetap masuk dan yang gagal terlihat jelas bagi pengguna; (5) upgrade-schema - versi aplikasi baru dibuka di atas database lokal versi lama berisi data belum tersinkron, tanpa kehilangan satu baris.
Lima kasus ini butuh dua-tiga hari untuk dibangun - dan setiap kasus yang gagal di sini adalah insiden lapangan yang berhasil Anda cegah. Dokumentasikan hasilnya sebagai lampiran ADR; saat ada yang mempertanyakan pilihan library di bulan keempat, Anda tinggal menunjuk bukti.
Kapan Sprint 0 Boleh Lebih Pendek
Kejujuran metodologis: tidak semua aplikasi butuh dua minggu Sprint 0. Bila aplikasi Anda online-only penuh (tidak ada klaim offline), satu platform saja, tanpa data sensitif, dan tim sudah pernah bekerja bersama pada stack yang sama - cukup tiga-hari versi ringkas: keputusan state management, pipeline rilis, dan metrik. Sebaliknya, tambah durasi bila tiga faktor ini hadir: sinkronisasi multi-perangkat, integrasi hardware (scanner, GPS presisi, kamera termal), atau kepatuhan regulasi data. Durasi Sprint 0 proporsional dengan mahalnya keputusan yang harus diambil - bukan dengan ukuran tim.
Sprint 0 yang gagal bukan yang terlalu lama, melainkan yang selesai tanpa dokumen keputusan - semua debat akan diulang dari nol di minggu keenam.
Template ADR: Satu Halaman per Keputusan
Architecture Decision Record tidak perlu formal berlebihan - template satu halaman ini cukup, dan justru kesederhanaannya yang membuatnya tetap dipakai:
# ADR-003: Strategi Sinkronisasi Data Lapangan
Tanggal : 2026-06-30 Status : Diterima
Konteks :
Surveyor bekerja 4-8 jam tanpa sinyal; volume
200-500 record/hari/perangkat; foto hingga 8MB.
Pilihan:
A. Online-only + retry manual (ditolak)
B. Offline-first SQLite + delta sync (dipilih)
C. Realm sync platform (ditunda - biaya lisensi)
Konsekuensi:
(+) Kerja penuh tanpa sinyal; konflik tercatat
(-) Wajib migration schema lokal disiplin
(-) Perlu UI antrean sync yang terlihat user
Diputuskan oleh : [BE lead] [Mobile lead] [PM]Enam keputusan inti = enam ADR sepanjang satu-dua halaman. Nilainya baru terasa di bulan ketiga saat engineer baru bertanya “kenapa pakai X?” - dan jawabannya tinggal dibuka, lengkap dengan alternatif yang sudah ditolak beserta alasannya.
Siapa Hadir di Sprint 0
Sprint 0 bukan acara seluruh tim - hadir terlalu banyak orang menghasilkan keputusan kompromi yang lemah. Komposisi ideal: mobile lead (pemegang suara teknis utama), backend lead (keputusan kontrak API & sinkronisasi adalah milik bersama), product owner (penjaga bahwa setiap keputusan masih melayani pengguna lapangan), dan ops/QA representatif untuk realita distribusi rilis serta skenario pengujian. Designer hadir pada sesi keputusan #6 (metrik) dan membawa alur pengguna lapangan sebagai bahan uji asumsi. Aturan rapatnya satu: setiap keputusan harus selesai hari itu - “kita pikirkan lagi” diperbolehkan maksimal sekali per keputusan, dengan deadline tegas.
ADR yang baik menuliskan nama orang dan tanggalnya - bukan untuk menyalahkan, melainkan agar dua tahun kemudian ada yang bisa ditanya “apa yang kalian ketahuai waktu itu?”
Penutup
Sprint 0 adalah investasi seminggu yang membeli ketenangan enam bulan. Bila aplikasi mobile Anda memiliki komponen lapangan - survei, inspeksi, inventarisasi gudang - jalankan Sprint 0 dengan disiplin sebelum menulis fitur pertama. Dan bila Anda ingin tim yang sudah melalui siklus ini berkali-kali mendampingi, mulai dari cerita kebutuhan Anda ke hello@ayah2ngoding.com.
Diskusi & Komentar (0)