Haruskah utang teknis dijadwalkan sebagai fitur atau tugas (atau bug)?


19

Saya telah menambahkan beberapa kisah pengguna yang membahas beberapa hutang teknis ke papan Pelacak Penting saya. Haruskah saya menganggap mereka sebagai fitur (menjaga tingkat kecepatan saya) atau sebagai tugas / bug (menurunkan kecepatan saya)? Saya mengerti itu tidak akan membuat perbedaan dalam jangka panjang jika saya melakukan satu atau yang lainnya secara konsisten, tetapi setiap kali saya menambahkan kisah hutang teknis saya harus membuat keputusan.

Beberapa pemikiran:

  • Mereka sebenarnya bukan bug, mereka tidak merusak apa pun
  • Pengguna belum meminta apa pun karena implementasi tingkat rendah yang tidak memengaruhi mereka, tetapi itu akan membuat pengembangan jangka panjang lebih mudah
  • Jika anda mendefinisikan fitur sebagai cerita yang menambah nilai bagi pengguna, baik a) mereka tidak sebagai pengguna akan tidak melihat manfaat langsung, tapi kemudian b) mereka lakukan karena mereka membuat pembangunan masa depan / pemeliharaan mungkin yang tidak menambah nilai, tidak sekarang

Saya tidak memutuskan apakah akan melakukan pekerjaan itu atau tidak, atau kapan harus menjadwalkannya, saya hanya tahu apa yang harus saya sebut utang teknis dalam alat manajemen proyek saya, dan mengapa.


Jawaban:


17

Ini adalah fitur.

As a [Developer], 
I want to [refactor the whizbang library] 
in order to [simplify maintenance and speed execution]

Ini didefinisikan dan dijadwalkan dan dilacak seperti fitur lainnya.

Jika menerapkan fitur ini tidak cukup berharga (untuk klien atau Anda) untuk itu dijadwalkan, itu masalah yang berbeda.


1
Aha. Jawaban yang fantastis. Saya belum memikirkan cerita yang ditulis dari sudut pandang saya, tetapi masuk akal bagi saya terutama menjadi pengembang di rumah, karena saya harus bertindak sebagai klien juga. Terima kasih!
Rebecca Scott

5
Saya harus tidak setuju. Dari perspektif ini, hampir semuanya - bahkan mengatur IDE saya atau mendapatkan akun SCM - akan terlihat seperti "fitur" ...
Péter Török

2
@ Peter - Tidak harus. Menyiapkan IDE Anda adalah upaya yang tidak dapat dihindari; hal-hal lain hanya termasuk dalam kategori "hal-hal yang dikerjakan". Tetapi mengganti kerangka kerja atau sesuatu sangat berbeda. Bisnis harus menyadari apa yang akan Anda lakukan, manfaatnya bagi mereka dan mereka harus diijinkan untuk memprioritaskannya terhadap pekerjaan lain. Dengan demikian, ini adalah fitur dalam segala hal.
pdr

4
Tentunya suatu fitur harus menambah nilai pada produk? Refactoring tidak menambah nilai seperti itu, itu hanya memungkinkan pengembang untuk bekerja lebih efisien dan mengurangi kemungkinan bug. Nilai tambah dari hal semacam ini akan menjadi efek sekunder. Menyebut fitur ini hanya akan menjadi cara penyajiannya sehingga pemilik produk mungkin lebih memprioritaskannya.
David Neale

3
-1 Kegagalan untuk melakukan pekerjaan Anda tidak boleh diperlakukan sebagai fitur.
Martin Wickman

18

(Membayar) utang teknis bukan fitur , karena klien tidak memenuhi syarat untuk mengambil keputusan . Yang paling penting klien tidak dapat memutuskan kapan itu selesai, dan selain itu klien sepenuhnya bergantung pada Anda untuk menjelaskan manfaatnya. Adalah penilaian Anda bahwa ada utang teknis, dan terserah Anda untuk memutuskan bagaimana cara memperbaikinya dan kapan Anda selesai. Utang teknis memengaruhi kecepatan (masa depan) Anda, bukan persepsi klien tentang perangkat lunak. Jika tidak ada hutang, Anda akan lebih produktif. Dan kecepatan yang Anda ukur sejauh ini salah, karena Anda seharusnya mengambil lebih banyak waktu untuk menjaga bentuk kode.

