Curso de Claude Code para Ingeniería de Software para empresas

Analizar la evolución desde perfiles especializados hacia desarrolladores con mayor capacidad de entrega end-to-end.

Revisar qué significa ser Fullstack en la práctica: entender flujo funcional, frontend, backend, datos, permisos y errores.

Diferenciar autonomía técnica real de “hacer más cosas sin control ni validación”.

Definir qué debe analizar un desarrollador antes de empezar a programar una tarea.

Revisar cómo la IA cambia la velocidad aparente de desarrollo y aumenta la necesidad de criterio técnico.

Identificar riesgos: código no comprendido, soluciones genéricas, tests superficiales, deuda técnica y falsa sensación de avance.

Establecer principios de uso saludable de IA: preguntar, contrastar, simplificar, validar y documentar.

Ajustar expectativas del equipo sobre qué debe venir preparado antes de la revisión senior.

Crear acuerdos de trabajo sobre análisis previo, validación, MR y uso de IA.

Taller: comparar una entrega Fullstack madura con una entrega rápida pero débilmente validada.

Definir responsabilidades prácticas del coordinador: capacidad, foco, dependencias, riesgos, prioridades y seguimiento diario.

Diferenciar coordinación técnica de microgestión o simple actualización de estados en Jira.

Revisar cómo proteger al equipo de interrupciones constantes sin ignorar urgencias reales.

Crear criterios para decidir qué entra en sprint, qué se pospone y qué requiere renegociación.

Gestionar tensión entre roadmap, incidencias de plataforma, deuda técnica, soporte y trabajo no previsto.

Detectar señales tempranas de sprint en riesgo: demasiadas tareas abiertas, bloqueos, cambios de alcance y MRs tardías.

Alinear coordinación con producto, negocio, soporte, plataforma, senior developers y responsables técnicos.

Preparar rutinas de seguimiento ligeras, útiles y orientadas a decisiones.

Evitar reuniones de seguimiento que no cambian prioridades ni eliminan bloqueos.

Taller: dirigir una revisión de sprint en riesgo y decidir ajustes concretos.

Calcular capacidad real teniendo en cuenta disponibilidad, reuniones, vacaciones, guardias, incidencias y soporte.

Diferenciar capacidad teórica, capacidad efectiva, foco disponible y margen de contingencia.

Planificar cuando existen varios sprints en una misma semana o equipos que trabajan en más de una línea.

Ajustar compromiso del sprint según complejidad, incertidumbre, dependencias y experiencia del desarrollador.

Evitar comprometer todo el tiempo disponible sin reservar margen para interrupciones previsibles.

Incorporar incidencias de producción y tareas urgentes sin esconder su impacto en la planificación.

Revisar tareas arrastradas de sprints anteriores y detectar causas reales de arrastre.

Usar históricos para mejorar previsión, no para culpar al equipo.

Definir reglas de entrada de trabajo no previsto durante el sprint.

Taller: planificar un sprint con capacidad limitada, personas compartidas, incidencias y prioridades en conflicto.

Mapear asignaciones cruzadas de una persona en varios proyectos, sprints, guardias o líneas de trabajo.

Calcular carga individual sumando tareas planificadas, soporte, reuniones, revisiones, incidencias y contexto perdido.

Detectar sobreasignación antes de que aparezca como retraso o mala calidad.

Evitar repartir tareas por disponibilidad aparente sin considerar seniority, contexto, dependencias y foco.

Ajustar planificación cuando una persona clave está compartida entre proyectos críticos.

Diseñar reglas para reservar tiempo de revisión senior y soporte a perfiles menos autónomos.

Gestionar tareas de alta incertidumbre con buffer y checkpoints intermedios.

Crear acuerdos para no fragmentar excesivamente el foco de un desarrollador.

Revisar impacto de multitarea en productividad y calidad técnica.

Taller: redistribuir carga de un sprint con personas sobreasignadas y prioridades incompatibles.

Usar Jira para tomar decisiones de planificación, capacidad, bloqueo, prioridad y avance real.

