Scrum

● Pendekatan agile lainnya adalah Scrum. Kata scrum diambil dari posisi
awal di rugby di mana tim rugby membentuk kerumunan dan
berjuang untuk menguasai bola. Scrum adalah menitikberatkan pada
kerja sama tim, mirip dengan apa yang dilakukan dalam bermain
rugby.
Anggota tim pengembangan sistem menyadari bahwa keberhasilan proyek
adalah yang paling penting, dan keberhasilan individu adalah yang kedua.
● Ini adalah metode agile/tangkas yang cocok untuk proyek yang lebih
kompleks dengan tindakan yang perlu dilakukan secara terus
menerus.

Peran yang Dimainkan di Scrum

1. Pemilik Produk
Pemilik produk dapat dipandang sebagai pencipta project creator
karena dia mengekspresikan visi untuk produk. Pemilik produk juga
bertanggung jawab atas rencana awal proyek, rilis produk, dan penilaian
akhir.
2. Master Scrum
Scrum Master memainkan banyak peran, termasuk sebagai pelatih
tim, penasihat yang berpengetahuan luas, pengembang
berpengalaman, dan fasilitator. Seorang Scrum Master harus memiliki
pengetahuan tentang praktek tangkas dan memiliki pengalaman untuk
membantu tim. Scrum Master adalah fasilitator tim, tetapi terkadang
mengambil peran untuk mengatasi rintangan bagi mereka. Budaya grup
bergantung pada Scrum Master. Dia memilih tim anggota, mengatur dan
memoderasi pertemuan Scrum, dan memoderasi konflik secara internal
dan secara eksternal.
3. Anggota Tim
- Bekerja untuk membuat dan meningkatkan cerita pengguna.
- Hasilkan perkiraan.
- Disiplin untuk menyelesaikan pekerjaan.
- Bersedia untuk berpartisipasi dalam kegiatan apapun untuk
membantu proyek.
Anggota tim dipilih karena soft skill dan technical skill mereka. Ingat soft
skill itu termasuk komunikasi dan membangun hubungan. Anggota
mungkin termasuk desainer, coders, pakar antarmuka pengguna, penguji,
dan pakar domain yang mengetahui tentang bisnis dan pelanggan.
Backlog Produk
Product backlog terdiri dari fitur dan desainer kiriman lainnya yang
ditujukan untuk produk berdasarkan cerita pengguna. Produk backlog juga
mencantumkan bug untuk diperbaiki atau bahkan aplikasi yang perlu
didokumentasikan.
Gambar 6.5 adalah product backlog registry. Kisah pengguna dijelaskan secara
singkat di kolom kedua. Kolom lain menjelaskan siapa yang akan mendapat
manfaat dari menyelesaikan setiap cerita pengguna, sumber daya apa yang akan
dibutuhkan, dan bagaimana kita akan tahu kapan cerita pengguna selesai dan
diterima.
Daftar cerita pengguna diatur ulang sehingga cerita pengguna yang paling
penting muncul di bagian atas. Ada banyak cara untuk memprioritaskan cerita
pengguna, tetapi hal-hal kecil yang dapat ditangani dengan cepat sangat cocok
untuk daftar teratas. Meskipun daftar ini tidak secara ketat diurutkan dalam waktu
pemrosesan terpendek, ini mendorong untuk menyelesaikan sesuatu.
Menyelesaikan banyak tugas kecil bisa lebih mendorong daripada menangani
satu tugas besar. Kisah pengguna perlu dipahami oleh semua orang di tim untuk
mengerjakan daftar. Cerita pengguna yang tidak jelas dapat ditempatkan lebih
jauh pada daftar backlog produk.

Siklus Sprint

