14 agosto 2006
SCRUM en Unkasoft: el product backlog
Bien, una vez hecha la introducción, vamos a tratar los distintos aspectos de SCRUM, siempre explicando cómo los hemos abordado en Unkasoft y qué problemas hemos tenido (y seguimos teniendo) a la hora de usarlos.
El primer elemento que tratamos de implantar fue el Product Backlog, o pila de producto: se trata de una lista de funcionalidades que debe llegar a tener el producto que estamos desarrollando. En teoría, cuando implementemos todas esas funcionalidades, el producto estará acabado (ya, a ver cuando llega eso, porque yo no lo tengo claro).
Este paso a sido fácil para nosotros, porque hace tiempo que usábamos un documento (que llamábamos "problemas a resolver") donde íbamos apuntando todas las cosas que nos gustaría que tuviera Battlewizard. Este documento lo íbamos ampliando con nuestra propia experiencia, peticiones del departamento de QA, o de empresas que están usando Battlewizard (como nuestros early adopters GPM-e y Karonte).
Adaptarnos a SCRUM a sido tan sencillo como convertir el documento en una hola de cálculo, incluyendo los títulos de las nuevas funcionalidades y con una explicación breve en forma de comentarios. En la propia hoja de cálculo hemos organizando las características en cuatro categorías conforme a la urgencia de implementarlas: muy alta, alta, media y baja.
¿Y para qué nos está sirviendo esto? Pues sencillamente para no olvidarnos de nada y para tener un sitio de consulta cuando queramos saber qué hay que hacer y qué es más urgente. Además,
Una vez que hemos implementado una característica, la borramos de la pila de producto, y así poco a poco va decreciendo (bueno, en realidad no ha parado de crecer desde que la hemos creado, añadimos más funcionalidades de las que nos da tiempo a implementar, pero con el tiempo y una caña... :)
El primer elemento que tratamos de implantar fue el Product Backlog, o pila de producto: se trata de una lista de funcionalidades que debe llegar a tener el producto que estamos desarrollando. En teoría, cuando implementemos todas esas funcionalidades, el producto estará acabado (ya, a ver cuando llega eso, porque yo no lo tengo claro).
Este paso a sido fácil para nosotros, porque hace tiempo que usábamos un documento (que llamábamos "problemas a resolver") donde íbamos apuntando todas las cosas que nos gustaría que tuviera Battlewizard. Este documento lo íbamos ampliando con nuestra propia experiencia, peticiones del departamento de QA, o de empresas que están usando Battlewizard (como nuestros early adopters GPM-e y Karonte).Adaptarnos a SCRUM a sido tan sencillo como convertir el documento en una hola de cálculo, incluyendo los títulos de las nuevas funcionalidades y con una explicación breve en forma de comentarios. En la propia hoja de cálculo hemos organizando las características en cuatro categorías conforme a la urgencia de implementarlas: muy alta, alta, media y baja.
¿Y para qué nos está sirviendo esto? Pues sencillamente para no olvidarnos de nada y para tener un sitio de consulta cuando queramos saber qué hay que hacer y qué es más urgente. Además,
Una vez que hemos implementado una característica, la borramos de la pila de producto, y así poco a poco va decreciendo (bueno, en realidad no ha parado de crecer desde que la hemos creado, añadimos más funcionalidades de las que nos da tiempo a implementar, pero con el tiempo y una caña... :)
La persona encargada de mantener este documento es el llamado "propietario del producto" ("product owner") y su función es... bueno, creo que ya está bien por hoy, así que el próximo día hablaremos del propietario del producto...
Comentarios:
dice...
Hola JM.
Por "armar" un poco la idea de fondo que debe tener detrás el backlog y el rol del propietario del producto.
El propietario del producto debe tener muy claros dos puntos: la visión del producto y el alcance del proyecto.
Visión es un término que resulta ambiguo, seguramente porque no es fácil de definir: tener claro el concepto del producto o servicio que se quiere, aunque no se conozca o no se sea capaz de explicar el detalle, porque de hecho se espera que el propio proceso de desarrollo trabaje e investigue sobre este detalle para dotarlo del mayor valor posible.
El alcance es el que establece las limitaciones del proyecto.
En Scrum, coste y agenda no son el resultado de la estimación hecha sobre el plan del proyecto. Scrum no es un modelo de gestión predictivo sino adaptable. Su objetivo no es planificar sino producir el mayor valor posible para las condiciones del negocio del cliente (para su alcance). Por eso la agenda de versiones o "releases" y el presupuesto no es una estimación del gestor sino una restricción del propietario del producto.
Esta información la debe conocer y compartir todo el equipo, y la herramienta que le da soporte es el product backlog (que yo llamo pila del producto, pero soy consciente de que lo raro es llamarlo en español).
Los requisitos se ordenan según la prioridad del negocio, y sobre la lista ordenada se delimitan los puntos de "release". En el fondo contiene la "visión" y el "alcance".
De todas formas, para ayudar al propietario del producto a perfilar la visión con la ayuda de las aportacioens de todo elequipo, y para conseguir que todos compartan el mismo concepto de la visión, yo incorporo también, al menos al inicio del proyecto, un ejercicio de caja de producto.
Como ahora voy "volao" de tiempo, esta tarde o mañana por la mañana hago un hueco y preparo un post contando como hago el ejercicio.
Saludos!
JM dice...
Eso de la "caja del producto" suena interesante (¿product box? :)
Esperamos tu post...
Saludos
JM
Publicar un comentario
<< Home
dice...Hola JM.
Por "armar" un poco la idea de fondo que debe tener detrás el backlog y el rol del propietario del producto.
El propietario del producto debe tener muy claros dos puntos: la visión del producto y el alcance del proyecto.
Visión es un término que resulta ambiguo, seguramente porque no es fácil de definir: tener claro el concepto del producto o servicio que se quiere, aunque no se conozca o no se sea capaz de explicar el detalle, porque de hecho se espera que el propio proceso de desarrollo trabaje e investigue sobre este detalle para dotarlo del mayor valor posible.
El alcance es el que establece las limitaciones del proyecto.
En Scrum, coste y agenda no son el resultado de la estimación hecha sobre el plan del proyecto. Scrum no es un modelo de gestión predictivo sino adaptable. Su objetivo no es planificar sino producir el mayor valor posible para las condiciones del negocio del cliente (para su alcance). Por eso la agenda de versiones o "releases" y el presupuesto no es una estimación del gestor sino una restricción del propietario del producto.
Esta información la debe conocer y compartir todo el equipo, y la herramienta que le da soporte es el product backlog (que yo llamo pila del producto, pero soy consciente de que lo raro es llamarlo en español).
Los requisitos se ordenan según la prioridad del negocio, y sobre la lista ordenada se delimitan los puntos de "release". En el fondo contiene la "visión" y el "alcance".
De todas formas, para ayudar al propietario del producto a perfilar la visión con la ayuda de las aportacioens de todo elequipo, y para conseguir que todos compartan el mismo concepto de la visión, yo incorporo también, al menos al inicio del proyecto, un ejercicio de caja de producto.
Como ahora voy "volao" de tiempo, esta tarde o mañana por la mañana hago un hueco y preparo un post contando como hago el ejercicio.
Saludos!
JM dice...Eso de la "caja del producto" suena interesante (¿product box? :)
Esperamos tu post...
Saludos
JM
Publicar un comentario
<< Home
