Traducido del inglés al español - www.onlinedoctranslator.com
RECUPERACIÓN DE PROYECTOS
¡Por qué fallar temprano en ágil es algo bueno! Un caso de estudio
de la mutua de Omaha
Abstracto
Entonces, ¿qué diría si le dijéramos que una vista ágil del estado del proyecto sería que todos
los proyectos comienzan en ROJO y tienen que llegar al estado VERDE? ¿Preferiría responder al
estado ROJO antes o cuando sea demasiado tarde? Fallar temprano le brinda a usted
(patrocinador, gerente de proyecto o equipo) la oportunidad de recuperarse y ver fallas
ocultas o pequeñas y resolverlas rápidamente. El marco de desarrollo ágil brinda
oportunidades diarias para ver posibles fallas pequeñas y resolverlas antes de que se
conviertan en GRANDES fallas. La primera parte del documento establece el conocimiento
fundamental del desarrollo ágil y los procesos, artefactos y reuniones clave. La segunda parte
trata sobre los grandes y pequeños fallos que se pueden encontrar en un proyecto. La tercera
parte proporciona ejemplos de trabajo real de fallas exitosas usando desarrollo ágil.
Introducción
Según una encuesta de VitalSmarts (2007) publicada en su estudio Silence Kills, se encontraron algunas
estadísticas alarmantes sobre la tasa de fracaso de los proyectos en las principales iniciativas
corporativas. Aquí hay un resumen:
•
El 82% de los empleados dentro de las empresas con importantes iniciativas en marcha en toda
la organización, cree que esos proyectos fracasarán.
•
El 78% está trabajando actualmente en un proyecto "condenado".
•
El 90% sabía desde el principio que el proyecto probablemente no alcanzaría los objetivos.
•
El 77% describe estos proyectos como "choques de trenes en cámara lenta".
•
El 81% cree que es imposible acercarse a la persona clave en la toma de decisiones del proyecto fallido.
El estudio identificó cinco áreas cruciales que son las barreras más costosas para el éxito del proyecto.
1. Planificación sin hechos. Los plazos y los límites de los recursos se establecen sin tener en cuenta la
realidad.
2. Patrocinadores AWOL. Los patrocinadores no participan y no brindan liderazgo, influencia, tiempo o
energía para llevar a cabo el proyecto.
3. Rodapié. La gente trabaja alrededor del proceso de establecimiento de prioridades.
1
RECUPERACIÓN DE PROYECTOS
4. Pollos. Los líderes de equipo y los miembros no admiten cuando hay problemas,
esperando que alguien más hable.
5. Fracasos del equipo. Miembros del equipo que no quieren o no pueden apoyar el proyecto. Posiblemente falta
de empoderamiento.
Marco de desarrollo ágil
Parte 1: ¿Qué es Agile?
Agile se refiere a un conjunto devaloresyprincipiosque rigen un estilo de desarrollo de
software que fomenta el desarrollo iterativo, colaborativo y centrado en los resultados. Agile
es el paraguas de varios métodos populares comoMelé,PEy otros.
Los valores y principios ágiles clave descritos en el Manifiesto Ágil (2001) (www.AgileManifiesto.org
) enfatizan la necesidad de una alta colaboración del cliente durante la planificación y ejecución del
proyecto, alto grado de interacción dentro del equipo y retroalimentación continua, medición
frecuente y temprana del software en funcionamiento (u otro entregable) y capacidadarecalibre
rápidamente y responda a los cambios en el terreno. Estos valores abordan las cinco áreas
cruciales de fracaso del proyecto mencionadas anteriormente.
Seguimos el ciclo de vida ágil que se muestra en el Anexo 1, que enfatiza la necesidad de las actividades de
planificación de lanzamiento e iteración 0 además de los sprints/iteraciones comunes para la mayoría de los
proyectos más grandes.
Anexo 1. Ciclo de vida de desarrollo de software ágil
2
RECUPERACIÓN DE PROYECTOS
Nuevas habilidades necesarias para que Agile tenga éxito
La transición al Desarrollo Ágil no es tan simple como parece; por el contrario, hay muchos puntos de
falla relacionados con la adopción incorrecta de procesos, la base del equipo y las habilidades de
liderazgo necesarias para que Agile tenga éxito.
Como gerente de proyecto, las nuevas habilidades clave que necesitará aprender son:
- Liderazgo de servicio: liderar equipos empoderados de alto rendimiento sin mandarlos
ni controlarlos
- Facilitación efectiva: deberá aprender cómo lograr que los grupos lleguen a un consenso de manera
efectiva.
- Procesos Agile, Scrum, XP: necesita aprender métodos del mundo real para aplicar prácticas
sólidas de ingeniería y gestión de proyectos a sus proyectos.
- Planificación de lanzamiento ágil: deberá aprender a recopilar requisitos, dimensionar, priorizar y
desarrollar de manera efectiva un cronograma de alto nivel para proyectos de tipo ágil
Parte 2: ¿Cómo se ve el fracaso del proyecto?
Grandes señales de falla
Estos son fáciles de hacer una lluvia de ideas. Son los que aparecen demasiado tarde en el juego y hacen que el
proyecto entre en estado ROJO (según nuestras medidas, ¡este proyecto debería haber estado en ROJO durante un
tiempo!).
•
El proyecto ha perdido varios hitos
•
El proyecto ahora está por encima del presupuesto
•
El cliente muestra signos de insatisfacción con los entregables finales
•
Los empleados y el personal están quemados
•
Los gerentes de proyecto luchan por consolar al patrocinador y recuperar la confianza
•
Perder la fecha o reducir los entregables prometidos se vuelve inevitable
Pequeños fracasos que conducen a los grandes
No siempre vemos o buscamos pequeños fracasos porque, como gerentes de proyectos, estamos muy concentrados
en los grandes fracasos. Al fin y al cabo, los grandes fracasos son los que pueden poner en riesgo nuestros proyectos.
Pequeñas fallas ocurren todos los días y tienen una forma de agravarse si no se abordan. En
3
RECUPERACIÓN DE PROYECTOS
De hecho, los pequeños fracasos son los que llevan a los grandes fracasos. Al ver las fallas temprano, podemos
mitigarlas y evitar fallas. Aquí hay algunas pequeñas fallas que, si no se abordan, pueden convertirse en
grandes fallas.
•
El proyecto no cuenta con las personas adecuadas.
• Las habilidades adecuadas
• El número correcto de personas
• La disponibilidad adecuada de personas
• Negocios y tecnología de la información: la combinación correcta de roles multifuncionales
•
fallas tecnológicas
• Nuevo software que no se probó o no se probó antes
• Hardware que llega demasiado tarde o no cumple con los requisitos básicos
• Problemas de integración con sistemas internos o externos que no se planificaron
antes ni se probaron
• No hay una acumulación clara y acordada de requisitos no funcionales, lo que lleva a un
trabajo de back-end fuera del alcance
•
fracasos de entrenamiento
• No hay capacitación inicial sobre la tecnología requerida. El equipo "lo resuelve a medida que
avanzamos".
• Liderazgo. Sin compromiso de liderazgo ni capacitación sobre Liderazgo Ágil y de Servicio.
Los líderes continúan al mando y control del equipo, lo que lleva a ocultar información y
problemas que podrían identificarse temprano.
• Negocio. Los socios comerciales no están capacitados sobre cómo y por qué colaborar con TI.
No se involucran, no brindan orientación sobre las prioridades, no responden a las preguntas
rápidamente, no prueban de manera iterativa y continua ni brindan comentarios sobre los
entregables.
• Entrenamiento. El método de adopción "Podemos aprender y hacer esto solos" sin
entrenamiento experto.
•
Fallas de proceso
4
RECUPERACIÓN DE PROYECTOS
• No hay reuniones diarias de pie para ayudar a identificar impedimentos temprano y mitigarlos.
• Sin retroalimentación/sesiones retrospectivas recurrentes que permitan al equipo señalar
puntos clave de falla o inquietudes.
•
Calendario—Fecha límite estricta
•
Presupuesto—No hay suficiente dinero para cubrir la finalización del proyecto
Parte 3: ¿Qué es un fracaso exitoso?
# 1 Estudio de caso temprano fallido: recursos ausentes
El estudio de caso n.° 1 fue un proyecto de almacenamiento de datos para Financial Business
Partners. El equipo central tuvo éxito en el Sprint 0 al diseñar e instalar el hardware y el
software necesarios para el proyecto. Sprint 1 estaba construyendo las estructuras de tablas
físicas para los datos financieros. El administrador de la base de datos (DBA) generalmente
estaba ausente de las reuniones diarias requeridas y su trabajo no se completaba...
IMPEDIMENTO. ScrumMaster abordó el problema con el patrocinador y el gerente de DBA y
ofreció varias alternativas. El gerente de DBA seleccionó venir a las reuniones diarias con el
DBA y terminó gustando las comunicaciones y colaboraciones diarias. El gerente también
realineó el trabajo para permitir que el DBA se dedique al proyecto de almacenamiento de
datos. El equipo podría perder meses de tiempo esperando que se generen las tablas,
# 2 Estudio de caso temprano fallido: nuevo software
El Estudio de Caso #2 fue un proyecto de portal para Recursos Humanos. El equipo recibió capacitación
básica sobre el nuevo software del portal. En Sprint 0, el equipo instaló con éxito todo el nuevo hardware
y software para el proyecto. Los diseños se completaron y el equipo estaba listo para comenzar a
codificar en Sprint 1. Después de una semana, el equipo estaba atrasado en cada historia de
codificación. El proyecto tendría al menos seis meses de retraso en su entrega. Un miembro del equipo
declaró en las reuniones diarias que la codificación era más difícil de lo previsto y que la capacitación era
demasiado básica... IMPEDIMENTO. ScrumMaster abordó el problema con el patrocinador y el director
de tecnología y lo resolvió en 24 horas. La capacitación no fue adecuada para la complejidad del
proyecto; traje a un experto durante 30 días para entrenar al equipo y se puso al día con el cronograma.
Colaboró con el cliente para una fecha de entrega realista, un mes después.
# 3 Estudio de caso inicial fallido—Presupuesto establecido
El estudio de caso n.° 3 fue un proyecto de inteligencia comercial que generó cientos de informes,
gráficos, tendencias y análisis financieros complejos. Los requisitos del patrocinador comercial incluían
cientos de informes. Se creó una cartera de productos para documentar todos los requisitos como
5
RECUPERACIÓN DE PROYECTOS
características y luego historias. El patrocinador asignó una prioridad a cada historia. El patrocinador,
ScrumMaster y el equipo crearon el plan de lanzamiento para todas las historias. Rápidamente el
patrocinador se dio cuenta de que no tenía suficiente presupuesto para el proyecto. El presupuesto
actual no permitiría completar todos los pisos; por lo tanto, solo se programó la entrega de las
prioridades de alto nivel. Al final del proyecto, el patrocinador ya no requería que se entregaran 90
historias. Fueron identificados como de alta prioridad al inicio del proyecto; pero la prioridad comercial
cambió y el proyecto podría cambiar fácilmente con ella. Esto le ahorró al proyecto ~$500,000 al no
implementar requisitos de baja prioridad o que ya no son necesarios.
# 4 Estudio de caso inicial fallido—Proyectos grandes
El estudio de caso n.º 4 era un gran proyecto de toda la empresa que se había intentado
dos veces antes... y fracasó. Este tercer enfoque utilizaba una metodología de desarrollo
ágil. Los requisitos se documentaron en la cartera de productos. El equipo central recibió
capacitación en desarrollo ágil y se ubicó junto con sus socios comerciales. El equipo
adaptó rápidamente las técnicas ágiles y siguió adelante en cada sprint. La colaboración
fue muy alta y los impedimentos se identificaron pronto y se resolvieron. Los resultados:
los desarrolladores trabajaron con la empresa para colaborar en el diseño; por lo que se
mejoró la comunicación con documentos de diseño mínimos. Los desarrolladores
trabajaron con la empresa para realizar pruebas y poder resolver los defectos en el acto;
evitar el retrabajo y minimizar el desperdicio. En cada Sprint, el software se probó, por lo
que cuando llegó la implementación de producción, fue un "no evento".
Parte 4: Buscando signos tempranos de fallas con Agile
#1 Impedimentos
En el Daily Scrum o reunión de pie; cada miembro del equipo describe lo que logró para el
proyecto el día anterior; lo que harán hoy; y si tienen algún impedimento del proyecto. Un
impedimento es algo que no permitirá que los miembros del equipo continúen con su trabajo.
La prioridad número uno del ScrumMaster para el equipo es ayudarlos a resolver los
impedimentos. El ScrumMaster toma estos impedimentos muy en serio y los resuelve dentro
de las 24 horas o se escalan al siguiente nivel de gestión.
# 2 Tablero de tareas donde hay demasiado trabajo en progreso
El tablero de tareas Agile puede ser tan simple como notas adhesivas en una pared; una hoja de cálculo
electrónica o una sofisticada aplicación de software Agile. Independientemente de lo que use, debería
proporcionarle signos de posibles fallas tempranas. Si su tablero de tareas tiene todas las tareas en curso o
iniciadas, entonces podría ser una señal de que el equipo no está trabajando en la prioridad de las historias. El
equipo puede trabajar mucho en la mayoría de las historias; pero el objetivo del Sprint es
6
RECUPERACIÓN DE PROYECTOS
completar las historias y entregar software funcional. Es mejor que el 85 % de todas sus historias se completen
y sean aceptadas por la empresa; luego tener el 100 % de sus historias completadas en un 50 % y ningún
software funcional para mostrar a sus socios comerciales.
# 3 Tablero de tareas donde las personas trabajan verticalmente
Si su tablero de tareas tiene la mayoría de las tareas en progreso y todas están siendo diseñadas; y luego
todos están siendo codificados; y luego probado; esto es trabajar verticalmente. Muchos gerentes de
proyecto llamarán a esto el Método de Cascada o si está usando Agile, Scrumfall.
Las cascadas son maravillosas atracciones turísticas. Son estrategias espectacularmente malas para
organizar proyectos de desarrollo de software.
- Ambler, Scott (2006, pág. 1)
Agile le permite concentrarse en las historias de alta prioridad y diseñar, codificar, probar y entregar el
software funcional y, al día siguiente, hacer lo mismo con la segunda historia de mayor prioridad. Una vez más,
es mejor que el 85 % de todas sus historias se completen y sean aceptadas por la empresa; luego tener el 100
% de sus historias completadas al 50 % y ningún software que funcione.
Ultimas palabras
En resumen, fallar temprano le brinda la oportunidad de recuperar y ver fallas ocultas y resolverlas
rápidamente antes de que se conviertan en fallas grandes y pongan en riesgo su proyecto. El marco de
desarrollo ágil le brinda varias formas de ver y escuchar pequeños errores antes de que se conviertan en
grandes errores y pongan en riesgo su proyecto. Por lo tanto, fallar temprano en el desarrollo ágil es
algo BUENO.
Referencias
Kent Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M. et al
(2001) El manifiesto ágil Obtenido dewww.AgileManifiesto.org
Ambler, S. y Sadalage, P. (2006). Refactorización de bases de datos—Diseño de bases de datos evolutivas Boston:
Pearson Education, Inc.
VitalSmarts. (2007). El silencio mata. Recuperado en julio
de 2010 de:http://www.pmi.org/pdf/pp_Mayfield.pdf
ACTIVIDADES:
1. Realiza la lectura
2. Realiza una Lluvia de ideas de 10 ideas
3. Valor 3%
7