¿Cómo escribir historias técnicas de deuda técnica?

La deuda técnica ralentiza la productividad y genera
productos de escasa calidad - cortesía de Pixabay

Un producto no es un producto de calidad si no da solución a las necesidades del usuario o cliente, eso representa su valor, y tampoco es de calidad si la infraestructura tecnológica que lo soporta no es excelente, eso lo representa su integridad tecnológica.

Centrarse únicamente en construir funcionalidades de negocio, como las historias de usuario, puede funcionar a corto plazo, e incluso proporcionar una gratificación inmediata al mercado, pero a medio plazo la velocidad de entrega se ralentizará irremediablemente por una carga aplastante de la deuda técnica que se va adquiriendo.

Es por ello que para garantizar que se realicen las inversiones adecuadas dentro del presupuesto para el producto o proyecto, es necesario incluir historias técnicas de resolución de deuda técnica en la pila del producto.

A menudo el Propietario de Producto no comprende la necesidad y los beneficios de reducir la deuda técnica y no considera historias técnicas para ello en la pila del producto. Recordemos que el Propietario del Producto es parte del equipo ágil y este debe de asumir la responsabilidad de reducir la deuda técnica y analizar esta con los miembros del equipo de desarrollo y trabajar juntos para darle la prioridad adecuada en la pila del producto: su dolor es el dolor del equipo y viceversa.

Los desarrolladores conocen la deuda técnica y son conscientes de la importancia de resolver este problema desde el punto de vista técnico. Hay un técnica provocativa que ideó un equipo de desarrollo para ayudar al Propietario del Producto a tener en cuenta la deuda técnica; utiliza el siguiente el patrón para escribir historias técnicas de esta índole:

If we don't do this [action required]

It will cause this impact [loss of service]

And that will result in [reputational damage] and/or [monetary impact]

Si no hacemos [acción requerida]

Causará el impacto [pérdida de servicio]

Lo que resultará en [daño a la reputación] y/o [impacto monetario]

un ejemplo podría ser:

Si no hacemos por resolver la cobertura de pruebas

Causará el impacto de un incremento mensual del 10% en el número de incidencias

Lo que resultará en una reducción de productividad mensual acumulada de aproximadamente 5 horas

Los equipos viven la realidad tecnológica (herramientas, hardware, entornos, etc.) día a día, ellos saben qué les cuesta en esfuerzo o en tiempo cada vez que se encuentran con un elemento con deuda técnica. Es su responsabilidad analizarla, estimarla y hacerla visible de forma argumentada al Propietario del Producto y a otros interesados.

Hacer partícipe al cliente e interesados tiene dos beneficios; hacer que estos entiendan los problemas del software, y que participen en la solución apoyando la resolución de deuda técnica o proporcionando una perspectiva de negocio que puede cambiar las prioridades.

Gracias Sara por compartir este patrón :-)