Skip to content

Clase 19 — Repaso, INVEST vs SMART y Consejos de Examen (última clase)

Resumen Ejecutivo

Última clase: repaso + refuerzo (resolución de dudas + comentario de la actividad grupal). Bloques tratados:

  1. Uso crítico de la IA (a raíz de errores en entregas: "Buscasofá" vs "Buscasofa") y reflexión sobre su impacto laboral.
  2. Patrones del Tema 5 vs Tema 6: por qué cliente-servidor/multicapa es "trivial" y conviene usar los patrones de arquitectura cloud del Tema 6.
  3. INVEST vs SMART: criterios para historias de usuario vs tareas, y cómo redactar tareas.
  4. Aplicabilidad de patrones según lenguaje/framework (React, use memo, componentes funcionales vs clases).
  5. Consejos de examen (planificación de sprint, justificar horas) y buenas prácticas de documentación (estructura, destacar lo importante, resaltar código con syntax highlighting en vez de imágenes).

⚠️ EXAMEN: en planificación de sprint, lo clave es justificar qué historias se eligen y por qué, y que el sumatorio de horas sea coherente con la capacidad del equipo (explicar la holgura). No hace falta panel Kanban. La pregunta teórica son ~15 min.

Conceptos Clave

  • SMART (tareas): Specific, Measurable, Achievable, Realistic, Time-boxed. ⚠️ EXAMEN
  • INVEST (historias de usuario): Independent, Negotiable, Valuable, Estimable, Small, Testable. ⚠️ EXAMEN
  • Diferencia clave INVEST↔SMART: la independencia y el valor aplican a historias de usuario, no tanto a tareas (las tareas de una historia suelen estar imbricadas: BD ↔ API ↔ código). ⚠️ EXAMEN
  • Jerarquía de objetivos: objetivo general (abstracto) → objetivos específicos con métricas → historias de usuario → tareas. Analizar = desgranar en cosas cada vez más SMART.
  • Tema 5 (estilos/arquitecturas generales): cliente-servidor, multicapa, maestro-esclavo. Muy genéricos → poca nota si son lo único. ⚠️ EXAMEN
  • Tema 6 (patrones cloud concretos): CQRS, CDN, supervisión, tuberías y filtros, caché. Resuelven problemas específicos → más valorados. ⚠️ EXAMEN
  • Aplicabilidad de patrones: el concepto se aplica en cualquier plataforma; la implementación depende del lenguaje/framework (herencia múltiple vs interfaces; React resuelve algunos con hooks).

Desarrollo del Temario

1. Uso crítico de la IA

El profesor detecta entregas generadas por IA sin revisar: el título real de la app es "Buscasofa" (de gasofa = gasolina, buscador de gasolineras), pero la IA "corrige" a "Buscasofá" (sofá) → delata que nadie revisó lo que escupió el algoritmo, ni siquiera en una actividad grupal.

Reflexión: la IA es una herramienta potentísima que destruirá puestos (ejemplo de operarios en India con cámaras para entrenar robots que les sustituyan), pero tendrán futuro quienes la controlen con criterio, no los que la usen "como borregos". "Para aprender a montar en bici hay que caerse; lo anormal es estrellarse de forma habitual."

2. Patrones del Tema 5 vs Tema 6 ⚠️ EXAMEN

  • Tema 5 = repaso de estilos/arquitecturas generales (cliente-servidor, multicapa, maestro-esclavo). Son de muy alto nivel y casi triviales en apps web/móviles (toda app es cliente-servidor multicapa). Decir solo "uso cliente-servidor multicapa + repositorio" → máximo 5/10 en ese apartado (redundante, poca aportación; en multicapa cada capa es servidor de otra).
  • Tema 6 = patrones de arquitectura cloud concretos que resuelven problemas específicos: CQRS (separar comandos de consultas para escalar independientemente), CDN, supervisión/monitorización, tuberías y filtros, caché. Estos demuestran conocimiento profundo → mejor nota.
  • Algunos del Tema 6 son aplicables casi siempre: caché (tan habitual que React tiene useMemo), supervisión, tuberías y filtros (procesamiento secuencial).

3. INVEST vs SMART

Dos acrónimos para dos cosas distintas:

Historias de usuario → INVEST Tareas → SMART
I/S Independent (separables conceptualmente) Specific (clara, comprensible)
N/M Negotiable (con el Product Owner) Measurable
V/A Valuable (aporta valor; lo decide el PO) Achievable
E/R Estimable Realistic/Relevant (para implementar la historia)
S/T Small Time-boxed
T Testable —

