Glosario: 50 términos que nadie te explica en tu primer trabajo

Llegas a tu primer trabajo como developer y la primera reunión está llena de términos que nadie te explicó en el bootcamp o la universidad. “Vamos a hacer una retro al final del sprint”, “el MR tiene conflictos”, “el CI está en rojo”, “tenemos que refinar el backlog para la planning”. Asientes, sonríes, y buscas en Google en cuanto sales de la reunión.

Este glosario va de eso. 50 términos que vas a escuchar en tu primer trabajo y que las explicaciones de internet hacen sonar más complicados de lo que son. Aquí están como te los explicaría un amigo: definición clara + ejemplo real + por qué importa.

Organizados por categoría para que puedas saltar a lo que necesites. Marca esta página, vas a volver.

Metodologías ágiles#

1. Sprint#

Un periodo de tiempo fijo (normalmente 2 semanas) durante el cual el equipo trabaja en un conjunto definido de tareas. Al final del sprint, se entrega algo funcionando.

Ejemplo: “En este sprint vamos a terminar el módulo de pagos. Empieza el lunes, acaba el viernes 14”.

Por qué importa: tu trabajo se organiza en sprints. Lo que se mete en un sprint debe acabarse en ese sprint, no en el siguiente. Sí o sí.

2. Stand-up / Daily#

Reunión diaria de 15 minutos máximo donde cada miembro del equipo dice: qué hizo ayer, qué hará hoy, si tiene bloqueos.

Ejemplo: “Ayer terminé el endpoint de login, hoy empiezo el de signup, sin bloqueos”.

Por qué importa: es la reunión más frecuente. Hazla breve: nadie quiere oír un monólogo a primera hora.

3. Refinamiento / Grooming#

Reunión donde el equipo revisa el backlog (lista de tareas pendientes), discute requisitos y estima esfuerzo.

Ejemplo: “El viernes hacemos refinamiento de las features del próximo sprint”.

Por qué importa: si no entiendes una tarea, este es el momento de preguntar. Si dices “sí, entendido” sin entender, te explotará en la cara durante el sprint.

4. Planning / Planificación#

Reunión al inicio del sprint donde se decide qué tareas se meten en el sprint según capacidad del equipo.

Por qué importa: aquí te comprometes a entregar X cosas. No te comprometas a más de lo que realmente puedes hacer.

5. Retrospectiva / Retro#

Reunión al final del sprint donde el equipo discute qué fue bien, qué fue mal y qué cambiar.

Ejemplo: “En la retro vimos que las PRs tardan mucho en revisarse, vamos a poner un tiempo máximo”.

Por qué importa: es el momento de plantear mejoras de proceso. Si algo te frustra del equipo, dilo aquí, no en privado.

6. Demo / Review#

Presentación al final del sprint donde se muestra lo que se construyó al equipo y a stakeholders.

Por qué importa: si tu trabajo no se ve en la demo, “no existe” para el resto de la empresa.

7. Backlog#

Lista priorizada de tareas pendientes del producto. Lo gestiona normalmente el Product Owner o Product Manager.

Estructura típica: cada item es una “historia de usuario” o “ticket” en una herramienta como Jira, Linear o GitHub Projects.

8. Historia de usuario / User story#

Formato típico para describir una funcionalidad desde el punto de vista del usuario.

Formato estándar: “Como [tipo de usuario] quiero [acción] para [beneficio]”.

Ejemplo: “Como usuario registrado quiero exportar mis datos en CSV para poder analizarlos en Excel”.

9. Story points / Puntos de historia#

Unidad para estimar el esfuerzo de una tarea. NO son horas, son una medida relativa de complejidad.

Escala típica: 1, 2, 3, 5, 8, 13 (secuencia Fibonacci).

Por qué importa: si una tarea es 8 puntos, vale para todo el sprint. Si es 1, son pocas horas.

10. Definition of Done (DoD)#

Criterios que una tarea debe cumplir para considerarse terminada.

Típicamente incluye: código escrito, tests pasando, code review aprobado, deployado a staging, documentación actualizada.

Por qué importa: “está terminado” puede significar 10 cosas distintas. La DoD lo aclara.

Roles y posiciones#

11. Product Owner (PO) / Product Manager (PM)#

La persona que decide qué se construye y en qué orden. Comunica con stakeholders y clientes.

Diferencia sutil: PO es más operativo (gestiona el backlog), PM más estratégico (define producto). En muchas empresas se solapan.

12. Scrum Master#

Persona que facilita las ceremonias ágiles (stand-ups, retros, etc.) y elimina bloqueos del equipo.

Importante: NO es jefe del equipo, es facilitador. No te da órdenes, te ayuda a desbloquear.

13. Tech Lead#

