Una metodología de desarrollo simplemente se refiere a los procesos y métodos que usas para crear tus aplicaciones. La mayoría de la gente ha escuchado acerca de las dos metodologías de desarrollo: Cascada e Iterativa. En el sentido más extenso, la metodología de Cascada es el proceso secuencial tradicional de análisis, diseño, construcción, prueba e implementación. La metodología Iterativa se refiere al proceso que construye soluciones más completas de manera parcial, pero gradual, a lo largo de una serie de iteraciones.
Por muchos años, esas fueron tus opciones. En los últimos años, sin embargo, un nuevo grupo de metodologías ha emergido, mismas que caen dentro de la categoría general de metodologías “light”. Éstas incluyen a: Programación Extrema, Programación Ágil y SCRUM (Existen otras igualmente). Llamarlas metodologías es probablemente muy general. Sería mejor referirnos a ellas como "marcos" para efectuar desarrollo, o incluso filosofías.
La revolución Ágil se inició como un movimiento de contra-cultura, en oposición a lo que mucha gente vió como metodologías de desarrollo pesadas y orientadas a los procesos. La aproximación ágil implica que el papeleo de un proyecto no provee valor. El valor proviene del software que funciona. Por ejemplo, digamos que un proyecto ha estado en desarrollo por seis meses. El equipo ha completado los requerimientos de negocio, modelos de procesos, diseño técnico, planes de prueba, etc. Puedes pensar que estás logrando un gran progreso, pero desde un punto de vista Ágil, no has entregado nada de valor. El valor real se origina en una solución que funcione.
En lugar de crear una documentación de proyecto tradicional, Ágil se enfoca en mínima documentación (mínima – no ninguna documentación) y la entrega de soluciones funcionando (software que funcione para el caso de TI). De hecho, para el final de los seis meses, un proyecto Ágil puede haber completado seis o más iteraciones de proyecto, y haber entregado una solución de software funcionando parcialmente. Los desarrolladores Ágiles suelen sostener que la solución que funciona es de mayor valor que el papeleo. Existen cuatro creencias generales que las metodologías ágiles tienen en común:
1.- Desarrollo en ciclos cortos: Usualmente, cada “Sprint” Ágil no toma más de 30 días, o menos. Las soluciones parciales deberían estar activas y funcionando en muy corto tiempo, con ciclos iterativos muy ajustados diseñados para entregar software funcionando (u otro tipo de resultado) continuamente que se construye como una solución final.
2.- Valorar a la gente: La gente debe ser valorada y tratada con respeto. Los gerentes deberían confiar en que ellos hacen un buen trabajo y no deben estar encima para controlarlos. Los equipos ágiles trabajan a un ritmo desafiante, pero a paso continuo que en teoría pueden mantener de manera indefinida.
3.- Involucrar al cliente: Si vas a alcanzar resultados rápidos, el cliente debe ser una parte integral del equipo de trabajo. De hecho, ellos deben estar asignados a tiempo completo y co-ubicados (co-located) en el mismo espacio físico que el resto del equipo.
4.- Luchar por la simplicidad: El pensamiento básico es que si tienes la opción de construir algo de manera sofisticada o de manera simple, escojas siempre la manera simple. Los requerimientos deben ser simples, el diseño de trabajo debe ser simple y las técnicas de codificación también deben ser simples.
Mi opinión: Mi experiencia previa es en gestión tradicional de TI, sin embargo, me ha fascinado el movimiento Ágil y lo he seguido desde el Manifiesto Ágil del 2001. Cuando se lo introdujo, todo era anarquía. ¡Los programadores regían el mundo! Con el tiempo, el modelo Ágil ha evolucionado para coexistir junto con un pensamiento más tradicional de Dirección de Proyectos y actividades de desarrollo. Puedes también adoptar mezclas híbridas de Ágil y acercamientos de desarrollo más tradicionales. Esto ha hecho que el movimiento sea la corriente prevaleciente y segura para la mayoría de las organizaciones.
¿Puede funcionar?, ¿Sí! ¿Puede fallar?, ¡Sí! He hablado con organizaciones que son altamente exitosas y han reducido dramáticamente los tiempos de desarrollo. He hablado con organizaciones donde Ágil ha fallado por completo, pero mayormente por la cultura de la organización. Por ejemplo: una iteración completa de proyecto (de análisis a implementación) puede efectuarse en 15 días. Esto ocurre si cuentas con un representante del cliente que es parte integral del proyecto y puede responder rápidamente a tus consultas. Puedes imaginar que si los desarrolladores tienen consultas y el cliente no puede reunirse hasta dentro de dos semanas, vas a tener mucha dificultad en tratar de entregar proyectos ágiles.
Como base, pienso que todas las organizaciones de TI deben tener proyectos ágiles. No todos los proyectos son candidatos para Ágil, pero muchos sí lo son y cada organización probablemente debería estar haciendo algo de trabajo Ágil, o por lo menos experimentándolo para probar cómo funciona.
¿Claro como el agua?
Contáctame para más información. Tenemos un curso estupendo de dos días para revisar y entender el modelo Ágil. Al final del curso tendrás un muy buen sentido de los beneficios y los retos que implican la implementación de ágil en tu organización.
También tenemos un curso de Certificación Scrum Master SMC™. Podemos también proveer servicios de consultoría para ayudarte a implementar Ágil en tu organización. TenStep ayuda a las organizaciones a implementar sus objetivos y estrategias a través de la exitosa ejecución de sus proyectos. Esto incluye implementación exitosa de prácticas sólidas en dirección de proyectos, definición y puesta en marcha de Oficinas de Proyectos (PMO´s), establecimiento de procesos de gestión del portafolio y mucho más.
Tom Mochal, PMP, PgMP, TSPM, ITBMC, President, TenStep, Inc.
Traducción y adaptación: Enrique Ledesma, M.Sc., PMP, TSPM, SPOC, SCT, SMC, SDC