Menyimpan daftar di backlog produk adalah satu hal, tetapi registri tidak
menyelesaikan apa pun kecuali tim mulai mengerjakan cerita pengguna dalam
daftar.
Sprint backlog dibuat untuk memilih cerita pengguna yang harus segera
diselesaikan.
Siklus sprint dapat bervariasi panjangnya, namun sebagian besar
perusahaan menetapkan dua minggu sebagai lamanya dari siklus sprint. Itu
memberi tim waktu dua minggu untuk mengirim beberapa cerita pengguna dan
kemudian memutuskan apakah produk siap untuk dirilis. Itu mungkin tampak
mustahil pada awalnya, tetapi begitu sebuah tim berhasil menjadi kebiasaan
siklus dua minggu, itu mulai menjadi rutin dan memuaskan pada saat yang sama.
Pada akhir siklus dua minggu, tim perlu menentukan apakah produk harus
dirilis. Pertanyaan pertama adalah, “Apakah rilis produk potensial ini
memiliki nilai?” Produk (yang aplikasi atau situs web yang sedang dikerjakan
tim) harus memiliki nilai lebih dari rilis sebelumnya. Pertanyaan kedua adalah,
"Apakah rilis produk siap dikirim?" Tim harus sudah selesai dan
menguji fitur baru berdasarkan cerita pengguna. Itu harus bekerja dan bebas dari
kesalahan. Rilis dua minggu memiliki banyak keuntungan. Semangat tim tetap
tinggi karena mudah untuk mengukur prestasi. Melengkapi produk lebih nyata
bagi tim. Jika tim dapat mengatasi masalah dalam waktu singkat, hanya perlu
beberapa rilis dua minggu untuk mendapatkan seluruh proyek selesai.
Keuntungan lain termasuk umpan balik terus menerus yang didapat tim dari
pelanggan. Pendek rilis adalah prototipe. Reaksi pelanggan sangat berharga.
Gambar 6.6 menunjukkan proses dan orang-orang yang terlibat dalam siklus
sprint. Perhatikan bahwa pemilik proyek, tim pengembang, dan produk perangkat
lunak yang baru dikembangkan semuanya memiliki peran untuk dimainkan.
Sprint adalah siklus pendek aktivitas pengembangan tim yang berlangsung
hanya dua hingga empat minggu, dengan tim rapat setiap hari selama sprint
untuk membuat rilis baru yang siap dikirim.

Fitur Unik Scrum Lainnya

- Rapat Perencanaan Scrum (Scrum Planning Meeting)
Ada dua bagian dalam rapat perencanaan Scrum. Pertama, Pemilik
produk menyajikan daftar fitur pada daftar keinginan cerita pengguna.
Pada titik ini, tim bertanya pertanyaan pemilik produk. Bagian kedua
melibatkan memperkirakan sumber daya yang dibutuhkan untuk
menyelesaikan semua fitur.
- Poker Perencanaan Scrum (Scrum Planning Poker)
Perencanaan poker adalah cara untuk membantu tim menentukan
perkiraan untuk menyelesaikan fitur yang muncul dari cerita pengguna.
Perencanaan poker dimainkan menggunakan setumpuk kartu.
Perencanaan poker bisa menjadi cara yang sangat berguna (dan
menyenangkan) untuk mengembangkan perkiraan waktu penyelesaian
untuk pekerjaan yang dilakukan desainer pada cerita pengguna.
Perkiraan yang baik sulit bagi pengembang yang tidak berpengalaman,
jadi alat seperti ini dapat meningkatkan keandalan perkiraan tim tanpa
membebani anggota tim yang lebih baru.
- Rapat Scrum Harian (Daily Scrum Meetings)
Pertemuan yang memulai Scrum harian disebut pertemuan stand-up
karena hanya berlangsung beberapa menit (konsepnya menyiratkan
bahwa anggota tim akan berdiri, tetapi hanya untuk waktu yang singkat).
Pada pertemuan ini anggota tim saling memberi tahu tugas apa yang
 telah mereka kerjakan sejak Scrum harian sebelumnya, tugas apa yang
mereka harapkan untuk diselesaikan selama Scrum harian saat ini, dan
hambatan apa yang mungkin menghalangi mereka.

- Menggunakan Grafik Burndown (Using Burndown Charts)