Developer senior que lidera técnicamente un equipo o proyecto. Toma decisiones de arquitectura, hace mentoría, asegura calidad.

No es manager (no gestiona personas formalmente), pero influye mucho.

14. Engineering Manager (EM)#

Manager formal del equipo de developers. Gestiona personas, revisiones de rendimiento, contratación.

Diferencia con Tech Lead: el EM se ocupa de personas, el Tech Lead de tecnología. Aunque a veces se solapan.

15. Junior / Mid / Senior / Staff / Principal#

Niveles típicos de seniority en una empresa tech:

Junior (0-2 años): aprende, ejecuta tareas claras, supervisión cercana.
Mid (2-5 años): autónomo en tareas medianas, contribuye a decisiones técnicas.
Senior (5+ años): autónomo en sistemas complejos, mentoriza juniors, define arquitectura.
Staff (8+ años): lidera proyectos cross-equipo, alto impacto técnico.
Principal (10+ años): decisiones a nivel de empresa, autoridad técnica máxima.

Control de versiones (Git)#

16. Branch / Rama#

Versión paralela del código donde puedes trabajar sin afectar a la versión principal.

Convenciones típicas: main o master para producción, develop para desarrollo, feature/nombre-feature para nuevas funcionalidades.

17. Pull Request (PR) / Merge Request (MR)#

Solicitud para incorporar tu rama al código principal. Se revisa por otros developers antes de fusionarse.

Diferencia: GitHub usa “Pull Request”, GitLab usa “Merge Request”. Mismo concepto.

18. Code review#

Proceso donde otro developer revisa tu código antes de mergearlo. Comenta cambios, sugerencias o problemas.

Por qué importa: tu primer trabajo va a tener muchas code reviews. Aprende a recibir feedback constructivamente y a dar feedback constructivo.

19. Merge / Fusión#

Combinar cambios de una rama en otra. “Mergear” en spanglish.

Ejemplo: “Mergea tu PR cuando dos personas la aprueben”.

20. Rebase#

Reescribir el historial de tu rama para que parezca que tus cambios se hicieron sobre la última versión de main.

Cuándo usarlo: para mantener historial limpio antes de mergear. Es polémico, hay equipos que prefieren merges normales.

21. Conflicto / Merge conflict#

Cuando Git no sabe cómo combinar dos cambios porque modifican las mismas líneas.

Solución: resolver manualmente eligiendo qué cambio mantener.

22. Cherry-pick#

Coger un commit específico de una rama y aplicarlo a otra.

Cuándo usarlo: cuando quieres llevar un fix concreto a otra rama sin merge completo.

23. Rollback / Revertir#

Deshacer cambios que se desplegaron. Volver a un estado anterior.

Ejemplo: “El deploy de ayer rompió producción, vamos a hacer rollback”.

DevOps y deployment#

24. CI / Continuous Integration#

Proceso automático que ejecuta tests, linting y otras validaciones cada vez que haces push.

Herramientas típicas: GitHub Actions, GitLab CI, CircleCI, Jenkins.

Por qué importa: si el CI está rojo, no puedes mergear. Aprende a leer los logs.

25. CD / Continuous Deployment (o Delivery)#

Proceso automático que despliega tu código a producción (o a un entorno intermedio) cuando los cambios se mergean.

Diferencia: Deployment = automático a producción. Delivery = automático hasta staging, despliegue manual a producción.

26. Pipeline#

Secuencia de pasos que ejecuta el CI/CD: build, test, deploy, etc.

Ejemplo: “El pipeline tarda 15 minutos porque los tests E2E son lentos”.

27. Build#

Proceso de compilar/empaquetar tu código para producción.

Ejemplo: “El build falló porque hay un error de TypeScript”.

28. Deploy / Despliegue#

Subir el código a un servidor donde lo pueden usar usuarios reales.

Tipos: deploy a staging (pre-producción), deploy a producción.

29. Staging / Pre-producción#

Entorno casi idéntico a producción donde se prueban cambios antes de ir a usuarios reales.

Por qué importa: si algo falla en staging, no afecta a usuarios. Si falla en prod, sí.

30. Hotfix#

Fix urgente que se despliega rápido (sin esperar al siguiente sprint) porque hay un bug crítico en producción.

Ejemplo: “Hotfix: el botón de pago ha dejado de funcionar”.

Métodos y patrones#

31. MVP / Minimum Viable Product#

Versión más pequeña posible del producto que ya aporta valor a usuarios.

Ejemplo: “El MVP del e-commerce: listar productos, carrito, checkout con Stripe. Sin filtros, sin cuenta de usuario”.

Por qué importa: lanza algo pequeño y itera, no construyas 6 meses sin enseñar nada.

32. POC / Proof of Concept#

Demo técnica para probar si algo es viable. NO es código de producción, es para validar una idea.

