Poin cerita untuk tugas perbaikan bug: Apakah cocok untuk Scrum?

Saya hanya ingin tahu apakah kita harus menetapkan poin cerita untuk tugas memperbaiki bug atau tidak. JIRA, perangkat lunak pelacakan masalah kami, tidak memiliki bidang poin cerita untuk masalah jenis Bug (hanya untuk Story s dan Epic s).

Haruskah kita menambahkan jenis masalah Bug ke jenis masalah yang berlaku bidang Story Points ? Apa pro dan kontra? Apakah ini cocok untuk Scrum?

Idealnya, perangkat lunak Anda harus bebas bug setelah setiap iterasi, dan memperbaiki bug harus menjadi bagian dari setiap sprint, sehingga pekerjaan yang diperlukan untuk memperbaiki bug harus dipertimbangkan ketika menetapkan poin cerita (yaitu, tugas yang lebih mungkin menghasilkan bug harus memiliki lebih banyak poin cerita yang ditugaskan padanya).

Namun pada kenyataannya, bug memunculkan post-deployment sepanjang waktu, tidak peduli seberapa keras pengujian Anda; ketika itu terjadi, menghapus bug hanyalah perubahan lain, sebuah fitur jika Anda mau. Tidak ada perbedaan mendasar antara laporan bug dan permintaan fitur dalam konteks ini: dalam kedua kasus, aplikasi menunjukkan perilaku tertentu, dan pengguna (atau pemangku kepentingan lain) ingin melihatnya berubah.

Dari perspektif bisnis, perbaikan bug dan fitur-fiturnya juga sama, sungguh: apakah Anda melakukannya (skenario B), atau tidak (skenario A); kedua skenario memiliki biaya dan manfaat yang melekat, dan pelaku bisnis yang layak hanya akan menimbangnya dan pergi dengan apa pun yang menghasilkan lebih banyak keuntungan (jangka panjang atau jangka pendek tergantung pada strategi bisnis).

Jadi ya, tentu saja, tetapkan poin cerita ke bug. Bagaimana lagi Anda akan memprioritaskan bug vs fitur, dan bug terhadap bug? Anda perlu beberapa upaya pengembangan untuk keduanya, dan lebih baik dibandingkan.

Masalah terbesar dengan ini adalah bahwa perbaikan bug seringkali lebih sulit untuk diperkirakan: 90% atau lebih dari upaya sebenarnya terletak pada menemukan penyebabnya; setelah Anda menemukannya, Anda dapat menghasilkan perkiraan yang akurat, tetapi hampir tidak mungkin untuk menilai berapa lama pencarian akan berlangsung. Saya bahkan telah melihat bagian bug yang adil di mana sebagian besar waktu dihabiskan hanya mencoba mereproduksi bug. Di sisi lain, tergantung pada sifat bug, seringkali mungkin untuk mempersempit pencarian dengan beberapa penelitian minimal sebelum membuat perkiraan.

Memperkirakan bug dengan poin pada dasarnya sulit karena sudah ditunjukkan dalam jawaban lain dan ya solusi yang ideal adalah bug yang ditemukan dalam fitur SETELAH sprint telah diterima harus dianggap fitur baru .

Namun kesulitan dalam estimasi titik untuk bug ini adalah salah satu dari banyak alasan bahwa paket perangkat lunak Agile PM memungkinkan tugas dan bug diperkirakan dalam hitungan jam, karena butuh ketekunan dan pengalaman untuk menjadi terampil dalam estimasi titik. Banyak proyek mengalami masalah yang signifikan dengan menentukan kecepatan dengan tepat, sehingga banyak proyek Agile menggunakan poin untuk menentukan cerita apa yang membuatnya menjadi sprint, namun mereka menggunakan jam saat menghitung grafik burndown .

Tampaknya berlawanan dengan intuisi, tetapi dapat dikelola selama estimasi jam tidak digunakan sebagai faktor dalam menentukan komitmen sprint. Overcommittment secara alami akan mengarah ke fitur yang terlewatkan atau tidak lengkap atau lembur, sehingga seiring waktu semua yang terlibat dipaksa untuk menjadi lebih baik pada estimasi titik, di mana titik memperkirakan jam pada tugas dan bug perlahan menjadi metrik yang tidak berarti.

