Scrum-time.com
Product Backlog

Product Backlog


En el artículo sobre Sprint escribimos que es la base de la metodología Scrum y todo gira alrededor del Sprint . Hoy es el momento más oportuno de decir:

«¡El Sprint mismo gira alrededor del Product Backlog y su derivada – Sprint Backlog!».

En realidad Product Backlog debe ser claro para todos. La transparencia del Product Backlog ayuda al equipo, así como al cliente comprenderlo. Hacerlo así es como un arte. A veces los clientes y los especialistas hablan en idiomas completamente diferentes y esta «barrera de lengua» molesta principalmente el trabajo, y aún más encubre entre sí algunos peligros. Si hay una falta de compresión y la interpretación de los deseos del cliente no es completamente justa, al cabo del sprint habrá un producto hecho, que no se ve exacto. La desviación mínima en el núcleo del producto puede llevar a su evolución incorregible, puesto que todo el otro código puede basarse en un error.

El Product Backlog mismo consiste en los elementos del Backlog o del "User Story". Es уn realidad la lista de los deseos,que deben ser arreglados por el grado de la importancia. Vamos a ver:

ID

Denominación

Importancia

Valoración inicial

Demostración

Emisión

Nota

1La creación de la cesta de las compras5013Pasar a la página de la mercancía, añadir la mercancía en la cesta. Pasar en la cesta, mostrar que la mercancía está añadida. Pasar a otra mercancía, añadirlo, volver en la cesta y demostrar que las dos mercancías están añadidas, hay una representación de los precios de los productos, la suma total. Mostrar como formalizar el encargo habiendo llegado a la fase de la paga.

1
2Conectar la caja electrónica para la paga de la mercancía (el nombre de la caja conectada)

4521Habiendo hecho la demostración del trabajo de la cesta – pagar por la mercancía.1

El desciframiento de los campos Product Backlog:

ID – para todos los elaboradores aquí todo está claro. El número único de la tarea, que va por orden.

Denominación – el nombre de la tarea, que debe ser en realidad unívoco y claro para todos.

Importancia – el orden en que hay que cumplir las tareas para que se haga el producto hecho lo más rápidamente posible ,y que después solamente se extienda y se mejore. Cada compañía hace los estándares por la escala de las apreciaciones. Por ejemplo, puede ser desde 10 hasta 150.

Valoración inicial – es un significado aproximado, que espera el Product Owner, pero en realidad, puede cambiarse. Cuando los equipos trabajan bastante mucho tiempo juntos sobre los productos parecidos, Product Owner comprende cuantos los recursos laborales son necesarios para la ejecución de una u otra tarea. Después esto se valora de nuevo a través de Planning (Scrum) Poker..

Demostración – para demostrar la finalidad del trabajo – es necesario demostrar el resultado. ¿Qué quiere ver el Product Owner y el cliente? Es necesario describirlo en este campo.

Emisión – en realidad, es la demostración evidente de lo que uno quisiera ver después del primer Sprint. Con los puntos de la importancia, es difícil determinar en que pararse si hay unos estados fronterizos. Por ejemplo, el Product Owner sabe por Velocity cómo va el trabajo del equipo. Él cuenta por Story Points y por la Importancia cuanto el equipo puede cumplir aproximadamente por una iteración. A veces sucede que un punto sale ya de los límites de las posibilidades del equipo según Velocity, o al contrario hay un espacio para hacer algo más. El Product Owner puede ver que para una finalidad lógica del producto en esta iteración no es necesario cumplir este punto y entonces pone la “Emisión 2”.

Notas - siempre es útil tener esta columna. Puede ser vacío, pero puede extender la comprensión de la tarea.

En realidad en un Product Backlog pueden haber algunos otros campos, que extienden la comprensión de las tareas y de todo el proyecto en general:

Temas – a qué tema o categoría se refiere una u otra tarea. Esto es necesario para la división de las tareas en los bloques temáticos. A veces esto ayuda hasta en la estimación de grupo. Por ejemplo, está decidido que la estimación de la mercancía ahora no es necesaria o que no es importante, y en la estimación de la mercancía entran un par de tareas. Entonces es posible en estos temas cambiar la importancia para todas las tareas de la categoría.

Componentes – la elaboración de algo es conectado de un modo o de otro con unos componentes de la producción. En la programación esto, por ejemplo, puede ser: la base de datos, el servidor de fichero, API etcétera, en otras direcciones los componentes. Una división así es muy útil si se usan varios equipos. Así los equipos pueden compartir las direcciones de la elaboración que mejorará a su vez la productividad. En el libro de Jeff Southerland hay un ejemplo, que refleja una de las bases de la metodología Scrum. El ejemplo dado consiste en la escritura de las cifras y las letras sucesivas.

