Burn Down Chart

BS GRUPO GRUPO 2 BURN DOWN CHART CURSO : ALUMNO : DOCENTE : GESTION DE PROYECTOS FRANCISCO EZEQUIEL REID MELO PE

Views 226 Downloads 0 File size 602KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

BS GRUPO GRUPO 2 BURN DOWN CHART

CURSO

:

ALUMNO

:

DOCENTE

:

GESTION DE PROYECTOS

FRANCISCO EZEQUIEL REID MELO PEDRO MIGUEL ZAVALA VINCES MIGUEL ANGEL TORIBIO HUARINGA LUIS ANGEL CUMPA PEÑA ING. DAVID CHIGNE, PMP

Lima, octubre del 2018

Burn down chart ¿Qué es? Un diagrama burn down o diagrama de quemado es una representación gráfica del trabajo por hacer en un proyecto en el tiempo. Usualmente el trabajo remanente (o backlog) se muestra en el eje vertical y el tiempo en el eje horizontal. Es decir, el diagrama representa una serie temporal del trabajo pendiente. Este diagrama es útil para predecir cuándo se completará todo el trabajo. Usualmente se usa en el desarrollo ágil de software, especialmente con Scrum. Sin embargo, este tipo de diagrama ha ido perdiendo importancia dentro de La Guía Oficial de Scrum desde las versiones de 2013 y 2016 El progreso de un proyecto Scrum puede ser medido por un release burndown chart. El ScrumMaster debe actualizar este gráfico al finalizar cada sprint. El eje horizontal del burndown chart muestra los sprints; el eje vertical muestra la cantidad de trabajo pendiente por realizar al inicio de cada sprint. Este trabajo restante se puede expresar en la unidad que el equipo prefiera -- story points (puntos de historia), ideal days (días ideales), team days (días de equipo) u otra unidad. En el burndown chart mostrado, el equipo inicia con un proyecto que fue planeado para 6 sprints. Ellos iniciaron con 360 story points de trabajo. Para finalizar en 6 sprints, ellos planificaron realizar 60 puntos por sprint. El primer sprint fue bueno y completaron 90, dejando 270. Las cosas continuaron bien durante el segundo sprint, pero durante el tercer sprint, el trabajo restante estimado ardió (aumentó, burned up). Esto podría haber sido porque se añadió trabajo al proyecto o porque el equipo cambió las estimaciones del trabajo restante. Después de eso, las cosas han ido bien otra vez. Este tipo de gráfica realmente ayuda en muchas situaciones y a muchos equipos. Sin embargo, en proyectos con un montón de requerimientos cambiantes, tal vez quieras ver una alternativa de release burndown chart a fin de mantener siempre la agilidad de tu proyecto. El burndown chart (gráfico de quemado) es una parte esencial de todo proyecto ágil y es una forma clara de mostrar al equipo qué está pasando y cómo se están realizando los avances en cada sprint. También conocido como A veces se encuentra el término "gráfico de quemaduras", posiblemente como una generalización que cubre variantes tales como el "gráfico de quemado". Beneficios esperados Esta práctica da como resultado que el estado del proyecto actualizado no solo sea visible, sino que de hecho se muestre en las caras de todos los involucrados: como resultado, alienta al equipo a enfrentar cualquier dificultad más pronto y de manera más decisiva. (El corolario es que la efectividad del cuadro depende de que sea lo suficientemente grande y esté situado en algún lugar que no puede evitar provocar discusión, una hoja A4 en un corredor alejado o en el fondo de un cajón no constituye

una implementación adecuada). de los gráficos burndown, que se pueden crear sobre la base del historial de velocidad solo, es otro factor de su efectividad. Errores comunes Los gráficos de Burndown solo muestran el número de puntos de historia completados, no indican ningún cambio en el alcance del trabajo, medido por el total de puntos en la acumulación. Como resultado, es difícil saber si los cambios en el gráfico de quemados se pueden atribuir a los elementos atrasados completados, o simplemente y aumentar (o mucho menos probable) una disminución en los puntos de la historia. El gráfico de grabación resuelve este problema al mostrar una línea separada para el tamaño de la acumulación total. Ni el diagrama de consumo ni el de agotamiento proporcionan ninguna indicación de qué elementos del registro de pedidos del producto se han completado. Esto significa que un equipo puede tener un cuadro de comparación que muestra el progreso continuo, pero no indica si el equipo está trabajando en las cosas correctas. Por esta razón, los gráficos de quemados y quemados solo pueden proporcionar una indicación de las tendencias en lugar de dar una indicación explícita de si un equipo está entregando los elementos correctos de los productos pendientes. Orígenes Los gráficos de Burndown parecen ser completamente originales para la comunidad de Scrum; el término no parece tener un uso anterior en ningún otro lugar en relación con la gestión del proyecto de software u otros esfuerzos. 2000: la tabla de burndown es descrita por primera vez por Ken Schwaber, quien la inventa mientras trabaja en Fidelity Investments en un intento de proporcionar a los equipos de Scrum un kit de herramientas simple; lo describe formalmente en su sitio web 2002: el burndown gana popularidad entre la comunidad de Scrum, así como alternativas como el "quemado" que simplemente invierte la dirección vertical, o el más sofisticado " Diagrama de Flujo Acumulativo ", que se asemeja más a un quemado, pero parece ser independiente invención Los 8 componentes de Burndown Charts En primer lugar, los gráficos burndown muestran la relación entre el tiempo (más comúnmente se muestra en el eje y) y la cantidad de trabajo restante para completar o finalizar un proyecto (comúnmente a lo largo del eje x).

