Históricamente los ingenieros de software empezamos a crear y usar metodologías muy parecidas a las de otras disciplinas de ingeniería con el objetivo de mejorar los resultados de los proyectos.
Esas primeras metodologías de Cascada compuestas por varias fases: Levantamiento, Análisis, Diseño, Construcción, Pruebas y Puesta en Producción; e iterativas como por ejemplo RUP(Rational Unified Process), funcionaron muy bien para productos antes de la aparición del Internet. Sin embargo, esas metodologías tradicionales ocupaban mucho tiempo en análisis de las necesidades y en generar documentación, para posteriormente proceder a construir una solución de acuerdo a lo especificado, sin permitir realizar cambios que afectaran el proceso y el resultado final.
Dramáticamente con la evolución de los negocios, y la velocidad que estos exigían, empezamos a notar que los productos que entregábamos al usuario final no cumplían las expectativas de estos. Muchos de esos productos se entregaban después de 3 meses, 6 meses, o 12 meses de desarrollo, para ser usados parcialmente o nunca ser utilizados. Está situación motivo a que pensáramos diferente y a buscar otras formas de hacer las cosas.
Así en el 2001 se reunió un grupo de críticos de los modelos de desarrollo de software basados en procesos, los cuales ya estaban experimentado o creando nuevos métodos de construcción de software. En esta reunión empezaron a hablar de "Métodos ágiles".
El resultado fue un conjunto de cuatro (4) postulados que denominaron "Manifiesto ágil".
El primer postulado consiste en valorar más “Individuos e interacciones sobre procesos y herramientas". Estamos convencidos que de nada sirve utilizar las mejores herramientas y procesos de construcción de software, sí la comunicación entre los usuarios y los técnicos no fluye de manera adecuada y constante para generar un único entendimiento de lo que requiere el negocio.
El segundo postulado valora más "Software funcionando sobre documentación extensiva". Lo que de verdad interesa a los negocios son aplicativos que funcionen. De nada sirve entregar al usuario final una herramienta que cumple con lo que se especificó en un documento, sí finalmente nadie lo usa porque no era lo que el negocio necesitaba.
El tercer postulado valora más “Colaboración con el cliente sobre negociación contractual”. Es importante ir más allá de la relación contractual y de verdad trabajar en equipo entre cliente y proveedor. En el mundo moderno tenemos que volver a la confianza. Creemos que se debe contar con contratos marco que definan las reglas de juego generales, pero en el desarrollo de los proyectos debe existir empoderamiento y toma de decisiones rápida. Y la relación comercial tiene que poderse evaluar de la misma forma que se validan los productos que se producen en los sprints de proyecto.
Y el cuarto y último postulado se refiere a “Respuesta ante el cambio sobre seguir un plan”. Finalmente, la capacidad de adaptación al cambio es mucho más importante que un plan ideal creado en papel. En el mundo actual hay que reinventarse todos los días, y desarrollar estrategias novedosas que permitan resolver situaciones y generar resultados.
En resumen, la agilidad más que una metodología es un marco general de trabajo que requiere que las empresas cambien su forma de pensar y de hacer las cosas(Cambio cultural).
Los invitamos a descubrir ¿Cuál es su forma de agilidad para Proyectos?...
