En 2026, las mejores prácticas para el desarrollo de software ágil utilizando PHP y Java ya no se reducen a “hacer sprints”. El reto real es entregar valor con cadencia predecible mientras crece la complejidad: microservicios, APIs, seguridad, cumplimiento, deuda técnica y expectativas de experiencia de usuario. PHP y Java siguen siendo pilares en B2B por su madurez, ecosistemas y disponibilidad de talento, pero exigen disciplina para escalar con agilidad.
La oportunidad es doble: por un lado, modernizar la forma de construir (arquitectura, automatización, métricas) y, por otro, modernizar la forma de trabajar (equipos, decisiones, aprendizaje). Además, la IA generativa ya impacta el ciclo de vida del software, pero solo crea ventaja competitiva si se integra con gobernanza, calidad y seguridad. Esta guía aterriza prácticas concretas para equipos que desarrollan con PHP y Java en entornos reales.
Key Takeaways
- La agilidad en 2026 se gana con equipos orientados a producto, límites de WIP y entrega continua, no solo con ceremonias.
- En PHP y Java, la velocidad sostenible proviene de arquitectura modular, APIs contract-first y pruebas automatizadas en pirámide (unitarias > integración > E2E).
- CI/CD con “quality gates” (seguridad, cobertura, linters, análisis estático) reduce retrabajo y permite releases pequeños y frecuentes.
- La IA generativa acelera codificación, refactor y documentación si se acompaña de estándares, revisión humana y datos protegidos.
- Mide flujo y resultados (lead time, throughput, fallos en producción, satisfacción) para mejorar de forma iterativa y verificable.
¿Qué significa “agilidad real” en 2026 para equipos PHP y Java?
Agilidad real en 2026 significa optimizar el flujo de entrega desde idea hasta producción con aprendizaje continuo, manteniendo calidad y seguridad. En equipos PHP y Java, esto se traduce en ciclos cortos, releases pequeños, automatización fuerte y arquitectura que permita cambiar sin romper. La agilidad se valida por resultados: valor entregado, estabilidad y capacidad de adaptación.
La evidencia de gestión respalda el enfoque: los métodos ágiles han mejorado tasas de éxito, calidad y velocidad de comercialización, además de la motivación de equipos de TI, cuando se aplican como sistema y no como rituales. Harvard Business Review lo describe en su análisis sobre adoptar la agilidad, destacando mejoras en calidad y time-to-market al combinar prácticas técnicas y organizacionales (https://hbr.org/2016/05/embracing-agile?language=es). En 2026, el “cómo” importa tanto como el “qué”.
¿Cómo organizar equipos y ceremonias para entregar valor (sin caer en “agile theater”)?
Organiza equipos alrededor de productos o flujos de valor, con autonomía para diseñar, construir, probar y desplegar. Mantén ceremonias mínimas pero efectivas: planificación basada en capacidad, dailies para desbloquear, refinamiento continuo y retrospectivas con acciones verificables. Evita métricas de vanidad (puntos) y prioriza métricas de flujo y outcomes.
Diseño de equipos: producto, plataforma y enablement
Un patrón que funciona en B2B es separar responsabilidades sin crear silos: equipos de producto (features y valor), equipo de plataforma (CI/CD, entornos, observabilidad) y un pequeño equipo de enablement (coaching, estándares, seguridad). El objetivo es reducir dependencias para que cada equipo pueda entregar de extremo a extremo. Esta estructura encaja tanto en stacks PHP (Laravel/Symfony) como Java (Spring).
Ceremonias con propósito: decisiones y aprendizaje
Mantén la planificación enfocada en hipótesis y valor, no en “llenar el sprint”. En el daily, pregunta por bloqueos y riesgos técnicos (migraciones, rendimiento, datos) y no por reportes de estado. En retrospectiva, limita el número de acciones y exige definición de “hecho” para cada mejora: quién, cuándo y cómo se medirá. Si no hay cambio observable, fue una reunión social, no una práctica ágil.
- Define una Definition of Done común: tests, revisión, seguridad, documentación mínima y despliegue automatizable.
- Establece límites de WIP por columna (Kanban o Scrum-ban) para evitar multitarea crónica.
- Usa refinamiento continuo: 1–2 sesiones cortas por semana con foco en dependencias y criterios de aceptación.
- Integra al equipo de seguridad/infra como “consultores embebidos” con SLAs, evitando colas largas.
- Crea un “acuerdo de ingeniería” por repositorio: convenciones, branching, versionado y estándares.
¿Qué arquitectura facilita la agilidad cuando conviven PHP y Java?
La arquitectura que mejor soporta agilidad en entornos mixtos PHP/Java es modular, con límites claros y contratos estables. Prioriza un modular monolith cuando el dominio aún cambia rápido y evoluciona hacia microservicios solo cuando existan razones operativas. Define APIs contract-first, versionado explícito y una estrategia de datos que minimice acoplamientos.
Modular monolith primero, microservicios después (cuando duela)
En 2026, muchos equipos han aprendido que microservicios “por defecto” generan sobrecarga: observabilidad, despliegues, consistencia de datos y seguridad. Un monolito modular en PHP (por ejemplo, Symfony con bounded contexts) o en Java (Spring con módulos) permite iterar rápido con menos fricción. Si el sistema crece, extrae servicios por dominios con métricas: dependencia, escalado independiente o necesidades de disponibilidad.
APIs contract-first y compatibilidad hacia atrás
Define contratos antes de implementar: OpenAPI para REST o AsyncAPI para eventos. Esto alinea equipos PHP y Java, reduce malentendidos y acelera pruebas de integración. Mantén compatibilidad hacia atrás con versionado semántico, “deprecations” anunciadas y pruebas de contrato. La agilidad se rompe cuando cada cambio de API obliga a coordinar a media organización.
Estrategia de datos: evitar el “shared database” entre servicios
Si separas servicios, evita compartir tablas como mecanismo de integración. Prefiere integración por eventos o APIs, y define un modelo de consistencia (fuerte vs eventual) por caso de uso. En PHP y Java, esto suele implicar colas/eventos, outbox pattern y “idempotency keys”. Donde el dominio lo permita, replica datos para lectura (CQRS ligero) en lugar de crear acoplamiento duro.
Si estás evaluando enfoques de arquitectura para stacks web, complementa esta guía con arquitectura adecuada en 2026 para aplicaciones web, donde se profundiza en criterios de elección y trade-offs. En contextos híbridos, también es útil contrastar patrones de integración y evolución de plataformas.
¿Cómo diseñar un flujo CI/CD moderno para PHP y Java en 2026?
Un flujo CI/CD moderno en 2026 automatiza build, pruebas, análisis estático, escaneo de dependencias y despliegue con quality gates. En PHP y Java, estandariza pipelines reutilizables, entornos efímeros para PRs y despliegues progresivos (canary/blue-green). El objetivo es reducir trabajo manual y eliminar esperas por aprobaciones repetitivas.
Pipeline de referencia: de commit a producción
- Pre-commit: formateo y linters (PHP-CS-Fixer/PHPStan; Checkstyle/SpotBugs), y ganchos para evitar secretos.
- CI (rápido): tests unitarios, análisis estático, build de artefacto (Composer/PHAR o imagen Docker; JAR), y caching.
- CI (profundo): tests de integración (DB/colas), pruebas de contrato, y escaneo SCA/SAST.
- CD: despliegue a staging con migraciones controladas, smoke tests, y promoción a producción con despliegue progresivo.
- Post-deploy: verificación de SLIs, alertas, y rollback automatizado si se incumplen umbrales.
Eliminar fricción de entornos: lección de la banca
Cuando levantar un entorno requiere tickets y aprobaciones, la agilidad se vuelve imposible. McKinsey describe un caso bancario donde un desarrollador debía pedir a varios equipos la configuración de entorno, realizar pruebas manuales extensas y obtener múltiples aprobaciones, añadiendo costo y complejidad al proceso (https://www.mckinsey.com/featured-insights/destacados/como-los-bancos-pueden-potenciar-la-velocidad-y-la-productividad-de-la-tecnologia/es). La práctica recomendada en 2026 es “self-service”: plantillas IaC, entornos efímeros y permisos por rol.
Para acelerar la entrega en proyectos empresariales, muchas organizaciones apoyan este flujo con servicios especializados de ingeniería. Si estás construyendo una plataforma o modernizando una existente, considera un partner con experiencia en desarrollo de software a medida y capacidades específicas en desarrollo con Java para estandarizar pipelines, gobernanza y prácticas de calidad.
¿Qué prácticas de calidad y testing sostienen la velocidad sin degradar el producto?
La velocidad sostenible depende de una estrategia de pruebas en pirámide, con alta cobertura de unitarias y un conjunto pequeño pero crítico de E2E. En PHP y Java, combina TDD donde aporte valor, pruebas de contrato para integraciones y “shift-left” de seguridad. La calidad no es un paso final: es un sistema automatizado.
Pirámide de pruebas práctica (PHP/Java)
En PHP, apóyate en PHPUnit/Pest y dobles de prueba para aislar dependencias; en Java, JUnit y frameworks de mocking. Para integración, usa contenedores efímeros (por ejemplo, bases de datos y colas) y datos semilla. Reserva E2E para flujos críticos (checkout, onboarding, facturación) y ejecútalos en paralelo para no bloquear el pipeline.
Pruebas de contrato y compatibilidad
Las pruebas de contrato reducen el “romper producción” por cambios en APIs. Define contratos y genera stubs/clients para PHP y Java, validando que productores y consumidores cumplan. Esto es especialmente útil cuando un backend Java sirve a servicios PHP (o viceversa) y hay despliegues independientes. El resultado es menos coordinación y más autonomía.
Calidad de código: estándares y revisiones efectivas
- Revisión de PR con checklist: lógica de negocio, errores, seguridad, observabilidad y performance.
- Reglas automáticas: linters y análisis estático como “gates” para evitar debates repetitivos.
- Refactor continuo: pequeñas mejoras por PR para reducir deuda técnica sin proyectos paralelos.
- Documentación viva: ADRs (Architecture Decision Records) cortos para decisiones relevantes.
- Política de “boy scout rule”: deja el código un poco mejor de lo que lo encontraste.
¿Cómo integrar seguridad (DevSecOps) sin frenar los sprints?
Integra seguridad como parte del flujo: modelado de amenazas ligero, escaneo automatizado y controles de acceso consistentes. En PHP y Java, prioriza gestión de dependencias, validación de entrada, secretos y hardening de contenedores. DevSecOps en 2026 busca reducir riesgo sin crear colas: automatiza lo repetible y reserva revisión humana para cambios de alto impacto.
Controles mínimos viables: lo que no debe faltar
- SCA (dependencias): alertas y actualización regular de librerías; política de versiones soportadas.
- SAST y linters de seguridad: ejecución en CI con severidades y excepciones auditables.
- Gestión de secretos: nunca en repositorios; rotación y almacenamiento en vault/servicio gestionado.
- Hardening: imágenes base mínimas, usuarios no-root, y escaneo de contenedores.
- Autorización y auditoría: least privilege, logs de acceso y trazabilidad por usuario/servicio.
Threat modeling ligero por sprint
No necesitas sesiones largas para cada historia. Un enfoque práctico es revisar amenazas por épica o por cambio arquitectónico: nuevos endpoints, cambios en autenticación, manejo de PII, o integraciones externas. Documenta riesgos y mitigaciones en un ADR breve, y añade pruebas de seguridad donde sea posible. La clave es que el equipo de producto lo vea como parte del alcance, no como “extra”.
¿Cómo usar IA generativa en el desarrollo ágil con PHP y Java (sin riesgos innecesarios)?
La IA generativa puede acelerar tareas de ingeniería, pero debe operar dentro de un marco de calidad, seguridad y propiedad intelectual. McKinsey reporta que el apoyo a la codificación con IA generativa puede ayudar a desarrollar código 35%–45% más rápido, refactorizar 20%–30% más rápido y documentar 45%–50% más rápido (https://www.mckinsey.com/featured-insights/destacados/el-momento-gestacional-de-la-tecnologia-con-la-ia-generativa-una-guia-para-cios-y-ctos). El valor aparece cuando se combina con estándares y revisión humana.
Casos de uso recomendados (y cómo operarlos)
En PHP y Java, la IA suele aportar más en tareas “de soporte” que en lógica de negocio: generación de scaffolding, ejemplos de tests, refactors mecánicos, documentación de módulos y explicación de código heredado. Define prompts tipo, plantillas de PR y reglas de validación (linters, tests) para que el output pase por el mismo circuito de calidad. Trata la IA como un acelerador, no como un autor confiable.
Gobernanza: datos, privacidad y revisión
- Define qué datos pueden compartirse con herramientas: nunca secretos, PII ni código propietario sensible sin controles.
- Exige revisión de código humana para cambios generados por IA, especialmente en autenticación, pagos y permisos.
- Registra el uso: etiqueta PRs “AI-assisted” y captura lecciones en retrospectivas.
- Crea una biblioteca interna de prompts y ejemplos aprobados para PHP/Java.
- Evalúa riesgo legal y de licencias con el área correspondiente antes de escalar el uso.
Capacitación práctica: el factor que más diferencia resultados
La adopción efectiva requiere aprendizaje aplicado. McKinsey señala que organizaciones de alto desempeño que invierten en talleres prácticos y tutorías individuales tienen 57% más probabilidades de ver mejoras cuantificables, frente a 20% en organizaciones de bajo desempeño (https://www.mckinsey.com/featured-insights/destacados/desbloquear-el-valor-de-la-ia-en-el-desarrollo-de-software/es). Tradúcelo a acción: sesiones cortas con ejercicios reales en tu base de código, no demos genéricas.
¿Qué prácticas de entrega y producto maximizan el impacto en negocio?
Maximizar impacto exige conectar backlog con resultados: hipótesis, experimentos y medición. En 2026, la agilidad madura combina discovery y delivery: valida antes de construir y aprende después de desplegar. En PHP y Java, esto se habilita con feature flags, instrumentación y releases pequeños que reduzcan el costo de equivocarse.
Backlog orientado a outcomes, no a outputs
Reescribe historias como cambios observables: “reducir abandono en onboarding” en lugar de “crear pantalla X”. Define métricas operativas y de producto por épica (tasa de error, tiempo de respuesta, conversión, tickets). Mantén un tablero de hipótesis con estado: por validar, en experimento, confirmado o descartado. Esto evita acumular funcionalidades sin impacto.
Experimentación segura con feature flags
Implementa flags por capa: backend (reglas), frontend (UI) y configuración. Asegura limpieza: cada flag debe tener dueño y fecha de retiro para evitar complejidad permanente. En Java, integra flags con el framework de configuración; en PHP, centraliza la evaluación para no dispersar condicionales. Combina con despliegues progresivos para reducir riesgo.
Mini caso ilustrativo 1 (hipotético): modernización de un portal B2B en PHP + servicios Java
Escenario hipotético: un portal B2B en PHP sirve catálogo y autoservicio, mientras Java gestiona pricing y pedidos. El equipo introduce contratos OpenAPI, pruebas de contrato y flags para activar el nuevo cálculo de precios por segmento. Resultado esperado: releases más pequeños, menos incidentes por cambios de API y capacidad de probar pricing con un subconjunto de clientes sin afectar al resto.
¿Cómo gestionar dependencias, librerías y versiones en PHP y Java sin frenar la entrega?
Gestionar dependencias en 2026 requiere disciplina: actualización continua, políticas de soporte y automatización de escaneo. En PHP, Composer y repositorios privados ayudan a estandarizar; en Java, Maven/Gradle con BOMs reduce incompatibilidades. El objetivo es minimizar sorpresas: cambios pequeños y frecuentes son más seguros que “big bang upgrades”.
Políticas de versión y compatibilidad
Define una política pública interna: versiones mínimas soportadas de PHP/JDK, ventanas de actualización y criterios de excepción. Mantén un calendario de upgrades y enlázalo al backlog técnico con prioridad explícita. En Java, usa BOMs para alinear dependencias; en PHP, bloquea rangos compatibles y revisa “lockfiles” en PRs. La agilidad se rompe cuando actualizar se vuelve un proyecto traumático.
Estandarización de proyectos: plantillas y “golden paths”
Crea plantillas de repositorio para servicios PHP y Java con lo mínimo: estructura, logging, health checks, tests base, pipeline y seguridad. Esto reduce decisiones repetitivas y acelera onboarding. En 2026, los equipos de plataforma suelen ofrecer “golden paths” para construir y desplegar, manteniendo libertad donde aporta valor. La estandarización bien diseñada es un multiplicador de velocidad.
Mini caso ilustrativo 2 (hipotético): reducción de incidentes por dependencia vulnerable
Escenario hipotético: un equipo sufre incidentes recurrentes por librerías desactualizadas en PHP y Java. Implementan escaneo SCA en CI, reglas de severidad y una rutina semanal de “dependency PRs” con pruebas automáticas. Resultado esperado: menos urgencias de seguridad, upgrades más pequeños y mayor predictibilidad del roadmap. La clave es convertir lo reactivo en una cadencia.
¿Qué observabilidad necesitas para operar ágil en producción?
Operar ágil implica aprender de producción con señales confiables. Implementa observabilidad con logs estructurados, métricas y trazas distribuidas, además de SLIs/SLOs por servicio. En PHP y Java, estandariza correlación de requests, dashboards por dominio y alertas accionables. Si no puedes detectar y diagnosticar rápido, los releases pequeños no bastan.
SLIs/SLOs: el puente entre ingeniería y negocio
Define SLIs por experiencia (latencia, disponibilidad, tasa de error) y por proceso (tiempo de procesamiento, colas). Acordar SLOs permite tomar decisiones: cuándo pausar features para estabilizar, cuándo invertir en performance y cómo priorizar deuda. Evita alertas por “CPU alta” sin contexto; alerta por impacto en usuario o incumplimiento de SLO. Esto hace que la agilidad sea sostenible.
Trazabilidad end-to-end en sistemas mixtos
Cuando un request entra por PHP y termina en un servicio Java (o al revés), la traza distribuida es la diferencia entre minutos y horas de diagnóstico. Estandariza IDs de correlación, propaga headers y registra eventos clave (inicio/fin, errores, dependencias externas). Complementa con “logs de negocio” para auditoría: pedidos, pagos, cambios de estado. La observabilidad no es “herramienta”, es diseño.
Mini caso ilustrativo 3 (hipotético): canary release con SLOs para un servicio Java crítico
Escenario hipotético: un servicio Java de pedidos se despliega con canary al 5% del tráfico, monitoreando latencia y tasa de error por segmento. Si el SLO se degrada, el sistema revierte automáticamente y abre un incidente con datos de traza. Resultado esperado: menor riesgo de despliegues y aprendizaje más rápido sobre comportamiento real. Esto habilita releases frecuentes sin “noches de despliegue”.
¿Cómo planificar sprints y releases con iteraciones de 1–2 semanas?
Planificar con iteraciones de 1–2 semanas funciona cuando el trabajo se divide en incrementos desplegables y se controlan dependencias. McKinsey describe que organizaciones ágiles se enfocan en iteraciones y experimentación rápida, produciendo un MVP en sprints de una o dos semanas con reuniones diarias para revisar avances y resolver problemas (https://www.mckinsey.com/industries/oil-and-gas/our-insights/giants-can-dance-agile-organizations-in-asset-heavy-industries//es-cl). En PHP/Java, el truco está en slicing técnico y producto.
Slicing de historias: vertical, desplegable y medible
Divide por valor y flujo, no por capas (“backend primero, UI después”). Un slice vertical incluye API, lógica, persistencia y una interfaz mínima, aunque sea detrás de un flag. Esto reduce integración tardía y permite medir. Si la historia no puede desplegarse, probablemente sea demasiado grande o dependa de decisiones aún no tomadas.
Release planning sin rigidez: roadmap como hipótesis
En 2026, los roadmaps efectivos declaran incertidumbre: objetivos trimestrales, apuestas y métricas, no listas cerradas. Alinea equipos PHP y Java con un “north star” de producto y límites de capacidad para trabajo no planificado (incidentes, soporte, seguridad). Revisa el roadmap con datos de producción y feedback de clientes. Esto evita que la agilidad se convierta en promesas incumplibles.
Mini caso ilustrativo 4 (hipotético): migración gradual de monolito PHP a módulos y servicios
Escenario hipotético: una empresa tiene un monolito PHP difícil de cambiar y decide modularizarlo por dominios (clientes, pedidos, facturación). Introduce un “strangler pattern” para extraer primero un servicio Java de facturación, con contratos y pruebas de contrato. Resultado esperado: reducción progresiva del acoplamiento, releases más seguros y capacidad de escalar equipos por dominio sin reescribir todo.
¿Qué prácticas específicas recomiendas para PHP en 2026 (frameworks, rendimiento y mantenimiento)?
En PHP en 2026, la agilidad se apoya en frameworks maduros, tipado más estricto, análisis estático y disciplina de dependencias. Prioriza diseño por módulos, pruebas unitarias rápidas y rendimiento medido con perfiles. Mantén consistencia con estándares de código y evita “magia” excesiva que dificulte el onboarding. La mantenibilidad es la ventaja competitiva.
Stack recomendado y prácticas de ingeniería
- Framework: Laravel o Symfony según necesidades; define convenciones de estructura y módulos.
- Calidad: PHPStan/Psalm para análisis estático; formateo consistente y reglas por repositorio.
- Testing: PHPUnit/Pest con factories; tests de integración con contenedores efímeros.
- Performance: cachés bien diseñadas, consultas optimizadas y profiling antes de “optimizar por intuición”.
- Observabilidad: logs estructurados y correlación de requests para rastrear flujos entre servicios.
Mini caso ilustrativo 5 (hipotético): acelerar onboarding con plantillas PHP
Escenario hipotético: un equipo crea una plantilla de servicio PHP con logging, health checks, pruebas base y pipeline preconfigurado. Los nuevos servicios se crean en horas, no días, y los PRs se revisan con el mismo checklist. Resultado esperado: menos variabilidad entre proyectos, menos errores repetidos y mejor movilidad de desarrolladores entre equipos. La estandarización reduce fricción sin matar la autonomía.
¿Qué prácticas específicas recomiendas para Java en 2026 (Spring, rendimiento y resiliencia)?
En Java en 2026, la agilidad se potencia con servicios bien delimitados, configuración consistente, pruebas confiables y resiliencia operacional. Con Spring como estándar frecuente, enfócate en contratos claros, manejo de errores predecible y límites de recursos. Automatiza perfiles de rendimiento y evita complejidad accidental en frameworks. La resiliencia es parte del diseño, no un parche.
Resiliencia y patrones operativos
Implementa timeouts, reintentos con backoff y circuit breakers para dependencias externas. Diseña idempotencia en endpoints críticos y usa colas/eventos para desacoplar procesos largos. Define límites de concurrencia y pools por tipo de carga para evitar efectos cascada. Estos patrones permiten que el equipo despliegue más a menudo sin miedo a que un fallo puntual escale a incidente mayor.
Mini caso ilustrativo 6 (hipotético): integración PHP–Java para campañas B2B
Escenario hipotético: marketing lanza campañas que disparan picos de tráfico en un frontend PHP, que llama a un servicio Java de cotización. El equipo introduce caché por segmento, colas para tareas no críticas y rate limiting, además de trazas distribuidas. Resultado esperado: mejor estabilidad en picos, menor latencia percibida y menos incidentes durante lanzamientos. La agilidad se refleja en lanzamientos sin “modo crisis”.
Si tu organización combina Java con otros enfoques de backend, puede ser útil revisar crecimiento empresarial con tecnologías híbridas: Node.js y Java para comparar patrones de integración, rendimiento y operación. Esto ayuda a decidir dónde Java aporta más y dónde conviene simplificar.
Checklist de implementación (30–60 días) para equipos ágiles PHP y Java
Implementa estas prácticas en oleadas de 30–60 días para evitar cambios masivos sin adopción real. Empieza por el flujo (CI/CD y calidad), sigue por arquitectura (contratos y modularidad) y consolida con métricas y formación. Prioriza acciones que reduzcan esperas y retrabajo, y valida mejoras con datos de entrega y operación. Este checklist está diseñado para ser ejecutable por un equipo y su plataforma.
- Semana 1–2: acordar Definition of Done, checklist de PR, límites de WIP y política de branching/versionado.
- Semana 1–3: crear pipeline estándar con linters, tests unitarios, análisis estático y escaneo de dependencias; convertirlo en plantilla reutilizable.
- Semana 2–4: instrumentar observabilidad mínima (logs estructurados, métricas, trazas) y definir 2–3 SLIs por servicio crítico.
- Semana 3–6: introducir contract-first (OpenAPI) y pruebas de contrato en una integración PHP–Java de alto tráfico.
- Semana 4–8: habilitar despliegue progresivo (canary/blue-green) y feature flags con política de retiro y ownership.
- Semana 4–8: plan de capacitación aplicada en IA y calidad: talleres cortos + tutorías (en tu propio repositorio), con reglas de gobernanza.
- Semana 6–10: refactor dirigido por métricas: reducir acoplamiento en un módulo y recortar tiempos de pipeline/feedback.
