Scrum dan alurnya
Oke, siap! Gw bikinin alur dan penjelasan Scrum yang simpel dan to the point.
Anggep aja Scrum itu kayak kerangka kerja (framework) buat ngerjain proyek yang rumit, misalnya bikin aplikasi. Tujuannya biar tim bisa cepet ngasih hasil, fleksibel sama perubahan, dan terus belajar dari prosesnya.
Para Pemain (The Roles)
Dalam Scrum, cuma ada 3 peran utama:
- Product Owner (PO): Ini "Si Bos Visi Produk". Dia yang paling tau apa yang user mau. Tugasnya bikin daftar semua fitur (Product Backlog) dan nentuin mana yang paling penting buat dikerjain duluan.
- Scrum Master (SM): Ini "Si Pelatih & Wasit". Dia bukan bos, tapi tugasnya mastiin semua tim ngikutin aturan main Scrum. Dia juga yang bantu ngilangin semua halangan yang ngeganggu kerjaan tim.
- Development Team (Tim Pengembang): Ini "Para Eksekutor". Tim yang isinya programmer, desainer, tester, dll. yang bener-bener ngebangun produknya. Mereka yang nentuin "gimana caranya" ngerjain tugas yang udah dipilih.
Alur Kerja / Ronde Permainan (The Flow)
Semua kerjaan di Scrum dilakuin dalam siklus yang disebut Sprint. Anggep aja satu Sprint itu satu "ronde permainan" yang biasanya berlangsung 2-4 minggu.
Berikut alurnya dalam satu Sprint:
1. Sprint Planning (Perencanaan Sprint)
- Kapan: Di awal banget setiap Sprint.
- Ngapain: Product Owner datang bawa daftar kerjaan (Product Backlog). Terus, seluruh tim diskusi bareng buat milih kerjaan mana aja dari daftar itu yang sanggup mereka selesaikan dalam satu Sprint ini.
- Hasil: Terbentuklah Sprint Backlog, yaitu daftar kerjaan yang jadi target buat diselesaikan di ronde ini.
2. Daily Scrum (Rapat Harian)
- Kapan: Tiap hari, di jam yang sama, selama Sprint berlangsung.
-
Ngapain: Rapat kilat, maksimal 15 menit. Setiap anggota tim jawab 3 pertanyaan:
- Kemarin gw ngerjain apa?
- Hari ini gw mau ngerjain apa?
- Ada halangan/masalah nggak?
- Tujuan: Biar semua anggota tim saling update dan bisa cepet bantu kalo ada yang mentok.
3. Sprint Review (Pameran Hasil)
- Kapan: Di akhir Sprint.
- Ngapain: Tim Pengembang nunjukkin atau demo-in hasil kerjaan mereka yang udah "jadi" selama Sprint ini ke Product Owner dan pihak lain (misal: klien, bos).
- Tujuan: Dapet feedback langsung tentang produk yang udah dibuat.
4. Sprint Retrospective (Introspeksi Tim)
- Kapan: Setelah Sprint Review, sebelum Sprint berikutnya dimulai.
-
Ngapain: Semua tim (PO, SM, Dev Team) ngumpul buat evaluasi. Bukan evaluasi produknya, tapi evaluasi cara kerjanya. Mereka diskusi soal:
- Apa yang udah bagus di Sprint ini?
- Apa yang kurang bagus?
- Apa yang bisa kita perbaiki buat Sprint selanjutnya?
- Tujuan: Biar tim jadi makin efisien dan kompak di ronde berikutnya.
Setelah itu semua selesai, siklusnya diulang lagi ke Sprint Planning untuk memulai ronde (Sprint) yang baru. Gitu terus sampe produknya jadi sempurna.
Alur Visual Sederhana
[ Product Backlog ] <-- (Daftar semua kerjaan, diurus PO)
|
V
[ Sprint Planning ] --> (Pilih kerjaan buat ronde ini) --> [ Sprint Backlog ]
| |
|--------------------------< SPRINT (2-4 MINGGU) >-----------------------------|
| |
| [ Daily Scrum ] <--> [ Daily Scrum ] <--> [ Daily Scrum ] ... |
| (Tiap Hari) |
| |
|--------------------------------> [ Increment / Produk Jadi ] -->-------------|
|
V
[ Sprint Review ]
(Demo hasil ke PO & Stakeholder)
|
V
[ Sprint Retrospective ]
(Evaluasi proses)
|
V
(ULANGI LAGI)
Intinya, Scrum itu soal kerja dalam siklus pendek, bikin produk sedikit demi sedikit, dapet feedback cepet, dan terus-terusan jadi lebih baik.
artinya diawal memang harus jelas dan detail fitur yang akan di buat ya?
Nah, ini pertanyaan bagus banget dan sering jadi salah paham soal Scrum.
Jawabannya: Nggak juga, dan justru di situlah letak kekuatan Scrum.
Lo nggak perlu punya detail semua fitur secara sempurna dari awal proyek. Yang perlu jelas dan detail itu cuma fitur-fitur yang akan dikerjain dalam Sprint terdekat (1-2 Sprint ke depan).
Begini cara kerjanya:
-
Piramida Terbalik: Bayangin
Product Backlog(daftar semua kerjaan) itu kayak piramida terbalik.- Bagian Atas (Prioritas Utama): Fitur-fitur yang mau dikerjain sebentar lagi harus sangat detail. Deskripsinya jelas, kriterianya lengkap, biar tim pengembang ngerti apa yang harus dibuat.
- Bagian Bawah (Prioritas Rendah): Fitur-fitur yang mungkin baru akan dikerjain beberapa bulan lagi cukup ditulis sebagai ide besar atau judul aja. Misalnya, "Integrasi Pembayaran via E-wallet" atau "Bikin Halaman Statistik User". Gak perlu detail dulu.
Kenapa dibuat kayak gitu?
Karena dunia nyata itu penuh perubahan. Kebutuhan user bisa berubah, ada teknologi baru muncul, atau kompetitor ngeluarin fitur baru.
- Kalau semua detail dari awal: Lo bakal buang-buang waktu ngedetailin fitur yang di tengah jalan ternyata nggak penting, harus diubah total, atau bahkan dibatalin. Sayang banget kan usahanya.
-
Dengan cara Scrum: Tim bisa fokus sama yang penting sekarang, sambil tetep fleksibel buat adaptasi sama perubahan di masa depan.
Product Ownerpunya tugas buat terus-menerus "memoles"Product Backlog, jadi fitur yang tadinya di bawah dan masih kasar, bakal didetailin pas gilirannya udah deket buat dikerjain.
Jadi, intinya:
- Awal proyek: Cukup punya visi besar dan daftar fitur secara umum.
- Menjelang Sprint: Baru detailin fitur-fitur yang jadi prioritas untuk Sprint tersebut.
Ini yang bikin Scrum disebut agile atau lincah. Bisa beradaptasi sama perubahan tanpa harus ngulang perencanaan dari nol.