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.
Desde la perspectiva de Scrum la pila de producto ha de ser única e incluir historias de usuario e historias técnicas, y todas ellas ser responsabilidad sea el Propietario del Producto. Puede ser muy positivo que las responsabilidades recaigan en dos individuos con dos pilas, 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.
Desde la perspectiva de Scrum la pila de producto ha de ser única e incluir historias de usuario e historias técnicas, y todas ellas ser responsabilidad sea el Propietario del Producto. Puede ser muy positivo que las responsabilidades recaigan en dos individuos con dos pilas, 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