He agregado un par de historias de usuarios que abordan algunas deudas técnicas a mi tablero de Pivotal Tracker. ¿Debería considerarlos como características (mantener mi nivel de velocidad) o como tareas / errores (reducir mi velocidad)? Entiendo que a la larga no hará ninguna diferencia si hago uno u otro de manera consistente, pero cada vez que agrego una historia de deuda técnica tengo que tomar la decisión.

Algunos pensamientos:

• En realidad no son errores, no rompen nada
• Los usuarios no han solicitado nada, ya que es una implementación de bajo nivel que no los afecta, pero facilitará el desarrollo a largo plazo
• Si define características como historias que agregan valor a los usuarios, bueno a) no lo hacen, ya que los usuarios no verán ningún beneficio directo, pero luego b) lo hacen porque hacen posible el desarrollo / mantenimiento futuro, lo que agrega valor, solo que no ahora

No estoy decidiendo si hacer o no el trabajo o cuándo programarlo, solo sé qué debo llamar deuda técnica en mi herramienta de gestión de proyectos y por qué.

Es una característica.

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

Se define, programa y rastrea como cualquier otra característica.

Si la implementación de esta función no es lo suficientemente valiosa (para el cliente o para usted) como para que se pueda programar, ese es un problema diferente.

(Pagar) la deuda técnica no es una característica , porque el cliente no está calificado para tomar decisiones al respecto . Lo más importante es que el cliente no puede decidir cuándo está terminado, y además el cliente depende totalmente de usted para explicar los beneficios. Es su criterio que hay una deuda técnica, y usted decide decidir cómo solucionarla y cuándo ha terminado. La deuda técnica está afectando su velocidad (futura), no la percepción del software por parte de los clientes. Si no hubiera deuda, sería más productivo. Y la velocidad que ha estado midiendo hasta ahora está mal, ya que debería haber tomado más tiempo para mantener el código en forma.

Creo que debería comunicar esto con su cliente, pero no es algo que esté bajo su control. Podría decir algo como esto: 'Hemos estado tomando algunos atajos hasta ahora, que tendremos que solucionar. Esto significa que nuestra velocidad disminuirá un poco en las próximas iteraciones, pero esto es para asegurarnos de que tengamos un software que pueda mantenerse a largo plazo ''.

El trabajo continuo en la función del cliente también ayudará a mantener su enfoque en mejorar el software para el cliente, en lugar de convertirse en una especie de ejercicio académico para encontrar el diseño perfecto (esto es algo con lo que personalmente lucho a veces).

En mi humilde opinión, una tarea para eliminar la deuda técnica definitivamente no es una característica. Podría introducirse en el departamento de "error", pero estaría ampliando la definición de los términos, ya que de nuevo no resulta en cambios de comportamiento observables por los usuarios.

Simplemente lo llamaría una tarea de mantenimiento. En cualquier proyecto de desarrollo, hay muchas tareas de este tipo, como configurar un entorno de desarrollo / prueba, reunir datos de prueba, fusionar sucursales en SCM, etc. Ninguno de estos es observable directamente por los usuarios, pero el no realizarlos regularmente resulta en un mayor desarrollo costos y tasa de errores a largo plazo.

Sin embargo, puede no ser necesario manejarlos como tareas separadas (a menos que sean enormes, y / o no esté bajo presión para implementar nuevas funciones en este momento). Por lo general, puede ser mejor simplemente identificar cuándo una nueva característica requiere refactorizar / escribir pruebas unitarias, etc. y manejarlas como parte del desarrollo de la nueva característica. Esto puede ser más fácil de explicar tanto a la administración como a los usuarios finales (si quieren saber a qué se dedica su tiempo). Actualización: Además, ayuda a los desarrolladores a centrarse también en el valor de la refactorización. Es fácil dejarse llevar por la refactorización por el bien de la refactorización, por lo que es IMHO útil centrarse en el valor agregado que aporta una refactorización específica desde la perspectiva del cliente.

Yo lo llamaría un improvement.

No es un error porque nada está roto.

Tampoco es una característica porque la refactorización no será una solicitud de su cliente. (¡porque funciona!)

La mayoría de los sistemas de seguimiento admiten un tipo de problema improvementde forma predeterminada, de lo contrario, probablemente pueda alterar los tipos de todos modos.