Sprint perangkat lunak Agile – rencana, bangun, uji, rilis

InformatikaKarier di bidang komputerUsia 17–18

Tim perangkat lunak kecil menjalankan sprint Agile untuk membuat aplikasi klub sekolah: pilih user story dari backlog yang sesuai kapasitas tim, lalu simulasikan sprint hari demi hari. Kartu bergerak melalui kolom Akan dikerjakan, Dikerjakan, Pengujian dan Selesai, grafik burndown melacak poin yang tersisa, dan bug yang muncul saat menulis kode tertangkap oleh pengujian atau lolos ke pengguna. Sprint diakhiri dengan review yang menilai kepuasan pelanggan.

Pelajaran: Karier pengembangan perangkat lunak: proses Agile dan peran dalam tim

Yang ditunjukkan

Simulasi ini menunjukkan cara tim perangkat lunak sungguhan bekerja dalam satu sprint Agile. Product owner telah mengurutkan user story aplikasi klub sekolah menurut nilainya; tim mengambil story yang muat dalam kapasitasnya, diperkirakan sebagai pengembang × hari × 0,8 poin. Setiap hari story dibangun, bug muncul di kode baru, dan pengujian atau tinjauan kode menangkap sebagian. Melewatkan tes mempercepat pembangunan, tetapi lebih banyak bug lolos ke pengguna. Grafik burndown melacak kemajuan dan review sprint menilai kepuasan pelanggan. Semua koefisien adalah asumsi ilustratif, bukan data industri.

Cara menggunakan

Pilih opsi Perencanaan atau centang sendiri story-nya, atur Pengembang, Penguji, Hari dan Waktu untuk tes, lalu nyalakan atau matikan tinjauan kode. Tekan Jalankan 1 hari untuk maju per hari atau Jalankan sprint untuk animasinya, lalu amati papan, garis burndown dan penghitung bug. Anda dapat membandingkan review sprint setelah mengubah satu pengaturan dan memakai Skenario lain untuk melihat variasi acak.

Parameter yang dapat diubah

  • Perencanaan sprint Sesuai kapasitas tim, Ambil seluruh backlog, Pilih sendiri
  • Jumlah pengembang 2–6 orang
  • Jumlah penguji 0–2 orang
  • Panjang sprint 5–15 hari
  • Waktu pengembang untuk menulis tes 0–40 %
  • Tinjauan kode antarrekan

Pertanyaan untuk dijelajahi

  1. Seberapa cepat tim membangun tanpa waktu untuk tes, dan berapa banyak bug tambahan sampai ke pengguna?
  2. Mengapa mengambil seluruh backlog biasanya menurunkan kepuasan pelanggan?
  3. Apa sumbangan setiap peran (product owner, pengembang, penguji) bagi sprint yang berhasil?