El desarrollo de productos siempre va acompañado de una deuda técnica, porque no todas las funciones se pueden realizar de manera eficiente en el tiempo asignado para la implementación de esta función. Este enfoque tiene sus pros y sus contras, pero si la deuda técnica no se extingue, agregar nuevas funciones al producto se vuelve cada vez más difícil.
Si está interesado en cómo aprendimos a trabajar con la deuda técnica, bienvenido a cat.
Un poco de teoría
¿Qué es la deuda técnica? Deuda técnica: el trabajo, si no se realiza, ocasiona daños invisibles para el usuario (configuración manual de una función, registros ilegibles / faltantes).
El resultado de pagar la deuda técnica no es visible para el usuario, pero aumentará la calidad del producto (confiabilidad, seguridad, velocidad de desarrollo, estabilidad).
Todos toman lo que está más cerca de él.
Cuando el producto es nuevo, esos. tiene poca deuda. Debido a esto, no teníamos algún tipo de mecanismo de clasificación para las tareas que caen en deuda técnica, al igual que no había ningún mecanismo de pago, aparte del propio entusiasmo de los desarrolladores. El principio Boy Scout se trata de nosotros. De hecho, las cosas no fueron tan color de rosa.
Todas las tareas se recopilaron al azar en un tablero, donde era difícil comprender la importancia de una tarea en particular.
. , — , - , .
- , , . - , , - code-review ( !)
- , , , , .
4 :
— . (0 — , , 5 — )
— . ( , , , ) (0 — , 5 — )
( , , ) (0 — , 5 — )
(0 — , 5 — )
story points, .
, TechDebt Value, ( , ).
X, Y Z. , — , X Y Z .
, , .
— . .
? , , .
, , .
?
, , story point — . , , , .
— , , 10-15 . - , .
.
, - . ( capacity), . , - , .
Ahora, además del hecho de que llevamos las tareas al sprint, algunas pequeñas tareas se cierran en el marco de otras tareas.
¿Entonces?
Estamos en la última de las etapas descritas. Es muy pronto para sacar conclusiones sobre qué tan exitoso es, lo principal es que hay un mecanismo, funciona y beneficia al equipo y al producto.