Anda seharusnya tidak memberikan poin ke resolusi bug. Pertimbangkan fakta bahwa bug tersebut muncul dari sebuah cerita di mana para pengembang sudah mendapatkan poin untuk menyelesaikan cerita. Seharusnya tidak menerima poin lagi di mana sebenarnya seharusnya tidak mendapatkan poin untuk memulai.

Memperbaiki bug harus memiliki efek negatif pada kecepatan. Kalau tidak, kualitas yang menurun pada akhirnya akan dihargai dengan kecepatan yang tidak terpengaruh atau bahkan meningkat!

Mungkin tautan yang bermanfaat:

http://www.infoq.com/news/2011/01/story-points-to-bugs

Saya akan merekomendasikan memperlakukan bug sebagai cerita pengguna dan menugaskannya sejumlah poin. Saya tidak perlu menuliskannya dalam format "Sebagai X, saya ingin Y sehingga Z" seperti yang umum dengan cerita pengguna - Saya akan menulis lebih sebagai "Sebagai X, ketika IY, Z terjadi, tetapi Z 'adalah perilaku yang diharapkan ".

Keuntungannya adalah memungkinkan Anda memprioritaskan perbaikan bug di samping permintaan fitur baru. Yang benar adalah bahwa kadang-kadang, fitur baru lebih penting daripada memperbaiki bug. Namun, ini juga memungkinkan Anda untuk mengukur pekerjaan yang diperlukan dengan benar, memungkinkan Anda untuk memasangnya dalam sprint ketika Anda memiliki kemampuan untuk melakukannya.

Satu hal yang perlu diingat bahwa mungkin sulit untuk memperkirakan upaya yang diperlukan untuk memperbaiki bug. Ini bisa melibatkan banyak komponen yang berinteraksi satu sama lain, mengharuskan seseorang untuk menjadi sangat akrab dengan interaksi potongan besar sistem atau banyak orang untuk memperbaiki.

Memperkirakan cerita didasarkan pada gagasan bahwa, seiring waktu, sebuah tim mendapatkan pengalaman dalam menyelesaikannya. Dengan itu akurasi ditingkatkan dan kecepatan dapat ditetapkan untuk mengukur kecepatan tim. Metodologi yang sempurna untuk membuat prognosis yang andal untuk sprint di masa depan.

Bug adalah fakta kehidupan perusahaan pengembangan perangkat lunak. Sementara saya setuju bahwa bug semua harus ditangkap selama pengembangan cerita, menerima bahwa ini tidak dapat dicapai setiap saat, harus menjadi sesuatu yang harus direncanakan oleh setiap tim. Alih-alih dengan keras kepala berpikir bahwa proses itu harus menguasai tim, itu harus sebaliknya.

Tentu saja, bug atau cerita, dari sisi bisnis tidak masalah apa yang dihadapi tim. Keduanya dapat menghasilkan jumlah nilai yang sama bagi pemilik produk.

Di tim kami, kami telah bereksperimen dengan beberapa teknik untuk memperkirakan bug:

1. Memperkirakan bug yang sama sekali tidak dikenal
2. Hanya memperkirakan bug yang sudah dianalisis
3. Mengalokasikan waktu untuk memperbaiki bug dan tidak memperkirakan bug, tetapi rangking mereka hanya berdasarkan nilai bisnis

Dengan 1. kita gagal secara salah. Untuk sebagian besar bug, kami menemukan 90% waktu dihabiskan untuk analisis bug. Setelah itu perbaikan bug dapat diperkirakan dengan cara yang sama seperti sebuah cerita. Dengan merencanakan bug menjadi sprint, kami membuat kesalahan bahwa ruang lingkup yang tidak diketahui memengaruhi resolusi cerita hingga titik di mana hampir setiap sprint yang kami lakukan dengan cara ini gagal.

Berdasarkan opsi estimasi teknik rasio 90/10 (analisis terhadap bug) 2. berarti kami harus merencanakan analisis yang bukan sesuatu yang dicakup untuk perencanaan sprint (kami telah belajar dari opsi 1, tetapi tidak memiliki solusi nyata cara melanjutkan dengan bug yang dianalisis). Hasilnya adalah bahwa analisis bug tidak dilakukan karena sprint berfokus pada item yang direncanakan sebagai gantinya. Tim tidak punya waktu untuk fokus pada bug dari backlog. Jadi pada akhirnya mereka juga tidak selesai.

