Waterfall vs Agile: ¿Cuál Metodología Debes Utilizar Para tu Proyecto?
He estado trabajando en la gestión de proyectos durante bastante tiempo (no voy a dar cifras exactas aquí, pero he estado presente desde los días donde los iPhones eran un destello lejano en los ojos de Steve Jobs y Facebook era EL Facebook…) y he vivido el debate más grande en la industria: Waterfall vs Agile.
Si hay algo con lo cual los gerentes de proyectos, y específicamente los gerentes de proyectos digitales siempre han estado obsesionados, es la metodología. Pero las metodologías son un gran problema en el mundo de la administración de proyectos. ¿Por qué articulamos todo lo que hacemos a su alrededor? ¿Realmente importan tanto?
En este artículo veremos cuáles son las metodologías centrales utilizadas en la gerencia de proyectos digitales, qué debes elegir y si existe una solución diferente.
En resumen, abordaré estos temas:
- ¿Cuáles son estas ‘metodologías de gestión de proyectos’?
- ¿Qué metodología debo utilizar en mi proyecto?
- ‘Quiero pasar a usar la metodología Agile, pero es demasiado difícil de implementar’
- ‘¿Una metodología garantiza el éxito del proyecto?
1. ¿Cuáles Son Estas ‘Metodologías de Gestión de Proyectos’?
Entonces, ¿qué es una metodología de un proyecto (aparte de ser una frase realmente aburrida)? Es un marco de los procesos involucrados en tu proyecto y tu gestión del mismo. Por lo general, implica tareas básicas que incluyen iniciar, planificar, ejecutar, monitorear y cerrar el proyecto.
Hay un montón de metodologías de proyectos para elegir. Existen las más tradicionales, lineales, como la famosa Waterfall o modelo de cascada. Luego está el marco Agile o la metodología ágil, con diferentes ramas: Scrum, Kanban y Lean, por ejemplo. Está la Gestión de Cadena Crítica, la Gestión de la Realización de Beneficios, la Programación Extrema, Prince2, el Marco de Proyecto Adaptativo – la lista sigue y sigue.
Voy a centrarme en “los dos grandes” que surgen una y otra vez cuando se habla de la gestión de proyectos digitales. Entra en escena el enemigo del mundo DPM, Waterfall, y en la otra esquina, Agile: la “bala de plata”, la “fórmula mágica”. Después de todo, Agile es el mejor, ¿verdad?
No necesariamente. Ambas metodologías tienen beneficios, y ambas tienen proyectos que se adecúan a ellos. Así que echemos un vistazo más profundo a cada uno.
Agile Vs Waterfall: Principios
Principios básicos de Waterfall
Recopilación de requisitos al inicio:
Los desarrolladores y los clientes están de acuerdo en lo que se entregará al principio del ciclo de vida del desarrollo. Esto puede hacer que la planificación y el diseño sean más sencillos. El progreso se mide más fácilmente, ya que el alcance completo del trabajo se conoce de antemano. Una buena documentación técnica es parte de los resultados y es más fácil para los nuevos programadores ponerse al día durante la fase de mantenimiento.
Trabajo completado secuencialmente en fases:
Cada fase generalmente comienza a medida que termina la anterior. A lo largo del desarrollo, varios miembros del equipo pueden participar o continuar con otros trabajos. Por ejemplo, los evaluadores pueden preparar scripts de prueba a partir de la documentación de requisitos mientras la codificación está en curso.
El enfoque es muy estructurado y puede ser más fácil medir el progreso con hitos claramente definidos, y más fácil de planificar al principio.
Las pruebas se producen al final del desarrollo:
Las pruebas son más sencillas de planificar y ejecutar, ya que se puede hacer por referencia a los escenarios definidos en la especificación funcional, al final de la fase de desarrollo.
Los clientes o partes interesadas no necesitan involucrarse mucho:
A excepción de las revisiones, aprobaciones y reuniones de estado, la presencia del cliente no es estrictamente necesaria después de la fase de requisitos.
Más sobre Waterfall | Herramientas de administración de proyectos de Waterfall | El administrador de proyectos de TI: cómo gestionar proyectos de Waterfall
Principios básicos de Scrum
En 2001, un grupo de desarrolladores se reunió y desarrolló lo que ahora se conoce como el Manifiesto Ágil, que describe los cuatro valores que vieron que respaldan esta forma de abordar el desarrollo. En estas 200 palabras, prácticamente cambiaron el aspecto del desarrollo de software y generaron industrias masivas a partir de él.
Si bien Agile es el marco, Scrum es el enfoque o modelo de desarrollo que utiliza Agile. Como verás, tanto el marco como los aspectos específicos de Scrum tienen sentido cuando piensas en el desarrollo de un proyecto digital.
Individuos e interacciones por encima de procesos y herramientas:
En primer lugar, se enfoca en individuos e interacciones por encima de procesos y herramientas. La comunicación es clave, no los procesos que ejecutan su proyecto. Dentro de Scrum, esto significa el equipo auto-organizativo y multifuncional.
Software de trabajo por encima de documentación completa:
Existe un fuerte enfoque en obtener productos que se pueden enviar con mayor rapidez, en lugar de gastar mucho tiempo en escribir los requisitos. En Scrum, las iteraciones de trabajo con límite de tiempo se ejecutan con un producto distribuible al final de cada iteración.
Colaboración con el cliente por encima de la negociación del contrato:
Los valores de Agile especifican la colaboración del cliente, trabajar con el cliente en todos los puntos y participando activamente en todo el proceso. Scrum tiene una participación constante y regular del cliente.
Responder al cambio por encima de seguir un plan:
En lugar de considerar al cambio como el enemigo, estar en una posición para considerar al cambio como algo bueno y responder a él es fundamental para el marco ágil. Scrum tiene requisitos que evolucionan constantemente, y el cambio se acepta.
Todas estas cosas realmente tienen sentido cuando se habla de lo digital. La comunicación como equipo, hacer que algo funcione rápidamente, involucrar al cliente y, cuando lo digital es un panorama en constante cambio, poder responder rápidamente al cambio.
Más sobre Scrum | Más sobre Agile | Herramientas ágiles | Scrum: una introducción breve y ágil impresionante
2. ¿Qué Metodología de Gestión de Proyectos Debo Usar en mi Proyecto?
¿Qué debe influir en tu decisión sobre qué metodología aplicar a un proyecto? ¿Qué define la pelea de Waterfall vs Agile? Hasta que sepas qué es el proyecto y otros factores de influencia, no podrás decidir cuál es la más adecuada. Algunos (o todos) de estos factores deben tenerse en cuenta al considerar las metodologías:
- Tamaño del proyecto
- Duración
- Complejidad
- Factores organizativos
- Clientes o partes interesadas, externos e internos.
¿A qué proyectos se puede adaptar Waterfall?
Los proyectos para la metodología en cascada son:
- Proyectos en los que trabajas con otras organizaciones o trabajadores remotos
- Proyectos con un alcance, tiempo y presupuesto fijos.
- Proyectos más pequeños, bien definidos y más simples
- Proyectos con un cliente ausente.
¿A qué proyectos se puede adaptar Agile?
Los proyectos para metodologías ágiles (o enfoques ágiles) son:
- Proyectos en los que su organización es responsable de todo el proceso.
- Proyectos con posibilidades de cambiar los requisitos.
- Proyectos más grandes, indefinidos y complejos.
- Proyectos con un cliente involucrado.
Pero, ¿las organizaciones realmente toman en cuenta todos estos factores? ¿Qué o quién decide realmente un proceso? Posiblemente lo que influye principalmente en la elección de la metodología son los procesos existentes. Es probable que los procesos actuales de tu organización determinen cómo ejecutas tu proyecto, cualquiera que sea. Es el enfoque clásico de talla única para todo. Dado que cada proyecto tiene diferentes necesidades y puede diferir bastante en los factores de influencia, esta no es la mejor manera de ejecutar cada proyecto en tu organización.
¿Cómo utilizo realmente estas metodologías?
Saber la diferencia teórica entre un Scrum model y un waterfall model es una cosa, pero ¿cómo hacemos para, como gestores de proyecto, poner en práctica estas metodologías y así maximizar los beneficios para nuestros equipos internos y nuestros clientes?
Aprende a utilizar un enfoque estratégico de estas metodologías en el mundo real con nuestro curso en línea. Con una capacitación relevante, práctica y dirigida por expertos, te convertirás en una fuente de análisis para tus equipos y clientes que te permitirá navegar con confianza las pruebas de administración de proyectos.
Venga, ¿cuál es mejor?
Me he mantenido al margen hasta ahora, diciendo que las dos metodologías de gerencia de proyectos o desarrollo de software que he presentado tienen beneficios por derecho propio. Pero si vivimos en un mundo ideal, el enfoque ágil se adapta más a los proyectos digitales puros. Todos los principios parecen encajar en el panorama digital, donde las necesidades cambiantes y los cambios están presentes en todos los proyectos. Para acabar la confrontación de Waterfall vs Agile, voy a echar un vistazo a algunos de los beneficios claves a continuación.
Las iteraciones
Las iteraciones regulares del trabajo, que incluyen las pruebas y revisiones realizadas por las partes interesadas cada dos semanas (cada iteración o “sprint”, por ejemplo) realmente ayudan a mantener un proyecto en marcha.
Hace unos años estaba gestionando un proyecto en el que teníamos que trabajar utilizando un modelo cascada. Todo fue definido y diseñado por otra agencia. No teníamos un sitio de preparación configurado en ese momento, por lo que el desarrollador estaba trabajando localmente en su máquina (primer error). Tuvimos reuniones frecuentes y las cosas parecían ir bien. Sin embargo, no vimos un producto en funcionamiento hasta que ingresamos en el control de calidad inicial. En este punto descubrimos que había grandes partes sin terminar y que el CMS no se había construido correctamente y de acuerdo a las especificaciones. Si hubiéramos tenido iteraciones regulares de construcción de un producto distribuible, probablemente hubiéramos evitado esto. Hay mucha más exposición al producto a lo largo del proyecto.
Piensa en dos de las reuniones que tienes en Scrum: la revisión, donde se revisa la compilación al final de la iteración, y la retrospectiva, donde se revisa el trabajo completado en la iteración. Esas son tus primeras señales de advertencia para cualquier cosa que se desvíe del camino.
Participación del cliente
Se realizó una revisión del proyecto de software y de TI durante un período de cinco años, denominado Manifiesto del Caos, publicado en 2013. Encontraron que el factor más importante en el éxito del proyecto era un patrocinador ejecutivo o propietario del producto comprometido. Cuando el cliente participa en la configuración de los requisitos a lo largo del proyecto, como la revisión del trabajo y la definición de prioridades, significa que es menos probable que produzcan sorpresas repentinamente. Están constantemente introduciendo los requisitos del negocio y del usuario en el proceso.
En un proyecto en el que trabajé hace unos cinco años, el cliente no estaba muy involucrado. Tuvimos un check-in semanal, pero lo único que querían era un informe de estado semanal, que fuera entregado los lunes. Tratamos de involucrarlos más en las reuniones y definiciones reales de UX, sin embargo, estaban demasiado ocupados en otro proyecto. Llegamos a la presentación, y su primer comentario fue “Estos wireframes se ven muy tristes”. Sí, en serio. Yo estaba manejando un proyecto con ‘wireframes tristes’. Cara triste, más bien. :(
Aparte de la falta de comprensión del propósito de los wireframes, no habían suministrado sus requisitos al proceso de manera adecuada, y no estaban involucrados en la evolución de la idea. Así que tuvimos que retroceder y perder unas pocas semanas del proyecto. Una experiencia que aviva el debate de Waterfall vs Agile.
Colaboración en equipo
En lugar de que UX trabaje para definir el proyecto, luego se lo entregue a diseño y ellos luego se lo entreguen a desarrollo, con todos en sus propias áreas aisladas: puedes evitar muchos problemas si el equipo colabora durante el proyecto. Como se puede ver en el proyecto del que hablé antes con el desarrollador trabajando más en forma aislada, si hubiera habido más colaboración, podría haber evitado sorpresas hacia el final.
Requisitos en constante evolución
Este es uno de los beneficios cruciales de los marcos Agile y Scrum. Aceptan y hacen frente al cambio de una mejor manera. Cambiar el alcance y los requisitos no hacen que el proyecto caiga en crisis. De hecho, este es el objetivo de la revisión de la iteración y la reunión de planificación de la iteración, para determinar qué cambios son necesarios. En proyectos más lineales, los planes se elaboran meses antes del desarrollo y se basan en estimaciones generalmente aproximadas en ese momento, y luego se escriben sobre piedra.
Afrontemos la verdad: los planes de proyectos lineales simplemente no funcionan, algo que, en la pelea de Waterfall vs Agile, le da la ventaja a éste último.
Donde se establecen los requisitos al comienzo, y los productos y plazos se resuelven con meses de anticipación, ¿qué sucede entonces? Las cosas cambian, y esto lleva a retrasos en los proyectos, ya que todo tiene que ser rediseñado y redefinido.
– “Durante un período de 5 años, un promedio del 53% de los proyectos se pasaron del costo, y el 76% se ejecutó a destiempo”
Si tomamos un ejemplo de una agencia que ejecuta un promedio de 50 proyectos en un año, eso es más de 25 proyectos que se pasan del costo y 37 proyectos (de 50!) que se ejecutan a destiempo. Algo obviamente no está funcionando.
He aquí un gran ejemplo:
Cuando creo un plan de proyecto lineal, esto suele suceder. Esta es mi carpeta de horarios, ¿has visto algo como esto antes? Algo en el proyecto cambia, por lo que se modifica el plan. Entonces el cliente quiere agregar algo al alcance, así que… aquí vamos de nuevo. En este proyecto he creado 10 versiones. (Y sí, también me doy cuenta de que necesitaba una carpeta de archivo…)
No recuerdo la última vez que, en un proyecto lineal más tradicional, no tuve que modificar el plan del proyecto al menos dos veces durante su curso. Eso es porque los proyectos cambian. Los clientes cambian. El usuario necesita cambiar. Hay cambios tecnológicos. Lo digital está en constante cambio. Por lo tanto, los marcos ágiles tienden a tener mejores formas de responder al cambio. De hecho, lo aceptan en lugar de verlo como un gran golpe para el proyecto.
3. ‘Quiero Pasar a Agile, Pero es Demasiado Difícil de Implementar’
Sin embargo, no siempre es fácil implementar los enfoques de Agile de forma completa o inmediata en las organizaciones. Como hemos visto, hay muchos factores involucrados en la implementación de un proceso. Los enfoques ágiles no siempre se adaptan a las agencias en las que los clientes quieren un alcance fijo, un presupuesto y líneas de tiempo por adelantado. Entonces, nace lo híbrido. Sí, es probable que todos hayan escuchado el término sucio, Wagile…
Cuando estaba investigando para mi charla sobre este tema para Deliver Conf el enero pasado, busqué el término ‘Wagile’ y encontré un par de artículos de este desarrollador. Esta es mi cita favorita, muy condenatoria:
“WAgile, como [todos] sabemos, significa “Waterfall-Agile”, y es el pináculo de las metodologías de desarrollo disfuncional. Sí, amigos: literalmente, miles de proyectos han fracasado a la manera de WAgile ”
Escribió esto en 2008, cerca del tiempo cuando nació el término. Y a pesar de la indignación excesiva, puedo ver de dónde viene. Mucha gente hace mal uso del término ágil. He visto que muchas organizaciones clasifican un proyecto como ágil porque tienen una reunión diaria, por ejemplo.
¿Qué es un híbrido?
Un proyecto en cascada o lineal sigue las etapas clave en secuencia: descubrir, definir, construir y luego probar y desplegar al final.
Lo que he visto con frecuencia en organizaciones, bajo el nombre de Ágil, es lo siguiente:
Dividir el desarrollo en dos semanas y hacer un seguimiento diario, no significa que sea ‘ágil’. Si estás siguiendo este proceso lineal de descubrimiento, definiendo por adelantado, para luego construir y probando de forma secuencial, sigue siendo un proyecto lineal. Todos los requisitos se definen al principio, y esto es lo que estás siguiendo dentro de cada fase de compilación.
En un proyecto verdaderamente ágil, el proceso se parecerá más a esto, con cada fase contenida dentro de las iteraciones:
Con las dificultades en torno a la implementación de Agile, un movimiento continuo hacia la entrega ágil es muy difícil para muchas organizaciones. Tener tanta participación del cliente, con una falta general de comprensión, que cuestiona cómo funciona la UX, o tal vez una relación histórica con un cliente. Hay muchos factores que hacen que sea difícil de implementar.
Es más fácil de implementar un cambio gradual hacia la adopción de los principios ágiles y el proceso Scrum, por ejemplo, utilizando un híbrido. Sé que puede ser bastante controvertido decirlo (y podría enojar a los puristas ágiles), pero para mí, un híbrido es una solución más realista, al menos mientras avanza la transición.
Así es como se vería el flujo:
Cómo implementar un híbrido
¿Trabajas en una organización que sigue las formas más lineales de trabajo, pero crees que los proyectos se beneficiarían con un enfoque ágil? ¿Cómo ayudas a tu organización a avanzar hacia una solución más híbrida?
1. Participación del cliente
Ideal: un propietario de producto habilitado y disponible
Un problema central suele involucrar al cliente o parte interesada como propietario de producto. Deben estar muy involucrados, y puede que esto sea difícil cuando están involucrados en otros proyectos. A menudo, tampoco están acostumbrados a esto. Habitualmente, simplemente esperan darte el trabajo, y luego saber cómo va todo en un informe de estado una vez por semana.
Híbrido: ayuda a cerrar la brecha entre los interesados ??y el equipo
En un proyecto en el que trabajé, ayudamos a cerrar esa brecha. Actuamos como el propietario del producto, pero conseguimos que el cliente aceptara participar en las reuniones centrales (como las revisiones y la planificación), y nos aseguramos de que estuviera involucrado en el establecimiento y definición de los requisitos en cada etapa.
2. Colaboración de Equipo
Ideal: un equipo multifuncional y dedicado
Obtener un equipo multifuncional y dedicado al proyecto puede ser difícil. Esto puede ser especialmente cierto en organizaciones más pequeñas donde hay muchos proyectos en curso y se espera que los miembros del equipo trabajen en más de un proyecto.
Híbrido: los miembros del equipo se mantienen involucrados durante todo el tiempo
Asegúrate de que, como mínimo, los miembros del equipo están trabajando juntos y colaborando. Si no puedes reservar a los miembros del proyecto a tiempo completo en cada iteración, intenta asegurarte de que estén incluidos en las discusiones regulares con el equipo de desarrollo, las tareas diarias, la planificación y las revisiones. Un equipo que se comunica entre sí puede ayudar al proyecto a tener éxito.
3. Planificación continua
Ideal: requisitos de planificación por iteración
Cambiar la forma de pensar del cliente o de las partes interesadas también es crucial para que los requisitos no se establezcan al comienzo del proyecto en una especificación de funcionalidad estricta, a la que estás vinculado en el transcurso de un proyecto. Pero los clientes y las partes interesadas usualmente tienen miedo de esto. Quieren saber qué reciben cuando aprueban el presupuesto.
Híbrido: algo de conformación inicial, pero deja la planificación detallada para la iteración
Observa si puedes realizar alguna conformación por adelantado de los requisitos del proyecto, pero deja la planificación detallada para las iteraciones. No identifiques todos los resultados en primera instancia, de modo que puedas reaccionar para cambiar en el camino. Entrena al cliente para obtener la aceptación de este enfoque de planificación. Resume los aspectos positivos de ser receptivo al cambio a lo largo del proyecto.
4. Diseñar lo que se necesita
Ideal: diseño dentro de cada iteración
¿Cómo encaja el diseño? Lo ideal sería ejecutar esto en cada iteración, de modo que diseñes solo lo que es necesario para cada iteración de trabajo.
Híbrido: Diseño en el último momento responsable
El diseño debe hacerse en el último momento responsable. En lugar de un montón de diseños iniciales que definen los requisitos con anticipación, diseña lo que necesitas tan tarde como sea posible. Esto evitará diseñar elementos innecesarios que ni siquiera se usan al final. Esto nuevamente se remonta a la colaboración, y a que los diseñadores, los desarrolladores y, de hecho, todos los involucrados en el proyecto, trabajen juntos en una iteración en una fase de trabajo con límite de tiempo.
Ayuda a que la transición sea exitosa
Obtén ayuda
Haz uso de capacitación, mentores y entrenamiento para ayudar a explicar los beneficios de un enfoque diferente. Esto va para ti, tu equipo y, lo más importante, tu cliente.
Obtén el apoyo de la directiva
Ningún proceso cambiará sin el apoyo de la directiva. Asegúrate de establecer los beneficios y el enfoque para la adopción. Si puedes presentar un plan definitivo de cómo se incorporarán los clientes y las partes interesadas, esto ayudará enormemente a la transición.
Sé realista
Por último, si las cosas no funcionan, no te excuses. Agile es iterativo. Tu implementación del proceso también debería serlo. Las revisiones periódicas de cómo van las cosas ayudan a detectar problemas y resolverlos con mayor rapidez.
En lugar de poner excusas sobre cómo va el proyecto, ‘oh, estamos implementando un nuevo proceso que seguramente tendrá problemas’, presenta planes de acción sobre cómo solucionarlos y seguir adelante. Si fallas, falla rápido y sigue adelante.
Errores comunes que debes tener en cuenta
Al definir tu propio proceso híbrido, hay algunos errores comunes que debes tener en cuenta.
No tienes proceso o estructura
En lugar de seguir algo, haces lo contrario y no tienes nada concreto o definido en absoluto. El proyecto se convierte en un desastre porque no hay forma de trabajar en absoluto.
Las personas del equipo hacen cosas diferentes
Si los miembros de tu equipo realmente no saben cómo deberían estar trabajando, es posible que comiencen a actuar en la tangente y no se enfoquen en lo que deberían hacer.
Procesos sólo porque sí
Esto es realmente importante: no pongas en marcha procesos sólo porque sí. No agregues documentación innecesaria sólo porque sí. Mantén el proceso lo más ágil posible con la metodología que estés siguiendo.
Un enfoque de talla única
Tenga cuidado con el enfoque de talla única: la idea de que debido a que algo tuvo éxito una vez, funcionará para todo. Asegúrate de que estás pensando en cada proyecto como una entidad separada. Debe haber una cohesión en los procesos de una organización, sin embargo, cada proyecto es diferente y debe ser tratado como tal.
4. La Pregunta Final: ¿Una Metodología Garantiza el Éxito del Proyecto?
Mucha gente está tan obsesionada con metodologías particulares o con la confrontación de Waterfall vs Agile que piensan que si usan una de ellas, esto significará que el proyecto tendrá éxito automáticamente. Sin embargo, creo que el éxito del proyecto desde una perspectiva de gestión de proyectos se basa en las habilidades, las llamadas habilidades “duras” y “blandas”. Realmente no me gustan estos términos, así que usemos ‘prácticas’ y ‘personales’. Las habilidades prácticas son las habilidades duras, las cosas concretas y aprendidas. Personales son las habilidades blandas, más arraigadas y que vienen de cómo eres en lugar de lo que haces. Voy a desglosarlas un poco más.
Personales
- Comunicación – Permitiendo la colaboración y la transparencia
- Liderazgo – Motivación y orientación
- Flexibilidad – Permitiendo y respondiendo al cambio
- Solucionador de problemas – Buscando soluciones
Prácticas
- Estimación de costos y tiempo
- Conocimiento técnico
- Evaluación del riesgo
- Proceso del proyecto
Ahí está, en el último punto, la metodología, el marco o procesos seguidos en el proyecto. Así que realmente es solo una parte de todo el conjunto de cosas que conforman una gestión de proyectos exitosa y proyectos exitosos.
De hecho, estaba hablando con mi jefe de recursos humanos cuando escribí mi charla original sobre este tema. Le conté acerca de esta división, ya que estábamos trabajando para implementar un programa de mentores para nuestros alumnos graduados en administración de proyectos. Ella dijo que la contratación de personas que muestran las habilidades personales es mucho más importante que aquellas que muestran habilidades prácticas, especialmente para las personas que recién ingresan a la industria. En general, las personas pueden aprender las habilidades prácticas y cómo implementarlas en proyectos, siempre que muestren el deseo de aprender. Pero las habilidades personales están más arraigadas y son fundamentales para el éxito como administrador de proyectos.
La lección: Concéntrate en lo que realmente importa: comunicación, liderazgo, flexibilidad y resolución de problemas.
Obtén Capacitación Relevante, Práctica y Dirigida Por Expertos
Mire esta descripción general de nuestro próximo curso en línea ‘Mastering Digital Project Management’ obtén instrucción de expertos para liderar equipos felices y entregar proyectos de alto valor en el mundo digital.
¿Qué Opinas?
Después de ver los pros y contras de cada una, ¿qué será? ¿Waterfall vs Agile, o Wagile? ¿Podría una metodología híbrida ser una buena alternativa en la transición a Agile? ¿Cuáles son tus experiencias y éxitos (o fracasos) al ejecutar proyectos en Waterfall, Agile o Wagile? Únete a la conversación y comparte tus pensamientos.