Anda tahu apa itu. Menyerahkan semua yang Anda butuhkan ke dalam sprint sudah sangat sulit, tetapi Anda masih perlu mencari tempat lain 10-20% dari waktu pengembang untuk mengembalikan hutang teknis . Jika Anda pernah membela kebutuhan untuk meluangkan waktu untuk ini, maka Anda tahu bahwa ini seperti perang salib proporsi epik.
Tetapi Anda dapat melakukan ini, dan dalam panduan ini kami akan mencari tahu caranya.
Saya telah melihat terlalu banyak pertemuan di mana tepatnya pertanyaan ini telah menghabiskan terlalu banyak waktu. Argumen biasanya tidak berdasar, dan emosi dapat berjalan tinggi - dan yang dengan suara paling keras di dalam ruangan menang.
Dilemanya adalah ini: jika tekanan bisnis di atas angin, perusahaan Anda berisiko mendapat terlalu banyak hutang teknis - dan kemudian para pengembang kehilangan motivasi mereka, perusahaan tersebut mengalami kebangkrutan teknis, dan pesaing Anda mengalahkan Anda. Jika Anda mengatasi tekanan pengembang , perusahaan berisiko mengambil terlalu sedikit hutang teknis, dan kemudian pesaing Anda akan dapat menyediakan produk dan fitur lebih cepat, menangkap pasar, dan kemudian menggunakan laba yang diterima untuk mengembalikan utang teknis mereka. Anda kalah lagi.
Akal sehat menunjukkan bahwa tim pengembangan harus mengembangkan pemahaman intuitif tentang basis kode, di mana utang teknis mengintai, serta konsekuensinya bagi perusahaan, sehingga membangun kepercayaan dalam organisasi. Jika kepala arsitek dan pendiri mengatakan bahwa Anda perlu refactor sekarang, Anda (biasanya) hanya pergi dan melakukannya.
Masuk akal untuk mencoba mempertahankan pengembang Anda untuk menciptakan budaya pengetahuan, pertukaran, dan kepercayaan. Tetapi itu akan membutuhkan kerja keras bertahun-tahun, dan, menyelesaikan refactoring, kami masih hampir tidak tahu apakah kami telah membuang waktu kami. Mungkin kita baru saja menghemat beberapa hari dari waktu pengembangan di masa depan? Atau bisakah kita menunggu sebentar untuk melunasi hutang teknis nanti, dan alih-alih menambahkan beberapa fitur baru? Kita tidak pernah tahu pasti dan menghubungkan ketidaktahuan kita dengan kenyataan bahwa pengembangan produk lebih merupakan seni daripada sains.
Nah, ini saatnya menambahkan beberapa sains ke dalam proses.
Apa keandalan yang serupa dari situs dan anggaran utang teknis
Hutang teknis yang dikelola dengan baik dan terencana dengan baik dapat menjadi alat yang sangat berharga. Menyadari apa yang kita lakukan, kita dapat menggunakannya sama seperti kita menggunakan hutang keuangan sebagai leverage. Tetapi jika kita, tanpa menyadarinya, kita mengambil terlalu banyak - misalnya, tidak sepenuhnya memahami kondisi transaksi (yaitu, efek yang tehdolg memiliki pada basis kode kita, pelanggan, tim dan bisnis) - itu mungkin berakhir dalam runtuhnya perusahaan kami.
Tim manajemen keandalan situs terbaik beroperasi dengan anggaran keandalan situs dalam hal utang teknis yang dikelola. Keandalan situs (Site keandalan) - sebuah konsep yang dipopulerkan Google; dia bertanggung jawab untuk menjaga perangkat lunak dalam keadaan "aktif dan berjalan", tetapi, yang menarik, perusahaan seperti Google tidak bertujuan untuk meningkatkan waktu kerja hingga 100%. Alasannya adalah bahwa uptime 99,99% cukup untuk produk Google menjadi sangat dapat diandalkan untuk pengguna nyata. Dan ini terakhir 0.01% mencapai eksponensial keras dan berjuang untuk itu hanya tidak masuk akal.
Karenanya, jika ini memberikan total downtime 52 menit per tahun, Google akan berusaha sedekat mungkin dengan angka ini; tetapi segala sesuatu yang kurang dari 52 menit setahun merupakan peluang yang terlewatkan untuk mengambil risiko tambahan dan dengan cepat menyediakan fitur yang menjanjikan kepada pelanggannya.
Pikirkan anggaran utang teknis Anda sebagai anggaran untuk keandalan situs. Asalkan Anda mengambil utang teknis yang wajar dan tetap di bawah jumlah maksimum utang yang Anda mampu sebelum mulai mempengaruhi pelanggan dan bisnis Anda, Anda harus meningkatkan jumlah utang untuk mengambil risiko lebih banyak dan memenangkan pesaing mereka.
Jika utang teknis Anda di zona merah, Anda perlu untuk melunasi sebagian itu. Jika dia berada di zona hijau, Anda dapat mengambil lebih banyak risiko dan lebih banyak utang. Tujuan Anda adalah untuk terus menjaga jumlah utang sedekat mungkin dengan ideal. Dengan kata lain, jika Anda berada di puncak bagian merah grafik, anggaran ideal untuk utang teknis adalah A ⇒ B. Jika Anda berada dalam depresi pada bagian hijau grafik, maka anggaran ideal adalah C ⇒ B. Ingat hanya bahwa A ⇒ C terlalu besar anggaran untuk utang teknis .
Karena hutang teknis dapat diukur (kami menulis tentang ini di artikel lain ), ini sekarang bukan hanya konsep - sepenuhnya memenuhi kebutuhan praktis.
Cara mendapatkan hasil maksimal dari anggaran utang teknis Anda
Anda harus berjuang untuk anggaran utang teknis yang mengembalikan Anda naik atau turun, ke jumlah maksimum utang teknis yang Anda mampu. Untuk menentukan anggaran ini, uraikan di area basis kode Anda di mana utang teknis harus segera dilunasi, yaitu utang yang akan mencegah perusahaan Anda mencapai tujuan saat ini. Tidak disarankan bagi Anda untuk membayar hutang terlalu sedikit atau terlalu banyak.
Andreas Klinger , Koordinator perintah remote AngelList, baik menempatkan dalam artikelnya "Refactoring basis besar kode warisan" :
Tidak semuanya perlu di refactored. Jika ini bukan bagian yang kritis, atau tidak ada yang perlu meningkatkan fungsi ini dalam beberapa bulan mendatang, atau terlalu rumit, pertimbangkan untuk mengenali tempat ini sebagai utang teknis.
Sederhananya, tujuan Anda adalah menemukan di mana dua hal bertumpang tindih: apa yang akan Anda kerjakan dalam sprint, bulan atau kuartal saat ini, dan bagian-bagian dari basis kode Anda yang berisi utang teknis. Bayar utang di area persimpangan ini, tetapi tidak di luar.
Dan di sinilah sains melengkapi seni. Anda dapat menggunakan data untuk mengidentifikasi area di mana Anda perlu melunasi hutang teknis dalam waktu dekat:
- Sorot file dengan kepemilikan yang lemah di basis kode Anda, karena kepemilikan kode adalah indikator utama dari kesejahteraan basis kode Anda. Lebih lanjut tentang ini dalam artikel kami "Salah satu fitur budaya perusahaan yang diperlukan untuk kesejahteraan basis kode" .
- Ukur kohesi dan penggandengan untuk file-file ini dan hanya menyisakan file dengan kepemilikan yang lemah, konektivitas rendah dan gigi tinggi dalam daftar. Anda dapat mempelajari lebih lanjut tentang masing-masing indikator ini dalam artikel kami "Menggunakan Studi Pemimpin Industri untuk Mengukur Utang Teknis" .
- Hitung aktivitas berulang (churn) untuk masing-masing file ini untuk menentukan subset dari file yang bermasalah. Menurut sebuah studi Microsoft , secara aktif mengubah file hanya membuat 2-8% dari total file dalam sistem, tetapi mereka bertanggung jawab atas 20-40% dari semua perubahan, dan mereka bertanggung jawab atas 60-90% dari semua bug.
- Hubungkan kembali daftar file yang dihasilkan dengan paket triwulanan Anda. Apakah salah satu fitur yang tercantum dalam paket Anda mengharuskan Anda untuk bekerja pada subset dari file masalah yang Anda uraikan? Jika ya, tetapkan tujuan yang terkait dengan refactoring file-file ini, evaluasi jumlah pekerjaan yang diperlukan dan tetapkan tugas untuk pengembang tertentu, lebih disukai mereka yang memiliki file yang sesuai. Sertakan pekerjaan ini dalam rencana Anda.
Untuk memulai, lihatlah kami VSCode ekspansi bebas - itu akan membantu Anda menyimpan melacak dan membayar utang teknis yang paling mendesak.
Masuk ke dalam hubungan jangka panjang dengan hutang teknis
Kami telah menerapkan pendekatan ini, berdasarkan data di stepsize, serta banyak perusahaan perangkat lunak kelas dunia. Tidak hanya itu masalah utang teknis telah menjadi sekarang jauh lebih jelas, karena kita masih, dan tahu berapa banyak utang kita bersedia untuk mengambil, dan kapan / bagaimana untuk mendapatkannya kembali. Kita semua jarang berpikir tentang apakah kita benar memilih kompromi antara fitur baru dan hutang teknis. Kami berhasil menghilangkan bagian penting dari dugaan ini, serta banyak ketakutan dan kecemasan yang menyertai pilihan ini.
Mari kita perjelas lagi: ini bukan peluru perak yang dapat digunakan setahun sekali dan kemudian dilupakan. Anda harus mengetahui tugas teknis Anda dengan lebih baik. Lacak kemajuan Anda pada semua indikator dari setiap sprint dan terus tingkatkan seluruh proses untuk mencapai kesejahteraan teknis .
Kami menulis tentang beberapa cara untuk melakukan ini, sehingga untuk menciptakan motivasi yang tepat, baca tentang menumbuhkan budaya pembangunan berdasarkan kepemilikan dan menghormati pengembang yang mengembalikan utang teknis .