Dengan merangkul ketidakpastian, kami sekarang telah memilih opsi 3. Kami telah membagi tumpukan produk menjadi bagian cerita / tugas reguler yang dapat diperkirakan oleh tim menggunakan poin cerita dan tumpukan bug. Dalam tumpukan bug, pemilik produk memberi peringkat bug berdasarkan nilai bisnis dan penilaian tim yang sangat kasar. Tim ini memungkinkan untuk mengalokasikan sejumlah waktu selama sprint yang dapat dihabiskan untuk fokus pada bug. Pemilik produk tidak mengetahui hasil pasti karena tidak mungkin merencanakannya sebelumnya. Rasio backlog bug dibandingkan backlog biasa dapat disesuaikan untuk setiap sprint tergantung pada status saat ini dari setiap backlog dan pentingnya dan nilai bisnis dari konten.

Dengan menghilangkan ketidakpastian itu membebaskan tim lagi. Sprint tidak terganggu oleh bug yang tidak dikenal. Dengan memisahkan bug ke dalam tumpukan berbeda, keduanya meningkatkan fokus sprint tim reguler dan membuat kami menyelesaikan bug yang mengandung nilai bisnis yang signifikan juga.

Jadi itu tergantung apakah poin cerita cocok untuk Anda. Saya akan mencoba memperkirakan bug menggunakan poin cerita terlebih dahulu. Jika gagal coba opsi saya 3. Ini telah membuat tim kami (lebih dari 30 sprint lama) fokus pada bug yang lebih lama yang mengandung nilai bisnis yang hebat. Hal ini juga membebaskan kami dari upaya memberikan sesuatu yang tidak bisa diperkirakan oleh tim. Itu merangkul hal-hal yang tidak diketahui yang membuat kami lebih dekat dengan kenyataan dan juga membuat sprint kami berhasil lagi sambil memberikan potongan besar (berdasarkan rasio bug ke cerita) dari nilai bisnis melalui perbaikan bug. Rasio yang kami gunakan baru-baru ini adalah 50/50.

Saya harus tidak setuju dengan jawaban teratas untuk menetapkan poin cerita ke bug. Poin cerita harus untuk nilai baru yang disampaikan. Jika Anda akan menetapkan poin ke item nilai produk dan non-nilai, Anda mungkin juga hanya memperkirakan dan melacak jam.

Bug adalah overhead dari apa yang Anda lakukan kemarin dan tidak menunjukkan kecepatan penyelesaian produk, dan mereka juga tidak menciptakan nilai produk baru (pikirkanlah). Bug adalah jenis interupsi seperti dan semua pai sapi lainnya yang perlu Anda tangani setiap minggu. Seluruh ide poin cerita adalah bahwa ia melacak / memperkirakan kapan kami akan mengirimkan produk (atau rangkaian fitur). Poin cerita sewenang-wenang dan begitulah cara menghilangkan semua overhead nilainya dari estimasi. Secara umum, pekerjaan yang tidak bernilai adalah konstan dari minggu ke minggu, jadi ia dimasukkan ke dalam kecepatan tim. Tim akan mempercepat ketika mereka menghapus atau mengurangi pekerjaan yang tidak bernilai ini.

Dengan kata lain, mengapa bahkan melacak poin ke bug? Sehingga pada akhirnya Anda tahu berapa banyak "pekerjaan" yang dilakukan setiap anggota? Hentikan itu! Manajer yang buruk! :) Ukur tim, bukan pemain. Dorong tim untuk mengelola diri sendiri jika satu orang tidak menarik berat badan mereka. Jauh lebih efektif. Melakukan item poin cerita tidak seharusnya membuat seseorang merasa lebih baik, tetapi tim secara keseluruhan harus merasa lebih baik ketika mereka membuat komitmen mereka di akhir sprint. Dalam olahraga, apakah tujuannya baik untuk tim atau individu? Jika individu bermain untuk dirinya sendiri, tim akan kalah dalam jangka panjang.

Anda tahu, pada akhirnya Anda ingin tidak menggunakan poin sama sekali. Estimasi adalah waktu yang diambil dari pekerjaan nyata. Ketika sebuah tim mencapai chi maksimum, mereka tidak menggunakan poin sama sekali belum tahu persis berapa banyak item yang dapat mereka tarik dalam sprint. Mereka telah menguasai seni memecah unit kerja yang estimasi adalah limbah proses.

