Post 1 Metodologas giles vs tradicionales (3/9/2011)

Introduccin
Mi experiencia en los proyectos tecnolgicos comenz en dos multinacionales del software y la tecnologa, 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 (ms o menos voluntariamente) los miembros del equipo, me hizo entrar con entusiasmo en el mundo de las metodologas de desarrollo y gestin de proyectos (RUP, PMBOK, SCRUM, Metrica3, etc.). Consegu trasladar este inters personal a la prctica profesional y me dediqu unos aos a la venta de metodologa y herramientas para el desarrollo y gestin de grandes proyectos. En este periodo tuve varias oportunidades para conocer las metodologas giles en sus inicios a travs de practitioners entusiastas de estas y de tener con stos encendidos debates acerca de cul era el mejor enfoque. En mi tercera etapa profesional dentro del mundo de la tecnologa aplicada a la gestin, me dedico a la consultora general sobre tecnologa y a la mejora de procesos TIC en organizaciones que adoptan crecientemente metodologas giles. De hecho, la adopcin de SCRUM que hace unos pocos aos 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 metodologas tradicionales y tambin las metodologas giles, tanto como usuario como consultor que ha ayudado a implantarlas, espero hacer una aportacin interesante a este LAB de SCRUM. En una serie de tres artculos, me propongo introducir el contexto de las metodologas y los modelos, identificar como las aplicar con xito las metodologas en funcin del contexto del equipo y como combinar el modelo CMMI y la metodologa SCRUM.

Metodologas giles vs tradicionales

1. Historia de las metodologas y de los modelos. Desde el inicio del desarrollo masivo de software [1] se ha querido encontrar las mejores prcticas y distribuir la experiencia obtenida a travs de la prctica. Esto se ha hecho tradicionalmente mediante metodologas impulsadas por universidades y grandes empreses de tecnologa a travs de metodologas, como la programacin estructurada (1969), SSADM (1980), RAD (1991), RUP y SCRUM (1998) o XP (1999).

Adems, se han generado diferentes modelos de calidad que identifican actividades del desarrollo determinadas como buenas prcticas (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 prcticas que mejor se adapta a sus contextos y caractersticas. 2. Donde aplican cada uno Simplificndolo mucho, se puede decir que las metodologas tradicionales (SSAD, RUP, etc.) ponen por encima de lo dems los objetivos de la definicin y del control del trabajo, mientras que las metologas giles priman la libertad del equipo, la comunicacin entre el cliente y el equipo, realizar slo 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 consideracin importante es el tamao de los equipos. La inmensa mayora de los proyectos se realizan por empresas o equipos muy pequeos (p.e. 1-10 personas) donde las metodologas tradicionales son difciles de aplicar, e incluso imposibles si se quiere hacer de manera exhaustiva. Otro aspecto influyente es el contexto y misin de los equipos, que pueden ser estables en su actividad (p.e. desarrollo de un producto) o cambiar ms 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 direccin con la mejora est por encima de todo lo dems. Cuando toca cambiar los roles de las personas, introducir actividades que no se realizaban antes o atajar malas prcticas, si la direccin no marca pblicamente 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 mtodo 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 metodologa? O por el contrario, el nuevo proceso se ve limitado a los cambios que los miembros estn dispuestos a aceptar. Existen diversas creencias falsas que pueden perjudicar la adopcin de una nueva metodologa, sea del tipo que sea. 1. Las metodologas tradicionales son pesadas y que suponen obligatoriamente un todo o nada. 2. Las metodologas giles son ms modernas y mejores que cualquiera de las tradicionales.

3. Las actividades de calidad son intiles y slo funcionan en equipos grandes, no se adaptan a nuestros proyectos. Cualquier cosa que nos quite tiempo de tareas tcnicas (programar, etc.) es una prdida de tiempo. 4. Trabajar con una metodologa gil no supone aplicar disciplina alguna, sin que es una manera fcil de dar estructura su caos imperante sin aadir actividades de calidad. Seguir SCRUM evita realizar testing? Como resmen, existen dos grandes conclusiones: 1. No hay varitas mgicas 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 difciles si la direccin y los miembros de la organizacin creen en ello decididamente. 2. Cada organizacin en mundo. Aplicar una metodologa estndar de manera rpida y sin trabajar abierta y reflexivamente con los miembros de un equipo suele ser una buena receta para el desastre. En los siguientes artculos se entrar en detalle en los factores que pueden ayudar a aplicar correctamente los modelos y las metodologas a equipos segn su tamao, su objetivo o su contexto.

Para leer ms
[1] http://en.wikipedia.org/wiki/Software_development_methodology [2] http://www.softwarepurist.com/blog/index.php/characteristics-of-sw-co-size/