Apakah bug bagian dari hutang teknis?

Scrum Master kami terus menyebut bug sebagai utang teknis. Apakah dia benar, apakah bug dianggap sebagai hutang teknis di dunia Agile?

Saya pikir jawabannya di sini cukup sederhana - fitur utama dari hutang teknis adalah bahwa hal itu merupakan pilihan yang kita tanggung.

Kami memilih untuk membuat keputusan arsitektural, desain atau implementasi yang kami harapkan akan menyebabkan masalah bagi kami di kemudian hari untuk mencapai tujuan spesifik lebih cepat.

Bug bukanlah sesuatu yang kita pilih untuk ada dalam kode kita - jadi de-facto itu bukan utang teknis.

Tentu saja orang dapat membuat semua jenis argumen yang menarik (dan mungkin valid) tentang pilihan yang dibuat pasca penemuan tetapi secara mendasar (dan khususnya dalam konteks pertanyaan) tidak, bug bukan hutang teknis - terdengar lebih seperti penyalahgunaan kata kunci bingo kepada saya.

Sebagai catatan tambahan - saya tidak setuju dengan pernyataan bahwa ini mengingat bahwa hutang teknis akan menyebabkan bug dalam dirinya sendiri karena hal itu membuat banyak asumsi tentang sifat dari pilihan yang dibuat. Misalnya Anda dapat memiliki kode pengujian yang ditulis dengan baik, terstruktur dengan baik, yang masih membuat kompromi arsitektur untuk pengiriman awal. Demikian pula Anda dapat memilih untuk tidak mengotomatiskan proses penyebaran Anda yang tidak akan menyebabkan bug tetapi mungkin akan menyebabkan banyak stres dan rasa sakit. Tentu saja jika hutang adalah bahwa Anda telah menulis kode yang bukan SOLID (atau apa pun) maka ya ... tapi itu tidak selalu berarti demikian.

Iya.

Utang teknis (juga dikenal sebagai utang desain atau utang kode) adalah metafora neologistik yang merujuk pada konsekuensi akhirnya dari arsitektur perangkat lunak yang buruk atau berkembang dan pengembangan perangkat lunak dalam basis kode.

Sumber: Wikipedia

Baca utang teknis sebagai sesuatu yang bisa Anda hindari dengan memiliki alur kerja yang lebih baik (misalnya melakukan arsitektur dengan benar sebelum beralih ke pengkodean, melakukan TDD, dll.), Praktik pengkodean yang lebih baik, dll.

Sebagian besar bug dapat dihindari dengan tinjauan tambahan atau penggunaan metode yang lebih formal. Dengan tidak melakukan apa pun yang Anda bisa untuk tidak memiliki bug di tempat pertama, Anda menurunkan biaya langsung / jangka pendek proyek, tetapi meningkatkan utang teknis.

Setelah membaca jawaban oleh BЈовић , saya melihat bahwa itu mungkin tidak semudah yang saya kira.

• Misalnya Apakah bug bagian dari hutang teknis? Artikel mengklaim bahwa hanya bug yang Anda ketahui tetapi memutuskan untuk tidak memperbaikinya adalah bagian dari hutang teknis.

• Contoh lain, Pikiran Christopher tentang Hutang Teknis memenuhi syarat bug sebagai akibat dari hutang teknis, bukan bagian dari itu. Karena itu, banyak hasil yang terdaftar, seperti "biaya untuk mengimplementasikan fitur baru", dipengaruhi oleh jumlah bug.

• Akhirnya, ketika membuat model ABCDE-T model utang teknis , saya memasukkan bug sebagai salah satu dari enam faktor, tetapi mereka dianggap berbeda. Fokusnya bukan pada bug itu sendiri, tetapi pada cara mereka dikumpulkan, diprioritaskan dan diselesaikan. Bug sendiri muncul sebagai hasil dari hutang teknis (seperti pada contoh sebelumnya), tetapi tidak pernah muncul sebagai faktor hutang teknis.