Diseñar una estructura clara de épicas, historias, tareas, subtareas, bugs, incidencias y tareas técnicas.

Crear campos útiles para riesgo, dependencia, área afectada, tipo de trabajo, validación y estimación.

Revisar tableros para distinguir trabajo comprometido, trabajo no previsto, bugs, soporte y tareas bloqueadas.

Evitar que Jira se convierta en un repositorio de tickets ambiguos sin valor operativo.

Definir estados de workflow que reflejen realidad: análisis, listo, en desarrollo, validación, MR, revisión y cerrado.

Crear filtros para ver carga por persona, tareas en paralelo, bloqueos, tareas sin estimar y MRs pendientes.

Usar dashboards para coordinadores, tech leads y equipo, no solo para reporting externo.

Revisar cuándo conviene usar plugins o planes avanzados para capacity planning y carga individual.

Taller: rediseñar un tablero Jira para mejorar visibilidad de capacidad, foco y calidad.

Revisar opciones nativas de Jira para sprint planning, backlog, estimaciones, reports, dashboards y planes.

Analizar capacidades de Jira Plans o Advanced Roadmaps para capacidad, roadmap, equipos e iteraciones.

Identificar limitaciones habituales cuando se necesita carga individual real sumando varios proyectos.

Evaluar plugins de capacity planning, resource planning, workload, timesheets o portfolio según necesidades reales.

Definir criterios de selección de plugin: carga por persona, disponibilidad, skills, proyectos cruzados, coste y adopción.

Preparar filtros JQL para sobrecarga, tareas sin estimar, bloqueos, work in progress y trabajo arrastrado.

Diseñar dashboards para coordinadores con foco en acción, no en gráficos decorativos.

Controlar calidad de datos: estimaciones incompletas, asignaciones erróneas, estados falsos y tickets sin owner.

Evitar comprar plugins si el equipo no mantiene datos mínimos con disciplina.

Taller: diseñar dashboard de carga individual, capacidad cruzada y riesgo de sprint.

Convertir tickets ambiguos en tareas claras, estimables, asignables y validables.

Definir contexto funcional, objetivo, alcance, fuera de alcance, dependencias, riesgos y dudas abiertas.

Redactar criterios de aceptación verificables y conectados con comportamiento esperado.

Incluir datos necesarios, permisos, estados, errores, integraciones, trazabilidad y expectativas de validación.

Separar historia funcional, tarea técnica, bug, spike, deuda técnica e incidencia.

Establecer Definition of Ready adaptada a Fullstack con IA.

Decidir cuándo una tarea no debe entrar en sprint porque aún no está preparada.

Usar IA para detectar ambigüedades, preguntas pendientes y escenarios no contemplados.

Evitar tickets que delegan el análisis completo en quien desarrolla sin tiempo real para hacerlo.

Taller: transformar un ticket mal definido en una tarea lista para sprint.

Convertir una necesidad funcional en épica, historia, tareas técnicas y subtareas accionables.

Dividir el trabajo en análisis, frontend, backend, datos, permisos, integración, testing, documentación y validación.

Identificar dependencias entre capas antes de comprometer fechas.

Separar tareas verticales de valor de tareas puramente técnicas cuando la planificación lo requiera.

Evitar dividir por capas de forma ciega si impide validar el flujo funcional completo.

Diseñar tareas que permitan avance incremental y revisión temprana.

Usar IA para proponer descomposición, detectar trabajo oculto y generar preguntas.

Ajustar la descomposición con criterio humano y conocimiento del producto.

Definir ownership claro de cada parte sin perder responsabilidad end-to-end.

Taller: convertir una funcionalidad de producto en estructura completa de Jira.

Usar GitHub Copilot, Claude Code u OpenCode para entender contexto de código, flujos y dependencias.

Pedir a la IA que identifique dudas funcionales, riesgos, casos límite, integraciones y posibles impactos.

Revisar rutas de código afectadas antes de estimar o comprometer trabajo.

Analizar cambios necesarios en frontend, backend, modelos, permisos, endpoints, validaciones y datos.

