ES KAsi UN blog

Blog de Unkasoft, donde hablamos de programación de juegos para móviles, advergaming, marketing móvil, la industria de los videojuegos, metodologías ágiles y todos aquellos temas que nos preocupan en nuestro día a día

16 agosto 2006

SCRUM en Unkasoft: el product owner

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: ,


Comentarios:

Una sugerencia:
En vuestro caso, cuando se trata de un cliente interno y con buena comunicación entre el departamento cliente y el desarrollador, no hay problema en que el rol lo tengan 2 personas.
Usando scrum con clientes externos, o con departamentos no tan cohesionados el propietario del producto, es recomendable que sea una sóla persona. Otra cosa es que él en su empresa o departamento comparta la información y decisiones. Pero para el equipo scrum es mejor en esos casos que solo haya una voz y un responsable del cliente.
 


Lo apuntamos, Juan, sobre todo para algún proyecto que tenemos abierto con otras empresas donde nosotros hacemos precisamente de product owner...
 


La "visión" no es más que tener claro las necesidades del software, y eso significa tener experiencia en los problemas que va a resolver dicho software. La complejidad radica en el traspaso del conocimiento de esa experiencia a aquellos que desarrollan el software. Si la persona que tiene "visión" es parte del grupo de desarrollo, entonces se adelanta muchisimo en la definición de iteraciones y en ir validando los resultados. De nada vale ir haciendo iteraciones si nadie valida el trabajo realizado de manera efectiva.
 


Publicar un comentario

Links to this post:

Crear un enlace



<< Home

This page is powered by Blogger. Isn't yours?