🤔 ¿Qué es una metodología de proyecto?
Una metodología es el "método de trabajo" que el equipo sigue para desarrollar la app: cómo organiza las tareas, en qué orden, quién hace qué y cuándo. Sin metodología, cada miembro trabaja de forma diferente y el proyecto se descontrola.
Las metodologías tradicionales son secuenciales: primero se hace todo el análisis, luego todo el diseño, luego toda la programación... como construir un edificio planta por planta sin poder cambiar los cimientos una vez puestos.
Cuando los requisitos están completamente cerrados desde el inicio y no van a cambiar: apps para banca, sanidad, gobierno, o proyectos con contrato de precio fijo.
🌊 Modelo en Cascada (Waterfall)
Es el modelo más antiguo y sencillo: cada fase debe completarse al 100% antes de empezar la siguiente. Como una cascada de agua, nunca sube.
Analogía: es como construir un LEGO siguiendo las instrucciones en orden estricto. No puedes poner el tejado antes de las paredes, ni puedes volver atrás a cambiar los cimientos.
| Fase | Descripción | Entregable |
|---|---|---|
| 1. Requisitos | Captura y análisis de todos los requerimientos | Documento SRS |
| 2. Diseño | Arquitectura, diseño de BD y UI | Documento técnico SDD |
| 3. Codificación | Implementación basada en el diseño | Código fuente, APK/IPA |
| 4. Pruebas | Verificación y validación completa | Informe de bugs |
| 5. Despliegue | Publicación y entrega al cliente | App publicada |
| 6. Mantenimiento | Corrección de bugs, actualizaciones menores | Parches |
✅ Ventajas
- Proceso claro y bien documentado
- Hitos definidos para medir progreso
- Fácil de gestionar y supervisar
- Ideal para proyectos regulados (salud, banca)
❌ Desventajas
- Muy difícil incorporar cambios
- El cliente no ve el producto hasta el final
- Errores tardíos son muy costosos
- En móviles, los requisitos siempre cambian
Usar Waterfall para una startup de app sin requisitos cerrados. Al llegar a la fase de pruebas y enseñarle el producto al cliente por primera vez, lo habitual es que diga «esto no es lo que quería». Corregirlo en ese punto puede costar el mismo tiempo que desarrollarlo de nuevo.
🔡 Modelo en V
Es una extensión del Waterfall que planifica las pruebas desde el inicio. Por cada fase de desarrollo existe una fase de prueba correspondiente. La forma de «V» refleja que el desarrollo baja y las pruebas suben.
La trazabilidad bidireccional garantiza que cada requisito tiene al menos un caso de prueba que lo valida. Los planes de prueba se elaboran en paralelo con cada fase de desarrollo, no al final.
🌀 Modelo Espiral
El modelo más sofisticado de los tradicionales. Es iterativo con gestión de riesgos integrada: en cada vuelta de la espiral se desarrolla un incremento y se evalúan los riesgos antes de continuar.
Analogía: como ir subiendo una montaña en zigzag. En cada curva puedes decidir si continuar o desviarte según lo que encuentres.
Definir metas, alternativas y restricciones de la iteración.
Identificar y mitigar riesgos técnicos y de negocio.
Implementar y verificar el prototipo o incremento.
Revisar resultados y planificar la próxima iteración.
Una app fintech con funciones de pago muy complejas. En cada espiral se prototipa una funcionalidad (p.ej. transferencias), se evalúan los riesgos legales y técnicos, se desarrolla y se evalúa antes de entrar en la siguiente espiral (p.ej. inversiones). Si un riesgo es inaceptable, se detiene el proyecto antes de invertir más dinero.
¿En qué situación de la vida real usarías Waterfall? ¿Y el Modelo en V? ¿Por qué crees que el 90% de las startups de apps eligen metodologías ágiles en lugar de estas?
Waterfall: secuencial, documentado, sin cambios posibles. V: igual pero con trazabilidad de pruebas. Espiral: iterativo con gestión de riesgos. Los tres son apropiados cuando los requisitos son estables. Para apps con cambios frecuentes → ágil.
⚡ ¿Qué diferencia a lo ágil de lo tradicional?
Las metodologías ágiles nacieron en 2001 con el Manifiesto Ágil. Su filosofía: en lugar de planificar todo de antemano, entrega algo que funcione cada 2-4 semanas y ajusta según el feedback del cliente.
🏉 Scrum: el framework ágil más popular
Scrum organiza el trabajo en sprints de 2-4 semanas. Al final de cada sprint, hay una versión funcional del producto. Es el método más usado en el desarrollo de apps móviles.
Analogía: es como un equipo de rugby (de ahí el nombre): todos empujan juntos en la misma dirección, nadie trabaja solo, y cada 2 semanas se para a evaluar si van bien.
Los 3 roles de Scrum:
| Rol | Responsabilidad | Habilidades clave |
|---|---|---|
| 🎯 Product Owner | Define y prioriza qué se hace. Representa al cliente. | Visión de negocio, decisiones, comunicación |
| 🛡️ Scrum Master | Facilita el proceso y elimina impedimentos del equipo. | Coaching, resolución de conflictos, Scrum |
| ⚙️ Dev Team | Autoorganizado, entrega el incremento en cada sprint. 3-9 personas. | Desarrollo, testing, diseño, DevOps |
Los 4 eventos de un sprint:
Los 3 artefactos de Scrum:
📝 User Stories y criterios de aceptación
Las User Stories son la forma de describir funcionalidades desde el punto de vista del usuario, no desde el técnico. Son la unidad básica del Product Backlog.
Criterios de aceptación — formato GIVEN-WHEN-THEN:
WHEN introduce email y contraseña correctos y toca 'Entrar'
THEN la app navega a la pantalla principal y muestra su nombre
Story Points y Planning Poker:
Burndown Chart — el termómetro del sprint:
Por encima de la línea ideal: el equipo va retrasado → revisar scope del sprint o pedir ayuda.
Por debajo de la línea ideal: el equipo va adelantado → puede añadir más ítems.
Línea plana (sin bajar): el equipo está bloqueado → el Scrum Master debe actuar inmediatamente.
📋 Kanban: gestión visual del flujo
Kanban no tiene sprints. El trabajo fluye continuamente de izquierda a derecha en un tablero. Lo más importante son los límites de trabajo en progreso (WIP limits): si tienes demasiadas tareas a la vez, todo va lento.
Analogía: como una cadena de montaje de coches. Si la estación de pintura tiene capacidad para 3 coches pero le mandan 10, todo se atasca. El WIP limit evita ese atasco.
Métricas clave de Kanban:
| Métrica | Qué mide | Uso |
|---|---|---|
| Lead Time | Tiempo desde que se crea una tarea hasta que se entrega | Eficiencia total del proceso de principio a fin |
| Cycle Time | Tiempo desde que se empieza a trabajar una tarea hasta que termina | Velocidad real del equipo de desarrollo |
| Throughput | Número de tareas completadas por unidad de tiempo | Productividad real del equipo |
| CFD | Cumulative Flow Diagram — acumulación en cada columna | Detectar cuellos de botella visualmente |
El error más común en Kanban es crear nuevas tarjetas sin respetar los límites WIP «porque parece que hay capacidad». Si tienes 3 tareas en revisión y el límite es 2, no empieces ninguna tarea nueva — ayuda a que las de revisión avancen.
🛠️ Herramientas de gestión de proyectos
| Herramienta | Metodología | Precio | Ideal para |
|---|---|---|---|
| Jira | Scrum + Kanban | Gratis hasta 10 users | Equipos medianos/grandes, integración CI/CD |
| Trello | Kanban | Gratis (básico) | Equipos pequeños, proyectos simples |
| Linear | Scrum + Kanban | Gratis (equipo) | Dev teams de startups, UI moderna |
| Notion | Flexible | Gratis (personal) | Todo en uno: docs + tareas + base de conocimiento |
| Azure DevOps | Scrum + Kanban | Gratis hasta 5 users | Empresas grandes, integración con Azure |
¿Cuál es la diferencia práctica más importante entre Scrum y Kanban para un equipo de 2 personas desarrollando su primera app? ¿Necesitas un Scrum Master si el equipo es de 3 personas?
Scrum = sprints de 2-4 semanas + 3 roles + 4 eventos + 3 artefactos. User Stories en formato «Como/quiero/para». Kanban = tablero visual + WIP limits + flujo continuo. Lead Time, Cycle Time y Throughput son las métricas clave de Kanban.
📱 La primera decisión: ¿iOS, Android o ambas?
Antes de escribir una línea de código hay que decidir para qué plataforma se desarrolla. Esta decisión afecta al presupuesto, al equipo necesario, al tiempo de llegada al mercado y a los usuarios que alcanzas.
- ~29% cuota global de mercado
- Lidera en EE.UU., Japón, Australia
- Gasto por usuario 2× mayor que Android
- Baja fragmentación (~5 tamaños activos)
- Swift / SwiftUI como lenguaje principal
- Requiere Mac + Xcode obligatoriamente
- Revisión manual Apple: 1–7 días
- ~70% cuota global de mercado
- Domina en Europa, Asia, LATAM
- Mayor volumen de usuarios
- Alta fragmentación (+1.000 modelos)
- Kotlin / Jetpack Compose como lenguaje
- Android Studio en Windows, Mac o Linux
- Revisión automática: pocas horas
| Dimensión | iOS | Android |
|---|---|---|
| Cuota de mercado global | ~29% | ~70% |
| Gasto por usuario | 2× respecto a Android | Referencia base |
| Fragmentación | Baja (~5 tamaños activos) | Muy alta (+1.000 modelos) |
| Actualizaciones del OS | ~95% actualizan en 2 años | ~50% actualizan en 2 años |
| Coste de desarrollo | $99/año + Mac obligatorio | $25 USD pago único |
iOS primero si el público está en mercados premium con alto poder adquisitivo (Europa Occidental, EE.UU., Japón). Android primero para máximo alcance global y mercados emergentes (LATAM, África, Asia del Sur). Multiplataforma si el presupuesto es limitado.
🔀 Desarrollo multiplataforma: Flutter vs React Native
En lugar de hacer dos apps distintas (una para iOS y otra para Android), las soluciones multiplataforma permiten escribir un único código que funciona en ambas plataformas.
| Framework | Lenguaje | Rendimiento | Cuándo elegirlo |
|---|---|---|---|
| Nativa pura | Swift/Kotlin | Máximo | Sin restricciones de presupuesto, máxima calidad UX |
| Flutter | Dart | Muy bueno | UI consistente, soporte Google, muy popular actualmente |
| React Native | JavaScript/TS | Bueno | Equipo web existente, ecosistema npm, gran comunidad |
| KMP (Kotlin Multiplatform) | Kotlin | Nativo | Compartir solo la lógica, UI nativa en cada plataforma |
🦋 Flutter — Google
- Dart: curva de aprendizaje moderada
- Hot reload: cambios en milisegundos
- Widgets propios (no UI nativa del SO)
- iOS, Android, Web, Windows, macOS desde un código
- Compila a código nativo ARM
⚛️ React Native — Meta
- JavaScript/TypeScript — equipo web puede usarlo
- Renderiza componentes UI nativos reales
- Ecosistema npm — miles de librerías
- Mantenido por Meta (Facebook)
- Comunidad muy activa y madura
Una startup con 3 desarrolladores web quiere lanzar su app de gestión de tareas en iOS y Android al mismo tiempo con un presupuesto de €40.000. La opción correcta es React Native o Flutter: un equipo, un código, dos plataformas. Hacer las dos apps nativas costaría el doble de tiempo y dinero.
| Factor | Solo iOS | Solo Android | Multiplataforma |
|---|---|---|---|
| Presupuesto limitado | Si target es premium | Si target es masivo | Mejor opción siempre |
| Target alto poder adquisitivo | Ideal | Funciona | Viable |
| Mercado global y diverso | No recomendado | Bueno | Excelente |
| Hardware avanzado (cámara, AR) | Muy bueno | Muy bueno | Limitado |
| Time-to-market urgente | Puede ser | Puede ser | React Native/Flutter ✓ |
Una app de banca con funciones de NFC, biometría avanzada y widgets del sistema operativo. ¿Elegirías nativa o multiplataforma? ¿Cambiaría tu respuesta si el presupuesto es de €500.000? ¿Y si es de €30.000?
iOS: 29%, mercados premium, 2× más ingresos por usuario, requiere Mac. Android: 70%, alcance global, alta fragmentación. Multiplataforma (Flutter/React Native) = un código, dos plataformas, menos presupuesto. La elección depende del target, presupuesto y capacidades del equipo.
🔥 Firebase Crashlytics: monitoreo de errores
Publicar la app no es el final — es el principio. Firebase Crashlytics te alerta en tiempo real cuando la app falla en los dispositivos de los usuarios reales, con toda la información necesaria para reproducir y corregir el error.
Analogía: es como el caja negra de un avión, pero en tiempo real. Si algo sale mal, tienes el stack trace exacto, el dispositivo, la versión del OS, lo que hizo el usuario justo antes del crash y el estado de la app.
| Métrica | Umbral objetivo | Acción si se supera |
|---|---|---|
| Crash-free users | > 99% | Hotfix urgente + rollback si es necesario |
| Crash Rate | < 1% | Pausar rollout, investigar causa raíz |
| ANR Rate | < 0.47% | Optimizar operaciones en el hilo principal |
| Crashes por versión de OS | Sin regresiones | Desactivar feature con Remote Config |
- Nuevo issue: crash que no existía antes en producción
- Regresión: un issue cerrado vuelve a aparecer
- Umbral de velocidad: la tasa de crash supera el % definido
- Canales: Email, Slack, PagerDuty, Google Cloud Alerts
No añadir contexto personalizado a los crashes. Si solo ves «NullPointerException en línea 47», no sabes qué usuario estaba haciendo qué. Con setCustomKey("screen", "CheckoutActivity") y log("Usuario pulsó confirmar"), el diagnóstico es inmediato.
📊 Firebase Analytics: métricas de comportamiento
Firebase Analytics registra automáticamente eventos en la app y te permite añadir eventos personalizados para entender exactamente cómo usan los usuarios el producto. Sin datos, no hay mejoras fundamentadas.
| Dimensión | Métricas principales | Objetivo típico |
|---|---|---|
| 📥 Adquisición | DAU, MAU, fuentes de instalación, CAC | Entender de dónde vienen los usuarios |
| 🚀 Activación | Tasa de onboarding, tiempo hasta acción clave | Reducir fricción en los primeros 5 minutos |
| 🔄 Retención | D1/D7/D30 retention, churn rate, DAU/MAU | D1 >35%, D7 >15%, D30 >5% |
| 💰 Ingresos | ARPU, LTV, tasa de conversión, MRR | LTV ≥ 3× CAC para sostenibilidad |
| 📣 Referral | NPS, K-factor viral, shares e invitaciones | NPS > 50 es excelente |
| 🖱️ Comportamiento | Funnel de conversión, pantallas más vistas | Detectar dónde abandonan los usuarios |
Firebase Analytics muestra que el 45% de los usuarios abandonan durante el paso 3 del onboarding de una app de e-learning. Eso significa que ese paso tiene demasiada fricción. El equipo lo simplifica en el siguiente sprint y la retención D1 sube del 28% al 41%.
📋 SLA: compromisos de servicio
Un SLA (Service Level Agreement) es un contrato que define los tiempos máximos de respuesta y resolución para cada tipo de incidencia. Sin SLA, no hay garantías ni prioridades claras cuando algo falla.
🔁 Ciclo de actualizaciones y release notes
Una app en producción nunca está «terminada». El mantenimiento continuo es lo que diferencia a las apps con alta retención de las que los usuarios abandonan.
| Tipo de release | Frecuencia | Qué incluye | Proceso |
|---|---|---|---|
| 🚨 Hotfix | Cuando sea necesario | Corrección crítica única | PR urgente → review rápida → deploy directo |
| 🐛 Patch (x.x.X) | Cada 1–2 semanas | 2–5 bugs no críticos | Sprint bugfix → QA básico → staged rollout |
| ✨ Feature (x.X.0) | Cada 4–6 semanas | Nuevas funcionalidades | Sprint completo → QA → beta → staged rollout |
| 🚀 Major (X.0.0) | Cada 3–6 meses | Rediseño o nueva arquitectura | Múltiples sprints → beta pública → rollout lento |
Ejemplo de release notes bien escritas:
🆕 NOVEDADES
• Modo oscuro: ahora disponible en Ajustes > Apariencia
• Sincronización con Google Calendar
• Filtros avanzados por etiqueta y prioridad
🐛 CORRECCIONES
• Solucionado el problema de notificaciones duplicadas en Android 14
• Corregido el crash al adjuntar archivos de más de 50 MB
⚡ MEJORAS
• La carga inicial es un 40% más rápida
• Menor consumo de batería en segundo plano
Los usuarios leen las notas de versión antes de decidir si actualizar. Notas claras, positivas y útiles en lenguaje no técnico impactan directamente en las valoraciones de la app. Nunca escribas «corrección de bugs menores» — explica qué bug se corrigió.
La app de vuestra startup tiene una tasa de retención D7 del 8%, cuando el objetivo es 15%. ¿Qué métricas de Firebase Analytics consultarías primero para entender por qué los usuarios se van? ¿Qué acción concreta tomarías?
Crashlytics: crash rate <1%, ANR <0.47%, alertas automáticas. Analytics: 6 dimensiones (adquisición, activación, retención, ingresos, referral, comportamiento). SLA: P1(1h/4h), P2(4h/24h), P3(24h/72h), P4(48h/1s). Releases: hotfix, patch semanal, feature 4-6 semanas, major 3-6 meses.
Ejercicios ordenados de menor a mayor complejidad. Pueden usarse en clase o como tarea.
Debate en clase: ¿habría elegido el mismo método hace 10 años?
💬 Reflexiones rápidas para clase
La gestión eficaz de un proyecto de app móvil abarca desde la elección de metodología hasta el monitoreo en producción. Estos cuatro bloques son los pilares:
El código solo es una parte del trabajo. Una app exitosa necesita la metodología correcta para organizarse, la plataforma adecuada para llegar a los usuarios y el monitoreo continuo para no morir de éxito. La gestión de proyectos no es burocracia — es lo que convierte buenas ideas en productos que funcionan.