Agilidad, la clave para mejorar
¿Pueden las metodologías ágiles ayudarnos a incrementar nuestro porcentaje de éxito?
Este artículo presenta estadísticas sobre la tasa de proyectos de informática "fallidos", entendidos como aquellos que se abandonan antes de ser completados y sin generar ningún producto útil. Según el artículo apenas un 35% de los proyectos son exitosos; es decir, se completan a tiempo, dentro del presupuesto, y con toda la funcionalidad planeada originalmente. Un 46% de los proyectos son no óptimos, pues se completan pero tal vez no con todas las características requeridas. El porcentaje restante, un 19%, son completas fallas .
Preocupa el 46% de proyectos completados "a medias", posiblemente tarde y saliéndose del presupuesto. En general la gran mayoría de los proyectos se planean a conciencia siguiendo al pie de la letra la regla de "80% en planeación y 20% en desarrollo"; se contemplan todos los casos posibles, se detallan todas las pantallas, funciones, flujos, casos de uso, etc; se generan calendarios de desarrollo, diagramas de gant; sin embargo estos proyectos no son del todo exitosos por diversas razones. ¿A qué se debe esto?
Una posible solución es incrementar (¿más?) el nivel de seriedad y de compromiso al plantear el proyecto. Se escribe todo "en piedra" e incluso antes de dar un estimado del tiempo requerido para completarlo. El problema es que en general estos proyectos podrán ser bastante tardados, y el hecho es que las necesidades de negocios o logística que conllevan a requerir un desarrollo, difícilmente son estáticas e inmutables; también es factible que a los involucrados se les "ocurran" requerimientos o funcionalidad adicionales forzando así a uno de dos caminos: cambiar los requerimientos y por tanto el tiempo de entrega del proyecto (terrible para el equipo de desarrollo), o dejar de lado características que posiblemente sean importantes para el cliente (pésimo para el cliente). Una de las dos nos acarrea desviarnos de los parámetros de entrega del proyecto; la otra conlleva un desarrollo que no cumplirá con las expectativas (independientemente de que algunas de ellas se plantearon "fuera de tiempo"; vaya, si esto parece procedimiento gubernamental) y que posiblemente acabará siendo despreciado o abandonado por estas fallas; nada peor que un usuario que dice "diablos, ojala hubieran podido implementar X" y desde un inicio le tenga poca confianza al sistema.
La solución que ofrecen las metodologías ágiles es mayor transparencia y menos resistencia al cambio. Con un ciclo de desarrollo que involucra al usuario desde el primer día, por medio de iteraciones y refactoración constantes que presentan resultados parciales y permiten redirigir el proyecto, el cambio deja de ser una propuesta onerosa y se convierte en parte integral del proceso. Aceptar con gusto el cambio es algo que en metodologías ágiles es completamente natural.
Esto responde mejor a las necesidades de proyectos en los cuales existe la posibilidad de cambios en los requerimientos; que por experiencia se sabe que serán la gran mayoría. Piénsese incluso en la ventaja para el usuario al que no se le hace firmar en piedra un documento de diseño; esto permite al usuario mayor libertad pues no se le tiene bajo la presión de plantear todos los requerimientos a la absoluta perfección desde el primer momento. Dejémosle al usuario la posibilidad de cambiar de ideas y de rumbo durante el proyecto, utilizando herramientas y técnicas que permiten dichos cambios sin tener que asesinar al equipo de desarrollo.
Como iremos viendo en esta sección las metodologías ágiles no son una panacea que resuelve todos los problemas, se requiere la misma disciplina que con los métodos tradicionales; es sólo una disciplina diferente que nos permitirá responder de manera más adecuada a cierta clase de proyectos. Es nuestra responsabilidad determinar cuáles proyectos y conducir la metodología más adecuada para resolverlos.