Beberapa tugas dapat diperkirakan, beberapa tidak. Untuk hal-hal yang tidak dapat diperkirakan, gunakan anggaran.

Memperbaiki cacat bukanlah tugas yang mudah diperkirakan karena memiliki beberapa komponen yang tidak diketahui. Apa yang menyebabkan cacat? Setelah penyebabnya dipahami, bagaimana cara memperbaikinya? Apa dampak perubahan ini terhadap sistem lainnya? Berapa banyak cacat baru yang Anda injeksi memperbaiki cacat ini?

Ingatlah bahwa penyebab cacat dapat datang dari titik mana saja dalam siklus hidup perangkat lunak - persyaratan yang salah dipahami atau salah komunikasi, desain buruk atau asumsi salah, pengkodean buruk, pengujian buruk, pengetahuan baru tentang masalah berdasarkan informasi yang dipelajari dari rilis saat ini ...

Membuat anggaran dapat dilakukan dengan beberapa cara berbeda untuk tugas perbaikan bug. Inilah beberapa ide yang saya gunakan secara efektif:

• Gunakan data historis (katakanlah dari iterasi sebelumnya) untuk membantu Anda memahami berapa banyak waktu yang disisihkan untuk perbaikan bug.
• Masukkan "blok" perbaikan bug (katakanlah 5 poin atau 20 jam) di tumpukan Anda dan biarkan pelanggan memilih ini sebagai pengganti cerita.
• Mengharuskan setiap anggota tim Anda mendedikasikan jumlah waktu yang ditentukan untuk setiap cacat perbaikan iterasi.

Tujuan Anda adalah untuk memperbaiki sebanyak mungkin cacat sesuai anggaran yang dialokasikan. Diskusikan dengan strategi pelanggan Anda untuk memprioritaskan cacat yang dilaporkan. Misalnya, apakah Anda mengurutkan cacat berdasarkan kekritisan lalu prioritas? Prioritas yang ketat? Haruskah Anda menyerang "buah yang tergantung rendah" terlebih dahulu? Bug UI dulu?

Selain itu, memperbaiki bug tidak menghasilkan nilai. Memperbaiki cacat adalah bentuk limbah. Anda sudah mendapatkan nilai pada fitur ini sehingga Anda seharusnya tidak mendapatkan "poin bonus" untuk memperbaiki bug.

Memiliki anggaran membantu perencanaan dan masih memberi Anda gambaran Velocity yang akurat. Anggaran sejumlah poin tertentu untuk memperbaiki bug, beri anggaran perkiraan waktu berdasarkan data historis Anda, lalu remas bug sebanyak yang Anda bisa dalam waktu yang dianggarkan!

Alih-alih fokus pada cerita dan bug serta tugas dan poin masing-masing, saya merasa lebih baik untuk fokus pada memberikan fitur bagi pelanggan.

Pelanggan mengharapkan perangkat lunak berfungsi dan hanya memberikan nilai nyata untuk pengembangan, peningkatan, dan fitur baru karena ini mendorong bisnis ke depan.

Perbaikan bug, sama pentingnya dengan itu, jangan mengarahkan bisnis ke bidang baru dan pelanggan baru (secara tangensial dan akhirnya mungkin ya tetapi tidak segera yang merupakan ukuran yang diukur manajemen).

Jadi poin paling baik dilihat dari sudut pandang kecepatan yang lebih tinggi dan berapa banyak poin per minggu telah dilakukan secara historis untuk cerita dengan skor yang sama.

Hal ini dapat mengarah pada manajemen dengan sejarah rekam jejak daripada mendorong kebutuhan mendesak agar cerita minggu ini menjadi lengkap dan seringkali menemukan bahwa itu tidak benar. Namun kehilangan kontrol di muka dan meningkatnya kepercayaan yang dibutuhkan ini akan membuat beberapa manajer berlari menuju pintu dengan ngeri.

Saya menggunakan Pivotal Tracker (Saya baru saja JIRA, Trak, Trello dan lainnya juga) dan Pivotal Tracker juga tidak melakukan poin untuk pekerjaan atau bug. Ini dilakukan untuk alasan baik yang sama di atas yang membuatnya juga benar di JIRA seperti yang Anda lihat sendiri.