Karena itu, saya masih cenderung menjawab bahwa bug — bug apa pun — adalah bagian dari hutang teknis.

Argumen pertama:

Membaca kutipan Jeff Atwood, sebagian besar bug akan memenuhi syarat sebagai:

upaya ekstra yang harus kita lakukan dalam pengembangan di masa depan karena pilihan desain yang cepat dan kotor

Dalam aplikasi bisnis, hampir setiap bug berasal dari pilihan desain yang cepat dan kotor atau praktik buruk (apakah itu karena kurangnya pengujian, penggunaan teknologi yang tidak cukup diketahui oleh pengembang, kurangnya komunikasi, kurangnya pemahaman tentang domain, dll.) Ini berarti bahwa "dengan refactoring desain cepat dan kotor ke dalam desain yang lebih baik" dan dengan mengadaptasi praktik yang lebih baik, bisnis dapat menyelesaikan sebagian besar bug mereka.

Argumen kedua:

Jika kita membuat paralel antara hutang biasa suatu perusahaan yang penting untuk diperhitungkan ketika sebuah perusahaan dijual kepada yang lain, dan utang teknis, yang sama pentingnya untuk diperhitungkan ketika sebuah proyek dijual ke perusahaan lain atau diberikan ke tim lain, kita dapat dengan mudah melihat bahwa bug adalah bagian dari hutang teknis, karena tim baru akan:

• Anda harus berurusan dengan bug tersebut sebelum membuat fitur baru (poin 5 dari Joel Test: Apakah Anda memperbaiki bug sebelum menulis kode baru?)

• Atau simpan bug, melestarikan / meningkatkan utang teknis ini.

Jeff Atwood dalam artikelnya Membayar Utang Teknis Anda memberikan jawaban yang cukup bagus tentang apa itu utang teknis:

utang teknis menimbulkan pembayaran bunga, yang datang dalam bentuk upaya ekstra yang harus kita lakukan dalam pengembangan di masa depan karena pilihan desain yang cepat dan kotor. Kita dapat memilih untuk terus membayar bunga, atau kita dapat membayar pokok dengan refactoring desain cepat dan kotor ke dalam desain yang lebih baik. Meskipun biaya untuk membayar pokok, kami mendapat keuntungan dengan mengurangi pembayaran bunga di masa depan.

Sebenarnya, bug bukan bagian dari hutang teknis, jika mereka tidak memperlambat pengembangan perangkat lunak lebih lanjut (mengubah hal-hal, menambah fitur baru, dll). Mereka cacat perangkat lunak.

Namun, ketika terlalu mahal untuk memperbaiki bug, atau memaksa Anda untuk mengatasinya (dan memperkenalkan lebih banyak hutang teknis), maka itu menjadi bagian dari hutang teknis.

Bug bukanlah hutang teknis. Utang teknis kurang pada kualitas, bukan ketiadaan itu. Perangkat lunak tidak boleh dikirimkan dengan bug di dalamnya sejak awal. Anda tahu, bahwa seluruh perangkat lunak yang berfungsi lebih dari hal dokumentasi yang komprehensif.

Pelanggar terbesar dari utang teknis adalah "perbaikan bug sementara", Anda tahu yang Anda lakukan untuk lulus tes dan menerima cerita yang diterima. Yang Anda janjikan kepada diri sendiri akan direvisi nanti, tetapi kemudian tidak pernah dilakukan. Karena perbaikan sementara ini, tambalan dan hal-hal lain menumpuk, kode menjadi tidak perlu berantakan, sulit untuk diperbarui dan diuji dan secara umum adalah mimpi buruk, tetapi masih melakukan pekerjaan itu.

Untuk mendukung pendapat ini, saya langsung menuju sumbernya, Ward Cunningham. Mengenai hal ini, Ward melakukan wawancara yang baik beberapa waktu lalu dengan Capers Jones, ada baiknya menonton.