1. Tiempo (eje horizontal) El tiempo a menudo se representa con días desde que comenzó el proyecto, pero a veces en el tiempo de desarrollo ágil es el número de sprints (con un tiempo de sprint determinado). Por ejemplo, el gráfico podría leer 21 días o tres sprints de 7 días. Los gráficos de Burndown pueden abarcar todo el proyecto, un gráfico de desarrollo del proyecto o un solo sprint. 2. Trabajo a la izquierda para completar (eje vertical) El trabajo que queda para completar un proyecto es la suma de las estimaciones de tareas. Para estimar el tiempo de las tareas en Desarrollo Ágil, consulte nuestro artículo sobre el uso de la Secuencia de Fibonacci. La estimación del trabajo que queda por completar puede ser a tiempo o puntos de historia. Además, incorporado en la tabla es un punto de inicio y final.

3. Punto de inicio (trabajo estimado)

El punto de inicio de un proyecto es el número total de tareas en el proyecto. Por ejemplo, este proyecto comenzó con 42 días de tareas estimadas. 4. Punto de finalización (tiempo estimado) El punto final de un proyecto es cuando calcula que habrá terminado todas las tareas según la cantidad de tareas, el número de miembros del equipo y un factor de eficiencia estimado. Por ejemplo, supongamos que, durante los 42 días de trabajo estimados, usted tiene 3 Diseñadores de Instrucción con los que espera trabajar con una eficiencia de aproximadamente el 70%. Por lo tanto, espera que el trabajo se complete en (42 ÷ 3) ÷ 0.7 = 20 días. La siguiente parte importante de los gráficos burndown son las líneas. Los gráficos Burndown tienen dos líneas: tareas estimadas restantes y tareas reales restantes.

5. Tareas estimadas restantes Esta es una línea recta desde el comienzo de la suma de todas las tareas hasta la finalización proyectada del proyecto. Esta línea es solo un cálculo matemático de las tareas promedio necesarias por día para completar a tiempo, no exactamente lo que espera que ocurra. Su equipo llevará inevitablemente más tiempo para completar algunas tareas y menos tiempo para completar otras. El ejemplo anterior muestra que se espera que 42 puntos de tareas al comienzo del proyecto tarden 20 días, para un promedio de 2.1 por día. 6. Tareas reales restantes Esta línea es el trabajo real que queda en cada punto en el tiempo a lo largo del proyecto. Esta línea es sobre lo que deben actualizarse sus equipos (diariamente) para comprender su progreso en comparación con las estimaciones. Por ejemplo, digamos que un día su equipo termina 2.6 días de trabajo estimado, y al día siguiente completa 1.5 días de trabajo. Durante esos 2 días, han completado 4.1 días de trabajo, y están esencialmente en curso con las estimaciones. Esta es una parte importante de la lectura de los gráficos burndown. Así es como puedes medir el rendimiento.

