rata-rata industri untuk waktu yang dihabiskan untuk pemeliharaan


17

Seorang manajer baru-baru ini mengumumkan bahwa mereka menghabiskan terlalu banyak waktu untuk memperbaiki bug. Saya kira dia berpikir kita harus menulis kode yang sempurna setiap saat (sementara masih mencapai tenggat waktu yang mustahil tentu saja!) Dan itu membuat saya bertanya-tanya apa rata-rata waktu yang dihabiskan industri untuk memperbaiki bug dan menulis kode baru.

Jadi, adakah yang punya metrik tentang waktu yang dihabiskan untuk memperbaiki bug terhadap pengembangan kode baru? Atau adakah analisis empiris waktu perbaikan bug untuk industri secara keseluruhan? Apakah 50% pengeluaran bug memperbaiki terlalu banyak, atau hampir benar? Bagaimana dengan 20% atau 33%?

Saya senang menerima bukti anekdotal dari pengalaman pribadi karena itu akan menjadi bagian dari beberapa statistik di sini yang bisa saya bandingkan dengan kinerja kami.


9
manajer Anda terdengar sangat bodoh. Bacaan yang disarankan untuk kasus-kasus seperti itu: Fakta dan Kekeliruan Rekayasa Perangkat Lunak oleh Robert L. Glass, khususnya "Fakta 43. Pemeliharaan adalah solusi, bukan masalah." Artikel Wikipedia menyebutkan upaya 80% dihabiskan untuk pemeliharaan perangkat lunak
nyamuk

3
Apa masalah sebenarnya ? Apakah Anda memiliki masalah kualitas? Apakah proses Anda benar-benar tidak efisien? Atau apakah manajer Anda hanya berharap perangkat lunak tidak membutuhkan biaya banyak?
kevin cline

@gnat: komentar Anda adalah jawaban terbaik
kevin cline

@kevincline terima kasih - komentar yang dikonversi menjadi jawaban
nyamuk

Pemeliharaan tidak hanya tentang memperbaiki bug (cacat) dan jumlahnya sangat bervariasi untuk setiap proyek (= tidak ada jawaban pasti). Bagi saya sepertinya Anda memiliki masalah kualitas.
MaR

Jawaban:


13

Seorang manajer baru-baru ini mengumumkan bahwa mereka menghabiskan terlalu banyak waktu untuk memperbaiki bug.

Suara di atas sangat bodoh. Bacaan yang disarankan untuk kasus-kasus seperti itu: Fakta dan Kekeliruan Rekayasa Perangkat Lunak oleh Robert L. Glass, khususnya "Fakta 43. Pemeliharaan adalah solusi, bukan masalah."

Artikel Wikipedia menyebutkan 80% upaya dihabiskan untuk pemeliharaan perangkat lunak.

manajer saya membuat PHB Dilbert terlihat seperti orang jenius :)

Hm yang diberikan di atas, saya juga akan melakukan beberapa upaya dalam menganalisis apakah semua permintaan yang Anda lakukan memang bug .

Menurut pengalaman saya, permintaan peningkatan atau fitur baru terlalu sering diajukan sebagai bug. Manajer yang baik melibatkan programmer mereka untuk mencari tahu tentang hal itu - manajer yang buruk, well, terus mengeluh tentang terlalu banyak waktu memperbaiki bug .


2
Memperbaiki bug! = Pemeliharaan! Memperbaiki bug berarti Anda mengkode kesalahan dalam sistem dan harus diperbaiki untuk mengembalikan fungsionalitas yang benar . Dengan pemeliharaan yang saya maksud adalah semua tugas seperti perbaikan bug, peningkatan skalabilitas, migrasi perangkat keras, dan peningkatan kinerja, dll. Saya akan mengatakan lebih dari 25-30% dari waktu yang dihabiskan hanya untuk perbaikan bug memerlukan panggilan tata kelola segera. Hingga 40-50% dari upaya yang dihabiskan untuk pemeliharaan secara keseluruhan terdengar masuk akal untuk sistem perusahaan menengah.
Apoorv Khurasia

Apakah Anda memiliki angka untuk kelas bug yang berbeda? Jelas jika Anda mendapatkan sejumlah besar prioritas tinggi, bug "show stopper" mungkin ada kasus bahwa proses pengembangan perlu beberapa pekerjaan untuk menentukan sumbernya, tetapi jika semua hal-hal kecil itu bukan masalah besar. Juga seperti kata nyamuk, banyak dari mereka mungkin permintaan tambahan.
Stevetech

