Introducción
Mi experiencia en
los proyectos tecnológicos comenzó en dos multinacionales del software y la tecnología,
donde pude experimentar “en mis carnes” las glorias y las miserias de proyectos
innovadores y en contextos organizativos frecuentemente complejos.
El abuso del
“modelo heroico”, donde equipos altamente motivados pero no bien organizados,
alcanzan los objetivos del proyecto al precio de un alto sobreesfuerzo personal
que asumen (más o menos voluntariamente) los miembros del equipo, me hizo
entrar con entusiasmo en el mundo de las metodologías de desarrollo y gestión
de proyectos (RUP, PMBOK, SCRUM, Metrica3, etc.).
Conseguí
trasladar este interés personal a la práctica profesional y me dediqué unos
años a la venta de metodología y herramientas para el desarrollo y gestión de grandes
proyectos. En este periodo tuve varias oportunidades para conocer las
metodologías ágiles en sus inicios a través de practitioners entusiastas de estas y de tener con éstos encendidos
debates acerca de cuál era el mejor enfoque.
En mi tercera
etapa profesional dentro del mundo de la tecnología aplicada a la gestión, me
dedico a la consultoría general sobre tecnología y a la mejora de procesos TIC
en organizaciones que adoptan crecientemente metodologías ágiles. De hecho, la
adopción de SCRUM que hace unos pocos años era marginal, ahora si no es
mayoritaria si es muy frecuente.
Así pues, a
partir del enfoque de alguien que ha conocido el caos (creativo), las
metodologías “tradicionales” y también las metodologías ágiles, tanto como
usuario como consultor que ha ayudado a implantarlas, espero hacer una
aportación interesante a este LAB de SCRUM.
En una serie de
tres artículos, me propongo introducir el contexto de las metodologías y los
modelos, identificar como las aplicar con éxito las metodologías en función del
contexto del equipo y como combinar el modelo CMMI y la metodología SCRUM.
Metodologías ágiles vs
tradicionales
1. Historia de las metodologías y
de los modelos.
Desde el inicio
del desarrollo masivo de software [1] se ha querido encontrar las mejores
prácticas y distribuir la experiencia obtenida a través de la práctica. Esto se
ha hecho tradicionalmente mediante metodologías impulsadas por universidades y grandes
empreses de tecnología a través de “metodologías”, como la programación
estructurada (1969), SSADM (1980), RAD (1991), RUP y SCRUM (1998) o XP (1999).
Además, se han
generado diferentes “modelos” de calidad que identifican actividades del
desarrollo determinadas como buenas prácticas (el QUE) pero que no prescriben
la manera de realizarlas concretamente (el COMO), de manera que los equipos que
los adoptan pueden elegir cual es la manera de realizar estas prácticas que
mejor se adapta a sus contextos y características.
2. Donde aplican cada uno
Simplificándolo mucho,
se puede decir que las metodologías tradicionales (SSAD, RUP, etc.) ponen por
encima de lo demás los objetivos de la definición y del control del trabajo, mientras
que las metologías ágiles priman la libertad del equipo, la comunicación entre
el cliente y el equipo, realizar sólo las tareas que aportan valor al cliente, y
finalmente definir el trabajo tal y como éste se va realizando para el
conocimiento adquirido durante su desarrollo evite realizar tareas
innecesarias.
Una consideración
importante es el tamaño de los equipos. La inmensa mayoría de los proyectos se
realizan por empresas o equipos muy pequeños (p.e. 1-10 personas) donde las
metodologías tradicionales son difíciles de aplicar, e incluso imposibles si se
quiere hacer de manera exhaustiva.
Otro aspecto influyente
es el contexto y misión de los equipos, que pueden ser estables en su actividad
(p.e. desarrollo de un producto) o cambiar más o menos frecuentemente de
miembros o proyecto.
3. Mitos y realidades
Mi experiencia
pasando por muchas organizaciones que desarrollan software me dice varias
cosas:
- Cada empresa es un mundo, lo que funciona en un sitio puede fracasar en otro.
- El compromiso de la dirección con la mejora está por encima de todo lo demás. Cuando toca cambiar los roles de las personas, introducir actividades que no se realizaban antes o atajar malas prácticas, si la dirección no marca públicamente el camino y acepta los problemas temporales que trae el cambio, la mejora fracasará parcial o totalmente.
- La experiencia y capacidad de las personas lo cambia todo, un gran método de trabajo no suplirá el valor de las personas.
- Una de las principales dificultades radica en el cambio de las personas. ¿Conseguimos que éstas entiendan y se adapten a los roles que les asigna la metodología? O por el contrario, el nuevo proceso se ve limitado a los cambios que los miembros estén dispuestos a aceptar.
Existen diversas
creencias falsas que pueden perjudicar la adopción de una nueva metodología,
sea del tipo que sea.
- Las metodologías tradicionales son pesadas y que suponen obligatoriamente un “todo o nada”.
- Las metodologías ágiles son más modernas y mejores que cualquiera de las tradicionales.
- Las actividades “de calidad” son inútiles y sólo funcionan en equipos grandes, no se adaptan a nuestros proyectos. Cualquier cosa que nos quite tiempo de tareas técnicas (programar, etc.) es una pérdida de tiempo.
- Trabajar con una metodología ágil no supone aplicar disciplina alguna, sinó que es una manera fácil de dar estructura su caos imperante sin añadir actividades de calidad. ¿Seguir SCRUM evita realizar testing?
Como resúmen, existen
dos grandes conclusiones:
- No hay varitas mágicas para conseguir mejorar la calidad y rendimiento de los equipos de manera radical sin cambiar profundamente la manera de trabajar. Y esto no supone en absoluto que los cambios sean difíciles si la dirección y los miembros de la organización creen en ello decididamente.
- Cada organización en mundo. Aplicar una metodología estándar de manera rápida y sin trabajar abierta y reflexivamente con los miembros de un equipo suele ser una buena receta para el desastre.
Para leer más
Servicios de Cynertia para el Coaching en metodología y gestión de proyectos.
No hay comentarios:
Publicar un comentario