1IA
2IIB
3IIIC
4IVD
5VE

En primer lugar es necesario intentar escribir todo eso por las líneas: 1 I A, 2 II B, 3 III C, 4 IV D, 5 V E – y anotar cuánto tiempo se ocupa. Se puede identificar que las cifras árabes representan el trabajo con la base de datos, las romanas – con el servidor de fichero, las letras - API. Es decir tienen que primero hacer algo por la base, después por los ficheros,y luego por API. Ahora por el test es necesario escribir lo mismo en las columnas: 1 2 3 4 5, I II III IV V, A B C D E. Así se sale más mucho rápidamente - no tienen que pasar de un sistema a otro, y se trabaja mucho mejor en un sistema de las coordenadas.

Atando al ejemplo dado con los componentes, imaginen que el equipo tiene una posibilidad del trabajo no con esto datos: 3 III C, 5 V E, sino que con otros: 1 2 3 4, A B C. Un trabajo así será mucho más productivo.

El iniciador de la tarea – responsable por el Product Backlog – es el Product Owner, sin embargo no sólo él puede ocuparse de su corrección. Es muy conveniente seguir quién ha puesto la tarea para saber con quién consultarse de este tema.

ID intercomunicación – un enlace con cualquier cosa. A veces es necesario atar las tareas del Backlog con unos servicios exteriores o interiores, por ejemplo, un separado bug-tracker.

Volviendo a la división en las categorías siempre surge la pregunta: ¿Qué se debe hacer si hay varios equipos de la elaboración? ¿Hacer un Product Owner y un Product Backlog para cada uno? ¿O es mejor tener un Product Backlog y un Product Owner común?

Hay en realidad unos enfoques diferentes usados por las compañías diferentes.

Enfoque №1 – un Product Owner y un Product Backlog

un Product Owner y un  Product Backlog

Este enfoque se parece a la situación, cuando los capitanes de los equipos en un juego eligen a los jugadores. Primero el capitán escoge a el jugador más fuerte ,después el segundo más fuerte de los que se han quedado etcétera. Hay aquí una situación parecida. El Product Owner dispone las tareas de Product Backlog a orden de la importancia y los equipos comienzan a eligir a él las tareas también según su importancia. La división pasa habitualmente por los temas (es conveniente usar para esto una columna correspondiente en Product Backlog).

Los equipos pueden regatear por unas tareas, agruparlos, cambiar las prioridades.

Cuando la distribución está acabada, cada equipo se ocupa solamente de sus tareas, es decir de su Sprint Backlog.

Enfoque №2 – un Product Owner y varios Product Backlogs

un Product Owner y varios Product Backlogs

En realidad es todo lo mismo, las tareas se distribuyen a las órdenes por el Product Owner. Aquí claro en seguida surgen unos comentarios razonables, por ejemplo – «¿Para que al Propietario del producto va a distribuir las tareas por los equipos? Los equipos saben mejor que es que, ya que Product Owner puede no saber las finezas de la realización.» Y esto es justo. Sin embargo, en algunos casos del proceso de trabajo, esto puede trabajar. Gracias a este enfoque la preparación misma y la formación del Sprint Backlog pasa considerablemente más rápido.

Enfoque №3 – varios Product Owners и varios Product Backlogs

varios Product Owners и varios Product Backlogs

Hay un enfoque así y algunos lo usan. De verdad, tal enfoque es útil para direcciones algo especificas, cuando se sabe exactamente, cómo se distribuye la elaboración o si consiste de los módulos globales, que se acoplan entre ellos en el último momento.

Scrum Sprint

Scrum Sprint

Tal vez, el elemento más importante de la metodología Scrum es el Sprint.

Sprint Backlog

Sprint Backlog

Product Owner

Product Owner

El Product Owner es un cierto eslabón de enlace entre el cliente y el equipo de la elaboración. La instancia definitiva en la toma de decisiones en el Scrum Team – es justamente Product Owner

Sprint Planning Meeting

Sprint Planning Meeting

Story Points

Story Points

Una de las partes más importantes de la metodología Scrum – la parte Story Points. Esta parte está integrada muy ajustadamente en el Scrum junto con la tecnología de Planning Poker.

Project Manegement
Project Manegement

Tiempo Scrum Time

keyboard_arrow_up