Bagaimana cara menghitung iterasi memperbaiki bug?

9

Kami telah mengimplementasikan Scrum dengan cukup sukses selama 5 bulan terakhir. Padahal, kami 3 minggu lagi dari PROD tanpa pernah melakukan tes integrasi ujung ke ujung. ADUH! Saya butuh bantuan. Tanpa mengatasi penyebab ini (pada titik INI), kita sekarang perlu merencanakan iterasi saat ini, yang terdiri dari perbaikan kecil dan BANYAK perbaikan bug yang masih belum diketahui. Bagaimana Anda menjelaskan skenario ini? Bagaimana Anda merencanakan iterasi Anda untuk memperbaiki bug yang belum ditemukan?

scrum bug planning

— Pomario
sumber

16

"Kami telah mengimplementasikan Scrum dengan cukup sukses ... tanpa pernah melakukan tes integrasi ujung ke ujung." Maaf Anda salah melakukannya. Anda seharusnya bisa mengirim pada akhir setiap iterasi.

— xsace

3

@ xsAce ini iterasi 6 bulan

— Bart

3

Pertanyaannya sendiri bagus tetapi deskripsi prosesnya membuat saya merasa Anda menyangkal seberapa baik segala sesuatu bekerja. Jika Anda tidak melakukan hal lain, beri tahu PO bahwa tim tidak dapat berkomitmen untuk tanggal rilis saat ini. Yang terbaik yang dapat Anda lakukan adalah berkomitmen padanya bahwa Anda akan fokus pada penilaian kualitas di iterasi berikutnya. Adakan diskusi tim yang serius di retrospeksi Anda berikutnya.

— GuyR

1

Menelusuri riwayat pertanyaan terkait Scrum di situs ini, jelas bahwa perusahaan Anda melakukan "tidak ada yang namanya" seperti Scrum dan malah terdengar seperti tim yang jauh lebih nyaman dan akrab dengan pengembangan Air Terjun. Bukan berarti Waterfall secara intrinsik "buruk" tetapi hanya mengenali ketika manajemen suka menggunakan kata-kata seperti "Agile", "Scrum", "Sprint", "Backlog" dan "Planning Poker" sebagai kata buzz tetapi tidak sepenuhnya berkomitmen pada budaya dan perubahan manajemen diperlukan untuk memenuhi hal-hal ini. Mereka menginginkan manfaat Scrum tanpa berkomitmen untuk Scrum.

— maple_shaft

4

Ini adalah proses scrum puritan seperti kalian yang mematikan orang dari itu. Jika dia tidak tahu dia punya masalah, dia tidak akan mengajukan pertanyaan. Mencari tahu di mana Anda salah dan mengambil langkah-langkah untuk melakukan yang lebih baik di iterasi di masa depan adalah apa yang lincah adalah semua tentang. Individu dan interaksi atas proses dan alat.

— Karl Bielefeldt

7

Scrum atau tidak, perbaikan bug pada dasarnya tidak mungkin untuk diprediksi. Yang terbaik yang saya percaya bisa Anda lakukan adalah:

Mulai pengujian segera, tanpa perkiraan awal kapan akan dilakukan.
Saat Anda menemukan setiap bug, lakukan analisis awal hingga Anda dapat memperkirakannya.
Perkirakan bug dan memutuskan apakah itu harus diperbaiki dan apakah itu harus diperbaiki untuk relese awal.
Jika harus diperbaiki, tambahkan ke iterasi.
Plot bagan burn-down. Pada titik tertentu itu akan mulai berkurang, artinya Anda tidak lagi menemukan bug lebih cepat daripada Anda berhasil memperbaikinya. Pada saat itu Anda akan dapat memberikan estimasi kasar (dan semakin tepat) ketika rilis dapat dibuat.

Daripada Anda harus memastikan lain kali Anda mulai menguji lebih awal dan memperbaiki bug saat Anda pergi. Semua metodologi yang masuk akal, gesit atau tidak, membutuhkan perbaikan bug yang diketahui sebelum melanjutkan dengan fitur baru. Anda juga harus memperhitungkan berapa banyak waktu yang dihabiskan untuk memperbaiki setiap fitur, sehingga Anda dapat meningkatkan taksiran Anda untuk menerapkan fitur ke status debugged di masa mendatang.

Perkiraan dan perbaikan bug dicakup dengan baik oleh Joel Spolsky dalam Penjadwalan Berbasis Bukti dan Perbaikan Bug yang Keras . Ini tidak terkait dengan Scrum, tapi saya pikir itu cukup umum sehingga banyak yang berlaku.