Pedir alternativas técnicas con pros, contras, riesgos y complejidad.

Detectar trabajo oculto: migraciones, tests, logs, errores, compatibilidad y documentación.

Evitar aceptar el primer plan generado si no encaja con arquitectura o dominio funcional.

Convertir el análisis en comentarios útiles dentro de Jira.

Crear checklist de análisis previo asistido por IA.

Taller: analizar una tarea nueva con IA y completar alcance, riesgos y preguntas.

Entender cómo MCPs e integraciones permiten consultar contexto y actuar sobre herramientas internas.

Identificar casos útiles: leer tickets, resumir contexto, crear subtareas, generar criterios y actualizar comentarios.

Diseñar permisos mínimos para herramientas conectadas a Jira, Confluence o repositorios.

Separar acciones de lectura, propuesta y escritura automática en herramientas corporativas.

Revisar riesgos de que la IA cree tickets incorrectos, modifique campos o publique información sensible.

Definir aprobación humana antes de cambios relevantes en Jira o documentación.

Usar IA para mantener trazabilidad de decisiones, dudas resueltas y criterios acordados.

Evitar integraciones sin logging, control de permisos o revisión de acciones.

Crear pautas de seguridad para conectar asistentes a sistemas internos.

Taller: diseñar flujo MCP seguro para crear y enriquecer tickets Jira.

Usar Copilot para comprender código existente, proponer cambios, generar tests y explicar diffs.

Aplicar Copilot a tareas pequeñas y bien definidas antes de delegar cambios amplios.

Revisar propuestas de Copilot frente a arquitectura, convenciones y dominio del producto.

Usar Copilot Chat para analizar errores, logs, validaciones, endpoints y componentes.

Preparar prompts con contexto, objetivo, restricciones, archivos relevantes y criterios de aceptación.

Evitar aceptar sugerencias por velocidad sin entender implicaciones.

Usar Copilot code review como apoyo, no como sustituto de revisión senior.

Generar borradores de documentación técnica y evidencias de prueba.

Medir dónde Copilot reduce tiempo y dónde introduce riesgo.

Taller: resolver una tarea Fullstack con Copilot manteniendo control técnico.

Usar Claude Code para explorar repositorio, entender arquitectura y proponer plan de implementación.

Pedir planes antes de cambios para validar enfoque, alcance y riesgos.

Separar sesiones de análisis, implementación, testing y revisión.

Configurar instrucciones de proyecto para que respete estándares internos.

Usar Claude Code para generar tareas, explicar diffs, proponer tests y detectar efectos colaterales.

Revisar comandos, cambios de archivos y acciones antes de aplicarlos en entornos sensibles.

Evitar sesiones largas sin checkpoints humanos.

Usar MCPs de forma controlada para consultar contexto de Jira, Confluence o repositorios.

Documentar hallazgos generados por Claude Code en ticket o MR.

Taller: usar Claude Code para analizar una tarea, proponer plan y validar cambios.

Entender OpenCode como agente open source para trabajar desde terminal, IDE o escritorio.

Configurar reglas de proyecto para orientar estilo, arquitectura, tests y límites de acción.

Usar agentes especializados para análisis, planificación, revisión, testing o documentación.

Controlar permisos de herramientas para evitar cambios no deseados.

Aplicar OpenCode a revisión de diffs, explicación de código, generación de tests y detección de riesgos.

Diseñar sesiones paralelas con cuidado para no generar cambios contradictorios.

Integrar OpenCode con GitHub workflows cuando el entorno lo permite.

Revisar diferencias entre usar OpenCode, Copilot y Claude Code según tarea.

Evitar que la herramienta opere sin comprensión del contexto de negocio.

Taller: configurar agente de revisión y agente de testing sobre una MR Fullstack.

Usar IA para diseñar componentes, estados, validaciones, formularios, mensajes y experiencia de usuario.

Revisar que la solución respeta patrones, diseño, accesibilidad, estados de carga y errores.

Validar consumo de APIs, contratos de datos, errores backend y estados vacíos.