Kutipan Anda untuk artikel wikipedia salah! Dikatakan bahwa "80% upaya pemeliharaan digunakan untuk tindakan non-korektif" , tetapi tidak mengatakan apa-apa tentang waktu pemeliharaan dibandingkan dengan desain atau pengkodean atau pekerjaan lain.
Tobias Knauss

9

Pertanyaan pertama yang harus ditanyakan adalah apakah "perbaikan bug" Anda sebenarnya memperbaiki bug pengkodean atau yang lainnya. Memperbaiki bug kode yang sebenarnya harus relatif kecil dalam banyak kasus selama Anda memiliki basis kode yang baik. Jika Anda bekerja dengan basis kode yang buruk, perbaikan bug yang luas tidak bisa dihindari.

Namun, dalam proses memasukkan program ke dalam produksi, Anda akan menemukan persyaratan yang tidak didokumentasikan, aktivitas pengguna yang tidak terduga, anomali data, ketidakcocokan perangkat keras, masalah instalasi dan masalah lain yang bukan kode bug. Seringkali manajer dan pengguna akan menganggap masalah dukungan / pemeliharaan produksi ini sebagai bug karena mereka biasanya memerlukan perubahan kode.

Saya juga menemui manajer yang akan mengelompokkan apa yang seharusnya disebut sebagai permintaan peningkatan minor sebagai bug. Seringkali ini dimasukkan ke dalam pelacakan bug atau sistem pelaporan masalah dan ini dapat membuat statistik "bug" Anda lebih tinggi dari yang sebenarnya.


