Friday, October 19, 2018

SCRUM


Scrum adalah sebuah proses yang Agile untuk menangani produk yang kompleks. Scrum memiliki proses yang berulang atau iteratif (iterative) dan bertahap (incremental) dalam menangani ketidakpastian dari pengembangan sebuah produk yang kompleks.

Agile Development Methods adalah sekelompok metodologi pengembangan perangkat lunak yang didasarkan pada prinsip-prinsip yang sama atau pengembangan sistem jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun.

Scrum sebuah metodologi?
Scrum bukan metodologi, Scrum adalah sebuah framework (kerangka kerja). Scrum sebagai framework mengatur hal-hal penting dan mendasar untuk membuat proses pengembangan menjadi lebih agile. Dalam kaitannya dengan pengembangan software, kita bisa menambahkan engineering practice tertentu yang dibutuhkan di atas framework Scrum.

Agile dan kaitannya dengan Scrum
Scrum tidak dapat dipisahkan dari yang namanya Agile. Agile merupakan kata sifat yang berarti cekatan, cepat, dan tangkas dan ini tersemat pada proses Scrum. Itulah mengapa kita mengatakan Scrum sebagai proses Agile. Dalam pengembangan software, prinsip dan nilai Agile pada Scrum mengacu ke Agile Manifesto.
Agile Manifesto merupakan nilai-nilai yang digunakan dalam mendasari berlangsungnya Agile Software Development. Agile Manifesto muncul dilatarbelakangi oleh frustasi para pengembang software akibat metode yang digunakan pada saat itu, yaitu Waterfall Model.

Bedanya Scrum dengan yang lain
Scrum termasuk ke dalam keluarga proses Agile. Kita bisa menemukan proses Agile yang lain seperti XP (eXtreme Programming) atau Crystal. Pendekatan pengembangan, mekanisme adaptasi perubahan, nilai, dan prinsip dalam proses Agile amat berbeda dibandingkan dengan proses prescriptive seperti Waterfall atau RUP (Rational Unified Process).

Siapayang terlibat dalam Scrum?
Ada tiga peran utama yang terlibat dalam proses Scrum, yaitu:
(1)Development Team, 
(2)Product Owner, dan 
(3)Scrum Master. 
Tiga peran utama ini tergabung dalam satu tim dan disebut sebagai Scrum Team. Meski tidak disebutkan secara eksplisit, peran-peran di luar Scrum Team tetap penting dan bermanfaat untuk menciptakan lingkungan yang mendukung proses Scrum dalam organisasi.

Peran Development Team
Development team adalah tim pengembang yang melakukan pembuatan produk. Dalam konteks software, development team memberikan peningkatan software yang bertahap dari waktu ke waktu. Anggota development team tersusun dari software developer, designer, business analyst, application tester, dan peran khusus lainnya yang dibutuhkan untuk mengubah requirement dalam bentuk PBI (Product Backlog Item) menjadi software. Mereka semua bekerja sebagai satu tim, berkolaborasi menyusun solusi dan saling membantu satu sama lain untuk mencapai tujuan pengembangan software.

Jumlah anggota Development Team dalam Scrum
Jumlah anggota development team tidaklah terlalu banyak dan juga tidak terlalu sedikit. Jumlah yang direkomendasikan adalah minimal 3 orang dan maksimal 9 orang. Kurang dari 3 orang, kerja sebagai tim menjadi kurang optimal. Lebih dari 9 orang, koordinasi antar anggota tim akan menjadi lebih rumit.

Self-organizing pada Development Team
Self-organizing pada tim memiliki arti bahwa tim mengatur dirinya sendiri dalam menyelesaikan tugas dan kerjaannya. Self-organizing pada development team berarti tim diberikan otonomi untuk memilih cara dan alat (tools) untuk mencapai tujuan pengembangan software. Tidak seorangpun, termasuk Scrum Master atau Product Owner, diperkenankan untuk memberitahu development team bagaimana cara mereka mengubah PBI menjadi peningkatan software.

Peran Scrum Master
Scrum Master merupakan seseorang yang membantu tim membangun produk dalam proses Scrum. Scrum Master memastikan praktik, nilai, dan aturan dalam Scrum diterapkan secara tepat. Lebih lanjut lagi, Scrum Master membantu memfasilitasi keputusan development team yang self-organizing dan menghapus hambatan-hambatan yang dihadapi oleh development team. Untuk organisasi, Scrum Master membantu organisasi memahami Scrum dan membuat perubahan-perubahan yang mendukung proses Scrum.