Detectar comportamientos no contemplados: permisos, datos incompletos, paginación, filtros y concurrencia.

Generar tests frontend útiles, no solo snapshots o pruebas superficiales.

Evitar componentes genéricos que no encajan con arquitectura o design system.

Documentar decisiones de UX y validación funcional en Jira o MR.

Usar IA para revisar impacto de cambios en flujos existentes.

Coordinar frontend con backend antes de abrir MR.

Taller: desarrollar y validar una pantalla con IA sin perder criterio de producto.

Usar IA para analizar servicios, controladores, modelos, validadores, permisos, errores y persistencia.

Revisar que endpoints, DTOs, contratos y reglas de negocio están correctamente definidos.

Detectar riesgos de seguridad: permisos, datos sensibles, validación insuficiente, logs y errores expuestos.

Generar tests de unidad, integración y casos negativos relevantes.

Evitar lógica backend sugerida por IA que no respeta dominio, transacciones o arquitectura.

Revisar rendimiento básico, consultas, N+1, concurrencia y efectos colaterales.

Documentar endpoints, supuestos, migraciones, flags y cambios de configuración.

Coordinar cambios backend con frontend, datos y QA.

Validar trazabilidad, logs y comportamiento ante errores.

Taller: implementar backend asistido por IA con permisos, validaciones y pruebas.

Definir contrato entre frontend y backend antes de desarrollar en paralelo.

Revisar payloads, tipos, estados, errores, códigos, paginación, filtros y mensajes.

Validar permisos y visibilidad de datos en ambos lados.

Gestionar cambios de API sin romper consumidores existentes.

Usar mocks, contratos o datos de prueba para validar flujo completo.

Detectar inconsistencias entre lo que espera la UI y lo que devuelve el backend.

Usar IA para generar casos de integración, datos de prueba y escenarios límite.

Evitar que frontend y backend se validen por separado sin prueba end-to-end.

Documentar acuerdos técnicos y funcionales en Jira o Confluence.

Taller: validar integración completa de una funcionalidad Fullstack.

Usar IA para generar escenarios principales, alternativos, negativos y casos límite.

Diferenciar pruebas unitarias, integración, end-to-end, manuales y exploratorias.

Crear casos de prueba alineados con criterios de aceptación.

Incluir permisos, roles, datos incompletos, errores de backend, estados límite y regresión.

Evitar tests generados que solo validan implementación y no comportamiento real.

Usar IA para revisar huecos de cobertura y riesgo funcional.

Generar datos de prueba coherentes con el dominio.

Documentar evidencias de prueba antes de abrir la MR.

Integrar pruebas con Definition of Done.

Taller: construir matriz de pruebas para una historia Fullstack.

Establecer que el desarrollador es responsable de validar su entrega antes de pedir revisión.

Comprobar flujo funcional completo desde la perspectiva del usuario.

Revisar casos principales, casos alternativos, errores, permisos, estados y datos límite.

Verificar que frontend, backend, logs, trazabilidad, datos y mensajes encajan correctamente.

Analizar efectos colaterales sobre otras pantallas, endpoints, procesos o roles.

Confirmar que no quedan cambios temporales, console logs, mocks, flags incorrectos o datos hardcodeados.

Preparar evidencias de validación: pasos, datos, capturas, logs, tests y resultado.

Usar IA como apoyo para generar checklist, no para sustituir la prueba real.

Bloquear apertura de MRs que no incluyan validación mínima.

Taller: aplicar checklist de autovalidación sobre una entrega Fullstack.

Definir qué significa terminado en un contexto de desarrollo Fullstack asistido por IA.

Incluir desarrollo, pruebas, validación funcional, revisión técnica propia, documentación y MR preparada.

Incorporar criterios de seguridad, permisos, logs, errores, datos y efectos colaterales.

Exigir comprensión del código incorporado, especialmente si fue generado o sugerido por IA.

Añadir evidencias de pruebas y validación end-to-end como parte de la entrega.

Diferenciar Done técnico, Done funcional y Done listo para revisión senior.