Apa yang Anda gambarkan adalah apa yang kami miliki, tetapi itu tidak mengubah apa pun :(
gbjbaanb

8

Itu tergantung pada berapa banyak kode yang Anda miliki di sana, berapa lama kode itu ada di sana, dll.

Waktu yang dihabiskan untuk memperbaiki bug dalam perangkat lunak harus dimuat di depan hingga 6-12 bulan pertama rilis, namun begitu waktu mendekati tak terhingga, waktu yang dihabiskan untuk pemeliharaan versus waktu yang dihabiskan untuk pengembangan awal akan melebihi 100% - itu hanya cara kerja.

Meskipun saya tidak memiliki statistik yang sulit (Kode Lengkap tidak, tetapi saya tidak dapat memberi tahu Anda dengan tepat halaman / bagian mana), menurut pengalaman saya kira-kira 40% pengembangan (terkadang setinggi 60%) dihabiskan untuk pemeliharaan. Jelas bahwa semakin banyak kode yang Anda lepaskan, semakin banyak waktu perawatan yang akan Anda miliki. Bug tidak selalu berfungsi, dan merupakan hasil dari ketidakpastian seperti halnya cacat program.


0

jika Anda menggunakan pelacak tiket yang baik (Seperti Jira dari Atlasian) dan Anda telah menghabiskan waktu memasukkan semua kategori yang berbeda, cerita pengguna, tingkat urgensi dengan benar dan dengan persetujuan dari rekan tim Anda, maka sebenarnya hitung metrik ini (dan banyak lagi) luar biasa mudah.

Pada proyek sebelumnya, kami menggunakan Jira untuk mengelola daftar bug / task / todo kami, dan pada akhirnya itu menunjukkan kepada kami bahwa penyebab terbesar dari keterlambatan dan masalah ternyata adalah praktik manajemen yang tidak efisien.

Anehnya, ketika informasi itu keluar, kami tiba-tiba mengatakan bahwa kami tidak akan lagi menggunakan Jira, dan bahwa produk baru akan dibawa untuk menggantikannya.

Sementara itu, semua permintaan data yang akan dikirimkan melalui Jira harus dikirim ke tim manajemen, dan kami memiliki akses langsung kami dihapus.

Apa yang tidak diperhatikan adalah bahwa sebagai bagian dari perhitungan statistik, tim dev memiliki Jira menusuk data ke kait web, dan kait web ini digunakan untuk meneruskan data ke titik akhir di beberapa server internal, di mana kami memiliki kode yang dibuat laporan ini secara otomatis.

Kami mulai memantau kait web, dan menemukan bahwa meskipun kami di mana diberitahu bahwa Jira tidak lagi digunakan, itu tetap sangat hidup untuk waktu yang cukup lama (6+ bulan tepatnya) dan penyalahgunaan grosir oleh manajemen atas adalah hanya merajalela dengan penggunaan yang salah.

Tentu saja, itu tidak harus sesuatu yang kompleks seperti Jira.

Jika Anda menginginkan solusi hasil rendah, Anda dapat menggunakan lembar spread Google-docs, dan API pemberitahuan GDocs, untuk melacak tugas / tiket / bug / permintaan fitur dll.

GDocs sendiri sekarang dapat menerbitkan kait web dan segala macam hal.

Berpasangan dengan Git dan / atau Github dan beberapa kait yang memicu ketika kode dikomit ke repositori Anda, dan Anda memiliki sistem home brew yang cukup efisien, yang dapat merekam jumlah data yang mengejutkan.

Namun secara umum, dari 100% dari masa pakai alami produk, pemisahan antara greenfield dev dan pemeliharaan umumnya 20/80, sebagian besar biaya dalam siklus ALM (Aplikasi Lifetime Management) diambil pada biaya pemeliharaan dan dukungan.

Tidak ada yang namanya menghabiskan terlalu banyak waktu untuk memperbaiki bug, karena tidak mungkin untuk menulis kode bebas bug.

Pengujian yang baik dan kebijakan integrasi berkelanjutan akan mengurangi defisit, tetapi Anda tidak akan pernah benar-benar memberantasnya.

Siapa pun yang percaya sebaliknya (IMHO) tidak memiliki pengetahuan yang cukup untuk membuat penilaian yang akurat, atau buta (Kasus yang lebih umum) hanya betapa sulitnya sebenarnya untuk menulis perangkat lunak.

Jika manajer Anda siap untuk itu, dan beberapa di antaranya, maka Anda mungkin ingin menyarankan agar dia membayangi Anda selama sehari, sehingga ia dapat melihat dengan tepat apa yang Anda lakukan dan bagaimana Anda melakukannya.

Iv'e bekerja di beberapa perusahaan di mana pekerjaan semacam ini didorong secara aktif, dengan staf tingkat atas membayangi staf tingkat bawah, dan sebaliknya, itu bisa menjadi pengalaman belajar yang benar-benar bagus untuk kedua pihak yang terlibat.


2
"Tidak ada yang namanya menghabiskan terlalu banyak waktu memperbaiki bug" - sungguh omong kosong. Jika Anda menghabiskan cukup waktu untuk memperbaiki bug yang perusahaan Anda alami karena tidak bisa tetap kompetitif di pasar (karena Anda memperbaiki bug daripada melakukan hal - hal), Anda menghabiskan terlalu banyak waktu memperbaiki bug ...
Telastyn

Dan alternatifnya? - Anda tidak menghabiskan cukup waktu untuk memperbaiki bug, dan aplikasi Anda crash, terbakar dan pesaing Anda mengambil semua kebiasaan Anda, secara efektif mendorong Anda keluar dari pasar. Triknya (dan bagian tersulit dari semua ini) adalah menemukan keseimbangan yang dapat diterima.
shawty

1
Tidak, saya setuju, tapi itu pendapat saya sendiri yang datang ke sana, karena saya benar-benar percaya pada zaman sekarang ini, seni debugging yang tepat menjadi seni yang hilang. Terlalu banyak dari kita, terlalu mengandalkan banyak pada hal-hal seperti unit test, yang IMHO memberikan terlalu banyak keamanan palsu. Saya tidak mengatakan uji unit harus dihapuskan, tetapi saya katakan tidak ada cukup debugging yang tepat dan praktik perbaikan bug dilakukan lagi, karena itu. Ini giliran mengarah ke manajer (Seperti dijelaskan di atas) percaya bahwa memperbaiki Bug tidak diperlukan, dan sebagai hasilnya kami benar-benar tidak (Lagi IMHO) melakukan cukup banyak.
shawty

2
unit test dan debugging adalah seni yang berbeda digunakan untuk masalah yang berbeda Meskipun memecahkan masalah "adalah kode kita benar" lebih baik mencegah masalah "mengapa kode saya rusak". Semua hal sama, saya lebih suka orang pandai membuat kode yang benar daripada mengidentifikasi akar penyebab.
Telastyn

1
Sekarang Anda memiliki persetujuan penuh saya pada. Ini adalah fakta yang menyedihkan bahwa dalam industri saat ini banyak programmer memperlakukannya hanya sebagai pekerjaan 9 sampai 5, di mana mereka masuk, mengeluarkan kode sampai waktu rumah dan waktu keluar. Kembali pada hari itu, devs sangat bangga dalam menulis kode yang baik, solid, teruji dengan baik dan menghabiskan waktu memikirkannya sebelum pergi ke dekat keyboard, Anda melihat sangat sedikit dari itu di zaman sekarang ini.
shawty
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.