Scrumadalah kerangka manajemen proyek yang menekankan kerja tim, akuntabilitas, dan kemajuan iteratif menuju tujuan yang jelas. Ini dimulai dengan premis sederhana: mulailah dengan apa yang dapat Anda lihat atau ketahui. Kemudian, lacak kemajuan dan sesuaikan sebagaimana diperlukan.
Tiga Pilar Scrum
Scrum berakar pada empirisme, yang menyatakan bahwa pengetahuan berasal dari pengalaman dan keputusan harus didasarkan pada apa yang diketahui. Ketiga pilar ini mengikat Scrum bersama.
Mengapa Scrum?
Scrum menghadirkan fungsi secara bertahap, sedangkan Waterfall hanya menghadirkan dalam tahapan. Pengembangan Waterfall tradisional adalah proses berurutan berbasis tahap di mana nilai tidak dikirimkan hingga akhir proyek. Scrum mengubah model ini dengan menghadirkan fitur baru setiap sprint—biasanya setiap 2–4 minggu—daripada fokus pada rilis besar di masa depan.
Scrum memecah pekerjaan yang kompleks menjadi bagian-bagian yang dapat dikelola, membagi organisasi besar menjadi tim kecil, dan mengubah proyek-proyek yang berdampak menjadi serangkaian sprint pendek yang dibatasi waktusprint.
Melalui pengembangan iteratif dan bertahap, perusahaan dapat menghadirkan produk dan layanan yang benar-benar dibutuhkan pelanggan lebih cepat dan lebih efisien. Dengan Scrum, Anda dapat menerima dan mengintegrasikan umpan balik pelanggan di akhir setiap sprint, yang berarti hasil Anda dibentuk oleh penggunaan dunia nyata daripada asumsi. Ini membuat lebih mudah untuk menjaga pelanggan dan pemangku kepentingan kunci tetap terlibat secara aktif.
Agile vs Scrum
Agileadalah praktik yang memungkinkan iterasi terus-menerus dalam pengembangan dan pengujian sepanjang SDLC. Agile memecah produk menjadi komponen-komponen kecil yang dapat dikelola.Scrum hanyalah salah satu dari banyak proses pengembangan perangkat lunak Agile yang iteratif dan bertahapyang memungkinkan kita fokus pada pengiriman nilai bisnis dalam waktu sesingkat mungkin.
Scrum biasanya menangani persyaratan yang dapat berubah atau tidak diketahui pada awal proyek. Scrum ditandai oleh:
- Ringan
- Mudah dipahami
- Sulit dikuasai
Manfaat Scrum
Berikut adalah manfaat yang dibawa Scrum bagi organisasi, tim, produk, dan individu:
- Kualitas Lebih Baik: Ada kerangka untuk mencapai visi atau tujuan. Scrum memberikan umpan balik dan visibilitas terus-menerus untuk memastikan kualitas seoptimal mungkin. Scrum membantu menjamin kualitas melalui praktik seperti:
- Waktu Pencapaian Pasar yang Dikurangi: Scrum telah terbukti menghadirkan nilai bagi pengguna akhir 30%–40% lebih cepat dibandingkan metode tradisional.
- Pengembalian Investasi (ROI) yang Lebih Tinggi: Waktu pencapaian pasar yang lebih singkat adalah alasan utama proyek Scrum mencapai ROI yang lebih tinggi. Akumulasi pendapatan dan manfaat awal berarti pengembalian total yang lebih tinggi. Ini didasarkan pada prinsip dasar perhitungan Nilai Sekarang Bersih (NPV).
- Semangat Tim yang Lebih Tinggi: Bekerja dengan individu yang bahagia dan terlibat adalah memuaskan dan produktif. Manajemen diri menempatkan keputusan yang biasanya dibuat oleh manajer atau organisasi ke tanganTim Scrum anggota.
- Kolaborasi Tim yang Lebih Kuat: Ketika tim Scrum memiliki proyek dan produk, mereka dapat mencapai hasil yang luar biasa. Tim Scrum bekerja sama dan meningkatkan kualitas serta kinerja proyek melalui keterlibatan dan komunikasi yang lebih baik.
Kerangka Kerja Scrum
Scrum sederhana. Ini bukan sekumpulan perintah kaku yang saling terkait. Scrum bukan sebuah metodologi. Scrum menggambarkan metode ilmiah empirisme. Ia menggantikan pendekatan algoritmik prosedural dengan metode heuristik, menghargai manusia dan otonomi diri untuk mengatasi ketidakpastian dan menyelesaikan masalah yang kompleks. Diagram di bawah ini menunjukkan Scrum dalam tindakan, seperti yang dijelaskan oleh Ken Schwaber dan Jeff Sutherland dalam buku mereka “Scrum: Seni Melakukan Dua Kali Kerja dalam Waktu Setengahnya,” menggambarkan perjalanan dari perencanaan hingga pengiriman perangkat lunak.
Komponen Proses Scrum
Kerangka kerja Scrum sendiri sederhana. Ia hanya menentukan beberapa pedoman umum, dengan sejumlah kecil aturan, peran, hasil kerja, dan acara. Namun, masing-masing komponen ini sangat penting untuk tujuan tertentu dan esensial untuk menggunakan kerangka kerja secara sukses.
Komponen utama dari Kerangka Kerja Scrum adalah:
- Peran Scrum: Master Scrum, Pemilik Produk, dan Tim Scrum
- Hasil Kerja: Backlog Sprint, Backlog Produk, Grafik Burndown, log, dll.
- Acara Scrum: Perencanaan Sprint, Tinjauan Sprint, Scrum Harian, Refleksi Sprint, dll.
- Sprint
Diagram di bawah ini menunjukkan elemen utama dari kerangka kerja Scrum. Proses ini divisualisasikan menggunakan Kanvas Proses Scrum dari alat perangkat lunak Agile Visual Paradigm.
Peran Scrum
Ketika suatu organisasi mengadopsi Scrum, hal pertama yang harus dipahami adalah bagaimana peran Scrum berbeda dari peran manajemen proyek tradisional. Meskipun hanya ada tiga peran utama dalam Scrum, mereka tidak secara otomatis sesuai dengan jabatan yang umum dikenal. Mari kita mulai dengan definisi singkat masing-masing:
Pemilik Produk
Pemilik Produk adalah peran Scrum yang bertanggung jawab untuk mewakili bisnis atau komunitas pengguna. Mereka bekerja erat dengan pengguna untuk menentukan fitur dalam backlog produk. Tanggung jawab utama meliputi:
- Menentukan visi dan strategi produk, termasuk tujuan jangka pendek dan jangka panjang;
- Menyediakan atau mengumpulkan pengetahuan tentang produk atau layanan;
- Memahami dan menyampaikan kebutuhan pelanggan kepada tim pengembangan;
- Mengumpulkan, memprioritaskan, dan mengelola persyaratan produk atau layanan;
- Menanggung tanggung jawab anggaran produk atau layanan, termasuk profitabilitas;
- Menentukan tanggal rilis produk atau layanan;
- Menjawab pertanyaan dan membuat keputusan setiap hari bersama tim pengembangan;
- Menerima atau menolak pekerjaan yang telah selesai dari Sprint;
- Menyajikan hasil utama tim pada akhir setiap Sprint;
- Mengelola Backlog Produk.
Master Scrum
Master Scrum adalah fasilitator tim pengembangan Agile. Scrum memungkinkan tim untuk mengatur diri sendiri dan beradaptasi dengan cepat berdasarkan prinsip Agile. Master Scrum mengelola aliran informasi. Tanggung jawab utama:
- Bertindak sebagai pelatih untuk membantu tim mengikuti nilai dan praktik Scrum;
- Membantu menghilangkan hambatan dan melindungi tim dari gangguan eksternal;
- Memfasilitasi kolaborasi yang baik antara tim dan pemangku kepentingan;
- Mempromosikan akal sehat dan transparansi dalam tim;
- Melindungi tim dari gangguan organisasi.
Tim Scrum
Tim Scrum (juga dikenal sebagai Tim Pengembangan) terdiri dari 3 hingga 9 anggota yang harus secara kolektif memiliki semua keterampilan teknis yang dibutuhkan untuk menghasilkan produk atau layanan. Mereka dibimbing langsung oleh Master Scrum tetapi tidak dikelola secara tradisional. Mereka harus mandiri, lintas fungsi, dan bertanggung jawab atas penyelesaian semua tugas yang diperlukan.
Tim pengembangan bertanggung jawab untuk menghasilkan peningkatan produk yang dapat dikirimkan pada akhir setiap Sprint—meliputi analisis, desain, pengembangan, pengujian, dan penulisan teknis. Karakteristik penting dari tim Scrum meliputi:
- Mandiri: Semua anggota tim mengelola pekerjaan mereka sendiri untuk menyelesaikan tugas yang ditugaskan. Dalam Scrum Agile, tidak ada pemimpin tim atau manajer langsung. Semua orang harus berkomitmen cukup untuk menggerakkan aktivitas mereka sendiri dan berkontribusi terhadap keberhasilan tim. Jika satu orang gagal, semua orang gagal.
- Lintas Fungsi: Semua anggota tim harus memiliki semua pengetahuan dan keterampilan yang diperlukan untuk menghasilkan produk yang berkualitas tinggi dan dapat dikirimkan. Ahli dapat dipanggil untuk bimbingan, tetapi hanya untuk mentransfer pengetahuan ke tim guna menutup celah keterampilan.
- Product Owner Membutuhkan Visi Bisnis: Product Owner mewakili suara pelanggan dan harus menerjemahkan kebutuhan mereka menjadi item yang dapat ditindaklanjuti bagi Master Scrum dan tim pengembangan. Ini biasanya merupakan peran penuh waktu.
- Master Scrum Bukan Manajer Langsung: Mereka membantu melatih tim pengembangan dan menghilangkan hambatan yang menghambat kemajuan.
Artifak Scrum
Artifak Scrum membantu mendefinisikan pekerjaan yang masuk ke tim dan saat ini sedang dikerjakan. Meskipun ada lebih banyak artifak—seperti cerita pengguna, daftar rilis, grafik burndown—di sini kita fokus pada tiga utama:
Daftar Produk
Daftar Produk adalah daftar yang diprioritaskan dari cerita pengguna yang mewakili fitur yang dibutuhkan atau diharapkan oleh tim produk. Biasanya, Product Owner yang memelihara daftar ini.
Sprint Backlog
Daftar Sprint berisi sejumlah item yang dipilih untuk diselesaikan selama Sprint saat ini. Dua poin penting yang perlu diperhatikan mengenai hubungan antara Daftar Sprint dan Daftar Produk:
1. Tim menentukan apa yang harus ditambahkan ke Sprint. Oleh karena itu, tim memiliki dan bertanggung jawab atas pengiriman item-item tersebut.
2. Sebelum memindahkan suatu item dari Daftar Produk ke Daftar Sprint, tim harus memastikan mereka memiliki semua informasi yang diperlukan. Tim biasanya menentukan daftar periksa kriteria yang harus dipenuhi sebelum suatu item dapat ditambahkan.
Daftar Produk vs Daftar Sprint
Daftar Sprint Backlog adalah daftar tugas yang dikomit oleh tim Scrum untuk diselesaikan selama Sprint. Selama pertemuan perencanaan Sprint, tim biasanya memilih beberapa Item Daftar Produk dalam bentuk cerita pengguna dan menentukan tugas-tugas yang diperlukan untuk menyelesaikannya, seperti yang ditunjukkan di bawah ini:
Grafik Burndown
Grafik Burndown adalah representasi grafis dari pekerjaan yang tersisa seiring waktu. Pekerjaan yang tersisa (atau pekerjaan backlog) ditampilkan pada sumbu vertikal, dengan waktu pada sumbu horizontal. Ini adalah grafik yang terus diperbarui mengenai pekerjaan yang tersisa untuk dilakukan. Dapat digunakan untuk memprediksi kapan semua pekerjaan akan selesai. Ini umum digunakan dalam metode pengembangan perangkat lunak Agile seperti Scrum tetapi dapat diterapkan pada proyek apa pun yang memiliki kemajuan yang dapat diukur seiring waktu. Pekerjaan yang tersisa dapat diukur dalam waktu atau poin cerita.
Acara Scrum
Komunikasi adalah kunci! Scrum mengandalkan transparansi di semua aspek (Pilar Scrum #1). Mengingat prinsip inti ini, kerangka kerja dibangun di sekitar serangkaian acara utama untuk memastikan dua pilar lainnya—Periksa dan Sesuaikan—seperti yang ditunjukkan pada tabel di bawah ini:
| Acara | Periksa | Sesuaikan |
|---|---|---|
| Perencanaan Sprint |
|
|
| Scrum Harian |
|
|
| Ulasan Sprint |
|
|
| Refleksi Sprint |
|
|
Catatan: Selama setiap Sprint, terdapat lima pertemuan utama dalam Scrum, seperti yang ditunjukkan di bawah ini:
Perencanaan Sprint
Setiap Sprint dimulai dengan perencanaan. Tim harus menentukan dan berkomitmen terhadap apa yang akan mereka hasilkan sebagai bagian dari Sprint. Item yang mungkin selalu diambil dari Sprint Backlog, seperti yang ditunjukkan di bawah ini:
Di sinilah Scrum Master dapat bersinar. Product Owner menentukan apa yang dibutuhkan dari sudut pandang bisnis/pelanggan, tim Scrum menentukan apa yang mereka percaya dapat mereka hasilkan, dan Scrum Master memastikan keseuaian terbaik bagi kedua belah pihak.
Rapat Harian Scrum
Setelah tim berkomitmen terhadap apa yang akan mereka hasilkan sebagai bagian dari Sprint, mereka mengadakan Daily Stand-up. Tujuan utama adalah memastikan setiap anggota tim (dan mungkin pengamat) memahami sepenuhnya status dan kemajuan pekerjaan:
- Apa yang telah saya lakukan kemarin?
- Apa yang akan saya lakukan hari ini?
- Apa yang menghambat saya?
Pembaruan harian ini memberikan umpan balik langsung kepada tim. Rapatnya singkat—tidak lebih dari 3 menit per orang.
Catatan:Pengamat hadir untuk mengamati. Scrum Master harus meminimalkan gangguan eksternal dan internal.
Rapat Tinjauan Sprint
Rapat Tinjauan Sprint atau Demo diadakan di akhir Sprint untuk meninjau Increment. Tim memperlihatkan Increment berdasarkan Definisi Selesai, dengan fokus pada Tujuan Sprint. Product Owner meninjau dan menerima Increment yang telah dikirimkan.
Refleksi Sprint
Refleksi Sprint biasanya merupakan aktivitas terakhir dalam Sprint. Banyak tim melakukannya segera setelah Rapat Tinjauan Sprint. Seluruh tim—termasuk Scrum Master dan Product Owner—harus berpartisipasi. Refleksi selama satu jam biasanya cukup. Rapat ini memungkinkan tim untuk merefleksikan:
- Apa yang harus kita mulai lakukan?
- Apa yang harus kita hentikan?
- Apa yang harus kita lanjutkan?
Tujuannya adalah terus-menerus meningkatkan efisiensi tim.
Penyempurnaan Backlog
Bayangkan Product Backlog sebagai peta jalan proyek. Seiring tim berkolaborasi, mereka membuat dan memperbarui daftar semua item yang dibutuhkan untuk menyelesaikan proyek, memastikan semua persyaratan yang diperlukan terpenuhi.
Sprint
Dalam kerangka kerja Scrum, semua aktivitas yang diperlukan untuk menerapkan suatu item dari Product Backlog Scrum dilakukan dalam satu Sprint (juga disebut “Iterasi”). Sprint selalu singkat—biasanya 2 hingga 4 minggu. Setiap Sprint mengikuti proses yang ditentukan, seperti yang ditunjukkan di bawah ini:
Seperti yang telah disebutkan, item dalam Product Backlog diprioritaskan dan dipilih untuk Sprint Backlog. Sprint hanya berisi beberapa item utama—setiap underestimasi pekerjaan untuk satu item dapat berdampak signifikan terhadap Sprint. Karena item yang lebih besar sering kali lebih sulit diperkirakan dan dipahami, risiko kegagalan Sprint meningkat. Tim Scrum yang berpengalaman menghabiskan waktu dan usaha untuk memecah item yang kompleks atau besar (misalnya fitur pengguna atau Epics) menjadi cerita pengguna yang lebih kecil (atau bahkan lebih jauh menjadi tugas atau sub-tugas).
Epic
Epic menangkap sejumlah besar pekerjaan. Secara esensial, ini adalah “cerita pengguna besar” yang dapat dipecah menjadi banyak cerita kecil. Menyelesaikan sebuah Epic mungkin memakan beberapa Sprint. Oleh karena itu, ketika menggunakan Epic dalam pengembangan, mereka harus dipecah menjadi cerita pengguna yang lebih kecil.
Epic diperkenalkan pada awal siklus proyek. Mereka adalah poin fungsional tingkat tinggi, hampir berfokus pada pemasaran.
Kami menyebut cerita besar sebagai ‘Epic’ untuk menyampaikan skalanya. Bayangkan seperti film. Jika saya memberi tahu Anda sebuah film adalah ‘aksi-petualangan’, Anda akan mendapatkan gambaran tentang apa yang diharapkan—mungkin kejar-kejaran mobil, tembakan, dll. Demikian pula, menandai sebuah cerita sebagai ‘Epic’ kadang-kadang dapat menyampaikan konteks tambahan.
Cerita Pengguna
Cerita Pengguna adalah pernyataan singkat mengenai kebutuhan produk atau kasus bisnis. Biasanya ditulis dalam bahasa sederhana untuk membantu pembaca memahami apa yang seharusnya dilakukan oleh perangkat lunak. Product Owner membuat cerita tersebut. Kemudian, anggota tim Scrum memecah cerita menjadi satu atau lebih tugas Scrum.
Cerita pengguna biasanya merupakan fitur yang terlihat oleh pengguna akhir. Mereka mengikuti format: “Saya ingin [melakukan sesuatu] agar [saya bisa mencapai tujuan].” Mereka memberikan nilai kepada pelanggan/pengguna. Ini adalah persyaratan produk pelanggan.
Contoh: “Sebagai pelanggan, saya ingin membuat akun agar saya bisa melihat pembelian saya dari tahun lalu untuk membantu saya merencanakan anggaran tahun depan.”
Tugas
Sebaliknya, suatu Tugas bersifat lebih teknis. Tugas-tugas sering melibatkan kode, desain, pembuatan data uji, otomasi, dll. Ini biasanya tanggung jawab individu. Tugas-tugas tidak ditulis dalam format cerita pengguna. Mereka lebih teknis.
Contoh: “Evaluasi sudut antarmuka menggunakan Material Design” atau “Kirim aplikasi ke App Store.”
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish