Berapa lama waktu yang harus dihabiskan untuk bug vs pengembangan asli? [Tutup]

Pertanyaan ini sedikit abstrak tetapi saya berharap seseorang dapat mengarahkan saya ke arah yang benar.

Pertanyaan saya adalah berapa lama waktu yang bisa diharapkan untuk mencurahkan bug proyek perangkat lunak sehubungan dengan waktu pengembangan asli. Saya menyadari ada sejumlah besar faktor penentu yang masuk ke dalam tetapi saya berharap untuk rincian khas atau rata-rata.

Misalnya, jika Proyek A membutuhkan waktu 40 jam untuk menyelesaikan dan tambahan 10 bug perbaikan maka proyek ini akan memiliki rasio 4: 1.

Jika Proyek lain (B) membutuhkan waktu 10 jam untuk menyelesaikan tetapi 8 lainnya pada bug maka itu akan memiliki rasio 5: 4.

Apakah ini konsep yang terdokumentasi / diteliti?

MEMPERBARUI

Terima kasih atas semua jawaban informatif. Saya mengerti bahwa tidak mungkin untuk menetapkan standar untuk jenis metrik ini karena semua variabel dan faktor lingkungan yang terlibat. Sebelum saya memberikan jawaban, saya ingin tahu apakah metrik ini memiliki nama yang disepakati sehingga saya bisa melakukan penelitian lebih lanjut. Saya ingin sampai pada titik di mana saya dapat memahami pengukuran yang diperlukan untuk menghasilkan metrik sendiri dan akhirnya menghasilkan standar dasar untuk proyek saya.

Persentase kesetimbangan dari total kapasitas yang dialokasikan untuk pemasangan cacat sama dengan laju injeksi cacat .

Banyak faktor yang dapat memengaruhi laju ini, di antaranya, tentu saja: jenis produk apa yang dikembangkan tim, teknologi dan praktik teknis apa yang mereka gunakan, tingkat keterampilan tim, budaya perusahaan, dll.

Mempertimbangkan Tim B, jika mereka membuat rata-rata 8 unit pengerjaan ulang untuk setiap 10 unit pekerjaan yang mereka selesaikan, maka mengerjakan 8 unit itu akan menciptakan 6,4 unit pengerjaan ulang baru. Kita dapat memperkirakan upaya total yang pada akhirnya harus mereka keluarkan sebagai jumlah dari perkembangan geometrik:

10 + 8 + 6.4 + 5.12 + ...

Jumlah bug akan berkurang secara eksponensial dengan waktu, tetapi Tim B memiliki koefisien sedemikian dalam eksponen mereka sehingga akan menjadi nol dengan sangat lambat. Sebenarnya, jumlah dari tiga istilah pertama dalam seri di atas hanya 24,4; dari lima yang pertama, 33,6; dari 10, 45 pertama; dari seluruh seri, 50. Jadi, ringkasan Tim B: tingkat injeksi cacat, 0,8; pengembangan fitur, 10/50 = 20%; memperbaiki cacat, 80%. 20/80 adalah alokasi kapasitas berkelanjutan mereka.

Sebaliknya, Tim A berada dalam kondisi yang jauh lebih baik. Kemajuan mereka terlihat seperti ini:

40 + 10 + 2.5 + 0,625 + ...

Jumlah seri ini adalah 53 1/3, jadi alokasi pengembangan fitur Tim A adalah 40 / (53 1/3) = 75% dan alokasi perbaikan cacat adalah 25%, yang cocok dengan laju injeksi cacat mereka 10/40 = 0,25 .

Sebenarnya, semua istilah dalam seri Tim A setelah tiga yang pertama sangat kecil. Apa artinya ini secara praktis adalah bahwa Tim A mungkin dapat mengatasi semua bug mereka dengan beberapa rilis pemeliharaan, rilis kedua memiliki cakupan yang cukup kecil. Ini juga menciptakan ilusi bahwa tim mana pun dapat melakukannya. Tapi bukan Tim B.

Saya memikirkan kesetaraan ini ketika membaca buku baru David Anderson, "Kanban" . (Buku ini membahas topik yang berbeda, tetapi juga membahas masalah kualitas.) Ketika membahas kualitas perangkat lunak, Anderson mengutip buku ini, oleh Capers Jones, "Penilaian Perangkat Lunak, Tingkatan, dan Praktik Terbaik" :

"... pada tahun 2000 ... kualitas perangkat lunak yang diukur untuk tim Amerika Utara ... berkisar dari 6 cacat per titik fungsi hingga kurang dari 3 per 100 titik fungsi, kisaran 200 hingga 1. Titik tengahnya sekitar 1 cacat per 0,6 hingga 1,0 poin fungsi. Ini menyiratkan bahwa itu adalah hal biasa bagi tim untuk menghabiskan lebih dari 90 persen dari upaya mereka memperbaiki cacat. "Dia mengutip contoh yang diberikan oleh salah satu rekannya dari sebuah perusahaan yang menghabiskan 90% waktu untuk memperbaiki bug mereka. .

