1.2 La revolución ágil

Waterfall como metodología

Ser un administrador de proyectos de “cascada” tradicional hizo que fuera muy poco probable que su proyecto se completara con éxito, y mucho menos de acuerdo con el plan que estableció al principio. Era más como ser un meteorólogo haciendo un pronóstico para un día específico el próximo año. Excepto por suerte al azar, estarías equivocado.

Waterfall, como metodología, no es inherentemente algo malo. En algunos casos tiene sentido, como en la construcción de edificios, donde un conjunto predefinido de pasos, cuando se ejecutan en orden, dará como resultado un edificio.

Absolutamente, puede planificar y programar todo el proyecto por adelantado. Ocurre cada vez que se construye una casa o un edificio de oficinas. El problema surge cuando se aplica la técnica a un trabajo altamente empírico como el desarrollo de software.

Pruebas algo, compruebas los resultados, y si no funcionó, pruebas otra cosa

El trabajo empírico es más como un experimento científico. Pruebas algo, compruebas los resultados, y si no funcionó, pruebas otra cosa. Ciertamente, no puedes hacer eso cuando construyes una casa, pero con software u otros productos, lo haces todos los días. Ese es el quid de por qué la cascada no funcionó bien para el desarrollo de software.

Literalmente, no puede planificar por adelantado el proceso de descubrimiento. La frustración de los desarrolladores de software altamente calificados que trabajan en proyectos en cascada fue el punto de inflexión que condujo a la revolución Agile. Cansados ​​de tener una tasa de fallos equivalentes a la de un meteorólogo, estas personas decidieron que tenían que encontrar una mejor opción.

El resultado se conoce como el Manifiesto Ágil.

Basándose en la mentalidad de la fabricación ajustada, en la que se hace lo justo a tiempo para alcanzar el objetivo, empezaron a averiguar cómo se aplica eso al desarrollo de software.

El resultado es el Manifiesto Ágil y sus principios subyacentes.

Echa un vistazo al Manifiesto Ágil. Como si estas palabras no fueran lo suficientemente revolucionarias, este grupo de innovadores apoyó este manifiesto con 12 principios clave. Este manifiesto y los principios se convirtieron en la base de un nuevo conjunto de metodologías de gestión de proyectos y desarrollo de software.

Hay un par de temas primordiales que hacen que Agile sea diferente

Uno de los cambios clave es que les estamos pidiendo a nuestros socios comerciales que trabajen con nosotros durante todo el proyecto, no solo que se presenten al principio para describir lo que quieren, sino que se presenten al final y nos digan cómo fallamos. . Necesitamos una interacción directa y continua para brindarles lo que realmente necesitan.

Otra clave es que ya no queremos medir el éxito utilizando hitos y fases del proyecto

Queremos un software que funcione para decirles a todos cómo lo estamos haciendo, y queremos escuchar comentarios todo el tiempo. Quizás el cambio más revolucionario es permitir que los equipos se organicen por sí mismos. Harán un trabajo mucho mejor haciendo el diseño y las pruebas desde el nivel del suelo que cualquier plan inicial.

La planificación inicial es teórica

El diseño en evolución es tanto práctico como táctico. Te llevará a tus objetivos más rápido, con mayor calidad. Entre el manifiesto y sus principios, este grupo de desarrolladores se hizo cargo de las versiones de software de alta tecnología del hombre del tiempo. Estaban listos para triunfar. Hay una mejor manera de hacer desarrollo de software, y es Agile.