Product Owner e Historias de usuarios




Product owner

El product owner (o en castellano, propietario del producto) es aquella persona con una visión muy clara del producto que se quiere desarrollar, que es capaz de transmitir esa visión al equipo de desarrollo y, además, está altamente disponible para transmitirla.
La figura del product owner es clave en el desarrollo de un proyecto ágil.
Para saber más:


Historias de usuario
Las historias de usuario (user stories) son una descripción breve, de una funcionalidad software tal y como la percibe el usuario.
Para tener un mejor entendimiento sobre las historias de usuario, recomiendo el libro User stories applied: For agile software development, de Mike Cohn (2004). 
Para asegurar la calidad de una historia de usuario se utiliza el método INVEST. El método se usa para comprobar la calidad de una historia de usuario revisando que cumpla las características descritas a continuación.

Independient
(independiente)
Es importante que cada historia de usuario pueda ser planificada e implementada en cualquier orden. Para ello deberían ser totalmente independientes (lo cual facilita el trabajo posterior del equipo). Las dependencias entre historias de usuario pueden reducirse combinándolas en una o dividiéndolas de manera diferente.
Negotiable
(negociable)
Una historia de usuario es una descripción corta de una necesidad que no incluye detalles. Las historias deben ser negociables ya que sus detalles serán acordados por el cliente/usuario y el equipo durante la fase de “conversación”. Por tanto, se debe evitar una historia de usuario con demasiados detalles porque limitaría la conversación acerca de la misma.
Valuable
(valiosa)
Una historia de usuario tiene que ser valiosa para el cliente o el usuario. Una manera de hacer una historia valiosa para el cliente o el usuario es que la escriba el mismo.
Estimable
(estimable)
Una buena historia de usuario debe ser estimada con la precisión suficiente para ayudar al cliente o usuario a priorizar y planificar su implementación. La estimación generalmente será realizada por el equipo de trabajo y está directamente relacionada con el tamaño de la historia de usuario (una historia de usuario de gran tamaño es más difícil de estimar) y con el conocimiento del equipo de la necesidad expresada (en el caso de falta de conocimiento, serán necesarias mas fases de conversación acerca de la misma).
Small
(pequeña)
Las historias de usuario deberían englobar como mucho unas pocas semanas/persona de trabajo. Incluso hay equipos que las restringen a días/persona. Una descripción corta ayuda a disminuir el tamaño de una historia de usuario, facilitando su estimación.
Testable
(comprobable)
La historia de usuario debería ser capaz de ser probada (fase “confirmación” de la historia de usuario). Si el cliente o usuario no sabe como probar la historia de usuario significa que no es del todo clara o que no es valiosa. Si el equipo no puede probar una historia de usuario nunca sabrá si la ha terminado o no.

 

Comentarios