Apakah memperbaiki bug yang dilakukan oleh orang lain merupakan pendekatan yang baik?


17

Mari kita asumsikan situasi di mana tim dari empat pengembang sedang membangun aplikasi. Selama fase pengujian, bug dilaporkan oleh pengguna. Siapa yang harus memperbaikinya? Orang yang melakukan kode yang salah, atau siapa pun yang bebas?

Apa pendekatan yang disukai dalam pengembangan tangkas (scrum)?


3
Dia yang telah membuat kode-Mu harus memperbaiki kode-Mu
Agile Scout

Jawaban:


35

Pendekatan yang lebih disukai dalam pengembangan tangkas akan membuatnya diperbaiki secepat mungkin, dengan siapa pun tersedia. Ini hanya karena kepemilikan kode tidak jatuh ke satu orang, tetapi ke seluruh grup pengembang. Jika satu individu secara konsisten menyebabkan bug, itu adalah masalah lain yang perlu ditangani secara terpisah.


1
+1 untuk "secepat mungkin". Ya, perbaiki secepat mungkin dan biarkan pengguna Anda untuk melanjutkan pengujian, dan laporkan bug baru.

1
Dan bagaimana dengan umpan balik kepada orang yang melakukan bug?

@Robert itu bukan masalah umpan balik. Bug harus ditutup secara resmi oleh pengirim.

10
Juga memperbaiki bug orang lain adalah cara yang bagus untuk belajar. Karena Anda tidak menulisnya, itu memaksa Anda untuk benar-benar memahami apa yang dilakukan kode.
AndrewKS

1
@Yegor, robert bertanya tentang orang yang menulis bug, bukan pengirim. Untuk bug penting harus dilaporkan, untuk bug sepele tidak.

8

Secara default orang tersebut. Alasannya cukup sederhana: umpan balik. Bug memberikan peluang besar untuk umpan balik pribadi dan profesional. Jika orang lain memperbaiki bug saya, saya akan membuat kesalahan yang sama lagi, karena saya tidak akan belajar darinya.

Jika orang itu tidak tersedia, orang lain dapat memperbaikinya, tetapi orang tersebut harus mengikuti siklus hidup bug.


3
Itu sebabnya komunikasi itu penting. Jika seseorang yang memperbaiki bug yang bukan pembuat kode asli menjelaskan apa masalahnya dan memperbaiki kepada pencetusnya, maka dua orang belajar darinya, bukan satu.
AndrewKS

7

Sebagai seorang PM saya akan menghindari menghubungkan bug ke pengembang tertentu. Jika perlu dilakukan, biarkan manajer fungsional / pengembangan melakukan itu. Peduli diri Anda dengan tim. Ada bug yang perlu diperbaiki tim.


Apa yang kami lakukan adalah kami memiliki penerima hak generik yang kami sebut "Pengembang Klien" yang bisa siapa saja di tim dan dalam triase kami akan memiliki bendera yang akan menampilkan semua masalah yang ditugaskan untuk pengguna itu. Yang sedang berkata, penting bahwa Anda akhirnya menetapkan tugas / bug ini sehingga orang bertanggung jawab untuk itu.
Agustus

2

Saya tidak tahu bagaimana scrum menangani skenario ini, tetapi di tim saya, kami memiliki sesuatu seperti pengujian silang / tinjauan kode. Dengan cara ini, jika ditemukan bug, pengembang dan peninjau mendiskusikan pendekatan terbaik untuk memperbaikinya.

Saya percaya bahwa, selama solusinya cocok, tidak masalah jika pengembang atau peninjau menerapkannya. Namun penting untuk menghindari segala jenis konflik antara pengembang dan penguji.

Rg

Sunting: Tidak yakin apakah saya membuat diri saya jelas, tetapi penting untuk menyoroti bahwa peninjau adalah pengembang lain dalam tim.


@Tiago: Saya menghargai solusi Anda, tapi saya pikir diskusi tidak selalu diperlukan.
Menunggu Long

1
  1. Mengevaluasi bug
  2. Jika akan lebih cepat / lebih masuk akal bagi pengembang asli untuk memperbaikinya, berikan kepada mereka
  3. Jika itu dapat diperbaiki oleh siapa pun di tim, biarkan siapa pun melakukannya.

1

Saya sepenuhnya setuju dengan Steven tentang kode milik semua tim; dan ada beberapa alasan mengapa Anda tidak harus memberikan bug kepada pembuatnya:

Seperti yang saya tahu, dalam banyak kasus sulit untuk mengidentifikasi siapa yang menyebabkan bug. Bahkan jika Anda menggunakan sistem manajemen dokumen seperti SVN, melacak kode kesalahan dapat menghabiskan banyak waktu. Jadi, dalam pandangan saya, berikan saja bug untuk siapa saja yang bebas.

