Introducción
En el actual entorno tecnológico en constante evolución, las organizaciones enfrentan una presión creciente para entregar productos de software de alta calidad más rápidamente, al mismo tiempo que mantienen la flexibilidad y la capacidad de respuesta ante las cambiantes demandas del mercado. Las metodologías tradicionales de gestión de proyectos a menudo tienen dificultades para adaptarse a estos requisitos, lo que conduce a fechas límite incumplidas, excesos presupuestarios y stakeholders insatisfechos. El marco ágil Scrum ha surgido como una solución poderosa ante estos desafíos, ofreciendo un enfoque estructurado pero adaptable al desarrollo de software que enfatiza la colaboración, el progreso iterativo y la mejora continua.
Esta guía completa explora los principios fundamentales del marco ágil Scrum y presenta un estudio de caso detallado que demuestra cómo las organizaciones pueden implementar con éxito este marco para transformar sus procesos de desarrollo y lograr resultados comerciales medibles.
Comprendiendo el marco ágil Scrum
El marco ágil Scrum representa un cambio de paradigma en la forma en que los equipos abordan la gestión de proyectos y el desarrollo de software. En su núcleo, Scrum se basa en los principios de transparencia, inspección y adaptación, lo que permite a los equipos entregar valor de forma incremental mediante ciclos de trabajo estructurados llamados sprints. Esta metodología descompone proyectos complejos en fragmentos manejables, permitiendo a los equipos responder rápidamente a los comentarios, ajustar sus prioridades y mejorar continuamente sus procesos.
La fortaleza del marco reside en su simplicidad y claridad. Al definir roles, eventos y artefactos específicos, Scrum crea un ritmo predecible que ayuda a los equipos a mantener el enfoque al mismo tiempo que permanecen adaptables al cambio. La representación visual anterior ilustra cómo estas componentes trabajan juntas en un ciclo coherente, desde la planificación inicial hasta la ejecución, pasando por la revisión y la reflexión.
Componentes y procesos clave
Roles y responsabilidades
Propietario del productoEl Propietario del producto actúa como voz del cliente y de los interesados, responsable de maximizar el valor del producto. Esta función implica mantener el Backlog del producto, una lista dinámica y priorizada de características, correcciones de errores, mejoras técnicas y requisitos. El Propietario del producto debe equilibrar constantemente las necesidades de los interesados, las demandas del mercado y las limitaciones técnicas para asegurarse de que el equipo trabaje en los elementos de mayor valor.
Máster de ScrumEl Máster de Scrum actúa como un líder servidor para el equipo, facilitando los eventos de Scrum, eliminando obstáculos y asegurando que el equipo siga los principios y prácticas de Scrum. Este rol se centra en capacitar al equipo en la autoorganización y la multifuncionalidad, al tiempo que fomenta un entorno de mejora continua.
El equipo de desarrolloEl equipo está compuesto por profesionales multifuncionales que colectivamente poseen todas las habilidades necesarias para entregar incrementos de producto potencialmente entregables. A diferencia de las estructuras jerárquicas tradicionales, los equipos de Scrum son autoorganizados, lo que significa que determinan por sí mismos la mejor manera de realizar su trabajo, en lugar de ser dirigidos por personas externas al equipo.
Artefactos principales
Backlog del productoEl Backlog del producto es la única fuente de verdad sobre lo que debe construirse. Contiene todo lo necesario para el producto, ordenado por prioridad, valor, riesgo y necesidad. Los elementos en la parte superior del backlog se refinan y detallan, mientras que los que están más abajo permanecen más generales y menos definidos hasta que se acercan a la cima.
Backlog del sprintDurante la planificación del sprint, el equipo selecciona elementos del Backlog del producto y crea el Backlog del sprint, que representa su compromiso para el próximo sprint. Esto incluye no solo las características seleccionadas, sino también el plan para entregarlas, desglosado en tareas específicas.
IncrementoEl Incremento es la suma de todos los elementos del Backlog del producto completados durante un sprint, combinado con el valor de todos los sprints anteriores. Al final de cada sprint, el Incremento debe estar en un estado usable, independientemente de si el Propietario del producto decide liberarlo o no.
Ceremonias y eventos
Planificación del sprintEste evento colaborativo marca el inicio de cada sprint. Todo el equipo Scrum trabaja juntos para definir qué puede entregarse en el sprint y cómo se logrará ese trabajo. El equipo considera su capacidad, su velocidad histórica y la prioridad de los elementos del backlog para hacer compromisos realistas.
Reunión diaria de alineaciónTambién conocida como el Daily Scrum, este evento con límite de tiempo de 15 minutos se realiza a la misma hora y lugar cada día. Los miembros del equipo sincronizan sus actividades y crean un plan para las próximas 24 horas respondiendo tres preguntas clave: ¿Qué hice ayer? ¿Qué haré hoy? ¿Hay algún obstáculo en mi camino?
Ejecución del sprintDurante el sprint, el equipo trabaja para completar los elementos comprometidos del backlog. El Máster de Scrum protege al equipo de interrupciones externas, mientras el equipo se autoorganiza para gestionar su trabajo. El progreso se rastrea visualmente, utilizando a menudo tableros de tareas y gráficos de consumo de trabajo.
Revisión del sprint Realizado al final de cada sprint, este encuentro informal permite al equipo demostrar el trabajo completado a los interesados. Es una oportunidad para recopilar comentarios, discutir lo logrado y adaptar el Product Backlog según nuevas perspectivas o prioridades cambiantes.
Retrospectiva de Sprint Después de la Revisión de Sprint, el equipo reflexiona sobre el sprint anterior para identificar lo que salió bien, lo que podría mejorarse y qué acciones tomarán para mejorar su proceso. Este mecanismo de mejora continua es crucial para el crecimiento y eficacia del equipo.
Seguimiento y Visualización
Gráficos de Burn Up/Down Estas herramientas visuales rastrean el progreso durante todo el sprint, mostrando el trabajo completado frente a la trayectoria planeada. Proporcionan visibilidad inmediata sobre si el equipo está en camino de cumplir su objetivo de sprint y ayudan a identificar problemas potenciales desde temprano.
Desglose de Tareas Durante la planificación, los elementos grandes de la lista de pendientes se desglosan en tareas más pequeñas y manejables que pueden completarse en un día o dos. Este enfoque detallado mejora la precisión de las estimaciones y hace que el progreso sea más visible.
Estudio de caso: Digital Solutions Inc. – Un viaje de transformación Scrum
Antecedentes organizacionales
Digital Solutions Inc., una empresa de desarrollo web de tamaño mediano con aproximadamente 80 empleados, se especializaba en crear plataformas de comercio electrónico personalizadas y aplicaciones web empresariales para clientes en los sectores minorista y de servicios financieros. A pesar de contar con desarrolladores talentosos y una base sólida de clientes, la empresa enfrentaba desafíos significativos que amenazaban su crecimiento y reputación.
La organización operaba bajo un método tradicional de cascada, en el que los proyectos avanzaban secuencialmente a través de fases de recolección de requisitos, diseño, desarrollo, pruebas y despliegue. Este enfoque generó varios problemas críticos:
- Plazos incumplidos:Los proyectos se retrasaban constantemente entre un 40 % y un 60 % respecto a sus plazos estimados
- Mala comunicación:Existían silos entre los equipos de gestión de productos, desarrollo y aseguramiento de calidad
- Expansión de alcance:Los cambios en los requisitos durante el proyecto causaron una reestructuración significativa y retrasos
- Bajo moral:Los desarrolladores se sentían desconectados de los resultados del negocio y frustrados por la constante necesidad de resolver emergencias
- Insatisfacción del cliente:Los interesados rara vez veían software funcional hasta avanzado en el ciclo de desarrollo, lo que generaba expectativas desalineadas
La decisión de cambiar
A principios de 2023, tras perder dos clientes importantes debido a fallas en la entrega, el equipo directivo reconoció la necesidad de un cambio fundamental. La Directora de Tecnología, Sarah Mitchell, impulsó la adopción de Scrum Ágil después de investigar diversos marcos y visitar empresas que utilizaban con éxito esta metodología.
El equipo directivo identificó tres proyectos piloto para la transformación Scrum:
- Una aplicación móvil de banca para una cooperativa de crédito regional
- Un sistema de gestión de inventario para una cadena minorista
- Un portal para clientes de una compañía de seguros
Estos proyectos fueron seleccionados porque tenían una complejidad moderada, involucraban a los interesados y contaban con equipos dispuestos a experimentar con nuevos enfoques.
Estrategia de implementación
Fase 1: Preparación y Capacitación (Semanas 1-4)
Antes de lanzar las pruebas piloto, Digital Solutions invirtió considerablemente en la preparación:
- Capacitación en Scrum:Todos los miembros del equipo, los propietarios del producto y los interesados asistieron a un taller de dos días sobre Scrum certificado, dirigido por un entrenador externo
- Definición de Roles:Se crearon descripciones claras de puestos para los Propietarios del Producto y los Scrum Masters, con tres desarrolladores senior que pasaron a roles de Scrum Master a tiempo completo
- Selección de Herramientas:La empresa adoptó Jira para la gestión del backlog y Confluence para la documentación, integrándolas con su repositorio Git existente
- Espacio Físico de Trabajo:Se crearon áreas dedicadas para el equipo con pizarras blancas, notas adhesivas y espacio para tableros de tareas, aunque algunos miembros del equipo trabajaran de forma remota
Fase 2: Creación del Backlog del Producto (Semana 5)
Para cada proyecto piloto, los nuevos Propietarios del Producto trabajaron intensamente con los interesados para:
- Realizar entrevistas con los interesados para comprender los objetivos empresariales y las necesidades de los usuarios
- Documentar los epics (grandes bloques de trabajo) y dividirlos en historias de usuario
- Priorizar los elementos del backlog utilizando el método MoSCoW (Debe tener, Debería tener, Podría tener, No tendrá)
- Definir los criterios de aceptación para cada historia
- Estimar los primeros elementos del backlog utilizando puntos de historia y póker de planificación
El backlog del proyecto de banca móvil, por ejemplo, contenía 127 historias de usuario que iban desde «Como cliente, quiero ver mi saldo de cuenta» hasta «Como usuario, quiero transferir fondos entre cuentas de forma segura».
Fase 3: Planificación y Ejecución del Sprint (Semanas 6-25)
Los equipos adoptaron sprints de dos semanas, encontrando que esta duración era óptima para mantener el impulso mientras permitía un progreso significativo. Así es cómo transcurría un sprint típico:
Planificación del Sprint (Día 1 – 4 horas)
La primera sesión de planificación del sprint del equipo de banca móvil marcó el tono para la transformación. El Propietario del Producto presentó los elementos de mayor prioridad del backlog, explicando el valor empresarial de cada uno. El equipo de desarrollo formuló preguntas para aclarar dudas, discutió enfoques técnicos y finalmente se comprometió a completar:
- Autenticación de usuarios con autenticación multifactor
- Visualización del saldo de cuenta
- Visualización del historial de transacciones
- Estructura básica de navegación
Utilizando su experiencia colectiva y las estimaciones de puntos de historia, el equipo determinó que podían completar de forma realista 34 puntos de historia en el sprint de dos semanas, estableciendo así su base inicial de velocidad.
Reuniones Diarias de Standup (Días 2-9 – 15 minutos cada una)
Cada mañana a las 9:30, el equipo se reunía alrededor de su tablero físico de tareas (con los miembros remotos que se unían mediante videoconferencia). Cada miembro respondía las tres preguntas estándar:
Ejemplo del Día 3:
- Desarrollador 1: “Ayer completé la integración de la API de inicio de sesión. Hoy trabajaré en la gestión de sesiones. Sin obstáculos.”
- Desarrollador 2: “Ayer comencé la interfaz de usuario del saldo de cuenta. Hoy la terminaré y comenzaré la lista de transacciones. Estoy bloqueado esperando el punto final de la API del equipo de backend.”
- Máster de Scrum: “Te conectaré con el equipo de backend inmediatamente después de esta reunión para resolver ese obstáculo.”
Estas breves reuniones resultaron de gran valor para identificar problemas temprano. El Máster de Scrum mantuvo una lista de impedimentos y trabajó de forma agresiva para eliminar obstáculos, asegurando que el equipo pudiera mantener el enfoque en el trabajo de desarrollo.
Ejecución y seguimiento del sprint
Durante todo el sprint, el equipo utilizó varias herramientas de visualización:
- Tablero de tareas: Columnas para “Por hacer”, “En progreso”, “Revisión de código”, “Pruebas” y “Hecho” proporcionaron visibilidad en tiempo real del estado
- Gráfico de desgaste: Actualizado diariamente, mostró que el equipo estaba ligeramente atrasado el día 5, pero se recuperó el día 7 tras resolver el obstáculo de la API
- Definición de terminado: El equipo estableció criterios claros: código completado, pruebas unitarias escritas, revisión de código, integración y pruebas de aceptación aprobadas
El Propietario del Producto permaneció disponible durante todo el sprint para responder preguntas y aclarar requisitos, evitando que el equipo hiciera suposiciones incorrectas.
Revisión del sprint (Día 10 – 2 horas)
Al final del Sprint 1, el equipo de banca móvil invitó a los interesados de la cooperativa de crédito a revisar sus avances. La demostración incluyó:
- Demo en vivo de la aplicación funcional en tabletas y teléfonos
- Revisión de las historias de usuario completadas con validación de los criterios de aceptación
- Discusión sobre lo que no se completó y por qué
- Presentación de la lista de productos actualizada y prioridades propuestas para el Sprint 2
Los interesados proporcionaron retroalimentación inmediata: “La autenticación multifactor es excelente, pero necesitamos agregar el inicio de sesión con huella dactilar como opción.” Esta retroalimentación fue capturada y priorizada en la lista de productos para sprints futuros.
Retrospectiva del sprint (Día 10 – 1.5 horas)
Tras la revisión, el equipo realizó su primera retrospectiva en una sala privada. Utilizando el formato “Empezar, Dejar de hacer, Continuar”, identificaron:
Empezar:
- Programación en pareja para características complejas
- Involucramiento más temprano de QA en la planificación del sprint
- Pruebas automatizadas para prevenir regresiones
Dejar de hacer:
- Aclaraciones de requisitos de último minuto
- Reuniones no programadas durante el tiempo de desarrollo enfocado
- Procesos manuales de despliegue
Continuar:
- Reuniones diarias de pie a la misma hora
- Resolución colaborativa de problemas
- Revisiones frecuentes de código
El equipo se comprometió a implementar dos puntos de acción en la próxima iteración: introducir el programación en pareja para las características de autenticación y automatizar la canalización de despliegue.
Desafíos y soluciones
Desafío 1: Resistencia al cambio
Algunos desarrolladores senior resistieron inicialmente el marco Scrum, considerando las reuniones diarias como un micromanagement y la planificación de iteraciones como una sobrecarga innecesaria.
Solución: El Scrum Master trabajó individualmente con los escépticos, abordando sus preocupaciones y demostrando cómo Scrum realmente aumentó la autonomía al capacitar al equipo para organizarse por sí mismo. En menos de tres iteraciones, incluso los miembros del equipo más reacios reconocieron una mejora en el flujo de trabajo y una reducción del estrés.
Desafío 2: Historias incompletas
En la Iteración 2, el equipo se comprometió con 38 puntos de historia, pero solo completó 28, con varias historias atrapadas en pruebas.
Solución: El retrospectiva reveló que las pruebas eran el cuello de botella al final de la iteración. El equipo ajustó su enfoque mediante:
- Enfocarse en historias para completarlas por completo antes de comenzar nuevos trabajos
- Involucrar al equipo de QA desde etapas tempranas del proceso de desarrollo
- Reducir el compromiso de la iteración a 30 puntos hasta que la velocidad se estabilizara
Desafío 3: Disponibilidad de los interesados
Los Propietarios del Producto tuvieron dificultades para equilibrar sus responsabilidades en Scrum con sus tareas existentes, lo que provocó decisiones retrasadas y requisitos poco claros.
Solución: La dirección reconoció que una propiedad del producto efectiva requería tiempo dedicado. Redistribuyeron las tareas administrativas y capacitaron a los Propietarios del Producto para decir «no» a solicitudes no esenciales, asegurando que pudieran centrarse en la refinación del backlog y la interacción con los interesados.
Resultados medibles
Después de seis meses de implementación de Scrum en los tres proyectos piloto, Digital Solutions Inc. logró resultados notables:
Rendimiento de entrega:
- Reducción del 30% en el tiempo de entrega de características:El tiempo promedio desde el requerimiento hasta el despliegue en producción disminuyó de 16 semanas a 11 semanas
- 85% de finalización de iteraciones a tiempo:Los equipos cumplieron consistentemente sus compromisos de sprint después de la curva inicial de aprendizaje
- Reducción del 40% en errores críticos:Las pruebas tempranas y continuas detectaron problemas antes de que llegaran a producción
Mejoras en la calidad:
- La cobertura del código aumentó del 45% al 78%mediante prácticas de desarrollo guiado por pruebas
- Las fallas reportadas por clientes disminuyeron un 60%en comparación con proyectos de tipo cascada
- La deuda técnica fue gestionada activamentemediante historias dedicadas de refactorización en cada sprint
Dinámica del equipo:
- Las puntuaciones de satisfacción de los empleados aumentaron de 6.2 a 8.4 (de 10)
- La rotación voluntaria disminuyó un 45%ya que los desarrolladores se sintieron más comprometidos y empoderados
- El entrenamiento cruzado aumentóya que los miembros del equipo colaboraron más estrechamente
Satisfacción de los interesados:
- Las puntuaciones de satisfacción del cliente mejoraron de 7.1 a 9.2
- La capacidad para acomodar solicitudes de cambio aumentódel 15% al 70% de los cambios solicitados pudieron incorporarse en el siguiente sprint
- La transparencia mejoró considerablementecon los interesados teniendo visibilidad sobre el progreso cada dos semanas
Impacto empresarial:
- Los ingresos de los clientes del proyecto piloto aumentaron un 25%debido a un tiempo más rápido para poner en el mercado nuevas funcionalidades
- Dos clientes anteriormente perdidos regresarondespués de ver las mejoras en las capacidades de entrega
- Las nuevas adquisiciones de negocio aumentaron un 40%ya que la empresa pudo comprometerse con confianza a plazos ambiciosos
Escalado y adopción organizacional
Basado en el éxito del proyecto piloto, Digital Solutions desarrolló un plan de implementación por fases:
Fase 1 (Meses 7-9):Extender Scrum a cinco equipos de desarrollo adicionales, utilizando miembros del equipo piloto como coaches y mentores.
Fase 2 (Meses 10-12):Implementar Scrum en todos los equipos de desarrollo, estableciendo una comunidad de práctica para los Scrum Masters y los Product Owners.
Fase 3 (Año 2):Introducir marcos ágiles escalados (SAFe) para coordinar múltiples equipos que trabajan en grandes programas empresariales.
La empresa también invirtió en:
- Crear un Centro de Excelencia Ágil interno
- Desarrollar rutas de carrera para Scrum Masters y Product Owners
- Integrar métricas ágiles en los sistemas de gestión del desempeño
- Establecer alianzas con organizaciones de capacitación ágil para una educación continua
Lecciones aprendidas y mejores prácticas
La transformación en Digital Solutions Inc. reveló varios factores críticos de éxito:
El compromiso de la dirección es esencialEl apoyo ejecutivo fue más allá de una simple aprobación verbal. Los líderes participaron activamente en la capacitación, protegieron a los equipos de la interferencia organizacional y celebraron públicamente los éxitos ágiles.
Invertir en capacitación y coachingEl taller inicial de dos días fue solo el comienzo. El coaching continuo, especialmente durante los primeros seis meses, ayudó a los equipos a superar desafíos y evitar errores comunes.
Comenzar pequeño y escalar con cuidadoEmpezar con proyectos piloto permitió a la organización aprender y adaptarse antes de la implementación a nivel empresarial. Las historias de éxito de los proyectos piloto generaron impulso y abordaron el escepticismo.
Empoderar a los Product OwnersOtorgar a los Product Owners la autoridad y el tiempo necesarios para realizar su trabajo de forma efectiva resultó crucial. Una propiedad de Product Owner a medias generó prioridades confusas y equipos frustrados.
Respetar el marcoLos equipos que intentaron personalizar Scrum demasiado pronto (‘Scrumbut’ – ‘Hacemos Scrum, pero saltamos las retrospectivas’) tuvieron dificultades. Dominar los fundamentos antes de adaptar produjo mejores resultados.
Enfocarse en resultados, no en salidasCambiar la conversación de ‘cuántos puntos de historia’ a ‘qué valor se entregó’ mantuvo a los equipos enfocados en resultados empresariales en lugar de manipular métricas.
Conclusión
El marco ágil Scrum representa más que solo una metodología de gestión de proyectos: representa un cambio fundamental en la forma en que las organizaciones abordan el desarrollo de software, la colaboración entre equipos y la entrega de valor. Como se demostró a través del estudio de caso completo de Digital Solutions Inc., una implementación exitosa de Scrum requiere compromiso, paciencia y una disposición para adoptar el cambio en todos los niveles organizacionales.
El camino de transformación rara vez es liso. Los equipos enfrentarán resistencia, cometerán errores y experimentarán contratiempos. Sin embargo, la naturaleza estructurada pero flexible de Scrum proporciona el andamiaje necesario para enfrentar estos desafíos mientras se mejora continuamente. Los resultados medibles alcanzados—un 30 % más rápido en la entrega, un 60 % menos de defectos y una satisfacción de los interesados drásticamente mejorada—ilustran el valor empresarial tangible que Scrum ágil puede ofrecer cuando se implementa con cuidado.
Para las organizaciones que consideran esta transformación, el mensaje clave es claro: el Agile Scrum no es una solución rápida ni un conjunto de prácticas que se apliquen mecánicamente. Es un cambio cultural que requiere invertir en las personas, empoderar a los equipos y mantener un enfoque implacable en la entrega de valor al cliente. Aquellos que se comprometen con este camino, como lo hizo Digital Solutions Inc., se posicionan para prosperar en un mercado cada vez más competitivo y cambiante.
La énfasis del marco en la transparencia, la inspección y la adaptación crea una organización aprendizaje capaz de responder a los cambios del mercado, los avances tecnológicos y las necesidades cambiantes de los clientes. En una era en la que el software se ha convertido en un diferenciador crítico para los negocios de todos los sectores, la capacidad de entregar software de alta calidad de forma rápida y confiable no es solo ventajosa: es esencial para la supervivencia y el crecimiento.
Al considerar la implementación de Agile Scrum en su organización, recuerde que el camino comienza con una única iteración. Empiece pequeño, aprenda continuamente, celebre los avances y permanezca comprometido con los principios de colaboración, enfoque en el cliente y mejora continua. Los resultados, como lo demuestran innumerables historias de éxito, incluida la descrita aquí, superarán con creces la inversión necesaria para realizar la transformación.
Referencias
- ¿Qué es el desarrollo de software ágil? [Guía rápida]: Guía rápida de aprendizaje ágil que le proporciona todo lo que necesita saber sobre el ágil. Es sencilla, pero completa.
- Herramienta ágil con IA | Visual Paradigm: El ecosistema definitivo de herramientas ágiles. Elija Visual Paradigm Desktop para un mapeo de historias de usuario completo y soporte de marcos, o VP Online para una suite de herramientas ágiles en la nube impulsadas por IA.
- Software de mapeo de historias de usuario ágil | Visual Paradigm: El software fácil de usar de mapeo de historias de usuario de Visual Paradigm le ayuda a visualizar y gestionar eficazmente los backlogs de productos. Estime historias de usuario con la tabla de afinidad, planifique iteraciones y simplifique las actividades de desarrollo.
- ¿Qué es la gestión ágil de proyectos?: Guía gratuita de ágil que habla sobre qué es la gestión ágil de proyectos. Proporciona una explicación detallada sobre los diversos marcos de Scrum ágil, como Large-Scale AScrum, Nexus, SAFe, entre otros.
- ¿Qué es el desarrollo de software ágil?: Guía gratuita de aprendizaje de Scrum para todos los equipos Scrum. Aprenda sobre el desarrollo de software ágil. Están disponibles más recursos gratuitos de Scrum.
- Las 7 principales metodologías de desarrollo ágil: Aprenda sobre las 7 principales metodologías de desarrollo ágil: Scrum, programación extrema, DSDM, RAD, Proceso Unificado, enfoque Lean y Kanban. Gestione su proyecto con software ágil profesional.
- Herramienta fácil de usar para casos de uso, ya sea en enfoque centrado en casos de uso o ágil: Herramienta fácil de usar para casos de uso adaptada a equipos ágiles. Incluye editor de escenarios y generación de diagramas de secuencia. Integrada con el mapa de historias de usuario.
- ¿Cómo apoya Visual Paradigm el desarrollo ágil de proyectos? – Ágil y Scrum – Discusión sobre Visual Paradigm: Quiero saber más sobre cómo VP apoya los proyectos ágiles. ¿Alguien puede darme algunas ideas?