Diferencia con MVP: POC valida tecnología, MVP valida producto.

33. Spike#

Investigación corta (1-2 días típicamente) sobre un tema técnico antes de implementarlo.

Ejemplo: “Hagamos un spike sobre si Stripe vs Adyen para nuestra integración de pagos”.

34. Refactor / Refactorización#

Cambiar código sin cambiar comportamiento. Mejorar legibilidad, performance o estructura.

Importante: refactor + cambio de funcionalidad = mala práctica. Hazlo por separado.

35. Tech debt / Deuda técnica#

Decisiones técnicas subóptimas que se hacen por velocidad ahora y se “pagan” después con más trabajo.

Ejemplo: “Metimos lógica de negocio en el componente porque íbamos justos. Eso es tech debt que arreglar el próximo sprint”.

36. Boilerplate#

Código repetitivo que necesitas escribir aunque no aporta lógica única.

Ejemplo: “El boilerplate para crear un nuevo endpoint en este framework es brutal”.

37. DRY / Don’t Repeat Yourself#

Principio: no repitas el mismo código en varios sitios. Si lo haces, extrae a una función o componente reutilizable.

38. KISS / Keep It Simple, Stupid#

Principio: la solución más simple suele ser la mejor. No sobreingeniería.

39. YAGNI / You Aren’t Gonna Need It#

Principio: no añadas funcionalidad “por si acaso la necesitamos”. Construye lo que necesitas ahora.

40. SOLID#

Cinco principios de diseño orientado a objetos. No te los vas a aprender de memoria pero los verás citados:

S: Single Responsibility (una clase, una responsabilidad)
O: Open/Closed (abierto a extensión, cerrado a modificación)
L: Liskov Substitution (las subclases deben ser sustituibles por sus padres)
I: Interface Segregation (interfaces específicas mejor que generales)
D: Dependency Inversion (depende de abstracciones, no de implementaciones)

Testing#

41. Unit test / Test unitario#

Test que prueba una función o componente aislado.

Ejemplo: testear que sumar(2, 3) === 5.

42. Integration test / Test de integración#

Test que prueba varias partes funcionando juntas.

Ejemplo: testear que el endpoint /api/users/create realmente crea un usuario en la base de datos.

43. E2E / End-to-end test#

Test que prueba un flujo completo simulando un usuario real.

Ejemplo: testear que un usuario puede registrarse, hacer login, comprar un producto y recibir email de confirmación.

44. TDD / Test-Driven Development#

Metodología: escribir el test primero, ver que falla, luego escribir el código que lo hace pasar.

Ciclo: Red (test falla) → Green (test pasa) → Refactor (mejoras código).

45. Coverage / Cobertura#

Porcentaje de tu código que está cubierto por tests.

Objetivo típico: 70-80%. 100% suele ser excesivo (no aporta valor proporcional al esfuerzo).

Términos varios#

46. SLA / Service Level Agreement#

Compromiso de nivel de servicio. Por ejemplo, “99,9% uptime” significa que el sistema puede estar caído máximo 8 horas y 45 minutos al año.

Por qué importa: define qué es “aceptable” para problemas en producción.

47. SLO / Service Level Objective#

Objetivo interno que el equipo se marca. Suele ser más estricto que el SLA.

48. Postmortem#

Documento que se escribe después de un incidente grave en producción. Analiza qué pasó, por qué y cómo evitar que vuelva a pasar.

Importante: el postmortem NO busca culpables. Es para aprender, no para señalar.

49. On-call / Guardia#

Turno donde un developer está disponible fuera del horario para responder a incidentes urgentes.

Compensación típica: extra de sueldo o días libres por las guardias.

50. WIP / Work In Progress#

Trabajo en curso. Verás “WIP” mucho en títulos de PRs para indicar que aún no está terminado.

Ejemplo: “WIP: añadir autenticación con Google OAuth” significa “esto no está listo todavía, no lo revisen formalmente”.

Conclusión#

Esta lista no es exhaustiva — hay 100 términos más que escucharás con el tiempo. Pero si dominas estos 50, vas a entender el 90% de las conversaciones en tu primer trabajo.

Y un consejo final: siempre pregunta cuando no entiendas algo. Es más profesional preguntar “¿qué significa CI rojo?” la primera vez que pasarte 6 meses asintiendo sin entender. Tus compañeros senior preferirán mil veces explicarte un término que descubrir 3 sprints después que llevas tiempo confuso.

Marca esta página, compártela con compañeros del bootcamp o de la universidad, y vuelve cuando necesites refrescar algo. La actualizamos cuando aparecen términos nuevos importantes.

Si crees que falta algún término importante o tienes alguna duda específica, escríbenos. Mantenemos este glosario actualizado con feedback de la comunidad.