Peran Product Owner
Product owner adalah seseorang yang memahami nilai produk yang akan dibangun dan memaksimalkannya dalam kerja dengan development team. Product owner menjelaskan visi produk kepada development team, mengapa produk ini dibuat dan apa nilai yang diberikan dari produk tersebut. Product owner mewakili stakeholders atau klien, menyusun apa yang sebenarnya diinginkan dan dibutuhkan oleh mereka dalam bentuk requirement. Requirement tersebut selanjutnya direpresentasikan dalam PBI (Product Backlog Item). Melalui pengelolaan PBI inilah, product owner akan menyusun prioritas pengembangan berdasarkan nilai bisnis dan berkolaborasi secara aktif dengan development team dalam mengembangkan produk.

PBI, Product Backlog, dan Sprint Backlog
PBI atau Product Backlog Item merepresentasikan requirement yang dibutuhkan agar hadir dalam produk. PBI umumnya merupakan User Story, yaitu gambaran bagaimana pengguna melakukan sesuatu dan berinteraksi dengan produk. Selain itu, PBI bisa juga merupakan fitur, perbaikan kesalahan, atau peningkatan fitur. Kumpulan PBI secara keseluruhan disebut Product Backlog. Sedangkan beberapa PBI yang terpilih untuk dikerjakan selama sprint disebut Sprint Backlog.

Sprint
Sprint adalah potongan waktu pengembangan yang umumnya dilakukan dalam 2 minggu dan paling lama 4 minggu atau 1 bulan. Yang dilakukan dalam sprint tentu saja pengembangan produk untuk mencapai tujuan sprint. agar pengembangan lebih terarah, ada empat acara penting dalam Scrum, yaitu:
(1)planning meeting, 
(2)daily meeting, 
(3)review meeting, dan 
(4)retrospective meeting. 
Pertemuan-pertemuan tersebut dalam Scrum memiliki karakteristik yg unik dan tujuan yang penting.

Planning meeting
Planning meeting merupakan pertemuan di awal sprint yang membahas rencana kerja selama satu sprint ke depan. Selama sesi ini, Scrum team membahas PBI (Product Backlog Item)yang dipilih selama sprint, detail dan kriterianya, hingga Definition of Done (DoD) dari setiap PBI yang dipilih. Product owner akan menjelaskan visi produk, tujuan yang ingin dicapai pada sprint kali ini, hingga detail requirement dalam suatu PBI, sedangkan development team akan memilih PBI selama satu sprint dan mengukur beban pekerjaan mereka.

Lama planning meeting
Untuk sprint selama 4 minggu atau 1 bulan, pertemuan ini paling lama 8 jam. Untuk sprint selama 2 minggu, paling lama 4 jam.

Daily meeting
Daily meeting merupakan pertemuan bagi development team untuk berbagi informasi sekaligus memantau kemajuan pekerjaan pengembangan.

Pertemuan ini cukup singkat, paling lama 15 menit.
Selama sesi ini, setiap anggota tim menjelaskan tiga hal, yaitu:
(1)apa yang sudah dikerjakan sejak pertemuan sebelumnya,
(2)apa yang akan dikerjakan hingga pertemuan berikutnya, dan
(3)apa masalah atau hambatan yang dihadapi dalam pengerjaan.
Dengan adanya daily meeting, tim dapat melakukan sinkronisasi kerjaan antar anggota development team, mengukur kemajuan pengembangan dan melakukan penyesuaian terhadapnya, juga meminta bantuan kepada yang lain jika menghadapi masalah.

Review meeting
Review meeting merupakan pertemuan di akhir sprint yang membahas hasil pengembangan yang sudah dikerjakan oleh development team selama satu sprint ini. Pertemuan ini melibatkan Scrum team dan klien atau stakeholders yang terkait. Selama sesi ini, development team mendemokan PBI yang sudah mereka kerjakan dan mengumpulkan masukan dari klien atau stakeholders untuk pengembangan di sprint berikutnya.

Lama review meeting
Untuk sprint selama 4 minggu atau 1 bulan, pertemuan ini paling lama 4 jam. Untuk sprint selama 2 minggu, paling lama 2 jam.

Retrospective meeting
Retrospective meeting juga merupakan pertemuan di akhir sprint dan diadakan setelah review meeting. Pertemuan ini merupakan saat bagi Scrum team untuk menengok ke belakang selama satu sprint ini, meninjau proses yang dilalui dan hasil yang dicapai selama pengembangan. Retrospective meeting berguna untuk menghasilkan komitmen perbaikan untuk Scrum team dan sprint yang lebih baik ke depannya.

Lama retrospective meeting
Untuk sprint selama 4 minggu atau 1 bulan, pertemuan ini paling lama 3 jam. Untuk sprint selama 2 minggu, paling lama 1.5 jam.