Examen de prueba gratis
Waterfall y Agile se examinan como dos metodologías para la gestión de proyectos, pero de forma independiente, Agile debe percibirse como un enfoque de gestión y desarrollo de productos.
Hoy en día, la mayoría de estas metodologías están relacionadas con el desarrollo de software, pero en el artículo también mencionaremos las aplicaciones y usos típicos de Waterfall y Agile. Es importante señalar que cada metodología tiene sus pros y sus contras.
Tabla de contenidos
Metodología de cascada (Waterfall)
La metodología en cascada es una metodología lineal y se caracteriza por el hecho de que cada etapa posterior comienza después de la finalización de la anterior. De ahí viene el nombre de la metodología. Esta palabra demuestra más claramente la idea detrás de esta metodología, en cuyo caso el proceso de desarrollo se compara con agua corriente que solo va en una dirección.
En esta metodología, la secuencia de acciones podría describirse de la siguiente manera:
- Fases y pasos de ejemplo de cascada
- Especificaciones del cliente (representa una descripción detallada del producto con toda la funcionalidad esperada)
- Diseño (Arquitectura, UI/UX)
- Desarrollo (Programación, Pruebas Unitarias)
- Pruebas de productos (Departamento de control de calidad interno)
- Provisión de prueba de cliente (CAT / UAT)
correcciones - Finalización y entrega del producto.
Pros de la metodología Waterfall
Hay criterios claros que el producto debe cumplir en su forma completa (no se permiten cambios; todo el alcance del trabajo está preestablecido).
El progreso del proyecto es fácilmente medible porque la cantidad de trabajo es clara desde el principio.
El trabajo de los diferentes equipos es consistente, y su compromiso con el proyecto es solo cuando se les necesita.
No se requiere la participación del cliente durante todo el trabajo.
Contras de la metodología Waterfall
El resultado solo es visible al final del proceso: el cliente no siempre puede juzgar cómo se verá el producto en su forma final en función de sus requisitos.
Este es también el mayor problema con este método porque el producto final no siempre es satisfactorio para el cliente, aunque se cumplan todos los requisitos.
A menudo, esto requiere cambios adicionales, que no siempre es posible hacer en función de un producto ya existente con alguna funcionalidad.
Esto afecta más comúnmente a todos los aspectos del producto (precio, calidad, duración). En el peor de los casos, el producto nunca se podrá usar y esto resultará en un gran desperdicio de los recursos del cliente.
Metodología ágil
La metodología ágil se caracteriza por el hecho de que es flexible e iterativa con el objetivo principal de un rápido desarrollo de productos.
El equipo o equipos involucrados en el desarrollo del producto juegan un papel central y se enfocan en priorizar la funcionalidad.
La secuencia de acciones se repite a intervalos cortos (Sprints), cuyo propósito es dotar al producto de una funcionalidad lista.
Al final de cada intervalo de desarrollo, el resultado es revisado por los equipos involucrados en el desarrollo y el cliente (Demo).
Esto significa que la metodología Agile requiere una participación continua del cliente en el proceso de desarrollo, y especialmente en el momento de la aprobación de la funcionalidad terminada.
Esta secuencia se repite repetidamente hasta completar el producto.
Ventajas de la metodología ágil
Claridad: el cliente obtiene una idea clara del producto a medida que se desarrolla. Esto permite cambios y juicios en las próximas etapas y minimiza el riesgo de insatisfacción.
Agile brinda la capacidad de proporcionar un producto que funcione, aunque con una funcionalidad incompleta, en un período de tiempo más corto.
Esto es especialmente importante para los productos en los que el tiempo de comercialización es crítico (como un sitio de apuestas).
El desarrollo está impulsado por prioridades, en primer lugar, desarrollar la funcionalidad básica para que el producto esté listo para que lo usen los consumidores lo antes posible y luego complementar la funcionalidad secundaria.
Esto, en cierta medida, asegura que incluso si hay imprevistos (suspensión de la financiación), el producto podría ponerse en uso, aunque sin la funcionalidad completa. Esto también garantiza la inversión del cliente hasta cierto punto.
Reduce el riesgo de fracaso total del proyecto debido a la insatisfacción del cliente.
Contras de la metodología ágil
Compromiso del cliente: el cliente no siempre puede o está dispuesto a dedicar tanto tiempo al proyecto.
Equipo / Compromiso del equipo: este modelo solo funciona si todos los equipos participan durante el desarrollo. Referencia: «Gestión ágil de proyectos», https://agileprogramming.org/agile-project-management/
Reciclaje de productos: dado que el alcance del proyecto no está claro desde el principio, y no se proporciona toda la funcionalidad en el diseño, y la arquitectura necesita reingeniería (Refactorización). El no hacerlo puede reducir la calidad del producto.
¿Enfoque en cascada o ágil? Conclusión
De la información anterior, diría que la elección de un sistema de gestión depende principalmente del tipo de proyecto que tenemos, el deseo del cliente de involucrarse en el proceso de desarrollo, los requisitos de su producto y nuestra capacidad para delegar equipos al cliente en pregunta.
Si el cliente no quiere participar activamente en el desarrollo, hay una funcionalidad y presupuesto fijo yo recomendaría el uso del modelo Waterfall, ya que en Agile, el cliente juega un papel clave, y esto podría retrasar el proyecto en su incapacidad para participar.
En esta situación, recomendaría una revisión exhaustiva de la documentación con sus requisitos para asegurarse de que tanto el equipo de desarrollo como el cliente tienen una idea clara de lo que se requiere del producto final. Esto, por su pasión, lleva más tiempo de planificación que en la metodología Agile.
Por nuestra parte, esta opción sería más conveniente en los casos en los que no podamos delegar equipos completos de personas para trabajar en este proyecto porque en diferentes etapas están involucradas diferentes unidades, y en el momento en que estos equipos no son necesarios, ellos podría trabajar con otro cliente.
Si el cliente tiene la oportunidad y el deseo de participar activamente en el proceso de desarrollo, recomendaría usar la metodología Agile, ya que permite un inicio rápido del proyecto con la funcionalidad básica del producto y no requiere un período de planificación tan largo como en el Metodología de cascada.
Un beneficio adicional es que el cliente tendrá una idea clara del producto en una etapa temprana, y esto evitará errores relacionados con la planificación imprecisa y la corrección temprana de errores de diseño y concepto.
Agile da confianza e información al cliente sobre la calidad del producto y su desarrollo. Desde nuestro punto de vista, en este modelo necesitamos proporcionar equipos que trabajarán con el cliente hasta que el producto esté completo debido a la naturaleza iterativa de la metodología, que involucra a todos los equipos aproximadamente al mismo tiempo por períodos cortos.
Personalmente, preferiría la metodología Agile en más casos debido a la dinámica de desarrollo y la reducción del riesgo de insatisfacción del cliente con el producto final. Por esta razón, la metodología mencionada anteriormente en la tabla está ganando popularidad y es un modelo de desarrollo cada vez más preferido en estos días.
Waterfall, Agile y Scrum en la práctica
En la práctica, muchos productos pueden desarrollarse sin restricciones en el tipo de proyecto o producto.
Agile (y sobre todo el framework Scrum, referencia: https://bvop.org/learnagile/scrum/) implica que tiene más «transparencia». La transparencia es un término bastante popular.
En Waterfall, podemos volver a lograr la transparencia si así lo deseamos.
Nuevamente, con ambos métodos, también podemos reducir la transparencia. Kanban, por ejemplo, no proclama la participación del cliente en el desarrollo.
El equipo puede trabajar con seguridad «cerrado» durante mucho tiempo, y nadie sabe lo que está pasando.
No se requieren sprints ni demostraciones. Esto es opcional, y muchas empresas y equipos están practicando formas híbridas de trabajar para lograr más resultados.
En la práctica, en todo modelo, podemos lograr la transparencia y romperla. Las doctrinas y prácticas no tienen condiciones estrictas excepto Scrum, donde la transparencia está claramente expresada y fuertemente enfocada.
Con Scrum, se realizan investigaciones e inspecciones frecuentes de los clientes para reducir el riesgo de problemas y demostrar que el trabajo del período (sprint) está completo.
El equipo Scrum puede saber con seguridad sobre un defecto, pero no expresarlo a otras partes y pasar desapercibido durante mucho tiempo. Solo la cultura y la actitud de los miembros del equipo pueden garantizarlo.
En Waterfall, podemos tener fases de trabajo listas para usar, a menudo llamadas lanzamientos (intervalos establecidos para lanzar parte de un proyecto).
En Scrum, tenemos sprints (intervalos de tiempo fijos para demostrar el trabajo terminado).
No hay condiciones en ninguna práctica para la duración de las fases.
En Scrum, la única condición para un sprint es que no dure más de un mes calendario. El tiempo mínimo de sprint no se menciona oficialmente. Todo lo que se necesita durante este período es lograr algún incremento (aumento).
En Waterfall, si tenemos tareas que se desglosan en pequeñas partes y el producto y la tecnología lo permiten, podemos tener un plazo de liberación de dos semanas, por ejemplo. Si usamos Scrum, y nuestros sprints también están a dos semanas, tenemos los mismos resultados.
El resultado de Sprint 1 puede ser el mismo que el resultado de Release 1
El resultado de Sprint 2 puede ser el mismo que el resultado de Release 2
etc.
En la gestión de proyectos clásica, tenemos una práctica llamada gestión de cambios y solicitud de cambio. Esto significa que el cliente puede solicitar un cambio en cualquier parte del proyecto.
Cada solicitud de cambio se planifica y calcula en términos de costo y tiempo y se evalúa si se implementará.
La difusión popular generalizada de la idea del alcance y la incapacidad de cambiar se enfatiza en exceso y se propaga de un sitio a otro y de un libro a otro sin ninguna competencia o intención.
La raíz de esta idea es que si vierte 200 toneladas de hormigón en su proyecto, sería un reto hacer «cambios de diseño» si la losa de hormigón fuera 20 cm más estrecha.
Sin embargo, muchos tipos de proyectos permiten cambios sencillos.
En Scrum, tenemos el rol de Product Owner (en otros flujos de trabajo de Product Manager), que decide qué cambio de la última iteración, cuándo se realizará, priorizando el trabajo y, nuevamente, si se realizará evaluando su valor.
En este caso, de nuevo, si lo deseamos, podemos conseguir mucha uniformidad.
Importante
Todas las similitudes y similitudes pueden ser válidas si la naturaleza del producto lo permite.
Si desarrollamos un producto con múltiples componentes que se pueden construir uno encima del otro y que pueden existir por sí solos, y el resultado es un producto parcialmente terminado, vemos la gran similitud.
Sin embargo, las prácticas ágiles no nos ayudarán si nuestro proyecto es una estación espacial que, para entender cómo funciona, debe estar fuera de órbita. Las iteraciones y adaptaciones también son difíciles de implementar.
La conclusión que podemos sacar después de este análisis tan detallado es que, en realidad, los dos enfoques tienen muchas más similitudes de las que señala la literatura popular.
Las diferencias son pequeñas pero significativas. La naturaleza del producto, el conocimiento de los requisitos y la capacidad de iterar con retroalimentación real son los factores más objetivos que influyen en nuestra elección del método. Todo lo demás son factores subjetivos.
También me gustaría publicar mis puntos de vista sobre el tema. Gracias.
Cascada
La cascada es un enfoque de gestión de proyectos en el que el proyecto se implementa en etapas separadas hasta que se completa con éxito. Se hace un gran plan de antemano con todos los detalles posibles, y luego linealmente, va desde la primera hasta la última etapa.
Después de pasar de un paso a otro, no es posible volver a la etapa anterior, por lo que el paso a la siguiente etapa se realiza después de que la etapa en la que nos encontramos se haya completado por completo.
Características:
Proceso secuencial: todo se ejecuta secuencialmente. Proceso previamente planificado. Sabemos exactamente lo que queremos obtener como producto final y cómo se verá.
La calidad es más importante que la velocidad de finalización del proyecto. Un proceso depende de los requisitos establecidos en una etapa anterior.
El alcance, el tiempo y el costo se estiman para todo el proyecto desde el principio. Entonces la empresa sabe qué esperar, cuánto tiempo llevará completar el proyecto.
Por lo general, lleva más de un año completar dichos proyectos. Es bastante difícil hacer cambios.
Incluso en la mayoría de los casos es imposible porque en un principio se decidió cuál sería el proyecto y qué pasos se darían. Todo está documentado.
Ágil
Agile es un enfoque flexible de gestión de proyectos. Este enfoque permite que los proyectos grandes se dividan en tareas más manejables para que las personas que trabajan en el proyecto las manejen más rápidamente.
Gracias a Agile, el equipo puede adaptarse más rápido y ofrecer un rendimiento más rápido. Originalmente fue diseñado para solucionar los inconvenientes de Waterfall en el desarrollo de software.
No está claro exactamente cómo se verá el producto final, y sabemos exactamente para qué se utilizará. Más importante es la velocidad de creación del proyecto que la calidad.
Un proyecto mucho más simple que se vuelve más claro durante el desarrollo. Los cambios son muy fáciles de hacer porque se esperan en cualquier momento. Se crea en partes que se pueden mostrar a los clientes para que puedan ver de dónde viene el proyecto y cómo va. Más comúnmente utilizado en el desarrollo de software.
Desde un punto de vista puramente práctico, logro encontrar algunas diferencias básicas entre las dos técnicas. Lo primero que llama la atención es la organización.
En Waterfall, todas las acciones se dividen en pasos sucesivos.
Cada uno viene después del anterior. El nuevo puede comenzar cuando se completa el anterior. Mientras que con Agile los procesos pueden funcionar en paralelo.
Con Waterfall, debemos haber acordado de antemano con el cliente los detalles del producto final porque todo debe estar incluido en el plan. Por otro lado, la técnica Agile proporciona un contacto constante con el cliente.
El método de cascada sería útil para construir pequeños proyectos.
El método Waterfall sería útil para construir pequeños proyectos. Cuando los pasos son pequeños, la visión final del producto también es clara y todo se puede planificar con precisión.
Por ejemplo, podemos tomar la producción de una pieza de metal según un dibujo. El cliente nos entrega el encargo final, un dibujo de un detalle. El camino se está construyendo en pasos claros y la producción y la comercialización avanzan.
Por su parte, cuando el proyecto es más grande, el cliente aún no sabe exactamente qué resultado espera al final, sería más adecuado utilizar la metodología Agile.
Esto lo requiere, porque muy probablemente durante el diseño del producto final surgirán requerimientos adicionales, se descubrirán necesidades adicionales del cliente y si estamos en constante contacto con él podremos corregirlas de inmediato. Como ejemplo, daría cualquier software de usuario final.
El cliente quiere una aplicación que haga algo básico pero no sabe que diseño tendrá, cuales serán las opciones principales y adicionales.
Otra diferencia entre las dos metodologías es la documentación y el informe del trabajo del proyecto.
Otra diferencia que veo entre las dos metodologías es la claridad y precisión con la que podremos documentar e informar sobre el trabajo del proyecto.
En el caso de Waterfall, tenemos pasos claros en los que podemos establecer plazos y requisitos claros. Podemos monitorear la calidad de cada etapa completada así como revisar lo que se ha hecho en ella.
Todas estas cosas serían mucho más complicadas si usáramos la metodología ágil, en la que las cosas se fusionan y cambian constantemente.
Tomaría mucho más tiempo y energía analizar el trabajo de un equipo en particular o el desempeño de una tarea en particular.
Sería mucho más difícil encontrar problemas de fondo en los procesos internos de la empresa (independientemente de la unidad/departamento), que si se detectan a tiempo se pueden corregir.
En conclusión, puedo decir que la adherencia estricta a cualquiera de las dos metodologías conduciría a dificultades y problemas en una etapa del proyecto.
Sería lógico utilizar técnicas de ambas metodologías (y no solo), y calibrar para cada proyecto y cliente específico. Cada proyecto debe planificarse de acuerdo con la naturaleza del producto final, manteniendo la máxima flexibilidad cuando sea necesario.
Por supuesto, el uso de buenas prácticas de ambas metodologías no nos limita a utilizar nuestra experiencia personal, así como a consultar otras metodologías menos populares.
La cascada es una metodología con un enfoque lineal para el desarrollo de productos y cada fase debe completarse para comenzar con la siguiente, lo que para un proyecto puede ser el mejor modelo porque, después de completar cada fase, puede hacer un análisis y decir si hay
Todavía quedan cosas por completar en la fase o ha terminado y puede pasar a la siguiente etapa.
El progreso del proceso es mucho más fácil de medir porque se puede ver el desarrollo de una fase a la que se ha llegado. La desventaja de este modelo es la finalización más lenta del producto.
En el modelo Agile hay una fusión de fases, lo que en algunos casos conduciría a un desarrollo más rápido del producto, pero se debe definir muy claramente para cada unidad, lo que debe hacer en su campo para que el grupo de departamentos avance. una onda, ya que son como vasos conectados y el retraso de una de las fases conduce a un retraso en las otras fases.
En el modelo Agile, en lugar de crear cronogramas, se realizan los llamados “sprints”, que forman parte del tiempo en cada fase. Cada sprint tiene una duración corta y unos objetivos determinados a conseguir, determinando así el resultado en el avance de las fases.
La desventaja de este modelo es que si no hay una buena conexión entre los departamentos, puede resultar que la duración de las apuestas para todo el proyecto sea muy incorrecta.
En general, Agile se está volviendo más popular debido a las nuevas empresas, que hoy en día no tienen mucho tiempo y recursos para dedicar a un proyecto lineal y están recurriendo al modelo Agile.
El enfoque de gestión de proyectos en cascada se utiliza en proyectos para los que tenemos una gran claridad sobre los requisitos del cliente. Esta metodología requiere una buena planificación, así como seguir el plan ya establecido.
Los cambios en el proyecto no son deseables, pero cuando son inevitables se hacen. Con Waterfall, no sabemos hasta el final del proyecto si tendrá éxito al final.
Agile, por otro lado, es una metodología que se basa en cambios frecuentes. Agile se utiliza para proyectos en los que no tenemos claridad sobre los requisitos.
El trabajo se realiza en iteraciones separadas, lo que generalmente toma 2 semanas. Con él, recibimos retroalimentación del cliente después de cada iteración. Si se necesita un cambio, se puede hacer de inmediato.
Puedo dar el siguiente ejemplo, si nuestro proyecto es para la construcción de un puente, elegiríamos el modelo Waterfall, si estamos desarrollando un producto de software Agile sería más apropiado.
Los modelos de desarrollo de los proyectos Agile/Flexible, Adaptive/ y Waterfall/Consistent/ se encuentran entre las metodologías más populares en la actualidad.
La diferencia entre ellos no es tanto teórica como práctica. Agile es un sistema de ideas y principios de gestión de proyectos «flexible», en base al cual se han desarrollado métodos populares de Scrum, Kanban y otros.
El principio clave es el desarrollo a través de ciclos cortos, al final de cada uno de los cuales el usuario recibe un código o producto de trabajo.
La naturaleza de esta metodología se reduce a los siguientes principios: las personas y las interacciones son más importantes que los procesos y las herramientas; Un producto funcional es más importante que una documentación completa; La cooperación con el cliente es más importante que negociar los términos del contrato; Estar preparado para el cambio es más importante que seguir el plan original.
Las ventajas de Agile: iteraciones cortas y claras: los ciclos de desarrollo duran de 2 semanas a 2 meses, al final de los cuales el cliente recibe una versión funcional del producto un alto grado de participación de los contratistas, organizadores y clientes del proyecto el producto del trabajo está a la vanguardia como un indicador clave del progreso; esto puede considerarse tanto una ventaja como una desventaja, ya que en este caso el equipo del proyecto tiene requisitos altos para la autoorganización minimizando los riesgos debido a un sistema Agile para realizar cambios ; la popularidad del método entre los desarrolladores de programas de gestión empresarial.
Desventajas de Agile: estimular cambios constantes en los proyectos: la flexibilidad del desarrollo del producto puede llevar a que nunca llegue a la versión final; mayores requisitos para la calificación y experiencia del equipo: además de la creación directa de un producto, el equipo debe analizar las posibles formas de mejorar la eficiencia de su trabajo, intercambiar constantemente información sobre el proyecto, estar motivado y autoorganizado.
Los recursos de los proyectos no siempre permiten atraer a tales especialistas; naturaleza filosófica de la metodología: Agile no es una instrucción clara para la acción, sino todo un concepto filosófico.
El equipo no puede aplicar mecánicamente mecánicas ágiles, se deben aceptar los principios clave del sistema; la complejidad de calcular la carga de trabajo total: estimular cambios y mejoras en el producto final conduce a un valor flotante de los costos del proyecto.
La cascada es una técnica de gestión de proyectos que implica una transición constante de una etapa a otra, sin saltar y volver a etapas anteriores.
Ventajas de Waterfall: una estructura clara y simple del proceso de desarrollo: esto reduce el umbral para la entrada de equipos; Informes convenientes: puede rastrear fácilmente los recursos, los riesgos, el tiempo empleado y las finanzas, gracias a las rigurosas etapas del proceso de desarrollo y la documentación detallada del proyecto; estabilidad de las tareas: las tareas antes del producto son claras para el equipo desde el comienzo del desarrollo y permanecen sin cambios durante todo el proceso; Estimación de los costos y condiciones para la entrega del proyecto: el tiempo de lanzamiento del producto final, así como su precio final, se pueden calcular antes del inicio del desarrollo.
Desventajas de Waterfall: un proceso sin flexibilidad, por lo que si un proyecto requiere más tiempo y recursos financieros de lo posible, entonces la fase de prueba pasará por el quirófano.
Según un estudio realizado por el equipo de consultoría de Rothman, el costo de la depuración posterior al lanzamiento es, en promedio, 20 veces más alto que con las pruebas completas de varias etapas durante el desarrollo; «Sostenibilidad» de los cambios: un marco rígido de las etapas de desarrollo y la condición de proporcionar solo el producto final determinan la imposibilidad de realizar cambios durante el desarrollo; inercia: en las primeras etapas, el pronóstico de tiempo y costos financieros puede cambiar hacia arriba, pero es imposible cambiar el proyecto a la optimización de costos, cambiar la funcionalidad o el concepto antes del lanzamiento del producto final; mayor riesgo: el sistema de prueba clásico incluye la prueba de cada uno de los componentes del proyecto por separado, incluso en interacción con otros.
Cuando se utiliza Waterfall, se prueba el producto terminado. En conclusión, se trata de dos métodos completamente diferentes para desarrollar y gestionar proyectos. Cada uno de ellos tiene decenas de modificaciones diseñadas para diferentes formatos.
El modelo Agile es adecuado para empresas de TI, nuevas empresas y proyectos innovadores. El modelo de cascada es más adecuado para proyectos en los que la clave es la limitación de tiempo, no la financiación.
La palabra Agile se ha puesto muy de moda estos días, pero hay que tener en cuenta que no todos los términos derivados de Japón se refieren a la gestión de proyectos en general.
Se trata más bien de procesos de producción y gestión de productos. Para ser más precisos, podemos decir que las características distintivas de este tipo de sistema de gestión de proyectos son la flexibilidad y la adaptabilidad.
Tiene un carácter iterativo y no sigue un patrón específico. Se caracteriza por la división de tareas en fases cortas de trabajo y frecuentes reevaluaciones y adaptaciones de planes.
Agile no es un enfoque riguroso y cualquier cambio que pueda conducir a una mejora se puede implementar incluso en el último minuto del desarrollo del proyecto.
Un ejemplo del uso de este modelo de gestión de proyectos puede ser el desarrollo de software.
Waterfall o modelo de cascada es considerado uno de los principales modelos de ciclo de vida para el desarrollo de proyectos y tiene su origen en los Estados Unidos.
Como su nombre indica, el modelo de la cascada se realiza secuencialmente de una etapa a otra. Es lineal y consistente, lo que significa que para pasar a la siguiente fase, la actual debe completarse en su totalidad.
Los equipos pasan mucho tiempo en cada etapa para que no haya errores y sea fácil pasar a la siguiente etapa, que podría ser la prueba del producto desarrollado.
Los casos en los que este modelo de gestión es aceptable son cuando no habría que hacer cambios cuando el proyecto es más pequeño y sencillo cuando no hay complejidad en la tecnología cuando hay más recursos disponibles.