Saya pikir Anda harus mengomunikasikan hal ini dengan klien Anda, tetapi itu bukan sesuatu dalam kendali mereka. Anda bisa mengatakan sesuatu seperti ini: 'Kami telah mengambil beberapa jalan pintas sejauh ini, yang harus kami perbaiki. Ini berarti kecepatan kami akan turun sedikit dalam beberapa iterasi berikutnya, tetapi ini untuk memastikan kami memiliki perangkat lunak yang dapat dikelola dalam jangka panjang. '

Terus bekerja pada fitur klien juga akan membantu untuk menjaga fokus Anda pada peningkatan perangkat lunak untuk klien, alih-alih menjadi semacam latihan akademis untuk menemukan desain yang sempurna (ini adalah sesuatu yang kadang-kadang saya perjuangkan secara pribadi).


Setuju dengan ini. Ini bukan fitur karena itu bukan masalah klien, dan itu bukan sesuatu yang harus mereka ketahui (dalam pengalaman saya, ketika klien menyadari bahwa Anda sedang refactoring / memperbaiki kode untuk melunasi hutang teknis, mereka melihatnya membuang-buang waktu mereka) dan uang , jadi yang terbaik mereka tidak tahu Anda melakukannya sama sekali).
Wayne Molina

+1 Ini juga merupakan sudut pandang yang valid tentang masalah ini. Saya suka memperlakukannya sebagai fitur karena dengan itu ia akan masuk dengan baik dengan mekanisme perencanaan dan pelacakan yang normal. Sulit untuk menjelaskan kepada klien.
Steven A. Lowe

+1, ini adalah satu-satunya jawaban yang menjelaskan bagaimana perhitungan kecepatan akan menjadi salah ketika Anda menghitung "tugas teknis" sebagai fitur.
Doc Brown

15

IMHO tugas untuk menghilangkan utang teknis jelas bukan fitur. Ini bisa dimasukkan ke dalam departemen "bug", tetapi akan memperluas definisi istilah, karena sekali lagi itu tidak menghasilkan perubahan perilaku yang dapat diamati oleh pengguna.

Saya hanya akan menyebutnya tugas pemeliharaan. Dalam setiap proyek pengembangan, ada banyak tugas seperti itu, seperti mengatur lingkungan dev / tes, mengumpulkan data uji, menggabungkan cabang di SCM dll. Tidak ada yang dapat diamati secara langsung oleh pengguna, tetapi kegagalan untuk melakukannya secara teratur menghasilkan peningkatan pengembangan biaya dan tingkat bug dalam jangka panjang.

Mungkin tidak perlu untuk menangani mereka sebagai tugas yang terpisah (kecuali mereka sangat besar, dan / atau Anda tidak di bawah tekanan untuk mengimplementasikan fitur-fitur baru sekarang). Biasanya mungkin lebih baik untuk mengidentifikasi ketika fitur baru memerlukan tes unit refactoring / menulis dll. Dan menangani ini sebagai bagian dari pengembangan fitur baru. Ini mungkin lebih mudah untuk dijelaskan kepada manajemen dan pengguna akhir (jika mereka ingin tahu apa yang Anda habiskan). Pembaruan: Selain itu, ini membantu pengembang fokus pada nilai refactoring juga. Sangat mudah untuk terbawa ke dalam refactoring demi refactoring, jadi berfokus pada nilai tambah apa yang dibawa refactoring spesifik dari perspektif klien adalah berguna IMHO.


1
Saya setuju bahwa refactoring utang teknis harus dimasukkan ketika diharuskan oleh fitur baru, tetapi saya membaca pertanyaan ini sebagai pembayaran utang teknis terlepas dari atau sebelum dibutuhkan oleh fitur baru.
Steven A. Lowe

@ Seven, itu interpretasi saya juga. Menghubungkan pembayaran utang teknis ke fitur terkait hanyalah sebuah saran.
Péter Török

3

Saya akan menyebutnya sebuah improvement.

Bukan bug karena tidak ada yang rusak.

Atau fitur karena refactoring tidak akan menjadi permintaan klien Anda. (karena berhasil!).

Sebagian besar sistem pelacakan mendukung jenis masalah improvementsecara default, jika tidak, Anda mungkin dapat mengubah jenisnya.

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.