Sejarah Scrum
Sejak publikasi laporan "Managing the Development of Large Software Systems" Winston Royce pada tahun 1970, banyak yang mencoba menemukan metodologi yang dapat menghilangkan kerugian dari model pengembangan Waterfall. Alternatif untuk “air terjun” adalah metode Scrum, yang akan dibahas sekarang.
Scrum mendapatkan namanya pada tahun 1986 dari karya Takeuchi dan Nonaki The New Rules for New Product Development. Dokumen ini berpendapat bahwa cara paling efektif untuk mencapai tujuan adalah dengan memberikan rencana tindakan yang jelas kepada pengembang.
Pada tahun 1995, panduan lain, "Pengembangan Perangkat Lunak dengan Scrum," oleh Sutherland dan Schweiber, muncul. Publikasi ini telah diperbarui beberapa kali. Sekarang dianggap sebagai panduan utama untuk pengembangan metode ini. Versi Panduan Scrum saat ini berisi informasi yang diperbarui pada tahun 2020.
Ketentuan utama Panduan Scrum menyarankan bahwa template manajemen proyek harus didasarkan pada fakta bahwa pengembang mengirimkan produk jadi dalam kerangka waktu yang disepakati - sprint. Untuk implementasi Scrum yang sukses, disarankan untuk menggunakan struktur yang terdiri dari beberapa elemen: peran, acara, aturan, dan artefak.
Peran dalam Scrum
Ada tiga peran dalam Scrum, yang semuanya membentuk tim Scrum:
Pelanggan produk perangkat lunak adalah orang yang paling penting dalam proyek, karena hanya dia yang sepenuhnya memahami nilainya bagi bisnis. Pelanggan menjelaskan kebutuhan pengguna akan produk masa depan kepada pengembang, tetapi dia tidak bertanggung jawab atas bagian teknis dari proses pengembangan. Pelanggan juga menentukan prioritas saat membuat elemen atau fungsi tertentu dalam produk.
Pengembang dipercayakan dengan implementasi tugas-tugas teknis, yang fungsi lintasnya bergantung pada ruang lingkup aplikasi. Pengembang sibuk membuat sprint backlog, menulis kode, menyesuaikan proyek dengan tujuan sprint, dan tugas lainnya.
Scrum Master adalah fasilitator tim Scrum. Ini memberikan bantuan kepada pelanggan dan pengembang. Sederhananya, Scrum Master sibuk berkomunikasi antara mereka yang tidak terlibat dalam proyek dan orang yang menulis kode. Terkadang tim pembuat kode yang berbeda di perusahaan besar yang sama berkomunikasi dan berkoordinasi pada rapat umum master scrum dari tim ini.
Acara di Scrum
Ada 5 jenis acara scrum:
Sprint adalah bagian terpenting dari Scrum. Ini termasuk perencanaan sprint, stand-up harian (scrum harian), review dan retrospektif sprint.
Perencanaan sprint. Semua anggota tim Scrum mengambil bagian dalam menyusun rencana sprint yang akan datang. Di sinilah ide produk disajikan dan setiap anggota tim dapat mengungkapkan pendapatnya, apa pendapatnya tentang hal ini. Kemudian pada pertemuan tersebut, prioritas ditentukan dan tenggat waktu diumumkan.
Daily Scrum adalah acara scrum singkat harian, yang berlangsung tidak lebih dari 15 menit. Biasanya dilakukan untuk merencanakan pekerjaan pembuat enkode untuk hari ini atau besok. Di Daily Scrum, Anda dapat mendiskusikan isu-isu terkini. Semua pengembang yang terlibat dalam proyek diharuskan untuk berpartisipasi dalam lokakarya semacam itu. Kehadiran Scrum Master diperbolehkan, tetapi tidak wajib.
Tinjauan Sprint (Demo) - Menampilkan hasil yang dibuat selama sprint. Biasanya acara ini berlangsung di tahap akhir. Semua orang yang tertarik mengambil bagian di dalamnya.
Sprint Retrospective - pembahasan hasil sprint. Anggota tim membagikan pendapat mereka tentang bagaimana mereka mengatasi tugas yang diberikan kepada mereka dan bagaimana meningkatkan hasil kerja di masa depan.
Selain itu, penyempurnaan backlog terkadang dilakukan - Backlog Refinement. Ini membahas item backlog, mempersiapkan sprint berikutnya, dan memprioritaskan tugas saat ini.
Artefak
Artefak scrum adalah pekerjaan yang terjadi di akhir proyek atau sprint. Ada tiga artefak - simpanan produk, simpanan sprint, dan kenaikan. Masing-masing diperlukan untuk pengiriman perangkat lunak yang tepat waktu kepada pengguna. Ada juga artefak tambahan (membakar grafik dan banyak lagi).
Komponen yang termasuk dalam artefak sprint:
Product backlog - fitur antarmuka dan backend.
Sprint backlog adalah daftar tugas yang perlu dilakukan selama iterasi. Mereka disepakati sebelum dimulainya sprint.
Penambahan - Jumlah total item backlog perangkat lunak yang dibuat selama sprint dan nilai penambahan yang dibuat sebelumnya. Inkremen baru yang telah selesai harus ditampilkan sebelum akhir sprint. Ini berarti Anda memiliki versi kerja yang memenuhi persyaratan tim scrum.
Item backlog produk - harus diselesaikan selama iterasi sprint. Sebagai aturan, elemen dibagi menjadi beberapa tugas kecil.
Tujuan sprint adalah tugas-tugas yang harus diselesaikan (membuat item backlog atau tugas lainnya).
Sprint burndown adalah pekerjaan yang tersisa sebelum akhir sprint. Bagan burn down bisa naik atau turun. Itu semua tergantung pada kesulitan yang dihadapi anggota tim saat bekerja. Ini bukan indikator kemajuan, tetapi hanya cara untuk memecahkan masalah dan insentif.
Product Release/Product Burn-Down Chart adalah bagan yang digambar oleh Scrum Master sebelum sprint berikutnya berakhir. Sumbu horizontal adalah sprint, sumbu vertikal adalah jumlah pekerjaan yang tersisa.
Aturan kerangka scrum
Peran, acara, dan artefak adalah dasar dari Scrum, tetapi ada aturan lain selain itu. Semuanya meningkatkan efisiensi proses kerja. Berikut daftar aturan tersebut:
- Tim scrum terdiri dari pelanggan perangkat lunak, master scrum, dan pengembang.
- Semua sprint harus memiliki panjang yang sama.
- Setelah menyelesaikan satu sprint, pengerjaan sprint baru segera dimulai.
- Sprint selalu dimulai dengan rencana.
- Anggota tim memiliki scrum pagi di awal hari kerja mereka.
- Setiap sprint ditinjau selama setiap sprint. Ini meningkatkan komunikasi antara tim dan pemangku kepentingan.
- Tidak disarankan untuk mengubah sprint backlog selama sprint berlangsung.
Keterbatasan dalam Scrum
Seiring dengan keuntungan yang jelas, Scrum juga memiliki kelemahan:
- Scrum sering menyebabkan penurunan jumlah pekerjaan yang dilakukan karena kurangnya tenggat waktu yang sama.
- Dengan keterlibatan yang rendah atau keengganan untuk bekerja sama di antara peserta proyek, ada kemungkinan besar untuk gagal dalam hasilnya.
- Struktur scrum sulit digunakan dalam tim besar, tetapi tetap memungkinkan. Ada kerangka kerja penskalaan untuk ini: LeSS, SAFe, Nexus, dan lainnya.
- Kepergian satu atau lebih anggota dari tim di tengah proyek tidak mempengaruhi proyek dengan baik.