Debat Utang Teknis, dengan Ward Cunningham & Capers Jones

Artikel lain yang layak dibaca adalah oleh Martin Fowler

Martin Fowler tentang Utang Teknis

Dalam artikel Martin, silakan temukan tautan ke penyebutan asli utang teknis oleh Ward Cunningham, dari OOPSLA92:

Sistem Manajemen Portofolio WyCash

Kutipan dari artikel di atas:

Meskipun kode yang tidak matang dapat bekerja dengan baik dan benar-benar dapat diterima oleh pelanggan , kelebihan jumlah akan membuat program tidak dapat diatur, yang mengarah ke spesialisasi ekstrim dari programmer dan akhirnya produk yang tidak fleksibel. Kode pengiriman pertama kali seperti masuk ke hutang.

Pada akhirnya, Hutang Teknis mungkin termasuk bug untuk beberapa orang, dan saya kira itu tidak masalah. Aku hanya berpikir itu bukan niat awal.

Sebenarnya, jawaban untuk pertanyaan Anda adalah TIDAK.

Utang teknis dapat (dan mungkin akan) mengarah pada bug, tetapi menyimpulkan bahwa bug apa pun adalah hasil dari utang teknis menempatkan interpretasi antara dua fakta: ada bug dan ada utang teknis (dengan asumsi yang dapat disimpulkan sebagai fakta).

Jika Scrum Master Anda menyatakan 'sebagai teori' bahwa bug adalah hasil dari hutang teknis, ia mengambil jalan pintas. Jika dia mengatakan ini tentang bug tertentu yang terus muncul kembali dia mungkin benar - kita tidak dapat melihat kualitas kode dari sini ;-)

Dia mungkin juga memiliki keluhan terus-menerus tentang orang-orang yang tidak mendengarkannya tentang utang teknis, dan karenanya menyebut setiap bug sebagai utang teknis, tetapi sekarang saya berspekulasi.

Menurut pendapat saya, benar-benar tidak masalah apakah Anda mengatakan bahwa bug adalah bagian dari hutang teknis ... atau tidak.

Fakta yang jelas adalah bahwa bug yang ada mewakili pekerjaan tambahan yang mungkin perlu dilakukan di masa depan, baik untuk memperbaikinya atau untuk mengatasinya.

Utang teknis (seperti label biasanya digunakan) juga merupakan pekerjaan tambahan yang mungkin perlu dilakukan di masa depan ... dengan satu atau lain cara.

Jadi apakah Anda mengatakan bug yang dikenal (atau tidak dikenal) adalah hutang teknis ... atau tidak ... sebenarnya hanya masalah definisi. Dan karena tidak ada definisi otoritatif ¹ tentang "utang teknis", seluruh diskusi tidak ada gunanya.

Seperti yang ditulis oleh Lewis Carroll:

'Ketika saya menggunakan sebuah kata,' kata Humpty Dumpty, dengan nada agak menghina, 'itu berarti apa yang saya pilih artinya - tidak lebih dan tidak kurang.' .

Sebenarnya itulah cara kerja bahasa alami. Kata-kata berarti apa yang orang pikirkan. Kamus definisi dan sebagainya hanya mendokumentasikan cara kata-kata digunakan, dan mereka tidak selalu dokumentasi yang akurat. Jika Scrum Master Anda ingin menyebut bug yang dikenal sebagai utang teknis, siapa yang dapat mengatakan bahwa ia "salah"?

^{1 - Mengutip orang seperti Ward Cummingham dan Caper Jones juga tidak membantu. Paling-paling itu memberitahu kita apa yang mereka maksudkan (atau maksudkan) ketika mereka menggunakan (menggunakan) frasa. Mereka tidak "memiliki" kalimat itu. Meskipun mereka tidak diragukan lagi pihak berwenang dalam masalah ini, ini masih hanya pendapat mereka.}