domingo, 8 de marzo de 2015

¿Cómo gestionar las historias técnicas?

Recientemente estuve hablando en un curso con un "Technical Product Owner". Me chirriaron los oídos, ese rol no existe en Scrum, pero me interesé más y le pedí que me contara. Me explicó en qué consistía su trabajo y cómo interactuaba con el resto del equipo.

¿Technical Product Owner?
La idea es tener dos pilas de producto, una para los requisitos funcionales, en forma de historias de usuario, y otra para los requisitos técnicos, la construcción de infraestructura que soporta las funcionalidades y la deuda técnica, en forma de historias técnicas. Cada pila tiene un responsable que colabora estrechamente con el otro; la primera el Product Owner o Propietario del Producto, y la segunda el Technical Product Owner. Ambos tipos de "product owners" se ponen de acuerdo a principios de cada sprint, especialmente en el inicio de las fases o releases, en donde deciden conjuntamente qué elementos técnicos van a incluir en los sprints.

Es muy positivo que las responsabilidades recaigan en dos individuos, ya que eso propicia la negociación entre dos personas realmente interesadas en las historias de su rol. 

Es importante focalizar los sprints en nuevas funcionalidades para que se produzca la entrega de valor al cliente, ya que las historias técnicas no aportan valor intrínseco, ahora sí, aseguran la capacidad de entrega funcionalidades y por tanto de valor. Alrededor de un 10% de estas historias técnicas son necesarias, a veces imprescindibles, según la fase en la que se encuentre proyecto.

Añadir que historias derivadas de deuda técnica pueden impactar fuertemente en la capacidad del equipo, mientras estas no se resuelvan, y a la vez puede ser positivo tenerla, porque nos hacen ágiles, ser mediocres a veces nos permite alcanzar un objetivo. Por supuesto hay que gestionar la deuda técnica y resolverla en cuanto sea posible.

No hay comentarios:

Publicar un comentario