LABSCRUM– POSTSALEXBALLARIN Post 1 – Metodologías ágiles vs v s tradicionales (3/9/2011) 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 c aos (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 m etodologí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 f inalmente 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: 1. Cada empresa es un mundo, lo que funciona en un sitio puede fracasar en otro. 2. 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 marc a públicamente el camino y acepta los problemas temporales que trae el cambio, la mejora fracasará parcial o totalmente. 3. La experiencia y capacidad de las personas lo cambia todo, un gran método de trabajo no suplirá el valor de las personas. 4. 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. 1. Las metodologías tradicionales son pesadas y que suponen obligatoriamente un “todo o nada”. 2. Las metodologías ágiles son más modernas y mejores que cualquiera de las tradicionales.
3. 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. 4. 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: 1. 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. 2. 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. En los siguientes artículos se entrará en detalle en los factores que pueden ayudar a aplicar correctamente los modelos y las metodologías a equipos según su tamaño, su objetivo o su contexto.
Para leer más [1] http://en.wikipedia.org/wiki/Software_development_methodology [2] http://www.softwarepurist.com/blog/index.php/characteristics-of-sw-co-size/