Revisar excepciones justificadas y cómo documentarlas.

Evitar marcar tareas como terminadas solo porque compilan o pasan tests mínimos.

Adaptar DoD por tipo de tarea: bug, feature, refactor, incidencia o deuda técnica.

Taller: crear Definition of Done del equipo para entregas Fullstack con IA.

Redactar MRs con objetivo, contexto, ticket, alcance, fuera de alcance y decisiones tomadas.

Explicar impacto funcional desde la perspectiva del usuario y del producto.

Documentar impacto técnico: componentes, endpoints, modelos, permisos, migraciones y configuración.

Incluir evidencias de prueba: pasos, capturas, datos, escenarios, logs y resultados.

Señalar riesgos, limitaciones, dudas y partes que requieren atención especial del revisor.

Evitar MRs grandes, mezcladas, sin contexto o con cambios no relacionados.

Usar IA para resumir cambios, detectar omisiones y mejorar claridad de la descripción.

Preparar checklist de MR antes de solicitar revisión.

Crear plantilla estándar de MR para el equipo.

Taller: transformar una MR deficiente en una MR clara, revisable y bien evidenciada.

Redefinir la revisión senior como validación de criterio técnico, no solo revisión de estilo.

Comprobar si la solución es simple, mantenible, segura, coherente y alineada con arquitectura.

Detectar si el desarrollador entiende realmente lo que ha entregado.

Revisar efectos colaterales, dependencias, deuda técnica, duplicidades y complejidad innecesaria.

Evaluar seguridad: permisos, exposición de datos, validación de entradas, errores, logs y trazabilidad.

Verificar calidad funcional: el cambio resuelve el problema y cubre flujos relevantes.

Revisar código asistido por IA buscando invención de APIs, lógica genérica, tests pobres y falta de adaptación.

Usar IA como copiloto de revisión para generar preguntas, riesgos y puntos de atención.

Evitar delegar el juicio final de merge en una herramienta automática.

Taller: revisar una MR desarrollada con IA y emitir feedback senior de calidad.

Identificar señales de alerta en propuestas aparentemente plausibles pero incorrectas.

Detectar código que compila pero no respeta dominio, arquitectura, permisos o comportamiento esperado.

Reconocer tests generados que confirman la implementación en lugar de validar el requisito.

Revisar usos inventados de APIs, librerías, patrones o endpoints inexistentes.

Analizar propuestas demasiado complejas para un problema simple.

Comparar solución generada con convenciones reales del proyecto.

Pedir a la IA contraargumentos, riesgos y alternativas para forzar pensamiento crítico.

Crear hábito de “validar antes de pegar” cualquier propuesta.

Documentar aprendizajes de errores de IA para evitar recurrencias.

Taller: analizar una solución IA incorrecta y corregirla con criterio técnico.

Clasificar interrupciones: producción, plataforma, soporte, bloqueos externos, urgencias de negocio y dudas internas.

Decidir qué interrupciones entran en sprint y cuáles requieren canal paralelo o renegociación.

Registrar trabajo no previsto en Jira para hacerlo visible y medible.

Medir impacto de incidencias en foco, capacidad y compromiso del sprint.

Crear política de guardias, rotaciones o buffers para reducir daño al roadmap.

Evitar ocultar incidencias bajo tareas existentes.

Revisar cómo compensar trabajo no planificado sin castigar la calidad.

Establecer criterios de prioridad y escalado con producto, soporte y dirección técnica.

Usar métricas para negociar capacidad futura.

Taller: gestionar entrada de incidencia urgente durante sprint ya saturado.

Medir compromiso frente a entrega real sin convertirlo en herramienta de presión individual.

Analizar trabajo arrastrado, cambios de alcance, bugs, incidencias y tareas no previstas.

Visualizar sobrecarga por persona, asignaciones cruzadas, multitarea y bloqueos.

Medir WIP individual y de equipo para detectar dispersión.

Revisar lead time, cycle time, tiempo en revisión y tiempo bloqueado.

Identificar patrones de desviación por tipo de tarea, proyecto, equipo o falta de definición.

