|
 Al tratar los requisitos en un proyecto ágil, me viene bien considerar que entre la visión del cliente, y las tareas de trabajo diarias, hay 3 niveles de "zoom"
El nivel es un punto de referencia sobre la forma de gestionar los requisitos, y las implicaciones o información que pueden suministrar en otros estratos.
Niveles "de gestión del equipo"
PRODUCTO:
Ámbito del sistema: descripción de las áreas o módulos o funcionalidades. En la ingeniería del software ortodoxa equivaldría a los requisitos del sistema o ConOps.
En un proyecto ágil, este es un "backlog" con la lista de funciononalidades generales del producto. Descritas de forma general, pero con las características de un backlog: priorizadas según los criterios de negocio, y con una estimación previa. Reflejaría el eje Y del gráfico Burn Up, en el que el cliente proyecta la previsión de desarrollo del producto a través de futuras versiones.
VERSIÓN:
Próximo objetivo de producto al que apunta. Lo que Scrum estricto considera el "product backlog", aunque desde esta perspectiva de tres niveles de trabajo para requisitos, los podamos considerar "release backlog". Se trata de la lista de funcionalidades con la que trabaja el equipo en las reuniones de inicio de sprint.
SPRINT:
El sprint backlog: la lista de tareas que se van a realizar en el sprint, que el equipo ha estimado y asignado, descomponiendo los puntos del "release backlog" que va desarrollar.
TAREAS DIARIAS:
Los tareas diarias que el equipo lleva a cabo y auto-gestiona durante el sprint. 
Los cuatro "niveles de gesión de proyecto" se completan con
VISIÓN:
La descripción general del sitio al que el cliente quiere llegar, de lo que quiere conseguir.
Normalmente el autor y responsable de este objetivo final no suele ser el propietario del producto, sino alguna instancia en la dirección de producto de su empresa.
A partir de esa visión concebida por su organización, la persona que trabajará integrada en el equipo del producto con el rol de "propietario del producto", empieza con la elaboración del plan del producto: product backlog + gráfico Burn Up .
Por esta razón, aunque resulta necesaria, su origen y responsabilidad no suele estar dentro del día a día de la gestión del proyecto. 
 |
RSS de los comentarios