Kefasihan yang digunakan Anderson beralih dari tingkat injeksi cacat ke alokasi kapasitas memperbaiki cacat ( permintaan kegagalan adalah istilah untuk itu) menunjukkan bahwa kesetaraan dua hal diketahui oleh peneliti kualitas perangkat lunak dan mungkin telah dikenal selama beberapa waktu. .

Kata-kata kunci dalam garis penalaran yang saya coba tampilkan di sini adalah "equlibrium" dan "berkelanjutan". Jika kami menghilangkan keberlanjutan, maka ada cara yang jelas untuk menipu angka-angka ini: Anda melakukan pengkodean awal, kemudian beralih ke kode di tempat lain, dan menyerahkan pemeliharaan kepada orang lain. Atau Anda menjalankan hutang teknis dan membongkar itu pada pemilik baru.

Jelas, tidak ada alokasi khusus yang cocok untuk semua tim. Jika kami memutuskan bahwa 20% harus dihabiskan untuk bug, maka, jika tim memiliki tingkat injeksi cacat sangat rendah, mereka tidak akan memiliki cukup bug untuk mengisi waktu, dan jika tim memiliki tingkat yang sangat tinggi, bug mereka akan terus menumpuk.

Matematika yang saya gunakan di sini disederhanakan. Saya mengabaikan hal-hal seperti biaya transaksi (perencanaan dan estimasi estimasi, post-mortem, dll.), Yang akan sedikit mempengaruhi persentase. Saya juga menghilangkan persamaan yang mensimulasikan mempertahankan satu produk dan mengembangkan yang lain secara bersamaan. Tapi kesimpulannya masih berlaku. Lakukan apa yang Anda bisa, dalam hal praktik teknis, seperti pengujian unit, integrasi berkesinambungan, tinjauan kode, dll., Untuk mengurangi tingkat injeksi cacat Anda dan, akibatnya, permintaan kegagalan Anda. Jika Anda hanya dapat membuat satu bug untuk setiap 10 fitur, Anda akan memiliki banyak waktu luang untuk mengembangkan fitur-fitur baru dan memuaskan pelanggan Anda.

Sayangnya saya percaya rasio ini sangat bervariasi dalam proyek yang diberikan. Ini akan secara drastis dipengaruhi oleh lingkungan, bahasa, alat, ukuran dan pengalaman tim Anda.

Anda harus menghabiskan waktu untuk bug hanya jika apa yang Anda peroleh dari perbaikan lebih besar dari apa yang Anda investasikan.

Gunakan matriks seperti berikut (waktu horizontal diperlukan untuk memperbaiki bug, jenis vertikal dampak bug pada pengguna)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Contoh masalah:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

Matriks dapat menjadi lebih kompleks dengan berbagai tingkat keparahan, upaya, risiko, dll

Anda bahkan dapat membuat peringkat untuk setiap bug dan memperbaikinya berdasarkan peringkat. Sesuatu seperti:

Bug priority = Risk x Severity x Effort

* Mungkin (1-x) untuk beberapa operan, tergantung pada skala yang Anda pilih :)

Jadi, untuk menjawab pertanyaan Anda: tergantung pada jenis bug, waktu / anggaran yang tersedia, dll.

Ini sangat bervariasi, tidak hanya (tentu saja) pada pengalaman dan kualitas tim, dan pada kesulitan proyek (itu tidak sama membuat aplikasi web standar lain dari kernel OS baru), tetapi juga pada pendekatan manajemen Anda akan digunakan.

Sebagai contoh, pada model air terjun Anda dapat menetapkan secara tepat bug pertama pada fase pengujian pertama, tetapi pada lingkungan yang gesit bisa sulit untuk menaikkan garis yang mengatakan "mulai sekarang, kami mengoreksi bug", karena fitur dapat berubah ( dan bagi saya itu tidak adil menghitung perubahan fitur sebagai bug)

Dari pengalaman, saya mengatakan bahwa itu adalah sesuatu yang SELALU diremehkan, dan sangat mudah dapat menghabiskan jumlah jam yang sama dari "proyek asli".

Jawaban yang benar-benar tepat adalah nol jam untuk perbaikan bug karena kode Anda sempurna. :-)

Secara realistis, saya tidak bisa mengatakan bahwa saya pernah mendengar seseorang meminta atau menawarkan jenis rasio itu. Itu tidak berarti bahwa beberapa perusahaan tidak melacak waktu untuk pengembangan dan pemeliharaan. Tetapi pengembangan aplikasi adalah jangka waktu yang singkat jika dibandingkan dengan pemeliharaan yang sebagian besar perusahaan tidak kembali dan menghitung rasio itu. Mereka mungkin lebih peduli tentang mempelajari mengapa suatu aplikasi membutuhkan pemeliharaan dan menerapkan temuan itu pada aplikasi baru.

