jueves, 11 de enero de 2018

¿Qué son y como funcionan las historias técnicas?

Las historias de usuario consumen historias técnicas
Cortesía de Pixabay
La pila de producto contiene todos los "qués" a construir, elementos como historias de usuario, epics y temas. Pero en realidad, para poder realizar planificaciones tanto de sprint como de release, debe de contener todo el trabajo a hacer, y algunos de los elementos puede que no sean funcionales y sean necesidades de carácter técnico que no aporten valor de negocio, pero son consumidas por los elementos funcionales. También es interesante que negocio y Propietario del Producto tengan contacto con los aspectos técnicos, ya que así se forja un lenguaje común en ambas direcciones y se da consciencia de su importancia.

A estos elementos se les llama historias técnicas o enablers (habilitadores), y son cosas como preparar un webserver, implementar un conjunto de tablas en una base de datos que va a ser consumida por varias funcionalidades, elementos de seguridad, escalabilidad, rendimiento, etc. Otros tipos de historias técnicas se centran en resolver deuda técnica y en refactorizaciones, otros en historias de exploración como un análisis técnico o uno funcional que sirve para despejar incertidumbre sobre alguna historia de usuario.

Las historias técnicas se escriben directamente en texto técnico claro y preciso, sin un patrón como ocurre con las historias de usuario. También tienen criterios de aceptación asociados que se comprueban en la revisión de sprint por la audiencia técnica correspondiente.

Aunque el Propietario del Producto sea el responsable de la pila de producto y por tanto de todos sus elementos, en el caso de las historias técnicas los verdaderos "propietarios" son perfiles de carácter técnico como el equipo o un arquitecto. Estos no solo son responsables de la definición de la misma sino también de responder a dudas y preguntas y aclaraciones en la planificación y en la entrega de las historias.

Se pueden identificar diferentes tipos de historias técnicas:
  • Arquitectura: construyen elementos como las API's que crean la estructura, funcionamiento e interacción entre distintas las partes del software.
    Ejemplo: "Implementar un sistema de login seguro".
  • Infraestructura de producto: historias que son consumidas directamente por historias de usuario. Esto podría incluir infraestructura nueva y/o modificada, y oportunidades de refactorización originada por alguna necesidad funcional.
    Ejemplo: "Preparar los servidores de base de datos y web".
  • Infraestructura del equipo: historias que respaldan al equipo en su capacidad para entregar software. Suelen ser historias para herramientas y marcos de pruebas, métricas, diseño, planificación... y también pueden implicar que el equipo "desarrolle" o "compre e instale" algo.
    Ejemplo: "Preparar un sistema de integración continua"
  • Refactorización: estas son historias que representan candidatos para refactorizar, como por ejemplo lo es la deuda técnica. Pero no solo el código necesita de refactorización, también puede incluir diseños, automatización, herramientas y cualquier documentación de proceso.
    Ejemplo: "Homogeneizar el código de la función de cálculo de préstamos".
  • Spikes: historias de exploración limitadas en tiempo que dan respuesta a una cuestión, o reúnen información para una toma de decisión posterior o el diseño de una solución.
    Ejemplo: "Evaluar Oracle versus SQL/Server".

No hay comentarios:

Publicar un comentario