Ayer hablamos del product backlog, o en castellano: pila de producto. Bien, la persona encargada de llevar a buen puerto este documento es el que SCRUM llama product owner, o para nosotros el propietario del producto. En realidad no se trata de una persona tal cual, sino que estamos hablando de un rol, que en nuestro caso lo adoptamos dos personas a tiempo parcial (Jaime y yo mismo), aunque podría ser una persona a tiempo parcial (lo más habitual) o en proyectos muy grandes, una o varias personas a tiempo completo (ojo, SCRUM no encaja en proyectos grandes, así que si estás en este caso piénsatelo dos veces antes de empezar).

Bueno, pues el(los) propietario(s) del producto deben tener una visión clara del producto a construir (Jaime la tiene, y yo lo intento :), debe(n) saber bien qué se debe implementar, y sobre todo lo que NO se debe implementar.
Por cierto, suele ser más difícil de distinguir lo que NO se debe implementar, ya que parece ser que el 45% de las funcionalidades implementadas nunca llega a usarse. Por otro lado está la teoría del 80/20, donde dice más o menos (traducción libre de las mías):

A muchos desarrolladores les seduce la idea de la teoría del 80/20. Parece que tiene mucho sentido: el 80% de la gente usa el 20% de la funcionalidad. Así que te convences a ti mismo de que sólo necesitas implementar ese 20% de funcionalidad para seguir vendiendo el 80% de las copias. Por desgracia, no siempre es el mismo 20%. Cada usuario usa un conjunto de funcionalidades distinto. [...]

Pero esto es otra historia y debe ser contada en otra ocasión...

Bien, como decíamos, el product owner debe tener una idea clara de la dirección del proyecto, manteniéndo al día y priorizada la pila del producto. No se trata de pasarse meses analizando las necesidades reales y sacar la cojo-pila (también llamdo mega-análisis o super-especificación), sino trabajar unos días para sacar la cantidad de funcionalidad suficiente para cubrir la primera versión (algo que pueda funcionar), y a partir de ahí, añadir cosas.
Lo de siempre: el movimiento se demuestra andando.

Esta figura se parece más o menos al "cliente" que pregonaba eXtreme Programming, donde era la persona que colaboraba con el equipo en redactar las famosas historias de usuario, y que decidía lo que se iba a implementar en cada iteración de desarrollo.

Una vez que la versión está implementada, el propietario de producto la revisará para ver si ha cumplido con las expectativas que él tenía sobre ella... es decir: ver si las funcionalidades que él propuso como útiles y necesarias, realmente lo son (que a veces no lo son).

Cuando el propietario del producto tiene su pila más o menos preparada, colaborará con el equipo de desarrollo para definir la pila del sprint... así que ya tenemos carrete para el próximo día, donde hablaremos de los sprints (:

Etiquetas: agile, SCRUM