Memiliki kriteria yang terlalu luas untuk apa itu bug dapat hampir melipatgandakan waktu Anda. Manajer yang terlalu bersemangat yang menganggap permintaan klien untuk membuat tombol lebih besar (mereka memiliki masalah mouse) adalah cara yang bagus untuk meningkatkan jumlah bug yang kami perbaiki. Hanya perlu beberapa detik untuk memperbaikinya karena tidak perlu mempertimbangkan, menguji, mengkompilasi ulang, dan mendistribusikan tambalan. Oh, dan itu dihitung ganda sebagai fitur baru.

Faktor penentu terbesar untuk ini adalah apakah Anda bekerja dengan teknologi baru atau yang sudah ada. Jika Anda bekerja dengan sesuatu yang baru dan mengembangkan sesuatu yang belum pernah dilakukan atau telah dilakukan beberapa kali dalam keadaan yang berbeda, Anda akan menghabiskan banyak waktu untuk memperbaiki bug dan membuat proyek Anda bekerja seperti yang Anda inginkan . Seringkali bug akan menjadi hasil dari pekerjaan Anda sendiri, dan Anda harus melakukan banyak pekerjaan untuk merestrukturisasi apa yang telah Anda lakukan. Selain itu, banyak bug akan dihasilkan dari pemahaman yang tidak lengkap tentang harapan pengguna dan ketidaksadaran pengembang akan kasus tepi.

Jika Anda bekerja pada teknologi yang mapan, sebagian besar masalah akan diselesaikan oleh perpustakaan atau praktik di komunitas, dan Anda harus dapat mencari, membeli, atau menanyakan jalan keluar dari bug yang Anda temui.

Pada perangkat lunak kritis, rasio A 1: 1 bukanlah tidak biasa. Untuk pengujian unit saja, saya telah melihat indikator menyebutkan 1 hari pengujian unit untuk setiap 10 baris kode.

Saya pikir pertanyaan ini bias: dimulai dari anggapan bahwa memperbaiki bug adalah fase yang mirip dengan mengembangkan fungsi baru . Ini bukan kasusnya.

Pengembang yang baik tidak akan menghabiskan banyak waktu untuk kode debug karena kodenya akan bebas bug sejak awal. Pengembang yang buruk akan menghabiskan banyak waktu men-debug kode-nya karena dia tidak dapat membuat abstraksi yang cocok untuk menyelesaikan masalah nyata.

Perhatikan bahwa pengembang harus menguji sendiri kode mereka sendiri. Adalah tanggung jawab pekerjaan mereka untuk memberikan kode bebas bug. Jadi sulit untuk memisahkan pengkodean dari debugging.

Ini juga masalah prioritas. Saat berkembang, waktu yang diperlukan untuk memperbaiki bug terkait secara eksponensial dengan waktu yang telah berlalu sejak saat Anda memasukkan bug dalam kode. Jadi mengoreksi bug harus menjadi prioritas lebih besar daripada mengembangkan fungsionalitas baru.

Jadi alih-alih berbicara tentang "waktu yang dihabiskan untuk bug", Anda harus berbicara tentang "waktu yang dihabiskan untuk tes" (tes integrasi, tes penerimaan pengguna ...)

Saya pikir Anda benar - Anda tidak akan mendapatkan metrik yang berarti karena banyaknya faktor yang mempengaruhi.

Jika itu membantu saya dapat memberi tahu Anda proyek yang saya kerjakan (ruang perusahaan, sistem kompleks besar, banyak integrasi ke sistem lain) memiliki rasio sekitar 3: 2. Sebagian besar ini bukan kesalahan dengan kode - lebih biasanya kesalahan dengan antarmuka. Sebagai contoh, sistem A dan B berbicara satu sama lain melalui antarmuka X. Pengembang sistem A menafsirkan antarmuka X sedikit berbeda dari pengembang sistem B. Terjadi komedi.

Satu pengamatan untuk dibuat adalah bahwa pengembangan kode dan pengujian / perbaikan bug kode tidak boleh dua fase yang berbeda. Jika Anda menguji saat Anda mengembangkan "biaya" perbaikan bug kurang.

Saya mengambil sudut pandang yang sepenuhnya praktis: Apa yang lebih menghambat kegunaan praktis proyek? Jika itu bug dalam fungsi yang ada, Anda harus memperbaiki bug. Jika ada fitur yang hilang, Anda harus melakukan pengembangan asli, lalu kembali dan memperbaiki bug setelah fitur yang paling parah diimplementasikan. Ini membutuhkan pengetahuan tentang kasus penggunaan Anda. Bug yang membuat crash program dalam beberapa kasus sudut aneh mungkin menjadi prioritas lebih rendah daripada peningkatan kegunaan kecil yang mempengaruhi semua orang. Bug gangguan kecil dalam fungsi yang paling umum digunakan mungkin lebih penting daripada fitur yang hanya menguntungkan orang-orang yang mendorong perangkat lunak Anda ke ekstrem.