— Jan Hudec
sumber

5

Bagaimana cara menghitung iterasi memperbaiki bug? Bagaimana Anda merencanakan iterasi Anda untuk memperbaiki bug yang belum ditemukan?

Mengenai "iterasi perbaikan bug". Bug yang ditemukan harus diperlakukan tidak berbeda dari cerita. Bekerja dengan tim untuk memperkirakan upaya (poin cerita) untuk memperbaiki setiap bug dan bekerja dengan pemilik produk / pelanggan untuk memutuskan apakah bug harus masuk ke iterasi berikutnya.

Mengenai "bug yang belum ditemukan". Lebih disukai, tim menemukan dan memperbaiki masalah setiap iterasi. Jika tidak, diskusikan hal ini di retrospektif Anda berikutnya. Jika kualitas produk sangat rendah sehingga rilis tidak dimungkinkan, maka segera pindahkan " pencari bug " terbaik Anda ke menemukan bug (tidak memperbaiki). Jika kualitas cukup tinggi untuk menyediakan rilis beta untuk memilih pengguna - lakukanlah. Jika Anda tidak bisa, maka sediakan setidaknya demo pengguna langsung yang membahas bidang lemah yang Anda rekomendasikan perlu ditingkatkan.

— GuyR
sumber

+1. Saat Anda berada pada tahap kualitas beta, Anda mungkin juga mempertimbangkan untuk melakukan sesi pengujian rekan.

— louisgab

2

Kami tidak merencanakan 'perbaikan bug yang diperbaiki', tapi kami merencanakan iterasi pengujian sistem sebelum setiap rilis. Uji sistem adalah uji integrasi, regresi, dan nyata pada semua bagian produk. Penguji menguji produk (sistem warisan yang cukup besar) dan pengembang memperbaiki bug yang ditemukan. Jika tidak ada bug yang ditemukan, kami mulai menyelidiki jadwal fitur untuk proyek berikutnya atau bekerja pada perbaikan internal.

Saat ini, kami merencanakan enam minggu pengujian sistem setelah pembekuan kode (untuk proyek lima bulan, termasuk pengujian sistem), untuk memastikan semuanya bekerja. Ini di atas semua pengujian yang dilakukan selama iterasi implementasi.

— Paula
sumber

1

Anda perlu menentukan serangkaian kriteria "rilis". Ini dapat mencakup:

Berarti waktu antara kegagalan
Jumlah cacat ditemukan per hari
Tingkat keparahan cacat ditemukan per hari
Jumlah cacat yang beredar

dll.

Kemudian pada akhir setiap iterasi di mana Anda memiliki beberapa orang menguji (baik secara manual atau dengan menulis tes otomatis) dan lainnya memperbaiki cek untuk melihat apakah Anda telah memenuhi kriteria Anda. Jika sudah maka lepaskan, jika belum maka lakukan iterasi lain.

Seharusnya ada kemungkinan override pada ini dan sering kali angka mentah tidak menyajikan gambaran realistis dari aplikasi. Anda mungkin memiliki beberapa cacat yang sangat serius, tetapi mereka hanya bermanifestasi dalam kondisi langka yang dapat Anda jalani dalam jangka pendek.

— ChrisF
sumber

1

Salah satu cara untuk melakukannya adalah dengan menulis cerita untuk pengujian integrasi Anda, di mana Anda menulis cerita baru untuk bug yang Anda temukan, kemudian memperbaiki cerita bug di iterasi berikutnya.

Cara lain untuk melakukannya adalah dengan hanya membuat cerita yang mengatakan "Perbaiki bug yang ditemukan dalam pengujian integrasi." Dari rilis sebelumnya Anda harus memiliki gagasan tentang berapa banyak masalah yang biasanya ditemukan, dan seberapa sulit mereka untuk memperbaikinya, sehingga Anda dapat menetapkan poin cerita berdasarkan pengetahuan itu. Anda mungkin dapat membaginya menjadi beberapa komponen jika itu membuatnya lebih mudah dikelola. Selalu ada ketidakpastian dalam hal ini. Tambahkan beberapa poin cerita tambahan untuk menjelaskannya.

Anda mungkin menyadari terlambat bahwa cara terbaik adalah menggabungkan sedikit pengujian integrasi ke setiap iterasi jika memungkinkan. Selamat atas pengakuan itu dan meningkatkan proses Anda hanya sedikit untuk rilis berikutnya.

— Karl Bielefeldt
sumber