Siapa tentang apa, tetapi saya berbicara tentang bug.

Tahun lalu saya memberi tahu Anda tentang Bagel - acara yang diadakan di perusahaan kami untuk membersihkan tumpukan bug. Acara ini bagus dan bermanfaat, tetapi itu memecahkan masalah bug satu kali. Kami sudah mengadakan enam Bagodelen, tetapi jumlah peserta secara bertahap menurun dan menjadi jelas bahwa kebutuhan untuk acara ini mulai menghilang. Alasan utamanya adalah kemunculan Kebijakan Nol Bug. Tidak banyak sumber dalam bahasa Rusia tentang tempat Anda dapat membaca dan menemukan solusi yang nyaman untuk diri Anda sendiri. Dalam artikel ini, saya akan berbicara tentang pendekatan kami pada topik dan akan membaca tentang pengalaman Anda dalam komentar dengan senang hati.

Apa ini

Zero Bug Policy (ZBP) adalah kebijakan penanganan kesalahan berbasis aturan:

"Ketika kesalahan baru muncul, Anda harus segera memutuskan untuk memperbaikinya dalam waktu dekat, atau menutupnya sebagai" Tidak Akan Memperbaiki "."

Dalam hal ini, jangan terlalu ekstrem: jangan membuat kesalahan sama sekali atau mengedit semuanya dalam satu baris. Sangat penting untuk mengembangkan sendiri kriteria kualitas untuk fitur yang siap Anda berikan kepada pengguna dan mempertimbangkan tugas yang diselesaikan setelah memperbaiki semua kesalahan penting.

Manfaat polis

• Semua orang tahu ada berapa banyak kesalahan terbuka dan jumlah ini cukup terbatas.
• Lebih sedikit waktu yang diperlukan untuk menemukan tugas di sistem pelacakan bug.
• Tidak ada rapat yang panjang untuk mengurutkan dan memprioritaskan backlog kesalahan.
• Mungkin secara psikologis Anda menjadi lebih mudah ketika Anda tidak ditekan oleh tumpukan yang membengkak.
• Setelah dikoreksi, tidak perlu mengingat apa yang ada "seratus tahun yang lalu", dan sekali lagi untuk terjun ke dalam konteks.

Kedengarannya hebat, tetapi efek samping mungkin terjadi.

• Kualitas produk menurun.
• Degradasi tingkat tim pengujian. (Mengapa membuang waktu mencari bug yang rumit dan rumit jika mereka masih belum diperbaiki?).
• Sumber informasi yang berguna (dalam bentuk backlog terbuka) untuk anggota tim baru hilang.

Dan selalu ada faktor ketakutan.

"Jadi kita akan menutup kesalahan, dan bagaimana jika masa depan yang cerah datang ketika ada waktu untuk memperbaikinya?"

Sangat tidak mungkin Anda memiliki waktu ekstra. Ini seperti menyimpan sampah lama di balkon: Anda tidak kehilangan harapan untuk menggunakan salah satu dari hal-hal ini, tetapi kemungkinan besar itu tidak akan pernah terjadi.

Di sini kita menutup kesalahan, dan pengguna melihatnya di prod.

Pengguna yang kecewa akan menulis untuk mendukung, yang pada gilirannya akan memberi tahu Anda. Penting untuk meninjau prioritas kesalahan ini dan memutuskan kembali apakah akan memperbaikinya atau tidak.

Implementasi

Bagian tersulit adalah memulai. Untuk melakukan ini, Anda perlu menemukan waktu, sumber daya, keinginan (perlu digarisbawahi) untuk menyekop seluruh tumpukan kesalahan kuno dan membuat keputusan radikal untuk memperbaiki atau menutup.
Kemudian, kumpulkan kekuatan dan koreksi "selamat" setelah membersihkan kesalahan.
Dan mulailah hidup dengan aturan baru.

Mulai membagi bug ke dalam dua kategori:

• bug ditemukan saat menguji fitur baru;
• bug ditemukan pada prod / dengan regresi.

Jika Anda menemukan bug saat menguji fitur baru, Anda harus segera mengambil keputusan:

• memperbaiki bug sebelum pengembangan / pengujian fitur selesai;
• mereklasifikasi bug (mungkin ini sebenarnya Perbaikan);
• mungkin Anda tidak perlu mendapatkan bug sama sekali jika Anda tidak akan mengeditnya.
  Pada tahap awal proses, lebih baik memulai dan menutup bug semacam itu dengan resolusi "Tidak akan Memperbaiki" yang menjelaskan alasan penutupan. Berdasarkan data ini, Anda akan dapat menganalisis cacat dan mengembangkan kriteria kualitas dengan benar di tim Anda.

Dan jika ada bug pada prod / dengan regresi, maka Anda harus memutuskan apa yang harus dilakukan.

• Perbaiki bug dan penuhi tenggat waktu tergantung pada prioritas bug. Waktu perbaikan adalah dari "sekarang" ke dua sprint. Jika bug belum diperbaiki dalam dua sprint, maka bug itu harus ditutup.
• Ubah jenis tugas dari "Bug" ke "Peningkatan".
• Tutup bug dengan resolusi "Won't Fix" dengan deskripsi alasan penutupan.

Untuk menentukan prioritas bug, kami menggunakan matriks yang menggabungkan kekritisan bug dalam perintah tertentu dan frekuensi kemunculannya.

Detail lainnya

Keuntungan dari menggunakan pendekatan ini kemungkinan tidak signifikan jika Anda tidak mengubah proses dan pendekatan tambahan dalam pengembangan dan pengujian.

Apa yang akan mengurangi jumlah bug saat mengembangkan fitur baru?

1. Gunakan berbagai praktik teknis dan organisasi (misalnya, penerapan Gerbang Kualitas, Analisis Dampak, Pengujian Agile).
2. Hilangkan lokasi penghasil bug dengan refactoring kode lama.
3. Perbaiki kesalahan dengan cepat, yang akan mengurangi dampaknya di masa mendatang.
4. Tulis autotest untuk mendeteksi area masalah lebih cepat dan
   mencegah pengulangan kesalahan.

Metrik

Agar tidak menarik kesimpulan tentang perasaan kami, kami memantau metrik ZBP (saya sangat suka Tableau dan menggunakannya untuk membuat laporan). Ini memungkinkan Anda untuk melacak kemajuan dalam dinamika dan menyoroti masalah yang muncul.

Hasil

Apa hasil kerja di ZBP bersama kami?

Kita hidup di dunia nyata, dan dalam bentuknya yang paling murni tidak mungkin menggunakan politik.
Seseorang mengalami masalah Legacy dan ketidakmampuan untuk memperbaiki beberapa bug untuk waktu yang terbatas. Seseorang memiliki tumpukan simpanan selama bertahun-tahun, itu hanya menakutkan untuk mendekatinya dan mereka tidak terburu-buru untuk memulai proses ini.

Tetapi secara umum, banyak tim berhasil mengurai backlog mereka dan menetapkan bar tertentu pada jumlah bug terbuka. Tim mulai mengevaluasi bug lebih baik dan membuat keputusan lebih cepat tentang perlunya koreksi.

Kesimpulan

• Dibutuhkan banyak upaya untuk mengubah pendekatan Anda untuk bekerja dengan bug.
• Agar proses bekerja, itu harus menjadi bagian dari budaya rekayasa perusahaan.
• Tim harus mencapai keseimbangan antara koreksi kesalahan dan pengembangan sprint.

Semua bug baik dan kurang!