domingo, 1 de diciembre de 2019

¿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 :-)

2 comentarios:

  1. Hummm? Si las HU se hicieran con cuidado y profesionalidad la deuda técnica no debería lastrar el proyecto. No suena a música en mis oídos escribir historias de DT, creo que lo único que se lograría sería dar por inevitable una falencia mejorable.

    ResponderEliminar
    Respuestas
    1. Hola Pedro,

      Absolutamente de acuerdo!!! Si aplicamos pensamiento Lean sobre el desperdicio deberíamos de utilizar TDD y BBD que incluyen refactorización en su ciclo, y cuando se produzca un bug ir a la causa raíz y solucionarla con máxima prioridad.

      Gran parte de las empresas suelen desconocer (o ignorar) las herramientas de automatización que traen XP y DevOps, por no hablar de no pelear por una cultura de responsabilidad compartida DevOps... tenemos herramientas potentísimas y seguimos inmersos en que los programadores están para rascar y no para otras cosas...

      Herramientas gratuitas como la Simian Army de Netflix suelen ser absolutos desconocidos... quizá porque si las utilizaramos nos dirían todas las carencias, y graves, de nuestro software.

      Desde mi perspectiva, en la que ayudo a equipos a sobrevivir en empresas en las que queda mucho por hacer, en sentido Agile me refiero, les ayudo con estas pequeñas herramientas que permiten cambiar la mentalidad de forma gradual.

      Gracias por escribir y darme la oportunidad de expresar lo pienso :-)

      Eliminar