7. Adelante del horario Cuando la línea de trabajo finalizada está por debajo de lo estimado, su equipo ha completado más trabajo de lo estimado y está por delante de lo programado. 8. Detrás del horario Por el contrario, cuando la línea completa de trabajo real está por encima de lo estimado, su equipo ha completado menos trabajo de lo estimado y está retrasado. Sin embargo, recuerde de la Guía Ágil y nuestro artículo sobre la estimación utilizando la secuencia de Fibonacci, las estimaciones de propósito en Desarrollo Ágil es dar una estimación amplia para fines de planificación. Si su equipo no cumple con su cronograma, debe volver y observar la precisión de sus estimaciones en comparación con el tiempo que debe completar. Aquí es donde puede mejorar sus estimaciones a través de comentarios. Si su equipo está constantemente debajo o sobreestimando cierto tipo de tarea, ajuste sus estimaciones para que coincidan mejor con el tiempo real que debe completar.

Lectura de los gráficos de quemado

Un gráfico de proyecto quemado

A continuación, se muestra un gráfico de reducción de una iteración completa y se puede leer conociendo lo siguiente: X-Axis Eje Y

Proyecto Start Point Project End Point Número de trabajadores y factor de eficiencia Ideal trabajo restante línea

Línea de trabajo real restante

La línea de tiempo del proyecto / iteración El trabajo que debe completarse para el proyecto. El tiempo o puntos de la historia estimados para el trabajo restante serán representados por este eje. Este es el punto más alejado a la izquierda del gráfico y ocurre en el día 0 del proyecto / iteración. Este es el punto que está más alejado a la derecha del gráfico y ocurre en el último día predicho del proyecto / iteración En el ejemplo anterior, se calcula que hay 28 días de trabajo por hacer, y hay dos desarrolladores trabajando en el proyecto, que trabajan con una eficiencia del 70%. Por lo tanto, el trabajo debe completarse en (28 ÷ 2) ÷ 0.7 = 20 días. Esta es una línea recta que conecta el punto de inicio con el punto final. En el punto de inicio, la línea ideal muestra la suma de las estimaciones para todas las tareas (trabajo) que deben completarse. En el punto final, la línea ideal intercepta el eje x que muestra que no queda trabajo por completar. Algunas personas se molestan en llamar a esto una línea "ideal", ya que generalmente no es cierto que el objetivo es seguir esta línea. Esta línea es un cálculo matemático basado en estimaciones, y es más probable que las estimaciones sean erróneas que el trabajo. El objetivo de una tabla de reducción de emisiones es mostrar el progreso hacia la finalización y proporcionar una estimación de la probabilidad de que se complete a tiempo. Esto muestra el trabajo real restante. En el punto inicial, el trabajo real restante es el mismo que el trabajo ideal restante, pero a medida que pasa el tiempo, la línea de trabajo real fluctúa por encima y por debajo de la línea ideal, dependiendo de la disparidad entre las estimaciones y de la eficacia del equipo. En general, se agrega un nuevo punto a esta línea cada día del proyecto. Cada día, la suma de las estimaciones de puntos de tiempo o historia para el trabajo que se completó recientemente se resta del último punto de la línea para determinar el siguiente punto.

Medición del rendimiento La línea de trabajo real está por encima de la línea de trabajo ideal La línea de trabajo real está debajo de la línea de trabajo ideal

Si la línea de trabajo real está por encima de la línea de trabajo ideal, significa que queda más trabajo del previsto originalmente y el proyecto está retrasado. Si la línea de trabajo real está por debajo de la línea de trabajo ideal, significa que queda menos trabajo de lo que se había predicho originalmente y el proyecto está adelantado a lo programado.

La tabla anterior es solo una forma de interpretar la forma del gráfico de reducción. Hay otros. Eliminando la variabilidad en las estimaciones de tiempo

Un problema que puede observarse en los gráficos de reducción de consumo es que el hecho de que la línea de trabajo real esté o no por encima o por debajo de la línea de trabajo ideal depende de qué tan precisas sean las estimaciones de tiempo originales. Esto significa que, si un equipo constantemente sobreestima los requisitos de tiempo, el progreso siempre aparecerá antes de lo previsto. Si subestiman constantemente los requisitos de tiempo, siempre aparecerán con retraso. Este problema se corrige al incorporar un factor de eficiencia en el gráfico de reducción de consumo. Después de la primera iteración de un proyecto, el factor de eficiencia se puede volver a calcular para permitir estimaciones más precisas durante la siguiente iteración. Algunas plantillas calculan automáticamente la eficacia a medida que progresa un proyecto. Esto se puede utilizar para identificar áreas / fases en las que se producen estimaciones inexactas de manera consistente.

Ejemplo. Un ejemplo de un diagrama burn down para una iteración completa, que muestra la serie temporal del esfuerzo y tareas restantes para cada uno de los 21 días hábiles de una iteración de un mes.