Apa yang harus kita lakukan untuk cerita pengguna untuk utang teknis di Pivotal Tracker? Haruskah kita menganggap ini sebagai fitur (memberi poin) atau sebagai tugas (tidak memberikan poin, sehingga menurunkan kecepatan)?
Saya bingung apa yang harus dianggap sebagai tugas:
Duplikasi Kode - Jelas bahwa jika kita telah menempatkan kode yang sama di banyak tempat, itu praktik kode yang benar-benar buruk dan menunjukkan pengembang dalam tim harus lebih memikirkan untuk membuat perangkat lunak dapat dipelihara, lakukan refactoring dan tim harus meluangkan waktu untuk tinjauan kode. Karena semua ini membutuhkan pengalaman tingkat kedewasaan, waktu, dan kode, lebih baik memberikan lebih sedikit poin sehingga kualitas kode tidak terganggu. Jadi, kesalahan seperti itu harus dihukum dan kecepatan harus diturunkan dengan tidak memberikan poin kepada tugas.
Peningkatan teknologi - Seperti bergerak untuk memodulasi JS, HTTP2, React, MVC atau teknologi baru / lebih baik lainnya. Langkah-langkah ini akan membuat kinerja dan pemeliharaan kode lebih baik. Tetapi haruskah ini menjadi tugas atau fitur? Saya percaya ini adalah bagaimana dunia teknologi, teknologi baru datang sesekali dan Anda harus bermigrasi ke sana. Jadi, saya melihat tidak ada gunanya menghukum kecepatan tim untuk pekerjaan seperti itu. Saran?
Duplikasi / Sub-Standar kode dalam kode warisan - Beberapa kode yang tidak tersentuh sejak lama ATAU ketika tim baru dibentuk tetapi basis kode agak lama, kami menghadapi tantangan ini. Tim mengatakan mereka belum mengkodekan bagian ini jadi mengapa kecepatan mereka harus dihukum dengan memilih hutang teknis seperti itu karena mereka tidak pernah membuat hutang tersebut.
Kode standar karena urgensi bisnis - Terkadang pengembang dipaksa untuk mendorong fitur ASAP secara langsung karena tekanan pesaing / target / bisnis / pengguna. Haruskah membersihkan kode buruk seperti itu dianggap sebagai tugas (tanpa memberikan poin) juga? Tim pengembang waktu ini tidak bersalah, jadi mengapa kecepatan mereka harus diturunkan, padahal sebenarnya mereka lebih banyak menghabiskan waktu ekstra dalam kasus-kasus seperti itu.
Saya percaya semua jenis tugas yang disebutkan di atas, jika dilakukan dengan bijak, akan meningkatkan kecepatan tim di masa depan. Tetapi bagaimana kita harus menjaga keseimbangan dengan mempertahankan kecepatan tim serta menghukum karena kesalahan teknis yang dilakukan tim dengan mengambil keputusan yang buruk?
Pertanyaannya mirip dengan: Haruskah utang teknis dijadwalkan sebagai fitur atau tugas (atau bug)? , tetapi saya tidak menemukan jawaban yang meyakinkan yang mencakup semua 4 poin sehingga saya memposting ulang dengan cara yang berbeda.