- Los Artefactos en SCRUM representan trabajo o valor añadido que aportan transparencia y oportunidades para la revisión y adaptación. Los Artefactos están diseñados específicamente para facilitar la transparencia de la información clave y unificar los criterios de compresión de dicho artefacto.
- Las decisiones para optimizar el valor y controlar el riesgo se toman basadas en el estado percibido de los artefactos. En la medida en que la transparencia sea completa, estas decisiones tienes unas bases sólidas.
- Las Story Cards (tarjetas de historias) son artefactos utilizados en un proceso de desarrollo ágil de software para especificar las capacidades del sistema automatizado que se desean por la comunidad empresarial.
- Están diseñados para ser fácilmente comprensible para cualquier miembro de la comunidad empresarial, sin embargo debe contener información suficiente para que el desarrollador de software pueda estimar el esfuerzo de trabajo e identificar los riesgos de entrega
- La Story Card se somete a una priorización conjunta con el dueño del producto y el desarrollador de software, para que se asigne a cada Story Card un plan de liberación para el suministro de software.
- Se deriva de las necesidades de la comunidad empresarial
- Tiene un título que sea fácilmente comprensible para la comunidad empresarial
- Contiene el nombre del actor que utilizará el componente de negocio resultante
- Un Story boards es un organizador gráfico que proporciona al espectador con una visión de alto nivel de un proyecto.
- En el desarrollo ágil de software, un Story boards puede ayudar a los desarrolladores a obtener rápidamente una idea del trabajo que aún queda por completar. Mientras el equipo mantiene el story board actualizado hasta la fecha, cualquiera puede ver lo que se ha completado del trabajo, lo que se está trabajando y lo que queda por hacer.
- Esto no sólo proporciona información al propietario del producto, sino que también ayuda al equipo a visualizar la secuencia y la interconexión de las historias de usuario.
- Una historia de usuario es una representación de un requisito de software escrito en una o dos frases utilizando el lenguaje común del usuario.
- Las historias de usuario son utilizadas en las metodologías de desarrollo ágiles para la especificación de requisitos (acompañadas de las discusiones con los usuarios y las pruebas de validación).
- Cada historia de usuario debe ser limitada, ésta debería poderse escribir sobre una nota adhesiva pequeña.
Cada fila en el tablero Scrum es una historia de usuario. Durante la reunión de planificación del sprint, el equipo selecciona los elementos del product backlog (cartera del producto) en este caso del producto que pueden completar durante el próximo sprint.
Cada columna representa un estado y las tareas de cada historia de usuario se arrastran a una nueva columna cuando el estado de estas cambia.
- Tiene una parrilla con 4 columnas. En la primera columna se colocan las Historias de Usuario (HU) y las otras 3 contienen el estado en que se encuentran las tareas relacionadas de cada HU: Por Empezar, En Proceso y Hecho.
Sólo tiene las Historias de Usuario que el equipo se ha comprometido a entregar en el Sprint en curso
- Las Historias de Usuario están ordenadas de arriba a abajo por orden de prioridad: cuanto más arriba, más prioritario
- Las tareas tienen un distintivo, por ejemplo una pegatina de color, que indica quién está trabajando sobre cada tarea.
- Contiene el Burndown Chart (gráfico con la estimación de horas pendientes del Sprint)
Es una representación grafica que muestra a lo largo del tiempo la velocidad a la que se está completando los objetivos/requisitos. Permite extrapolar si el Equipo podrá completar el trabajo en el tiempo estimado.
Se pueden utilizar los siguientes Burndown Chart
Product Burndown Chart (Product Backlog)
Sprint Burndown Chart(Iteration Backlog)
- Es un camino a la finalización de un proyecto, que nos permite llevar la gestión visual de un proyecto.
- En su forma más simple se compone de dos líneas en el gráfico, una representa el trabajo que se debe completar y la otra representa el trabajo que se ha realizado hasta el momento.
- El eje vertical es el cantidad de trabajo, cuya medida es propia de cada proyecto (algunas medidas son varias tareas, horas estimadas puntos de la historia).
- El eje horizontal se coloca el tiempo normalmente medido en días.
- Burn up chart nos permite ver el alcance del proyecto, cuanto nos falta para las fechas de entregas (deadlines) y nos permite ver el valor ganado en el proyecto además que permite la adhesión de más trabajo a realizar.
- aunque algunas veces se incluye una tercera línea la cual representa el ideal de trabajo, es decir que representa la media de trabajo para que el equipo trabaje de manera sostenida a lo largo del proyecto.
- Principalmente usamos el burn-up chart para ayudar al equipo a encontrar un ritmo sostenible de trabajo a lo largo del proyecto.
- Además, cuando la velocidad de éste se estabiliza, podemos hacer un cálculo de cuándo podría acabarse el proyecto.
- Simplemente hay que proyectar la línea de software entregado y calcular dónde se corta con nuestra estimación del product backlog.
- Mostramos en el eje horizontal la duración del proyecto, medido en sprints (todos de la misma duración), y los puntos en los que hemos estimado las historias de nuestro product backlog en el eje vertical.
- Vamos trazando, iteración tras iteración, una línea que irá uniendo los puntos entregados. De manera acumulada, puesto que estamos representando la cantidad de software con valor que hemos entregado hasta ese momento.
- Por tanto, la pendiente de esta gráfica se corresponde con la velocidad a la que estamos consumiendo (“quemando”) el backlog, de ahí el nombre de “burn-up chart”.
- El tamaño del backlog se obtiene como una estimación temprana que habrá que actualizar, de ahí que en la imagen a continuación lo veamos como una línea (gris) que también se actualiza.
Un burn down chart muestra la cantidad de trabajo que está quedando por hacer en el proyecto, mientras que un burn up chart muestra tanto cantidad de trabajo que se ha completado como la cantidad total de trabajo que se debe completar.
Desafortunadamente burn up chart es más complejo que su contraparte burn down chart, dado que la información extra que muestra requiere una mayor explicación especialmente con personas que no están familiarizada con el tema.
En esta lección, debe haber aprendido a:
Identificar los artefactos descritos.
- Analizar el estado del proyecto.
- Interpretar la información de los artefactos.
- Llevar un seguimiento del proyecto.
Realice un ejemplo de Story card en base al patrón o plantilla establecida.
Dibuje la estructura básica del Story boards.
Explique para que sirve el Burn Up Chart.
Artefactos de Scrum
¿Cómo crear un Burn down Chart?
- Crear una lista de tareas.
- Asignarle un tiempo a cada tarea.
- Graficar el Burndown Chart ideal.
Burn Down Chart
¿CÓMO DEBE SER UN STORY BOARD?
Story Board
¿Cómo actualizar el Burn down Chart?
Cada miembro toma tareas del desglose y trabaja en ellas al final del día, se tiene que actualizar el esfuerzo pendiente para la tarea y también su estado.
Story Boards
Interpretar el Burn down Chart
¿Qué es un artefacto SCRUM?
Resumen
Practica
Burn Up Chart
Story Cards
Burn Up Chart vs Burn Down Chart
¿Cómo hacer un Burn up Chart?
Características
Otras Tecnicas
¿Que es Burn Up Chart?
Objetivos
¿PARA QUE SIRVE?
Redacción de una
Story Card
- Seguimiento del progreso del Sprint.
Después de finalizar esta lección, usted debería ser capaz de:
- Diferenciar los artefactos de SCRUM.
- Interpretar la información grafica que aportan los artefactos.
- Conocer la structura básica de la Story Card, Story boards , burn down chart y burn up down.