Perencanaan sprint
Perencanaan sprint adalah tahap awal dalam sprint Scrum. Ini menentukan ruang lingkup dan cara melakukan pekerjaan selama sprint. Seluruh tim Scrum terlibat dalam perencanaan.
Sprint adalah periode waktu yang ditentukan dengan jelas di mana pekerjaan tertentu harus diselesaikan. Sprint membutuhkan perencanaan sebelum dimulai. Pertama-tama, Anda perlu menentukan durasi dan tujuan sprint.
Di bengkel perencanaan, daftar tugas dan tujuan sprint disepakati. Penting untuk mengisi tim dengan motivasi yang tepat untuk bekerja, sehingga setiap anggota fokus pada kesuksesan.
Jika sprint tidak direncanakan dengan baik, maka ini dapat menyebabkan kegagalan tim. Pengembang tidak akan dapat mengatasi ekspektasi yang diberikan kepada mereka, karena tugasnya ternyata tidak realistis.
Pertanyaan yang perlu dipertimbangkan saat merencanakan sprint:
- Pelanggan atau pemilik perangkat lunak mengumumkan tujuan sprint, sambil menjelaskan cara mencapainya. Tim Scrum mencari tahu tugas apa yang dapat diselesaikan dalam sprint mendatang untuk mencapai tujuan ini.
- Pengembang mendistribusikan rencana kerja di antara mereka sendiri, yang disepakati dengan pelanggan perangkat lunak.
- Pelanggan (pemilik) produk selalu mengambil bagian dalam menyusun rencana sprint. Dia menetapkan tujuan, dan tim pemrograman harus mencari tahu apakah itu dapat dicapai dalam sprint.
- Rencana tersebut harus menggunakan simpanan produk, informasi dari mana dapat ditambahkan ke rencana.
- Anggota tim harus mengakhiri rapat perencanaan dengan pemahaman yang jelas tentang apa yang mereka butuhkan untuk mencapai hasil. Anda dapat menampilkan urutan tindakan selanjutnya di sprint backlog.
Perencanaan tidak boleh melebihi dua jam per minggu. Scrum Master harus menjelaskan kepada semua orang bahwa ada batasan waktu. Jika semua masalah pekerjaan diselesaikan dengan cepat, maka rapat bisa berakhir lebih awal dari biasanya. Tidak ada durasi minimum untuk pertemuan semacam itu.
Evaluasi tugas
Menaksir kompleksitas pekerjaan tidak perlu berlebihan. Proses perencanaan tidak membutuhkan penilaian yang tepat, tetapi setidaknya perkiraan kompleksitas pembangunan. Tim tidak hanya harus memahami tujuan sprint, tetapi juga membandingkan tujuan dengan kemampuan timnya.
Untuk menilai kerumitannya, Anda bisa menggunakan ukuran pakaian yang biasa untuk semua orang (L, XL, XXL). Tentu saja, ini tidak memberikan jaminan keakuratan, tapi tetap saja.
Agar penilaian kompleksitas menjadi lebih akurat, diperlukan saling pengertian. Anggota tim harus secara terbuka membagikan pendapat mereka dan tidak takut untuk bertanya kepada pemilik produk.
Kritik terhadap tim setelah pekerjaan selesai dapat mengarah pada fakta bahwa ketika merencanakan sprint berikutnya, ramalannya akan kurang optimis. Ini akan membantu tim menghindari pengulangan kesalahan dan melindunginya dari penilaian negatif di masa mendatang.
Evaluasi kesulitan dalam poin, poin dan jam
Biasanya, tim pengembangan memperkirakan kompleksitas pekerjaan mereka dari waktu ke waktu. Tetapi beberapa tim Agile memilih untuk menilai kesulitan dalam poin atau poin. Ini adalah indikasi yang lebih baik dari total biaya yang diperlukan untuk mengimplementasikan item backlog atau tugas lain yang diberikan.
Poin diberikan berdasarkan kompleksitas dan volume pekerjaan. Selain itu, kemungkinan risiko diperhitungkan. Penilaian menggunakan metode ini membantu memecah pekerjaan menjadi langkah-langkah kecil secara efektif.
Dengan menggunakan metode penilaian (poin) secara teratur saat merencanakan, tim memiliki pemahaman yang lebih baik dan lebih akurat tentang berapa banyak waktu yang mereka perlukan untuk menyelesaikan pekerjaan. Selain itu, ada keuntungan lain juga.
- Estimasi waktu tidak memperhitungkan pekerjaan yang tidak terkait langsung dengan proyek, meskipun pasti akan muncul. Membahas masalah pekerjaan melalui messenger, mengadakan rapat - semua ini juga membutuhkan waktu bagi anggota tim.
- Emosi dapat memengaruhi pilihan tanggal. Penilaian saat mengevaluasi pekerjaan menghilangkan faktor ini.
- Penilaian kompleksitas pekerjaan dan, karenanya, kecepatan penyelesaian tugas mungkin berbeda untuk masing-masing tim. Bekerja dengan poin yang dibuat tidak dapat dianggap sebagai indikator kecepatan apa pun. Artinya, tidak ada tekanan psikologis pada tim.
- Dengan mendistribusikan biaya dan kerumitan tenaga kerja dengan benar, Anda dapat dengan cepat dan tanpa konflik membagi poin untuk pekerjaan yang dilakukan di antara para peserta.
- Jumlah poin yang diterima untuk menyelesaikan suatu tugas bergantung pada kerumitannya, dan bukan pada waktu yang dihabiskan. Oleh karena itu, pemrogram akan berpikir untuk meningkatkan efisiensinya, dan bukan tentang berapa lama waktu yang dibutuhkan.
Kerugian estimasi kompleksitas adalah sering disalahgunakan. Misalnya, metode ini tidak dapat digunakan untuk mengevaluasi karyawan.
Tim harus menggunakan sistem penilaian untuk lebih memahami jumlah pekerjaan yang ditugaskan kepada mereka dan memprioritaskan dengan benar.
Rapat Scrum Harian
Lokakarya itu penting: di sana, anggota tim berbagi pendapat, berkomunikasi, dan menyepakati tindakan lebih lanjut. Rapat scrum harian juga diperlukan untuk meningkatkan semangat tim dan mengumumkan berita terkini.
Stand-up adalah pertemuan singkat para peserta proyek utama: pemilik perangkat lunak, pemrogram, dan master scrum. Struktur stand-up terdiri dari tiga pertanyaan.
- Apa yang bisa kita lakukan kemarin?
- Apa yang sedang kita kerjakan hari ini?
- Apa yang menghalangi kita untuk mencapai hasil?
Mengajukan pertanyaan ini merangsang pengembangan dan membantu mengidentifikasi masalah dalam tim. Ketika setiap peserta mengkomunikasikan bagaimana dia membantu mencapai tujuan bersama, ini meningkatkan saling pengertian dalam tim.
Penting untuk diingat bahwa tidak ada pola tunggal untuk melakukan stand-up. Setiap tim mengadakan rapat dengan modelnya masing-masing, berdasarkan karakteristik tim.
Dan sekarang mari kita bahas apa yang dibutuhkan untuk stand-up yang sempurna dan berkenalan dengan contoh-contoh stand-up yang efektif.
Pertama, Anda perlu memilih waktu yang cocok untuk semua orang. Biasanya stand-up tim dari kantor yang sama diadakan di awal hari kerja - antara jam 9 dan 10 pagi. Ini memberi Anda waktu untuk merencanakan jadwal Anda hari itu dengan lebih baik. Jika anggota tim bekerja di wilayah yang berbeda, maka dipilih waktu yang cocok untuk semua orang. Misalnya, jika beberapa anggota tim tinggal di California dan Sydney, maka stand-up dimulai pukul 15:30 waktu California. Tentu saja, stand-up setelah makan malam tidak nyaman untuk semua orang, tetapi memungkinkan untuk tetap berhubungan dengan rekan kerja di seberang lautan.
Melacak produktivitas stand-up. Jangan mengadakan rapat terlalu lama - konsentrasi perhatian harus tetap maksimal. Jika memungkinkan, tahan stand-up tidak lebih dari 15 menit.
Gunakan bola. Itu bisa dilempar satu sama lain secara bergantian. Jadi semua orang akan terlibat dalam diskusi. Permainan ini membantu menjaga perhatian dalam kelompok. Gunakan retrospektif tim. Stand-up digunakan dalam banyak metodologi Agile, hal ini tidak menghalangi kami untuk membahas keefektifan stand-up pada retrospektif. Seseorang bertemu setiap hari, tim lain - beberapa kali seminggu. Jika sulit bagi tim untuk mendapatkan keuntungan dari stand-up, temukan alasannya dan ubah sesuatu.
Ulasan sprint
Tinjauan musim semi dilakukan pada tahap akhir sprint. Penting untuk memeriksa kenaikan produk dan menyesuaikan backlog. Seluruh tim scrum dan semua pemangku kepentingan berpartisipasi dalam peninjauan hasil sprint. Pertemuan diadakan dalam format santai untuk meningkatkan interaksi peserta proyek.
Tinjauan Hasil Sprint mencakup elemen-elemen berikut:
- Pemilik software menunjukkan apa dari backlog yang sudah selesai dan mana yang belum.
- Pemrogram mendiskusikan apa yang berjalan dengan baik, di mana kesulitan muncul, dan bagaimana cara menghilangkannya.
- Tim pengembangan menunjukkan hasil kerja mereka selama sprint, dan peningkatan produk apa yang mereka terima.
- Pemilik Produk membagikan pemikirannya tentang backlog saat ini. Ini juga memberikan perkiraan untuk tujuan selanjutnya dan tenggat waktu untuk implementasinya.
- Semua orang mendiskusikan apa yang terbaik untuk dilakukan selanjutnya berdasarkan penilaian pasar dan minat pengguna.
- Ada pertukaran pandangan tentang waktu, anggaran, dan prospek untuk menambah backlog.
Hasilnya adalah simpanan yang diperbarui dengan tujuan baru untuk sprint berikutnya. Backlog dapat diubah jika situasinya membutuhkannya.
Retrospeksi Sprint
Retrospektif Sprint adalah lokakarya yang membahas cara meningkatkan alur kerja Anda. Ini juga membuat rencana peningkatan untuk sprint berikutnya. Pertemuan biasanya berlangsung setelah tinjauan sprint dan memakan waktu tidak lebih dari tiga jam. Memimpin rapat adalah Scrum Master.
Tujuan utama Sprint Retrospective meliputi:
- Analisis sprint (pekerjaan peserta, hasil dan masalah).
- Diskusikan kemungkinan solusi untuk meningkatkan alur kerja dalam sprint berikutnya.
- Pembuatan rencana pelaksanaan perbaikan oleh anggota tim selama pelaksanaan proyek.
Scrum Master mengundang anggota tim untuk memberikan saran tentang cara meningkatkan efisiensi pengembangan. Tim membahas proposal dan menyarankan cara dan teknik tertentu untuk implementasinya.
Di akhir Retrospektif Sprint, tim harus menyoroti beberapa saran perbaikan untuk diterapkan di sprint berikutnya. Saran dapat diterapkan kapan saja, tetapi Sprint Retrospective memberikan kesempatan untuk melihat lebih dalam kemungkinan adaptasi mereka dari sudut pandang tim.
Di sinilah kami mengakhiri diskusi kami tentang metodologi Scrum. Anda dapat mempelajarinya lebih lanjut di dokumentasi tematik atau di tempat kerja pertama Anda.