CONTENIDO
UNIDAD TEMÁTICA 1: PRINCIPIOS DE LA GESTIÓN ÁGIL DE PROYECTOS ... 4
1.1. COMPETENCIAS POR DESARROLLAR ................................................ 4
1.2. CONTENIDO ........................................................................................... 4
1.2.1. ¿QUE SON Y PARA QUÉ SIRVEN LAS METODOLOGÍAS AGILES? .. 4
1.2.1.1 Beneficios de la gestión ágil de proyectos. ................................... 5
1.2.1.2 Fases de gestión Ágil de proyectos .............................................. 5
1.2.2. Diferencia entre enfoques de gestión de proyectos tradicional y ágil. ... 6
1.2.3. Introducción Scrum, XP, Kanban, Lean ................................................. 9
Scrum .......................................................................................................... 9
Roles y evento dentro de Scrum .......................................................... 10
Planificaciones del sprint........................................................................ 10
Xtreme programming ............................................................................. 10
Roles XP ................................................................................................... 11
Kanban ...................................................................................................... 12
Los cuatro Principios Kanban................................................................. 13
Principio 1: ............................................................................................. 13
Principio 2: ............................................................................................. 13
Principio 3: ............................................................................................. 13
Principio 4: ............................................................................................. 13
Las seis prácticas de Kanban ................................................................ 13
Tablero Kanban ..................................................................................... 15
Teoría de las restricciones en Kanban ................................................... 15
Lean software ............................................................................................ 16
Las 8 formas de desperdicio .................................................................. 17
Constancia en el aprendizaje ................................................................. 17
1.2.4. Manifiesto Ágil y sus principios. ........................................................... 18
1.2.4.1. Manifiesto Ágil: ............................................................................. 18
1.2.4.2. Principios Ágil:............................................................................ 18
1.2.5. Value Stream Mapping ........................................................................ 19
1.2.5.1 OBJETIVO Y BENEFICIOS DEL VSM........................................... 19
1.2.6 Burn-down Charts ................................................................................ 21
1.2.6.1 ¿Cómo se crea un Burndown chart? → 4 etapas .......................... 21
1.2.6.2 Burndown chart: Scrum ................................................................. 21
1.2.7. Information Radiators. ......................................................................... 24
1.2.7.1 Objetivo de los Information Radiators ............................................ 24
1.3 BIBLIOGRAFÍA...............................................¡Error! Marcador no definido.
UNIDAD TEMÁTICA 1: PRINCIPIOS DE LA GESTIÓN ÁGIL DE
PROYECTOS
1.1. COMPETENCIAS POR DESARROLLAR
-Conocer los alcances y herramientas básicas de la gestión ágil de proyectos
1.2. CONTENIDO
1.2.1. ¿QUE SON Y PARA QUÉ SIRVEN LAS
METODOLOGÍAS AGILES?
La gestión Ágil de proyectos es un enfoque iterativo que se centra en la entrega de
valor frecuente y en obtener retroalimentación rápida del mercado y el cliente para
poder adaptarse mejor a los cambios, un proyecto es considerado Ágil cuando
tienen lugar los siguientes atributos:
• Transparencia
• Enfoque en el cliente
• Adaptabilidad
• Sentimiento de pertenencia (Liderazgo efectivo)
• Mejora continua
La utilidad de este enfoque esta, en que permite establecer una base común
para que los equipos de trabajo puedan desarrollar productos y servicios basados
en conocimiento. En esencia el enfoque ágil, se traduce en implementar
herramientas que permitan tener la capacidad de mantener un flujo hacia
delante de forma rápida y que permita cambios de dirección fáciles.
En este sentido adoptar un enfoque ágil en proyectos, implica seguir valores y
principios dentro de los cuales se encuentran los siguientes:
1. Las personas y la interacción por encima de los procesos y las
herramientas.
2. Software que funciona por encima de documentación extensa.
3. Colaboración con cliente por encima de la negociación del contrato.
4. Responder a los cambios por encima de seguir un plan.
El enfoque ágiles se han utilizado principalmente para el desarrollo de software,
pero en los últimos años, otros sectores y en especial en proyectos de
innovación.
1.2.1.1 Beneficios de la gestión ágil de proyectos.
• Se establecen prioridades flexibles.
• Se empieza a entregar antes.
• Costes y plazos conocidos.
• Mejora la calidad final.
• Mayor transparencia.
1.2.1.2 FASES DE GESTIÓN ÁGIL DE PROYECTOS
En general, la forma en la que funciona la entrega de un proyecto Ágil se puede
resumir en las siguientes fases:
• Visualizar – crea una visión a alto nivel del producto/servicio para el cliente
y determina quién va a participar en el proyecto
• Especular – Esta es una extensión de la fase de Visualización en la que los
equipos recopilan los requisitos generales iniciales para un
producto/servicio y desarrollan de iteración basado en la visión.
• Explorar – trabajar en los entregables con el foco en el flujo, con el objetivo
de obtener feedback del cliente lo antes posible
• Adaptarse – revisar los resultados entregados y adaptarse según sea
necesario a las condiciones actuales
• Cierre – saca las conclusiones del proyecto, trasmite los resultados clave
1.2.2. DIFERENCIA ENTRE ENFOQUES DE GESTIÓN
DE PROYECTOS TRADICIONAL Y ÁGIL.
El enfoque ágil diferencia del enfoque tradicional, se gasta menos tiempo en la
planificación y más flexible en relación a la necesidad de cambios durante la
ejecución del proyecto, a continuación destacamos algunas de las diferencias:
• Más flexibilidad
Cuando se trata de realizar cambios en el producto o en un proceso, la
metodología ágil es mucho más flexible que la metodología de cascada o
tradicional. Este enfoque prioriza más la consecución producto sobre el plan del
de dirección inicial.
• Transparencia
En el enfoque ágil, los grupos de interés y el gobierno del proyecto los que
participan activamente en las fases y procesos de inicio, planificación,
seguimiento y control, a diferencia del enfoque tradicional,
Por otro lado los integrantes tienen acceso a visualizar el desarrollo del proyecto
desde el inicio al cierre.
• Retroalimentación
El enfoque ágil asegura el cumplimiento de los requisitos de los productos clientes
a medida que validan cada iteración,
La tabla a continuación muestra las principales diferencias entre el enfoque de
gestión de proyectos tradicional y ágil.
Diferencia entre el enfoque de gestión de proyectos tradicional y ágil.
Características Enfoque ágil Enfoque tradicional
Estructura organizativa Iterativa Lineal
Escala de proyectos Pequeños y medios Grandes
Requisitos Dinámicos Bien definidos antes de
empezar
Implicación del cliente Alta Baja
Modelo de desarrollo Entrega evolutiva Ciclo de vida
Participación del cliente Los clientes Los clientes se involucran
participan
al principio del proyecto,
desde el momento en que
pero no una vez que la
se empieza a realizar el ejecución ha comenzado.
trabajo.
Gestión de escalado Cuando ocurren problemas, El problema se escala a
los gerentes del proyecto.
todo el equipo trabaja junto
para resolverlo.
Preferencias del modelo El modelo ágil favorece la El modelo tradicional
favorece la anticipación.
adaptación.
Producto o proceso Menos enfoque en los Más enfocados sobre los
procesos que sobre el
procesos formales y
producto.
directivos.
Planificación Se planifica de Sprint en Se planifica todo con gran
detalle.
Sprint.
Estimación del esfuerzo El Scrum Master facilita las El gestor del proyecto
estima y obtiene la
tareas y el equipo hace la
aprobación del propietario
estimación. del proyecto.
Revisiones y Las revisiones se realizan Constantes revisiones y
aprobaciones por parte de
aprobaciones después de cada iteración.
los líderes del proyecto.
Tabla 1 Diferencia entre el enfoque de gestión de proyectos tradicional y ágil
Fuente: Rodelgo 2019
Es importante destacar que no existe en enfoque mejor que otro, para lo cual
se debe identificar cuando están dadas las condiciones para adoptar un
enfoque ágil .
A continuación se presentan algunos aspectos a tener en cuenta para decidir
cuando es mas conveniente aplicar el enfoque ágil a los proyectos.
Cuando los requisitos del proyecto no están claros o tienden a cambiar, se
recomienda elegir el enfoque ágil, caso contrario, el enfoque tradicional se adapta
mejor a una situación donde los requisitos están claramente definidos y bien
entendidos desde el principio.
El enfoque ágil, por ser más flexible que la anterior, permite más espacio para
experimentar con nuevas tecnologías. Por lo tanto si en el proyecto a desarrollar
se quiere adoptar nuevas tecnologías este es mas apropiado
Si el proyecto tiene una alta probabilidad de que se activen riesgos y esto a su
vez son de alto impacto, abordar el enfoque ágil, es una buena alternativa, para
la gestión de riesgos. dado que la naturaleza rígida del enfoque tradicional, no es
recomendable ante un contexto de alta incertidumbre
Finalmente frente a una alta restricción de la disponibilidad de recursos El
enfoque ágil se adapta a equipo en un número limitado de miembros
experimentados del equipo. En contraste a el enfoque tradicional que funciona
mejor con equipos y proyectos grandes y complejos.
1.2.3. INTRODUCCIÓN SCRUM, XP, KANBAN, LEAN
Sin duda dentro de las metodologías agiles más utilizada, son Scrum, XP,
Kanban, Lean por este motivo se realizara una introducción en estas
metodologias, donde se detallara sus características.
SCRUM
Scrum puede utilizarse en el desarrollo de productos y soluciones para cualquier
tipo de industria y en cualquier tipo de proyecto, La clave es, precisamente, que
los equipos Scrum son interfuncionales, autoorganizados y empoderados. Estos
equipos trabajan de forma colaborativa dividiendo las partes del proyecto en ciclos
de trabajo cortos y concentrados llamados sprints.
Principales ventajas del Scrum
Las principales ventajas que la metodología puede aportar a la gestión de
proyecto pueden ser resumidas así:
• Adaptabilidad
• Transparencia
• Mejora y retroalimentaciones continuas
• Ritmo sostenible
• Proceso de desarrollo eficiente
• Motivación • Resolución de problemas de forma rápida
• Centrado en el cliente
• Ambiente de alta confianza
• Responsabilidad colectiva
• Ambiente innovador
ROLES Y EVENTO DENTRO DE SCRUM
- Product owner: Dueño del producto
- Scrum master: Es el coordinador del equipo, controla al equipo para la
consecución de los objetivos.
- Equipo: Desarrolladores del producto.
Hay 4 eventos Scrum principales: Planificación del Sprint - Reunión diaria (Daily) -
Revisión del Sprint - Retrospección del Sprint
PLANIFICACIONES DEL SPRINT
Debe finalizar con un objetivo claro de lo que se va abordar y con el backlog
adecuado, el equipo eligira los ítems que consideran que pueden realizar y los
dividirán entre todos.
- Reunión diaria (10-15 min). Cada componente del equipo comenta que está
realizando, las tareas que ha terminado y si se tiene alguna dificultad.
- Revisión del sprint (1 hora por semana/iteración). Una vez finalizado el sprint se
debe realizar una reunión para comprobar el producto entregado junto con el
cliente. Es el momento de saber que se está construyendo.
- Retrospectiva (1 hora). En esta reunión se deben ver que se puede mejorar
dentro del equipo, aquí se analiza la forma en la que se está trabajando.
XTREME PROGRAMMING
Su impulsor fue Kent Beck, el cual fue uno de los firmantes y de los principales
impulsores del manifiesto ágil. Uno de los primeros métodos de desarrollo de
software ágil , que enfatiza la excelencia de las habilidades de desarrollo sobre la
gestión de proyectos complejos. Su abreviatura XP viene del inglés eXtreme
Programming.
En XP, doce prácticas técnicas basadas en los valores de comunicación,
simplicidad, retroalimentación y coraje estructuran iteraciones breves centradas en
la entrega de productos de alta calidad. El cliente está muy involucrado en la
definición y la priorización de las funcionalidades (tarjetas de historia) que se
desarrollarán, mientras que el pequeño (12 personas o menos) autodirigido y el
equipo de desarrollo estrechamente integrado utilizan pruebas y planificación
continuas, y bucles cortos de retroalimentación para entregar Software a intervalos
muy cortos (1 a 4 semanas).
A continuación se describen unas buenas prácticas a seguir (Kuphal 2011):
1- Las historias suelen ser una serie de tareas, donde cada tarea no debe
superar más de tres días de desarrollo. En caso contrario, se deben dividir
en tareas más pequeñas.
2- Crear tareas que una vez completadas generen un producto entregable, es
decir tareas relacionadas con una misma funcionalidad.
3- No dedicar excesivo tiempo a estudiar todos los detalles de cada tarea. Es
verdad que puede ayudar a realizar una estimación más precisa pero
retrasa el proceso de división de las Historias de Usuario en tareas.
4- En el conjunto de tareas deben estar incluidas las tareas de pruebas y su
posible automatización.
ROLES XP
- Programador. El programador escribe las pruebas unitarias y produce el
código del sistema.
- Cliente. Escribe las historias de usuario y realiza las pruebas funcionales
para validar su implementación. Además, asigna la prioridad a las historias de
usuario y decide cuáles se implementan en cada iteración centrándose en
aportar mayor valor al negocio.
- Encargado de pruebas (Tester). Es el encargado de las pruebas del
proyecto, ayuda al cliente a realizar las pruebas funcionales.
- Encargado de seguimiento (Tracker). Es el encargado de verificar que las
tareas que se realizan van acorde con lo estimado, lleva el control de tiempos
diario. Debe adelantarse a posibles desviaciones imprevistas.
- Entrenador (Coach): Es el máximo responsable del proyecto, es el encargado
de garantizar que el cumplimiento de los hitos se lleva a cabo. - Consultor: Es
un especialista, externo al equipo se puede requerir para solventar cualquier
imprevisto relacionado con su especialidad.
- Gestor (Big boss): Es el coordinador, el enlace entre el equipo de desarrollo y
los clientes, controla de que el equipo trabaje eficazmente creando las condiciones
adecuadas
Al principio de cada iteración se debe establecer, por parte del cliente, las tareas
más prioritarias según las Historias de Usuario disponibles y los errores
producidos en los test de aceptación, todas estas tareas irán al plan de
lanzamiento. Una vez establecidos las prioridades se deben estimar por el
desarrollador cuantos días de programación requieren 1, 2 y 3. Se puede añadir ½
si se requiere, las tareas de menos se pueden agrupar en una sola y las tareas de
más de tres días se deben dividir en tareas más pequeñas. Una vez estimadas, se
dispone del plan de iteración con las tareas a incluir, hay que tener en cuenta que
las iteraciones en XP se aconsejan que sean de 1 a 3 semanas.
KANBAN
Es una palabra Japonesa que literalmente significa “Tarjetas visuales”. Kaban es
un método visual muy recomendado para gestionar proyectos donde los requisitos
cambian constantemente. También es útil en planificaciones y estimaciones de un
equipo se alarguen o dejen de ser productivas así́ como cuando un equipo no se
puede comprometer a trabajar en iteraciones fijas. El método está enfocado en
llevar a cabo las tareas pendientes a través de cuatro principios y seis prácticas.
Los cuatro Principios Kanban
PRINCIPIO 1: Empezar con lo que hace ahora.
Kanban no requiere configuración y puede ser aplicado sobre flujos reales de
trabajo o procesos activos para identificar los problemas.
PRINCIPIO 2: Comprometerse a buscar e implementar cambios incrementales y
evolutivos.
El método Kanban está diseñado para implementarse con una mínima resistencia,
por lo que trata de pequeños y continuos cambios incrementales y evolutivos del
proceso actual.
PRINCIPIO 3: Respetar los procesos, las responsabilidades y los cargos
actuales.
Kanban reconoce que los procesos en curso, los roles, las responsabilidades y los
cargos existentes pueden tener valor y vale la pena conservarlos.
PRINCIPIO 4: Animar el liderazgo en todos los niveles.
Algunos de los mejores liderazgos surgen de actos del día a día de gente que está
al frente de sus equipos. Es importante que todos fomenten una mentalidad de
mejora continua (Kaizen) para alcanzar el rendimiento óptimo a nivel de equipo/
departamento/ empresa. Esto no puede ser una actividad a nivel de dirección.
LAS SEIS PRÁCTICAS DE KANBAN
Existen seis prácticas que deben adoptarse a la hora una implementación Kaban
como método de gestión de proyectos.
• Visualizar el flujo de trabajo
Es necesario comprender la dinámica del flujo de trabajo, para identificar
oportunidades de mejora, para esto se utiliza un tablero con tarjetas y columnas.
• Eliminar las interrupciones
la segunda práctica de Kanban se enfoca en establecer los límites del trabajo en
proceso (los límites WIP). Si no hay límites de trabajo en proceso, no está
haciendo Kanban. Una de las cualidades que tiene Kanban es el WIP (Work In
Progress), esta característica determina cuanto trabajo debe haber como máximo
en proceso. Establecer un número máximo de elementos por etapa asegura que
solo se avanza cuando hay capacidad disponible.
Si se tiene un WIP muy bajo, podría ocasionar que haya miembros del equipo que
no puedan realizar tareas. En cambio si el WIP es muy alto se corre el riesgo de
tener multitareas y de finalizar pocas. Hay una regla por la que se puede empezar
que sería WIP ideal = 2n -1, donde n es el número de miembros del equipo.
• Gestionar el flujo
Se entiende por flujo, el movimiento de elementos de trabajo a través del proceso
de producción. En este sentido se busca que el flujo cuente con la velocidad y la
continuidad del movimiento óptimo.
• Hacer las políticas explícitas (Fomentar la visibilidad)
Se debe garantizar u los equipos involucrados en los procesos conozcan y
comprendan el objetivo común como sus los roles y responsabilidades.
• Circuitos de retroalimentación
Se debe propiciar la transferencia de conocimiento (circuitos de
retroalimentación). Mediante las reuniones para sincronizar el equipo. Utilizando
el tablero Kanban donde los miembros de equipo presentan comparte lo
trabajado y las acciones futuras, estas retroalimentaciones incluyen ejercicios
de revisión de entrega de operaciones y de riesgos.
• Mejorar colaborando
El establecimiento de una visión compartida, facilita a los equipos ,una
comprensión el análisis de un problema y sugerir acciones de mejora que pueden
acordarse por consenso.
TABLERO KANBAN
Como se puede observar el número que figura entre paréntesis, es el número
máximo de tareas para cada fase del proyecto:
Tomado y adaptado de Project Management Institute 2017
TEORÍA DE LAS RESTRICCIONES EN KANBAN
La teoría de las restricciones se basa en que la planta de fabricación será́ tan
rápida como el proceso más lento de la cadena de fabricación. Por lo tanto, la
teoría de las restricciones tiene como finalidad la búsqueda y eliminación de
cuellos de botella.
Se basa en los siguientes puntos:
1- Identificar los cuellos de botella
2- Decidir cómo resolver esos cuellos de botella
3- Subordinar la organización y al sistema para ayudar a resolver la decisión
tomada
4- Solventar el cuello de botella
5- Si en los pasos anteriores se consigue resolver el cuello de botella, regresar
al paso 1.
LEAN SOFTWARE
El siguiente sistema deriva del Sistema de Producción de Toyota, el objetivo
principal del sistema de producción y de la metodología de software es eliminar
todos los desperdicios (waste). Es decir, todo lo que retrase y no sea necesario
para la producción.
Realmente no se podría considerar una metodología por sí misma, son más una
serie de principios que se pueden aplicar dentro de los proyectos agiles, son los
siguientes:
• Ver todo el conjunto
En este sentido, se debe disponer de una visión integral del proyecto para poder
comprobar que puede fallar y donde se debería corregir los problemas.
• Eliminar los desperdicios
El objetivo es encontrar todo aquello que no es necesario para el proyecto y solo
supone más carga de trabajo. Para ello se pone el esfuerzo en distinguir y
reconocer los desperdicios del proyecto, para este trabajo se utiliza la técnica
value stream mapping”. Una vez localizados los desperdicios, el siguiente paso es
eliminarlos. Este proceso se debe repetir iterativamente hasta que lo que parecía
en principio esencial pueda ser eliminado.
LAS 8 FORMAS DE DESPERDICIO
1. Sobreproducción: más producción de la necesaria.
2. Tiempo de espera: pérdida de tiempo por esperar a otro paso del proceso.
3. Transporte: movimiento innecesario de mercancías físicas u objetos
virtuales.
4. Procesamiento innecesario
5. Inventario
6. Movimiento
7. Error.
8. Conocimiento no utilizado
CONSTANCIA EN EL APRENDIZAJE
Se fomenta la interacción entre los equipos de desarrollo de trabajo con el cliente.,
mediante unas reuniones cortas y constantes para comprobar el estado del
proyecto y buscar soluciones conjuntas a los problemas.
• Decidir lo más tarde posible: la intención es retrasar las decisiones cuando
realmente están claras, es decir no es necesario realizar una previsión
temprana de lo que hay que realizar.
• Reaccionar tan rápido como sea posible: Requiere de unas entregas de
funcionalidades acabadas y sin fallos en iteraciones cortas, esto provoca un
mejor aprendizaje y comunicación dentro del equipo.
• Potenciar el equipo: Se debe fomentar la comunicación directa entre los
miembros del equipo y directivos del proyecto
• Crear la integridad: Se trata que de que las diferentes partes por separado
funcionan perfectamente una vez unidos, realizando un proyecto único con
una fuerte integración. Facilitando el desarrollo, el mantenimiento y la
eficiencia.
1.2.4. MANIFIESTO ÁGIL Y SUS PRINCIPIOS.
1.2.4.1. MANIFIESTO ÁGIL:
Este manifiesto surgió en 2001 en una reunión celebrada en SnowBird, Utah. Su
principal impulsor fue Kent Beck. Aunque muchas de las metodologías que se
tratan en este proyecto son anteriores al manifiesto ágil, se puede decir que a
partir de la reunión surgió un movimiento que no ha parado de captar adeptos
tanto individualmente como empresas. Además, se creó la “alianza ágil” cuya
finalidad es promover el desarrollo ágil en los proyectos.
1.2.4.2. PRINCIPIOS ÁGIL:
2. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega
temprana y continua de software con valor.
3. Aceptamos que los requisitos cambien, incluso en etapas tardías del
desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
4. Entregamos software funcional frecuentemente, entre dos semanas y dos
meses, con preferencia al periodo de tiempo más corto posible.
5. Los responsables de negocio y los desarrolladores trabajamos juntos de
forma cotidiana durante todo el proyecto.
6. Los proyectos se desarrollan en torno a individuos motivados. Hay que
darles el entorno y el apoyo que necesitan, y confiarles la ejecución del
trabajo.
7. El método más eficiente y efectivo de comunicar información al equipo de
desarrollo y entre sus miembros es la conversación cara a cara.
8. El software funcionando es la medida principal de progreso.
9. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.
10. La atención continua a la excelencia técnica y al buen diseño mejora la
Agilidad.
11. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado,
es esencial.
12. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-
organizados.
13. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo
para a continuación ajustar y perfeccionar su comportamiento en
consecuencia.
1.2.5. VALUE STREAM MAPPING
El mapa de flujo de valor o Value Stream Mapping (VSM) es un diagrama o mapa
que permite visualizar, analizar y mejorar el flujo dentro de un proceso de
producción. Este flujo hace referencia a los procesos y la información que se
realizan desde el inicio del proceso hasta su entrega al cliente
1.2.5.1 OBJETIVO Y BENEFICIOS DEL VSM
El objetivo principal del value stream mapping es resolver todos los problemas
existentes en el proceso de producción para aumentar la productividad del mismo,
reduciendo o eliminando desperdicios.
Los pasos para la implementación del Mapeo de la cadena de valor son:
1. Selección de un área crítica productiva
2. Preparación del mapa del estado actual:
1. Revisión documentación existente
2. Identificación procesos principales
3. Definir que datos hacen falta y deben recopilarse
4. Recoger la información
3. Análisis del mapa
4. Mapa del estado futuro:
1. Cálculo del Tack Time
2. Establecer tiempo deseado
3. Implementación de herramientas de mejora
Ejemplo Mapeo de la cadena de valor o “Value Stream Mapping” (VSM)
sistema de producción
Tomado de Vilaplana 2017
El tiempo takt, que en alemán significa ritmo o compás, es un concepto utilizado
principalmente en el entorno productivo para referirse al ritmo de salida de los
productos que debe alcanzar una empresa para responder a la demanda del
cliente
1.2.6 BURN-DOWN CHARTS
Un tipo de tabla utilizada en metodologías ágiles para medir la cantidad de trabajo
restante contra el tiempo. En inglés es conocida como Burndown Chart
Un gráfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la
que se está completando los objetivos/requisitos. Permite extrapolar si el Equipo
podrá completar el trabajo en el tiempo estimado.
1.2.6.1 ¿CÓMO SE CREA UN BURNDOWN CHART? → 4
ETAPAS
1. Definir el objetivo. ...
2. Proyectar las tareas. ...
3. Preparar el gráfico. ...
4. Completar y analizar el gráfico.
1.2.6.2 BURNDOWN CHART: SCRUM
El Burndown chart es una herramienta de control del sprint, a menudo utilizada
en el enfoque agil, como Scrum. Sin embargo, puede también aplicarse a
cualquier entorno y para cualquier tipo de proyecto, con el fin de conocer el trabajo
que aún queda por hacer dentro de un plazo determinado.
De esta manera, el Burndown chart es un gráfico que relaciona:
• el tiempo de trabajo necesario para completar un proyecto (estimación de
días u horas necesarios ) → eje horizontal;
• el trabajo que queda por hacer (backlog) → eje vertical.
La relación entre los dos ejes (tiempo y trabajo), permite obtener una perspectiva
del desarrollo ideal del proyecto en un plazo determinado. En otras palabras, el
gráfico Burndown proporciona información sobre la cantidad de trabajo que queda
por "quemar" (de ahí el nombre de Burndown chart) hasta alcanzar el objetivo
fijado.
Asimismo, es una herramienta que da cuenta sobre la dinámica entre el equipo del
proyecto y las partes interesadas. Además, puede proporcionar información sobre
las distintas actividades, a partir de la cual pueden surgir sugerencias de mejora
en diferentes aspectos.
¿Cómo se crea un Burndown chart? → 4 etapas
1. Definir el objetivo: El primer paso para crear un Diagrama Burndown es
identificar un objetivo que quieres alcanzar y proyectar las acciones que será
necesario realizar para asegurar el cumplimiento del mismo.
2. Proyectar las tareas: A su vez, las acciones que has estimado necesarias,
debes subdividirlas en tareas. Gracias a la estimación del esfuerzo que requiere
cada tarea y a la evaluación de las habilidades de cada persona del equipo,
puedes asignar un responsable para cada tarea.
3. Preparar el gráfico: Con la información de partida lista, el siguiente paso
consiste en crear el Burndown chart. Esto significa representar la información a
partir de un gráfico con dos ejes:
• horizontal, que indique el tiempo (días, horas, etc.),
• vertical, que indique el esfuerzo restante (puntos de historia o story points).
Puesto que lo que se está realizando es un seguimiento del trabajo pendiente por
completar, la progresión del tiempo debe tomar necesariamente un valor distinto
de cero. Por lo tanto, se supone que la curva del gráfico desciende a medida que
avanza el proyecto.
4. Completar y analizar el gráfico: Para completar el gráfico, se dibuja la línea
del backlog. En su implementación más básica, el Gráfico de Burndown muestra
sólo la línea de backlog ideal. Esta línea muestra la estimación teórica del tiempo
ideal dentro del cual se desarrollarán las actividades.
Sin embargo, existen otras dos líneas posibles:
• Línea real del sprint, la cual permite visualizar también el curso verdadero
que se está siguiendo. Esta deberá modificarse diariamente en función del
progreso real del trabajo del equipo.
• Línea de tendencia, la cual resulta de unificar la línea ideal con la línea real
del sprint.
Fuente: Aguirre, 2021
1.2.7. INFORMATION RADIATORS.
Un Information Radiator (radiador de información) es un gran gráfico visual
colocado en un lugar destacado. Transmite información clave y muestra el
desempeño de un equipo. Se utiliza para visualizar el flujo de trabajo, muestra
dónde ocurren los cuellos de botella y permite que cualquiera pueda ver en qué
está trabajando el equipo en cualquier momento.
Un Information Radiator son murales , donde generalmente se utilizan formatos
como tableros o , post-it, que permitan modificar información de modificar por el
equipo y están ubicados en lugares y cerca de los equipos de trabajo
involucrados.
1.2.7.1 OBJETIVO DE LOS INFORMATION RADIATORS
En términos generales, el objetivo de este herramienta, es irradiar información,
sin embargo, esta puede tener varios objetivos específicos como:
• Facilitar la focalización en el trabajo
• Promover la transparencia
• Proporcionar la información necesaria y disponible.
• Promover la gestión colaborativa,
La efectividad de esta herramienta se incrementa en la medida que contenga
los siguientes atributos:
• información actualizada: los Information Radiators deben suministra
información actualizada y su estado de ejecución.
• información valiosa: Deben contener poca información, pero de alto valor
para las partes interesadas.
• Ubicación estrategica: debería tener un espacio que permita una reunión
de pie (Stand-Up meeting) y una ubcación doinxe se estimwe alto transito
del publico objetivo.
• El tamaño importa: Debe tener un tamaño que debe facilite poder leerse
desde lo más lejos posible
1.3 BIBLIOGRAFÍA
Guía práctica de Ágil, Project Management Institute 2017
Vilaplana Maria 2017 en https://www.proyectainnovacion.com/mapeo-la-cadena-
valor-value-stream-mapping-vsm/
Aguirre, María Fernanda ¿cómo hacer un seguimiento eficaz del avance de tu
proyecto?2019 en:
https://www.appvizer.es/revista/organizacionplanificacion/gestionproyectos/burndo
wn-chart
