Sandra Garrido Sotomayor Las metodologías ágiles son formas de organizar el trabajo en ciclos cortos, incorporar feedback frecuente y ajustar decisiones conforme aparece nueva información. Funcionan bien cuando todavía no conocemos del todo la solución, necesitamos aprender del usuario o podemos dividir el trabajo en entregas parciales. No todos los proyectos necesitan Agile ni Scrum, Kanban, Lean o XP sirven para lo mismo.
Buena parte de la confusión empieza al meter bajo la misma etiqueta cosas distintas. Agile reúne principios y prácticas. Scrum es un framework. Kanban gestiona el flujo de trabajo. Extreme Programming nació alrededor del desarrollo de software. Lean tiene una historia propia ligada a la producción. Lean Startup aplica experimentación y aprendizaje validado a nuevos productos y negocios.
Índice de contenidos
Qué son las metodologías ágiles
Agile propone trabajar con entregas frecuentes, colaboración cercana y revisiones periódicas del plan. La idea es sencilla: tomar algunas decisiones después, cuando sabemos más, en lugar de intentar resolverlo todo al principio.
El término se popularizó a partir del Manifiesto para el Desarrollo Ágil de Software, publicado en 2001 por diecisiete profesionales del desarrollo. Sus autores daban más peso a las personas y sus interacciones, al software funcionando, a la colaboración con el cliente y a responder al cambio.
El propio manifiesto aclara algo que se olvida con frecuencia: procesos, documentación, contratos y planes siguen teniendo valor. Agile no nació para trabajar sin ellos.
Con los años estas ideas salieron del software y se aplicaron a producto, innovación, emprendimiento, marketing y dirección de proyectos. La adaptación funciona cuando el trabajo permite aprender y corregir durante el recorrido. Copiar nombres de reuniones no basta.
De dónde viene Agile
En desarrollo de software era habitual definir durante meses lo que había que construir y descubrir demasiado tarde que el producto no respondía bien a las necesidades del usuario. Trabajar en partes más pequeñas permitía enseñar antes algo funcional, recoger feedback y corregir el rumbo con menos trabajo acumulado detrás.
La misma lógica puede funcionar al lanzar un nuevo servicio, diseñar una funcionalidad o probar una idea de negocio. Si podemos validar una parte antes de construir el conjunto, obtenemos información cuando todavía sirve para tomar decisiones.
En IEBS llevamos años trabajando con Agile y formando profesionales en Scrum, Kanban y gestión de proyectos. También hemos visto bastante Agile de escaparate: equipos con sprints, Dailies y tableros que siguen tomando las mismas decisiones de siempre.
Los principios que importan en el trabajo diario
- Dividir el trabajo. Entregar partes manejables permite revisar resultados antes de llegar al final.
- Recoger feedback pronto. Un usuario real encuentra problemas y necesidades que un documento de requisitos no siempre anticipa.
- Priorizar. El equipo decide qué merece atención primero en función de valor, riesgo y necesidad.
- Colaborar durante el proyecto. Negocio, usuarios y equipo comparten información mientras se trabaja.
- Revisar el plan. Nuevos datos pueden obligar a cambiar una decisión anterior.
- Mejorar la forma de trabajar. El equipo revisa bloqueos, errores y trabajo innecesario y actúa sobre ellos.
Pedir feedback sirve de poco si después nadie puede cambiar una prioridad. Lo mismo ocurre con los sprints cuando todo el plan está cerrado desde hace seis meses.
Agile no es lo mismo que Scrum
| Enfoque | Qué es | Para qué sirve | Cuándo encaja |
|---|---|---|---|
| Scrum | Framework iterativo | Organizar trabajo complejo mediante ciclos cortos y objetivos de producto | Productos o proyectos donde hay que aprender y repriorizar con frecuencia |
| Kanban | Método de gestión de flujo | Visualizar trabajo, limitar tareas en curso y mejorar el flujo | Operaciones y equipos con entrada continua de trabajo |
| Extreme Programming (XP) | Conjunto de prácticas de desarrollo de software | Mejorar el feedback técnico y mantener la calidad del código | Equipos de software con cambios frecuentes |
| Lean | Sistema de pensamiento y gestión | Crear valor reduciendo desperdicio y mejorando el flujo | Procesos en los que interesa analizar cómo se crea valor y dónde se pierde tiempo o recursos |
| Lean Startup | Enfoque para nuevos negocios y productos | Validar hipótesis mediante experimentación | Startups, nuevos productos y modelos de negocio aún no validados |
| Crystal | Familia de métodos ágiles | Adaptar las prácticas al tamaño y criticidad del equipo | Equipos que necesitan un método ligero y contextual |
| Design Sprint | Proceso intensivo de diseño y validación | Definir un problema, prototipar y probar una solución | Decisiones de producto o diseño que pueden validarse rápidamente |
| Agile Inception | Técnica de alineamiento inicial | Aclarar visión, usuarios, objetivos y alcance | Equipos que necesitan empezar con una comprensión compartida del proyecto |
Llamarlos a todos «metodologías ágiles» resulta práctico al hablar, pero borra diferencias. Lean, por ejemplo, procede de la gestión y la producción y tiene un alcance mucho mayor que un framework de proyectos. El Lean Enterprise Institute lo define como una forma de crear valor utilizando menos recursos y reduciendo desperdicio.
Scrum: iteraciones, backlog y revisión frecuente
Scrum organiza el trabajo en ciclos llamados sprints. La Scrum Guide define un equipo formado por Product Owner, Scrum Master y Developers, además de eventos, artefactos y compromisos.
El Product Backlog recoge y ordena el trabajo pendiente. Durante el sprint, el equipo trabaja para alcanzar un objetivo y producir un incremento. Al final revisa lo construido y también su propia manera de trabajar.
Las reuniones tienen una función concreta: coordinar, inspeccionar y decidir. Una Daily diaria no arregla prioridades impuestas, dependencias mal resueltas ni falta de autonomía.
Si quieres profundizar en el framework, tenemos una guía específica sobre cómo funciona Scrum.
Kanban: visualizar el flujo y limitar el trabajo en curso
Kanban suele asociarse al tablero, aunque el método va bastante más allá de mover tarjetas entre columnas.
La Kanban Guide trabaja con visualización del flujo, control del trabajo en curso y métricas que ayudan a detectar bloqueos y mejorar cómo avanza el trabajo.
Los límites WIP —Work in Progress— evitan que un equipo abra muchas tareas y termine pocas. Si veinte elementos están «en progreso» y solo dos avanzan, el tablero está enseñando un problema que antes quizá estaba escondido.
Kanban encaja bien en soporte, operaciones, mantenimiento o equipos donde las peticiones llegan de forma continua. Puede convivir con Scrum o con otros sistemas de gestión.
En nuestra guía de Kanban explicamos con más detalle los límites WIP y las métricas de flujo.
Extreme Programming, Lean, Lean Startup, Crystal y Design Sprint
Extreme Programming (XP)
XP nació en desarrollo de software y presta mucha atención a las prácticas técnicas. Programación en parejas, integración continua, pruebas automatizadas, refactorización y entregas pequeñas son algunas de las más conocidas.
Es especialmente útil cuando el software cambia con frecuencia y el equipo necesita evitar que cada modificación deteriore el código. Nuestro artículo sobre Extreme Programming desarrolla esas prácticas.
Lean
Lean estudia cómo se crea valor y qué trabajo consume tiempo o recursos sin contribuir a él. Su origen está ligado al sistema de producción de Toyota y posteriormente se ha aplicado a fabricación, servicios, producto y trabajo del conocimiento.
Lean Startup
Eric Ries trasladó parte de esa lógica al desarrollo de nuevos productos y negocios. Lean Startup utiliza experimentos y aprendizaje validado: construir una prueba, medir qué ocurre y decidir con lo aprendido. El ciclo Build-Measure-Learn resume esa forma de trabajar. (The Lean Startup)
Si todavía no sabemos si alguien quiere nuestro producto, dedicar seis meses a perfeccionarlo puede significar optimizar una idea equivocada.
Tenemos una guía específica sobre Lean Startup.
Crystal
Crystal es una familia de métodos creada por Alistair Cockburn que adapta las prácticas al tamaño del equipo y a la criticidad del proyecto. Da bastante peso a la comunicación, las entregas frecuentes y la capacidad del propio equipo para ajustar cómo trabaja.
Hoy tiene menos presencia que Scrum o Kanban, pero forma parte de la evolución de Agile. En IEBS tenemos una pieza específica sobre Crystal.
Design Sprint
Design Sprint es un proceso de diseño y validación popularizado por Google Ventures. Concentra definición del problema, ideación, prototipo y prueba con usuarios en un periodo corto.
Postgrado en Metodologías Ágiles
Aprende aquellas metodologías ágiles necesarias para desarrollar productos/servicios innovadores
¡Me interesa!Sirve para responder preguntas concretas sobre un producto antes de construirlo por completo. No gestiona por sí solo meses de desarrollo.
En IEBS explicamos también cómo funciona un Design Sprint.
Cuándo funciona bien Agile
Agile encaja bien cuando todavía no sabemos del todo qué solución necesitamos y podemos aprender mientras construimos.
Un equipo que desarrolla una aplicación puede enseñar una primera versión a usuarios y ajustar las siguientes prioridades. Un ecommerce puede probar un nuevo checkout antes de reconstruir toda la experiencia. Un equipo de innovación puede validar una hipótesis con un prototipo antes de aprobar una inversión mayor.
- Los requisitos pueden cambiar.
- La solución no está completamente definida.
- El trabajo puede dividirse en partes útiles.
- Podemos obtener feedback frecuente de usuarios o clientes.
- El equipo tiene margen para cambiar prioridades.
- La organización acepta revisar decisiones durante el proyecto.
Cuándo no compensa utilizar Agile
Un proceso muy estable y repetitivo puede necesitar otra cosa. Si fabricamos el mismo componente con una secuencia conocida, procesamos una operación bien definida o debemos seguir un procedimiento reglado, añadir sprints, historias de usuario y ceremonias puede introducir trabajo sin resolver ningún problema real.
También hay proyectos con dependencias físicas difíciles de alterar. No se instala el tejado antes de construir la estructura porque el equipo haya repriorizado el backlog.
En sectores regulados pueden utilizarse prácticas ágiles, pero siguen existiendo controles, documentación, validaciones e hitos obligatorios. Muchas organizaciones trabajan de forma iterativa dentro de ese marco.
Si el equipo tampoco puede cambiar prioridades, acceder al usuario o tomar decisiones, parte de Agile pierde utilidad. Puede conservar algunas prácticas, pero no toda la lógica de adaptación.
Agile frente a gestión predictiva
| Factor | Enfoque predictivo | Enfoque Agile |
|---|---|---|
| Requisitos | Más definidos al inicio | Pueden evolucionar durante el trabajo |
| Planificación | Mayor detalle inicial | Se revisa durante el proyecto |
| Entrega | Grandes fases o hitos | Incrementos más pequeños y frecuentes |
| Cambio | Puede exigir revisar alcance, coste o calendario | Está previsto dentro del proceso |
| Feedback | Se concentra en determinados hitos | Se busca con frecuencia |
| Contexto | Mayor certidumbre y estabilidad | Mayor incertidumbre y necesidad de aprendizaje |
Un proyecto con requisitos estables puede beneficiarse de una planificación detallada desde el principio. Otro con mucha incertidumbre necesitará revisar decisiones a medida que aprende.
Los modelos híbridos son habituales
Una misma organización puede gestionar de formas distintas trabajos distintos. Un banco puede utilizar Scrum para desarrollar una aplicación y mantener controles formales para presupuesto, auditoría y cumplimiento normativo. Un fabricante puede planificar de forma predictiva una nueva planta y utilizar Kanban para mantenimiento. Un equipo de producto puede trabajar por sprints mientras dirección revisa hitos financieros trimestrales.
En organizaciones complejas, combinar enfoques suele ser más práctico que imponer uno solo.
Tenemos una pieza específica sobre modelos híbridos de dirección de proyectos.
Cómo elegir el enfoque adecuado
| Pregunta | Qué conviene observar |
|---|---|
| ¿Cuánta incertidumbre existe? | Con mucha incertidumbre interesa aprender antes de cerrar demasiadas decisiones. |
| ¿Podemos dividir el trabajo? | Los incrementos útiles facilitan una gestión iterativa. |
| ¿Necesitamos feedback frecuente? | Cuando la solución depende del usuario, probar pronto reduce suposiciones. |
| ¿Los requisitos son estables? | Si apenas cambian, una planificación previa más detallada puede funcionar bien. |
| ¿El equipo tiene autonomía? | Sin capacidad para decidir y repriorizar, muchas prácticas ágiles quedan vacías. |
| ¿Existen dependencias fuertes? | Dependencias externas o secuencias rígidas obligan a planificar más. |
| ¿Hay regulación? | Puede exigir documentación, validaciones y aprobaciones que deben incorporarse al modelo de trabajo. |
| ¿Cuál es el coste del error? | Cuanto mayor sea, más control, pruebas y gobierno necesitaremos. |
Errores habituales al implantar Agile
Creer que Agile significa trabajar sin planificación
Un equipo ágil planifica producto, iteraciones, capacidad, riesgos y prioridades. Lo que no intenta es decidir con meses de antelación aquello para lo que todavía no tiene información suficiente.
Confundir velocidad con productividad
La velocidad de Scrum es una medida interna del trabajo completado. Cuando se utiliza para comparar equipos o premiar a quien acumula más puntos, las estimaciones empiezan a cambiar mucho antes que la productividad.
Hacer reuniones sin cambiar decisiones
Daily, planning, review y retrospectiva pueden ocupar una parte importante de la semana sin mejorar nada. Si las prioridades llegan cerradas, los problemas detectados nunca se corrigen y el feedback no altera el backlog, las ceremonias se convierten en agenda.
Llamar Scrum a cualquier trabajo por sprints
Scrum tiene una definición concreta. Utilizar Jira, celebrar una Daily y trabajar en periodos de dos semanas no basta. La Scrum Guide define responsabilidades, eventos, artefactos y compromisos.
Implantar Agile sin autonomía
Un equipo no puede autogestionarse si necesita permiso para cada decisión. La autonomía tampoco elimina presupuesto, objetivos, arquitectura, regulación o compromisos con otros equipos.
Comprar herramientas antes de arreglar el trabajo
Jira, Trello, Asana, Notion o un tablero de post-its hacen visible un proceso. No resuelven prioridades contradictorias, cuellos de botella ni decisiones que nadie quiere tomar.
Convertir Agile en burocracia
Cuando cada práctica genera otra reunión, otra plantilla y otro campo obligatorio, merece la pena revisar qué problema resuelve. Agile también puede llenarse de burocracia.
Qué puede aportar la inteligencia artificial
La IA puede resumir feedback, agrupar incidencias, preparar borradores de historias de usuario, documentar decisiones, analizar información de una retrospectiva o acelerar prototipos.
También puede transcribir reuniones, actualizar documentación o localizar dependencias. Hay que revisar los resultados: un modelo puede redactar una historia de usuario impecable sobre una necesidad que nadie ha validado o resumir veinte comentarios y perder el único que revela un problema serio.
La prioridad sigue siendo una decisión del equipo. La IA procesa información; no conoce por defecto qué riesgo puede asumir la empresa ni qué compromiso existe con un cliente.
Qué perfiles necesitan entender Agile
Product Managers y Product Owners lo utilizan para desarrollar y priorizar producto. Project Managers necesitan conocerlo para decidir cuándo conviene una gestión adaptativa y cuándo no. Scrum Masters trabajan directamente sobre Scrum y la efectividad del equipo.
También es útil para emprendedores, responsables de innovación y equipos digitales que trabajan con hipótesis y feedback frecuente. En operaciones, Kanban o Lean pueden encajar mejor que trasladar Scrum sin más.
No todo profesional necesita convertirse en agilista. Sí ayuda saber distinguir un backlog de una lista de tareas, un experimento de una entrega y una retrospectiva útil de una reunión que se celebra porque toca.
Cómo formarse en metodologías ágiles
En el Curso en Metodologías Ágiles: Introducción a Agile, Scrum y Kanban trabajamos los fundamentos y las diferencias entre los principales enfoques, incluido su encaje frente a modelos tradicionales.
Para profesionales que necesitan gestionar proyectos con una perspectiva más amplia, el Máster en Digital Project Management combina Scrum, Kanban y otros métodos con presupuesto, riesgos, dirección de proyectos y modelos híbridos.
Antes de elegir Scrum, Kanban o cualquier otro marco, conviene describir bien el trabajo: qué sabemos, qué puede cambiar, qué depende de terceros y qué necesita validación. A veces la respuesta será Agile. Otras veces no. Y no pasa nada.
Postgrado en Metodologías Ágiles
Aprende aquellas metodologías ágiles necesarias para desarrollar productos/servicios innovadores
¡Me interesa!
Considero que las metodologias agiles son como una caja de herramientas que nos permite moldearnos a la situacion, ha sido un material muy util para tener alternativas para gestion un proyecto de acuerdo a sus necesidades
Gracias por compartir este contenido sobre las metodologías ágiles. Sin duda es muy útil y práctico, un saludo
muy buena publicación muchas gracias!
Muchas gracias por la información compartida…!!!
Buenos días, el «Basecamp», pudiera ser considerado como herramienta en «Las metodologías ágiles » ?
Hola Emilio, muchas gracias por tu comentario. Tal y como comentas, el «Basecamp» es una herramienta de metodologías ágiles. Te animo a que te suscribas al blog para no perderte ninguno de los artículos que publicamos referente a las metodologías ágiles. Un saludo
En cuanto a la metodología ágil, yo utilizo el método Kanban. En mi empresa nos encanta trabajar con kanbantool.com/es/ . Dicha herramienta sirve para la gestión visual de proyectos, entre otros. Cumple con todas nuestras expectativas. ¡Saludos!
Hola Cornelia, muchas gracias por tu comentario y por aconsejarnos una herramienta para la gestión visual de proyectos. Seguro que es de ayuda para muchos profesionales. Un saludo
.muy buena la imformacion
esta muy interesante
Muchas gracias Leonardo
Buenas tardes, excelente información:
En empresas industriales cuando la diferencia entre el costo beneficio es alta, es muy factible, ya que al asumir costos del proyecto, estas se pagaran en corto tiempo para esto tiene que tener un seguro financiero que la rentabilidad de mismo negocio tiene que tenerla, deberá tener un equipo ágil de puesta en marcha para su feedback y retorno de la inversión, en empresas que tienen un producto único local en la zona es mas rápido el retorno de la inversión el el crecimiento del mismo.
Las metodologías tanto Tradicionales como «Agiles», deben estar siempre apegadas a cumplir con la satisfacción del cliente deseadas, para esto debe utilizarse un estilo (Marco de trabajo o metodología) que necesariamente involucre la revisión del avance en los productos por parte de cliente quien proveerá de la retroalimentación necesaria para tomar las decisiones y acciones pertinentes y a tiempo, llevando el proyecto por el camino de la satisfacción deseada. Así mismo la reducción del riesgo e incertidumbre juegan un rol protagonico, y no existe una mejor manera de reducirlos que detallando al máximo posible los requerimientos del producto, y por supuesto creando los canales de comunicación e integración de las partes involucradas (a lo interno entre los miembros del equipo de trabajo) y a lo externo con los clientes y usuario finales del producto que se quiere conseguir.
Cual es la diferencia entre una metodología y un marco de trabajo?
Buenos días Brihan,
¿Qué tal? Muchas gracias por tu comentario, me valgo de la wikipedia para resolver tu duda:
La metodología, hace referencia al conjunto de procedimientos racionales utilizados para alcanzar el objetivo o la gama de objetivos que rige una investigación científica, una exposición doctrinal o tareas que requieran habilidades, conocimientos o cuidados específicos. Con frecuencia puede definirse la metodología como el estudio o elección de un método pertinente o adecuadamente aplicable a determinado objeto.
Un framework, entorno de trabajo o marco de trabajo es un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.
Espero haberte ayudado.
Saludos
o sea es lo mismo !
Al menos en mi experiencia en bancos comerciales, cuesta mucho que los usuarios le dediquen tiempo a un proyecto, principalmente en la etapa de definición de requerimientos y pruebas. No me imagino cómo lograr una participación activa y permanente de ellos a lo largo de un proyecto, a menos que esta metodología o marco de trabajo se implemente como un modelo a nivel de la empresa.
Buenos días Pablo.
¿Qué tal? Muchas gracias por compartir tu experiencia con nosotros.
Un saludo.
SCRUM es una metodología?, que yo tenga entendido es un marco de trabajo.
Buenos días Luis,
¿Qué tal? Muchas gracias por tu comentario. Es cierto que existe algo de controversia, existen expertos que lo consideran una metodología y otros un marco de trabajo.
Un saludo.
cómo sabes qué es «a tiempo»? funcionamente puede ser perfecto, un entregable completo…sin embargo, técnicamente puede ser un completo desastre, por ejemplo: un equipo de desarrollo coloca una librería de aplicación en la librería del servidor, corre, está funcionalmente correcto, nadie se percata, y va a producción. en donde nadie lo puede cambiar, por que obviamente funciona excelente!, pero, e un nuevo desarrollo desean innovar con una versión superior y necesitan colocar esa librería de la aplicación en la aplicación, pero la librería de la versión anterior fue puesta en el servidor e impide la compilación. Absoluto desastre.
Scrum es una moda, sin embargo debe verse también la arquitectura, los patrones y las buenas prácticas. No basta con que funcione en el plazo establecido, por que si no tiene buenas prácticas, puede impedir futuros desarrollos.
Hola Paul,
Muchas gracias por tu aportación, como veo no te convence esta metodología. ¿Has tenido alga mala experiencia que quieras con nosotros?
Un saludo.
Muy buen artículo.
Pero yo tengo un debate: en muchos sitios encontramos las bondades de los marcos de trabajo Agile, pero pocos hablan de sus desventajas y aquí menciono algunas.
– Los proyectos son distintos unos de otros, difícilmente encontraremos 2 iguales, por esta razón es bastante complicado detectar en la planeación todos los riesgos y sus planes de contingencia, las metodologías Agile aunque lo contemplan, no están libres de esta incertidumbre.
– Otra característica de Agile, en Scrum para ser específico, es que un equipo puede llegar a acumular muchas tareas incompletas en sus backlog, esto debido a la propia flexibilidad que brinda el marco de trabajo.
– La acumulación de tareas incompletas, los problemas surgidos al vuelo, y las constantes adecuaciones solicitadas por el cliente, Product Owner o por el propio equipo, aumentan los costos, esfuerzos y tiempos los cuales son invisibles hasta ya muy avanzado el proyecto.
– Generalmente un equipo deberá trabajar junto por mucho tiempo aplicando estos marcos de trabajo antes de lograr la eficiencia, eficacia, calidad, rapidez, motivación y bajos costes que la misma metodología promete.
Hola Armando,
En primer lugar agradecerte tu feedback porque aporta mucho a nuestra comunidad. Supongo que hablas desde la experiencia cuando describes estas desventajas. ¿No crees que una persona bien formada conseguirá lidiar con esto problemas?
Muchas por leernos!
Un saludo
Para que las ágiles lleven a resultados el Director del Proyecto debe ser un planificador muy experto, que haya hecho proyectos duros con PMBOK que sepa gerenciar. Sino estamos fritos.
Hola Víctor,
Muchas gracias por tu aportación, cuéntanos más acerca de tu experiencia así nos ayudas a crecer en la comunidad.
Un saludo.
No estoy de acuerdo, antes de siquira conocer los procesos del PMI y el PMBOK la aproximación Agile me sirivió para lograr concretar proyectos. Lo que es cierto es que si tú o tu orgzanización no buscan obtener buenos hábitos o disciplina no habrá metodología ni marco de trabajo que te salven. Hoy ya hasta comparto mi experiencia en internet80.com 😀 saludos!
Hola Emmanuel,
Muchas gracias por tu aportación, nos ayuda a mejorar nuestra comunidad. 🙂
Buen día, saludos.
He trabajado con SCRUM años y la verdad no considero que las metodologias agiles sean adecuadas para la calidad del software todo lo contrario lo han empeorado, hablas maravillas de ellas pero NO ES CIERTO y sabes porque porque la mayoria no sabe ni siquiera planear un proyecto
¡Hola! Lamentamos que en todos tus años de trabajo dicha metodología no te haya servido para agilizar tus tareas. No obstante, no te desanimes, al principio es complicado llevar a cabo un gran proyecto, a pesar de ello, a muchas personas les ha servido para encontrar el punto de equilibrio en sus proyectos. Si quieres puedes compartirnos tu experiencia o probar con otras metodologías que se adapten mucho mejor a tus necesidades diarias.
Muchas gracias
¡Saludos!
Buenisimo, me sirve para sumar conocimientos en la carrera que estoy cursando de mkt y publicidad digital. Gracias por el aporte, voy a analizar de sumarme a la formación. Saludos
Excelente articulo, muy concreto.
Felicitaciones.
¡Gracias Mauro! Una de las ventajas de un proyecto ágil es la concreción, por lo que está muy bien que destaques eso mismo del artículo 😉
Excelente Información!