Salah satu cara untuk melacak kinerja adalah dengan menggunakan
grafik burndown sprint. grafik burndown yang dapat diperbarui setiap hari.
Grafik burndown adalah cara yang berguna untuk secara grafis
menunjukkan kemajuan proyek pengembangan perangkat lunak yang
gesit.
- Tinjauan Sprint (Tinjauan Sprint)
Di akhir sprint, tim berkumpul dalam rapat untuk meninjau pekerjaan yang
telah dilakukan dan mencatat tugas yang belum selesai. Kisah pengguna
yang diselesaikan didokumentasikan dengan jelas, dan kisah pengguna
yang dilakukan oleh tim yang belum selesai dicatat. Tim tidak membuat
keputusan untuk sprint berikutnya. Itu akan terjadi ketika tim mengulangi
langkah-langkah yang dimulai dengan membuat backlog produk baru.
Pertemuan ini adalah retrospektif di mana tim mengartikulasikan
pencapaian dan pelajaran. Dengan menyatakan apa yang berjalan
dengan baik dan apa yang tidak, tim dapat meningkatkan proses untuk
mengantisipasi sprint berikutnya.

Kanban
Kanban adalah konsep yang dikembangkan oleh Toyota untuk mencapai
cara penyampaian produk yang lebih efektif dan efisien. Arti kata dalam
bahasa Inggris adalah “signboard”, metode mengarahkan konsumen ke
area tertentu untuk menemukan produk atau mengarahkan karyawan ke
lokasi untuk mengisi kembali barang. Konsep kanban banyak digunakan
dalam pengembangan perangkat lunak saat ini.
Elemen kunci dari sistem kanban yang diterapkan pada pengembangan
perangkat lunak adalah:
1. Visualisasikan alur kerja.
2. Menjaga Work-in-process (WIP) sekecil mungkin.
3. Mengevaluasi kembali alur kerja, menetapkan kembali prioritas jika perlu.
4. Berusaha untuk perbaikan terus-menerus, menghilangkan kemacetan
dan mengevaluasi batas WIP.
Kanban didasarkan pada sistem Pull/Tarik. Berikut ini contohnya: Sebuah cerita
pengguna baru diperkenalkan yang menyatakan bahwa situs web perusahaan
harus diperbarui. Pemberitahuan ini berarti bahwa “Card” kanban harus dibuat.
Pekerjaan ini kebetulan menjadi prioritas tinggi, sehingga ditarik dari kolom
“backlog” ke kolom “sprint”. Segera itu ditarik ke dalam kolom "to-do". Ketika
desainer Web mulai mengerjakannya, mereka menarik tugas ke kolom "doing".
Setelah halaman web baru dibuat, tugas ditarik ke kolom "verify" sehingga tautan
dapat diuji dan divalidasi. Saat pengujian selesai, tugas ditarik ke kolom "done".
Konsep sistem pull/tarik membantu memastikan akuntabilitas dan tanggung
jawab ketika proyek membutuhkan tim orang.

Keuntungan dan Kerugian Scrum

Keunggulan dari scrum, antara lain:

1. Pengembangan produk cepat
2. Menjalankan pendekatan berorientasi pengguna
3. Mendorong kerja tim
4. Menjadi kurang membingungkan daripada pendekatan yang lebih formal
5. Fleksibilitas
6. Memuaskan bagi anggota tim
7. Menghargai pencapaian yang lebih kecil namun bermakna
8. Memberikan umpan balik
9. Kemampuan beradaptasi

Kerugian scrum, meliputi:

1. Mendokumentasikan fitur dengan tidak benar
2. Melepaskan produk dengan kesalahan
3. Melepaskan produk terlalu cepat untuk pengguna
4. Menyelesaikan sprint backlog di bawah tekanan
5. Bekerja sebagai tim yang tersebar secara geografis mungkin sulit
6. Bekerja sebagai tim ketika keterampilan khusus diperlukan mungkin
menantang
7. Mengganti anggota tim yang keluar dari tim itu sulit
Scrum adalah metodologi berintensitas tinggi yang memiliki banyak keuntungan
untuk mengembangkan paket yang kompleks dan inovatif. Ini adalah salah satu
pendekatan yang mengadopsi filosofi pemodelan tangkas; namun, jika menjadi
terlalu intens, sebuah organisasi dapat memutuskan untuk menggunakan metode
tangkas lainnya.