Apakah bug bagian dari hutang teknis?


44

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


Mengapa penting untuk memutuskan apakah itu utang teknis atau bukan? Apakah itu akan memengaruhi cara Anda merepresentasikan bug di papan scrum Anda, atau memengaruhi bagaimana Anda berencana memperbaikinya?
Bryan Oakley

@BryanOakley Beberapa bug dapat memblokir Anda sedemikian rupa sehingga memaksa Anda untuk bekerja di sekitar mereka, bahkan menambah hutang teknis. Bug ini mungkin terlalu mahal untuk diperbaiki
BЈовић

4
@BryanOkley - Saya selalu berpikir hutang teknis adalah desain atau refactoring yang diperlukan untuk meningkatkan implementasi tetapi tidak mungkin pada saat ini karena keterbatasan waktu / anggaran. Saya pikir penting untuk menggunakan terminologi yang benar. Saya mungkin salah atau dia mungkin salah, itulah sebabnya saya mengajukan pertanyaan.
user86834

Aku mengerti itu. Mengapa penting menyebut mereka utang teknis? Apakah Anda mengatakan bahwa jika Anda mengklasifikasikannya sebagai "hutang teknis" maka Anda akan memperlakukan bug-bug tersebut secara berbeda dari bug lainnya?
Bryan Oakley

1
Anda dapat memiliki sejumlah besar departemen teknis dan tidak memiliki bug tunggal. Departemen teknis adalah kebalikan dari kode yang ditulis dengan baik dan dirancang dengan baik. Kode yang ditulis dengan baik mudah untuk dirawat, diuji, dan ditambahkan. Departemen teknis memperlambat pengembangan, membuatnya sulit untuk melacak bug, dan meningkatkan kemungkinan kode baru akan memperkenalkan bug.
Luis Perez

Jawaban:


35

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.


1
+1. Saya pikir jawaban BЈовић cukup tepat, tetapi jawaban Anda benar-benar menyentuh kepala. (Tapi saya agak bingung dengan penggunaan istilah de facto . Saya tidak berpikir Anda dapat mengatakan bahwa de jure , bug adalah hutang teknis?)
ruakh

Penggunaan bahasa sangat menyenangkan ... coba ini: en.wikipedia.org/wiki/De_facto - bacalah sebagai "untuk semua maksud dan tujuan" yang cukup dekat dengan maksud saya
Murph

"Saya pikir jawabannya di sini cukup sederhana - fitur utama dari hutang teknis adalah sesuatu yang kita keluarkan berdasarkan pilihan." Dari mana Anda menarik definisi ini? Saya pikir itu tidak benar. Itu salah satu bagian dari hutang teknis, bagian lainnya implisit dan biasanya karena ketidaktahuan dan praktik buruk.
gphilip

de jure du jure. Besok de facto. QED.
radarbob

1
menurut Technical Debt Quadrant oleh Martin Fowler Anda dapat mengidentifikasi bug dan kode buruk sebagai utang "sembrono": martinfowler.com/bliki/TechnicalDebtQuadrant.html . Saya pikir intinya adalah bahwa jika Anda menandai beberapa bug sensitif sebagai hutang maka Anda dapat memahami berapa harganya dan apakah Anda perlu menghilangkannya. Misalnya, apakah Anda memiliki modul tertulis yang ceroboh yang diubah hanya sekali dalam setahun dan itu akan memakan waktu berminggu-minggu untuk menulis ulang - Anda mungkin harus menyimpannya karena pembayaran bunga untuk utang ini sangat kecil
shershen

20

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.


1
Saya pribadi tidak menganggap cacat sebagai utang teknis meskipun argumen yang disajikan dalam jawaban ini masuk akal, tetapi a) tidak masalah bagaimana kita mendefinisikan utang teknis IMO, dan b) ini adalah jawaban yang ditulis dengan baik. Saya memilih itu pula. +1!
Bryan Oakley

13

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.


1
Sebenarnya mereka melakukannya, karena bug dapat menyebabkan pekerjaan tambahan pada fitur-fitur baru yang tidak perlu tanpa bug. Saya bahkan telah melihat kode berevolusi ke arah yang buruk (membangun lebih banyak hutang teknis) karena bug yang entah bagaimana berevolusi menjadi "itu bukan bug itu adalah fitur" karena pelanggan menulis skrip atau apa pun yang bergantung pada perilaku buggy.
Marjan Venema

@MarjanVenema Poin bagus. Saya belum memikirkan itu.
BЈовић

Perhatikan bahwa kutipan ini bukan dari Jeff Atwood, kutipan ini diambil dari pos Martin Fowler . Jeff mengutip ini juga di posting blognya.
Uooo

6

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.


"Perangkat lunak seharusnya tidak diberikan bug di dalamnya sejak awal." Semua perangkat lunak tetapi program yang paling sederhana berisi bug. Anda menetapkan bilah ini terlalu tinggi.
bhspencer

2

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.


2

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 1 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.

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.