Apa itu Papan Tugas Sprint

---

Apa itu Papan Tugas Sprint?

Kotak tugas sprint adalah kotak waktu. Setiap sprint memiliki tanggal mulai dan akhir di mana sejumlah cerita pengguna yang dipilih harus diselesaikan dan dikonfirmasi. Gambar berikut menunjukkan elemen kunci dari sprint, yang mencakup sejumlah cerita pengguna, anggota scrum yang terlibat, penugasan pekerjaan, durasi dan tanggal akhir (sudut kanan atas).

Pada awal sprint, pemilik produk, pemangku kepentingan, dan tim pengembangan bertemu bersama untuk memprioritaskan, lalu memilih cerita pengguna yang akan diselesaikan dalam sprint. Karena berbagai pihak memiliki preferensi, pertimbangan, dan kekhawatiran yang berbeda terkait proyek dan jadwal proyek, tujuan pertemuan ini adalah memberi kesempatan kepada peserta yang berbeda untuk mendengarkan dan memahami pandangan satu sama lain, serta menentukan kumpulan cerita pengguna yang disetujui oleh semua pihak.

Durasi sprint

Pengiriman pekerjaan berkualitas secara cepat adalah salah satu alasan mengapa tim perangkat lunak ingin mengadopsi metodologi perangkat lunak agile. Oleh karena itu, meskipun tidak ada pilihan durasi sprint yang cocok untuk semua, umumnya disepakati bahwa durasi harus sependek mungkin. Tapi sependek apa seharusnya?

Meskipun durasi sprint yang panjang tidak diinginkan, durasi sprint yang terlalu pendek dapat melemahkan motivasi tim pengembangan dalam menyelesaikan pekerjaan penting, atau bahkan dapat menyebabkan kualitas hasil kerja yang buruk.

Jadi, pemilihan durasi sprint adalah hasil dari diskusi di seluruh tim – pemilik produk, scrum master, dan anggota scrum seperti desainer basis data, programmer, desainer UX, tester, analis, dll. Namun pada akhirnya, seseorang harus membuat keputusan. Pada saat itu, scrum master biasanya yang akan memberikan jawabannya.

Secara tradisional, sprint berlangsung selama tiga minggu hingga satu bulan, tetapi saat ini semakin banyak tim yang sukses dengan sprint dua mingguan. Bagaimanapun, belum ada pilihan tetap untuk durasi sprint. Seorang scrum master yang baik memiliki keterampilan kolaboratif dan fasilitatif dalam menentukan panjang sprint, agar pekerjaan dapat diselesaikan sesuai harapan. Berikut adalah beberapa faktor yang mungkin dipertimbangkan oleh scrum master:

1. Jadwal proyek yang disepakati
2. Ketersediaan pelanggan/pemangku kepentingan/pemilik produk (yang dapat menjelaskan keraguan potensial)
3. Kebudayaan kerja pelanggan
4. Kemampuan tim scrum
5. Pengalaman scrum

Setelah tim mencapai kesepakatan, semua sprint mendatang akan mengikuti durasi sprint yang sama tanpa sering mengubahnya dari sprint ke sprint. Namun, merupakan praktik baik bagi tim scrum untuk terus meninjau efektivitas sprint, dan menemukan durasi sprint optimal yang paling sesuai untuk semua pihak.

Konfirmasi Pekerjaan (Cerita Pengguna) dalam Sprint

Kegiatan pengembangan disusun di sekitar cerita pengguna setelah sprint dimulai, dan semakin banyak cerita pengguna yang diimplementasikan seiring berjalannya sprint. Namun, implementasi lengkap dari sebuah cerita pengguna bukanlah akhir dari cerita tersebut. Masih ada langkah penting yang harus dilalui – konfirmasi.

Untuk mengonfirmasi sebuah cerita pengguna adalah mencoba fitur yang telah diimplementasikan dan menentukan apakah fitur tersebut diimplementasikan sesuai harapan. Keputusan harus dibuat berdasarkan kriteria yang ditetapkan saat mendetailkan cerita pengguna, yang ditulis dalam bentuk item konfirmasi. Selama proses konfirmasi, pemilik produk diberikan lingkungan pengujian atau perangkat untuk menguji pekerjaan yang telah diimplementasikan. Pemilik produk akan memeriksa satu per satu item konfirmasi yang tertulis dalam cerita pengguna. Jika semua item dikonfirmasi telah selesai, maka cerita pengguna dikatakan telah dikonfirmasi. Jika ada item yang ditemukan belum selesai atau tidak berfungsi sesuai harapan, pemilik produk akan meminta tim pengembangan untuk memperbaiki. Proses perbaikan dan konfirmasi akan diulang hingga cerita pengguna sepenuhnya dikonfirmasi.

Kapan harus dikonfirmasi?

Sprint, dan pada kenyataannya agile adalah proses pengiriman berkelanjutan. Alih-alih mengonfirmasi cerita pengguna di akhir sprint, konfirmasi seharusnya dilakukan tepat setelah penyelesaian setiap cerita pengguna. Namun, jika pemilik produk gagal berpartisipasi dalam konfirmasi berkelanjutan, Anda dapat mengatur pertemuan mingguan yang berlangsung selama 1 hingga 2 jam. Selama pertemuan tersebut, pemilik produk akan bekerja bersama tim untuk mengonfirmasi cerita pengguna yang telah selesai. Pertemuan ini juga mencakup sesi diskusi yang menjelaskan keraguan yang muncul saat mengimplementasikan cerita-cerita lain yang termasuk dalam sprint.

Konfirmasi tidak setara dengan pengujian

Seperti dikatakan, tujuan konfirmasi adalah memastikan cerita pengguna diimplementasikan dengan benar. Keputusan dibuat berdasarkan item yang ditetapkan sebagai item konfirmasi saat mendetailkan cerita pengguna, tidak lebih dan tidak kurang. Skala pemeriksaan jauh dari cukup untuk memastikan fitur siap digunakan dalam produksi. Jadi, kapan harus melakukan ‘pengujian nyata’?

Tim yang berbeda memiliki praktik yang berbeda terkait pengujian perangkat lunak. Beberapa tim lebih memilih pengujian per-sprint yang melibatkan pelaksanaan pengujian seperti pengujian integrasi dan pengujian regresi pada akhir sprint. Beberapa tim lebih memilih menyiapkan sprint stabilisasi, seperti namanya, untuk pengujian dan perbaikan bug. Tidak akan ada aktivitas pengembangan baru dalam sprint tersebut.

Tidak peduli pendekatan apa yang Anda pilih, perlu diingat bahwa pilihan tersebut bukan milik satu orang, tetapi milik semua orang.

Visual Paradigm menyediakan semua alat yang Anda butuhkan dalam pengembangan perangkat lunak agile, yang mencakup alat diagram kasus pengguna UML, (agile) cerita pengguna, sprint, storyboard dan wireframe untuk desain UX, alat manajemen tugas, dll.