Por qué acrónimos distintos: la independencia y el valor tienen sentido en historias de usuario, pero no en tareas: las tareas de una historia están imbricadas (tocar la BD afecta a la API, que afecta al código). El valor de una tarea es instrumental (ayuda a implementar la historia); el de la historia lo determina el Product Owner.

Jerarquía: objetivo general (p.ej. "ser el buscador de hidrocarburos más usado en España", abstracto) → objetivos específicos con métricas ("encontrar la gasolina apropiada en ≤5 pasos") → historias de usuario → tareas. Analizar = desgranar en cosas cada vez más SMART/medibles.

4. Cómo redactar tareas

Una tarea son "cosas que hay que hacer" para implementar una historia. Redactar con infinitivo y vocabulario relacionado con la historia (no genérico): - Diseñar el formulario de login, crear las tablas para almacenar X, desarrollar los scripts de comunicación con la API, modificar los estilos CSS de la pantalla Y.

Tipos habituales: tareas de diseño de interfaz, de construcción de código (front/back), de base de datos. No todas las tareas son testables (modificar CSS) — la testabilidad es más propia de las historias.

5. Aplicabilidad de patrones según plataforma

  • El concepto del patrón se aplica en web, móvil y escritorio; cambia la implementación según lenguaje/framework.
  • Los patrones se muestran con interfaces porque son más portables (una clase implementa N interfaces; con herencia múltiple sería más difícil de trasladar). Esto facilita combinar patrones (p.ej. Abstract Factory + Prototype: objetos de una familia que además son clonables).
  • React: los componentes son funciones (aunque en JS las funciones son objetos), lo que cambia el paradigma frente a clases. Algunos patrones pierden protagonismo: el Observer se diluye porque las props pasan de padres a hijos; la caché la resuelve useMemo. Pero en una app web hay mucho código de soporte (librerías, funciones fuera de los componentes) donde sí tienen sentido Facade, Builder, etc. (ejemplo: clase TypeScript que encapsula las llamadas a la API y cachea con localStorage).

6. Consejos de examen ⚠️ EXAMEN

  • Planificación de sprint: justificar qué historias se eligen, por qué son prioritarias en la pila de producto, y que el sumatorio de horas sea coherente con la capacidad del equipo (explicar la holgura). No hace falta panel Kanban (no se pide simular el sprint). Critica fuerte: sprints con capacidad nominal de 200h y pila de 120h con un gap de 80h sin explicar.
  • Pregunta teórica: 2 temas a elegir, pero pueden ser del mismo capítulo → no dejar ningún tema sin estudiar. ~15 min.

7. Buenas prácticas de documentación (refuerzo)

Comentando un trabajo modelo: - Estructura lógica y en paralelo con el enunciado (no mezclar pruebas corregidas con nuevas; orden de complejidad ascendente). La estructura se valora también en el TFG. - Destacar lo importante al principio (resumen, introducción, inicio de cada capítulo) y en negrita: un revisor que lee muchos trabajos lee "en diagonal" a mitad de capítulo. - Código como texto con syntax highlighting, no como imagen (mejor resolución, buscable, ajustable). Servicios online o pegado especial en Word. - Evitar textos diminutos en capturas (cansan la vista y pierden calidad al generar el PDF). - En el manual de uso, explicar lo que se ha añadido (no repetir lo que ya hace la aplicación base).

Preguntas de Autoevaluación

  1. ¿Por qué describir una app web solo como "cliente-servidor multicapa" da poca nota? ¿Qué patrones del Tema 6 conviene usar?
  2. Desarrolla los acrónimos INVEST y SMART. ¿A qué se aplica cada uno?
  3. ¿Por qué la "independencia" aplica a historias de usuario pero no a tareas?
  4. ¿Quién determina el valor de una historia de usuario y por qué no el equipo de desarrollo?
  5. Describe la jerarquía objetivo general → tareas. ¿Qué significa "desgranar en cosas SMART"?
  6. ¿Cómo se redacta una tarea? Pon tres ejemplos de tipos de tarea.
  7. ¿Por qué los patrones se representan con interfaces y no con herencia?
  8. ¿Cómo afecta React (componentes funcionales, useMemo) a patrones como Observer o la caché?
  9. En el examen, ¿qué hay que justificar en la planificación de un sprint? ¿Hace falta Kanban?
  10. Da tres buenas prácticas de documentación para el TFG vistas en clase.