Jika Anda ingin melacak bagaimana bug diproduksi, di waktu senggang Anda dapat bertanya kepada tukang reparasi tentang kasing (sebelum semua tim). Karena tim Anda kecil, saya pikir ini akan membagikan pengalaman tentang kemungkinan bug, dan tidak membuat orang malu.


1

Hanya ada tiga alasan untuk peduli tentang siapa yang memperbaiki bug: biaya, kecepatan, dan pengembangan profesional.

Dan ada pro dan kontra untuk ketiganya. Misalnya pengembangan profesional, di satu sisi ini adalah kesempatan untuk mempelajari lebih lanjut tentang kode di sisi lain itu adalah kesempatan untuk mengenali jenis kesalahan yang Anda buat dan menghindari beberapa di masa depan. Atau mengambil biaya, mungkin orang yang membuat kesalahan akan dapat memperbaikinya lebih cepat, dan mungkin lebih murah, di sisi lain ada biaya untuk waktu yang dihabiskan mengidentifikasi siapa yang melakukan kesalahan, dan menugaskannya kepada orang yang tepat - waktu yang dalam banyak kasus melebihi memperbaiki bug.

Pendekatan lincah adalah membiarkan pengembang menentukan sendiri masalahnya, saya akan menimpanya hanya karena alasan yang baik.


1

Di tim saya, kami selalu memutuskan sesuai prioritas. jika orang yang mengirimkan kode tersedia, dia memperbaiki kode tersebut. Jika orang itu mengerjakan cerita prioritas yang lebih tinggi, siapa pun yang tersedia dan dapat memperbaiki kode sesegera mungkin akan memperbaikinya. Jika semua orang sibuk mengerjakan tugas dengan prioritas lebih tinggi dalam iterasi saat ini, perbaikan dijadwalkan pada iterasi berikutnya sesuai dengan prioritasnya dibandingkan dengan cerita dan cacat lainnya.


0

Pikirkan: Siapa yang memiliki lebih banyak informasi tentang bug? Tim pengembangan.

Jadi biarkan mereka memutuskan apa yang harus dilakukan dengan bug. Mereka memiliki kode, jadi mereka bertanggung jawab untuk itu.

Anda dapat membantu mereka dengan mengelola proyek, mengalokasikan waktu pada ruang lingkup proyek untuk perbaikan bug dan membiarkan mereka sendiri untuk melakukan pekerjaan.

Hindari mengambil banyak keputusan di mana Anda (sebagai peran PM) memiliki informasi yang lebih sedikit daripada tim.

Lihat pertanyaan tentang: Bagaimana Cara Menghindari Mikro-Mengelola Tim Pengembangan Perangkat Lunak?


0

Saya katakan, Anda memerlukan sistem pelacakan bug, untuk merekam bug, yang disebabkan oleh apa, dilaporkan oleh, dan kemudian menetapkan bug, untuk orang yang berbeda berdasarkan beban pekerjaan mereka. Juga ditunjukkan kode siapa yang menyebabkan bug, dan kemudian memiliki laporan yang menunjukkan berapa banyak coders, dan aplikasi apa, yang menyebabkan x jumlah bug selama seminggu.

Lalu Anda bisa menunjukkan itu kepada coders, untuk menunjukkan bagaimana mereka menyebabkan bug.

Dan cara terbaik untuk mencegah bug, adalah melibatkan semua orang dengan memperbaikinya. Maksud saya menetapkan perbaikan bug untuk orang yang berbeda, untuk memberikan pengalaman langsung tentang apa yang menyebabkan bug dan apa yang memperbaiki mereka.

Maka mungkin setelah satu atau dua bulan semua orang memperbaiki bug, merevisi atau membuat pedoman gaya pengkodean Anda untuk membantu mencegah bug di masa depan, sistem yang luas, dengan memiliki standar tertulis / terdokumentasi untuk bagaimana Anda memprogram.


0

Ketika bug ditemukan, itu adalah tanggung jawab seluruh tim pengembangan untuk memperbaikinya.

Jika orang percaya bahwa bug harus diperbaiki oleh pembuatnya, itu seperti mengatakan "Saya tidak memperbaiki masalah, lubangnya tidak ada di sisi saya di kapal". Tapi kapalnya masih akan tenggelam jika lubangnya tidak diperbaiki, dan Anda berada di perahu itu bersama yang lainnya.

Individu perlu menyadari bahwa mereka adalah bagian dari tim dan memahami bahwa kode, bersama dengan tanggung jawabnya, adalah milik mereka semua. Keberhasilan suatu proyek terletak pada semua anggota tim.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.