Crear métricas de foco: cambios de prioridad, interrupciones, proyectos simultáneos y contexto perdido.

Conectar métricas con acciones: ajustar capacidad, mejorar DoR, reforzar validación o reducir WIP.

Evitar métricas que incentivan cerrar tareas rápido sin calidad.

Taller: diseñar dashboard de métricas útil para coordinación técnica.

Medir retrabajo, bugs posteriores, MRs rechazadas, defectos en revisión e incidencias post-release.

Analizar calidad de MRs: contexto, evidencias, tamaño, claridad, tests y comentarios de revisión.

Medir uso de IA por tarea: análisis, implementación, testing, documentación, revisión y mantenimiento.

Identificar dónde la IA aporta valor real y dónde aumenta riesgo o retrabajo.

Crear indicadores de código generado no entendido, tests superficiales o validación insuficiente.

Revisar defectos recurrentes atribuibles a mala definición o mal uso de IA.

Incorporar métricas de autovalidación y Definition of Done.

Evitar controlar la IA como vigilancia individual; usar datos para mejorar el sistema.

Ajustar guías de uso de IA según evidencias.

Taller: crear cuadro de mando de calidad y uso responsable de IA.

Convertir retrospectivas en decisiones concretas sobre capacidad, definición, validación y revisión.

Revisar periódicamente Definition of Ready, Definition of Done y plantilla de MR.

Ajustar política de interrupciones según datos reales de sprints.

Identificar patrones de tareas que siempre se estiman mal y corregir análisis previo.

Crear acciones de mejora para reducir WIP, sobrecarga y dependencia de perfiles clave.

Revisar guías de IA según errores, aprendizajes y nuevas capacidades de herramientas.

Mantener repositorio interno de ejemplos: ticket bueno, ticket malo, MR buena, MR mala y revisión senior.

Evitar que la mejora continua se quede en conversaciones sin owner ni seguimiento.

Definir responsables y fechas para cada mejora del proceso.

Taller: diseñar plan de mejora de 90 días para el equipo.

Construir plantilla de ticket Jira con contexto, objetivo, alcance, dependencias, riesgos y criterios de aceptación.

Crear checklist de análisis previo antes de comprometer una tarea en sprint.

Diseñar guía de descomposición de historias en tareas frontend, backend, integración, testing y validación.

Redactar plantilla de criterios de aceptación verificables y conectados al flujo funcional.

Definir Definition of Ready adaptada a Fullstack con IA.

Definir Definition of Done adaptada a entregas end-to-end asistidas por IA.

Crear checklist de autovalidación antes de abrir una MR.

Diseñar plantilla de MR de calidad con contexto, impacto, evidencias, riesgos y pruebas.

Redactar guía de revisión senior de código asistido por IA.

Preparar propuesta de métricas, dashboards, filtros y posibles plugins Jira para visibilidad de capacidad y calidad.

Simular un contexto real con varios sprints, personas compartidas, incidencias, tareas no previstas y uso de IA.

Partir de una necesidad funcional ambigua y convertirla en épica, historia, tareas técnicas y criterios de aceptación.

Usar IA para analizar requisitos, detectar dudas, proponer riesgos, dependencias, casos límite y escenarios de prueba.

Completar tickets Jira con contexto, alcance, definición de ready, estimación, owner y validaciones esperadas.

Planificar sprint considerando capacidad real, carga individual, interrupciones, prioridades y margen de contingencia.

Desarrollar o simular una entrega Fullstack con frontend, backend, integración, permisos, errores y logs.

Aplicar checklist de autovalidación antes de abrir MR, incluyendo casos principales, límites y efectos colaterales.

Preparar MR de calidad con descripción, impacto funcional, impacto técnico, evidencias, riesgos y pruebas realizadas.

Ejecutar revisión senior de una entrega asistida por IA, detectando problemas de arquitectura, seguridad y mantenibilidad.

Presentar paquete final de entregables internos: plantillas, DoR, DoD, checklist, guía de MR, guía senior y métricas.