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".

2 comentarios:

  1. No se... Tengo mis dudas... si son historias o actividades para desarrollar una historia....

    Gracias por el punto de vista

    ResponderEliminar
    Respuestas
    1. Hola Marco,

      Las actividades para desarrollar historias son las tareas y son propias de una historia, como por ejemplo crear una tabla, ejecutar una prueba, etc. Preparar un websever o refactorizar una parte del software no son tareas de una historia, es algo más general que va como PBI a la pila de producto, y es a estos elementos a lo que se refiere este post.

      A fecha de hoy y con experiencias exitosas (en mi realidad) les daría el siguiente patrón:

      If we don't do this < action required>
      It will cause this impact
      And that will result in and/or

      Y priorizaría la pila de producto en base al coste del retraso en lugar de valor. El coste del retraso representa lo que estamos perdiendo por no tener cierta cosa. Lo interesante es que el coste de retraso aplica a historias de usuario y a los habilitadores. Por ejemplo la instalación de un webserver no tiene valor de negocio, pero si tiene coste del retraso, ya las historias de usuario de valor lo consumen y no pueden ser sin este... las historias de usuario a su vez tienen el coste del retraso del valor que no generan mientras no estén funcionando.

      Gracias por escribir, un abrazo,

      Alex

      Eliminar