Introducción ágil para equipos de cascada por Brad Egeland

¿Es usted un analista de negocios de Waterfall o un miembro del equipo de proyectos desde hace mucho tiempo en un entorno que se mueve hacia una metodología ágil para administrar proyectos y realizar actividades de desarrollo de software en esos proyectos? Entonces este artículo puede ser una introducción decente para ti. Piense en ello como una especie de cascada ==> Agile 101 que involucra y discute solo algunas de las diferencias clave de alto nivel entre estas dos diferentes metodologías de desarrollo de software y entrega de proyectos. A partir de ahí, se trata más de mojarse los pies en un proyecto ágil real y aprender los entresijos en el camino. Fingir hasta que lo logre, pero aún necesita desempeñarse de manera productiva y planificar la mejora con cada proyecto ... incluso con cada entregable y "sprint".

Ahora ... comencemos por definir un "sprint" ya que acabo de usar ese término. En el desarrollo de productos o en un proceso de desarrollo de software, un sprint es un período de tiempo establecido durante el cual se debe completar un trabajo específico y prepararlo para su revisión. Cierta funcionalidad, acordada de antemano, se crea y finaliza durante cada sprint. Mientras que Waterfall considera un proyecto como una serie de fases ... lo que nos lleva a nuestra primera discusión de los entendimientos de transición clave para el analista de negocios y los miembros del equipo del proyecto ...

En Waterfall, el proceso de desarrollo de software se divide en fases que ocurren una vez; en Agile pueden ocurrir una y otra vez. En el proyecto Waterfall, el proceso de desarrollo de software se divide en diferentes fases clave. En una metodología ágil, el proceso del software se divide básicamente en una serie de sprints, cada uno de los cuales crea y finaliza una nueva o un conjunto de nuevas funcionalidades. El final del proyecto no es la única implementación de la funcionalidad en funcionamiento ... sino que ocurre al final de cada sprint. Waterfall considera el proceso de desarrollo de software como un gran proyecto único dividido en muchas fases y entregables, pero cada uno aparece solo una vez durante el ciclo de vida del desarrollo. Con Agile, las mismas fases pueden aparecer en cada sprint. Por ejemplo, el diseño, el desarrollo y las pruebas aparecerán repetidamente en lugar de solo una vez. El proyecto de desarrollo de software ágil en realidad puede verse como una colección de muchos proyectos diferentes y puede ... y con frecuencia crecerá ... con las necesidades del cliente, los requisitos cambiantes y en evolución, así como su creciente disponibilidad de fondos y presupuesto.

En Waterfall, los requisitos deben ser los correctos la primera vez. En el modelo Waterfall para el desarrollo de software, los requisitos complejos y detallados del proyecto deben desarrollarse desde el principio. Cada cambio en los requisitos trae órdenes de cambio y probablemente reelaboración, cambios de horario, cambios de presupuesto y cambios en el marco de tiempo o niveles de esfuerzo. Debe ser claro con todos los requisitos de desarrollo de antemano, ya que no hay posibilidad de cambiar los requisitos una vez que comienza el desarrollo del proyecto, excepto a través de órdenes de cambio formales que generalmente el cliente del proyecto no cumple con gran entusiasmo ... les gusta el precio único se adapta a toda la mentalidad de financiación de proyectos.

La metodología ágil, por otro lado, es mucho más flexible. Agile permite realizar cambios en los requisitos de desarrollo del proyecto incluso después de que se haya completado la planificación inicial. El modelo de cascada es más adecuado para proyectos que tienen requisitos claramente definidos y en los que no se espera mucho o nada de cambio, aunque el cambio es casi siempre (siempre, en realidad, como he encontrado). Con Agile, el proceso de desarrollo respalda una metodología en la que se espera que los requisitos cambien y evolucionen. Por lo tanto, si planea desarrollar una solución de software o un producto con requisitos de cliente cambiantes o en evolución, es probable que Agile sea el mejor enfoque a seguir. El costo final en ese tipo de proyecto probablemente será menor con Agile. O al menos hay una mayor posibilidad de satisfacción del usuario final y del cliente, ya que el resultado final coincidirá más estrechamente, o coincidirá exactamente, con lo que ese usuario personalizado y final realmente necesita y desea. ¿Cuántas veces su cliente de proyecto sabe realmente lo que quiere al comienzo del proyecto? ¿Alguna vez? Por lo tanto, órdenes de cambio ... y reelaboración frustrante ... en la metodología Waterfall.

El diseño, el desarrollo y las pruebas ocurren una vez en Waterfall, muchas veces en Agile.  Como se mencionó anteriormente, en un proyecto de software, el diseño, desarrollo y prueba y otras fases y actividades clave se completan una vez en el modelo Waterfall. En el modelo Agile, el equipo sigue un enfoque de desarrollo iterativo. Como resultado, la planificación, el diseño, el desarrollo y las pruebas y otras actividades clave relacionadas y otras fases de desarrollo de software pueden aparecer más de una vez durante todo el ciclo de vida del desarrollo de software (SDLC). En realidad, es un proceso de desarrollo de software altamente colaborativo, lo que conduce a una mejor participación del equipo y una resolución de problemas más rápida y, por lo general, una solución final más precisa que está más a tiempo y dentro del presupuesto si todo sale según lo planeado.

Waterfall no requiere una gran participación de los clientes. La metodología de cascada es un proceso interno y no requiere la participación de los clientes, aunque es útil en la mayoría de los casos que involucran la revisión del estado y la toma de decisiones. En el escenario de desarrollo de software ágil, el enfoque se centra en la satisfacción del cliente y, por lo tanto, implica la participación de los clientes durante toda la fase de desarrollo y durante gran parte del proyecto en su conjunto.

Waterfall siempre se centra en el lanzamiento final de la imagen grande.  El modelo Waterfall exhibe una mentalidad de proyecto y se centra estrictamente en la finalización del desarrollo del proyecto, mientras que Agile presenta una mentalidad de producto que se centra en garantizar que el producto desarrollado satisfaga a sus clientes finales y se cambie a sí mismo a medida que cambian los requisitos de los clientes.

Resumen / solicitud de aportaciones

Hay diferencias, sin duda. Grandes diferencias, pero el cambio no es imposible de navegar y los beneficios pueden ser enormes. Con Waterfall, si todo va bien desde el principio, con el escenario perfecto… puedes salir muy por delante. Sin embargo, en el escenario ágil, se entiende que los requisitos evolucionan con el tiempo y que la funcionalidad a menudo se necesita en el camino, no de una vez al final del proyecto. Por lo tanto, la solución real puede evolucionar y escalar a lo largo del compromiso.

Lectores: ¿qué elementos clave pueden agregar? Estoy seguro de que he simplificado mucho las cosas aquí y las diferencias clave pueden ser notadas por aquellos con más experiencia en métodos ágiles que yo. Doy la bienvenida a sus comentarios y discusiones.