Vocabulario de desarrollo de software en inglés: significado y ejemplos en español

Mundo de juego amplio que se puede explorar libremente y casi en cualquier orden, en vez de avanzar por una serie fija de niveles.

Versión inicial de un nivel construida con formas grises sencillas, sin arte final, para probar distribución, escala, rutas y ritmo antes de que los artistas trabajen en él.

Recorrido más directo por un nivel o juego que se debe seguir para terminarlo, frente a zonas secundarias, secretos y misiones opcionales.

Creación automática de contenido, como mapas, mazmorras, terreno o botín, mediante algoritmos y reglas, en vez de diseñar cada elemento manualmente.

Mapa simplificado de las superficies transitables de un nivel que la IA del juego usa para encontrar rutas y mover personajes evitando obstáculos.

Objeto del motor físico que conserva su forma y se mueve por fuerzas como gravedad y colisiones, por ejemplo una caja que cae o una granada lanzada.

Comprobación que lanza una línea invisible desde un punto en una dirección para detectar el primer objeto que encuentra; sirve para disparos, visibilidad y contacto con el suelo.

Configuración física en la que el cuerpo de un personaje se compone de partes articuladas que caen y reaccionan a fuerzas, normalmente al morir o ser derribado.

Fotograma de animación en el que se fija una pose o valor importante; el programa calcula el movimiento intermedio entre fotogramas clave.

Estructura interna de huesos y controles de un modelo 3D que los animadores mueven para posar y animar el personaje.

Orden que la CPU envía a la tarjeta gráfica para dibujar un grupo de polígonos con un material; demasiadas por fotograma pueden ralentizar el juego.

Unidad de procesamiento gráfico que renderiza imágenes ejecutando sombreadores y dibujando millones de píxeles por fotograma; la CPU lleva gran parte de la lógica del juego.

Efectos visuales aplicados a la imagen completa después de renderizar la escena, como resplandor, desenfoque de movimiento, gradación de color y profundidad de campo.

Herramienta que crea efectos como fuego, humo, chispas, lluvia o magia generando y moviendo muchas imágenes o formas pequeñas llamadas partículas.

Técnica que sustituye un modelo por versiones más sencillas a medida que se aleja de la cámara, para que los objetos distantes usen menos polígonos y el juego funcione más rápido.

Calcular de antemano algo costoso, como iluminación, sombras o datos de navegación, y guardar el resultado para no tener que calcularlo en tiempo real durante el juego.

Herramienta que mide en qué se emplean el tiempo y la memoria de un juego, fotograma a fotograma, para localizar la causa de la lentitud sin tener que adivinar.

Enfoque de diseño de sistemas que separa responsabilidades en capas, como presentación, lógica de negocio y acceso a datos.

Estilo arquitectónico que organiza capacidades del sistema como servicios separados que se comunican mediante interfaces definidas.

Estilo de diseño en que los componentes se comunican generando y respondiendo a eventos, en vez de hacer llamadas directas estrechamente acopladas.

Diseño que aísla grupos de recursos o componentes para limitar cuánto afecta un fallo de una parte al resto.

Registro de una secuencia de eventos del dominio como fuente autorizada, a partir de la cual se deriva el estado de la aplicación.

Principio que separa las operaciones que modifican el estado de las que devuelven información sin modificarlo.

Diseño que mantiene la lógica del dominio independiente de sistemas externos mediante puertos y adaptadores definidos.

Sustitución progresiva de un sistema heredado: se trasladan capacidades a uno nuevo y se redirige allí su tráfico.

Mecanismo por el que un componente receptor reduce o limita el trabajo entrante cuando no puede procesarlo con suficiente rapidez.

Propiedad por la que repetir una operación produce el mismo efecto previsto que ejecutarla una sola vez.

Operación de negocio posterior que contrarresta los efectos de otra operación ya completada cuando el flujo entero no puede terminar.

Una capacidad del producto que el usuario puede ver o utilizar, como una barra de búsqueda, el modo oscuro o la exportación de informes.

Registro en una herramienta de seguimiento, como Jira, que describe una unidad de trabajo —por ejemplo, un error, una tarea o una función— e indica responsable y estado.

Periodo fijo, normalmente de una o dos semanas, durante el cual un equipo se compromete a completar un conjunto elegido de tareas.

Reunión breve diaria del equipo, a menudo de 15 minutos, en la que cada persona cuenta qué hizo, qué hará y si tiene algún impedimento.

Función que el software debe ofrecer o condición que debe cumplir, según lo acordado con usuarios, clientes o el equipo de producto.

Lista ordenada del trabajo que el equipo aún no ha empezado, como funciones, errores y mejoras, con lo más prioritario arriba.

Calcular aproximadamente cuánto tiempo o esfuerzo requerirá una tarea antes de empezar. Como sustantivo, estimate es esa cifra aproximada.

Problema que impide a alguien continuar hasta que se resuelva, como la falta de acceso, una duda pendiente o un entorno averiado.

Descripción breve de una función desde el punto de vista del usuario, a menudo con la forma «Como [tipo de usuario], quiero [objetivo] para [motivo]».

Describe una forma de trabajar en ciclos breves, entregar partes pequeñas con frecuencia y ajustar el plan según los comentarios, en lugar de seguir un plan largo e inmutable.

Mantener una reunión o conversación corta para compartir novedades y asegurarse de que todos tienen la misma información y el mismo plan. También se usa como sustantivo: quick sync.

Trabajo que no forma parte de lo acordado para un proyecto, sprint o ticket y que, por tanto, no se hará ahora aunque sea una buena idea.

Marco ágil de trabajo popular en el que un equipo pequeño avanza en periodos breves y fijos llamados sprints, con responsabilidades y reuniones periódicas para planificar y revisar el trabajo.

Reunión al final de un sprint o proyecto en la que el equipo analiza qué salió bien, qué salió mal y qué conviene cambiar la próxima vez.

Decidir qué tareas son más importantes o urgentes y deben hacerse primero, sobre todo cuando no hay tiempo suficiente para todo.

Lista de condiciones concretas que una función o historia de usuario debe cumplir para que el equipo y el responsable de producto la den por terminada.

Unidad que los equipos ágiles utilizan para estimar el esfuerzo de una tarea según su tamaño, complejidad e incertidumbre, en vez de calcular horas.

Enviar a alguien un mensaje corto, normalmente por el chat del equipo, para hacer una pregunta, recordarle algo o llamar su atención. En redes también es comprobar si se alcanza un servidor.

Sigla de «estimated time of arrival» («hora estimada de llegada»); en el trabajo suele indicar cuándo se espera terminar una tarea, corrección o entrega.

Forma de trabajar en la que dos desarrolladores escriben código juntos desde un equipo o una pantalla compartida: una persona teclea y la otra revisa y piensa los siguientes pasos.

Aumento paulatino y no controlado de los requisitos después de empezar, al añadir peticiones sin ajustar plazo ni presupuesto.

Persona o grupo afectado por un proyecto o con influencia en él, como clientes, responsables, otros equipos, asesoría jurídica o soporte.

Persona que decide qué debe hacer un producto y por qué, comprende a usuarios y negocio, y guía al equipo que lo construye.

Plan general que presenta qué pretende abordar un equipo de producto durante los próximos meses o trimestres y por qué, sin enumerar cada tarea.

Versión más sencilla de un producto que puede publicarse para usuarios reales y comprobar si vale la pena seguir desarrollando la idea.

Documento que explica qué debe hacer una función o producto, para quién y por qué, de modo que el equipo comparta un mismo plan.

Momento en que un producto o función nueva queda disponible para usuarios, junto con las actividades de marketing, ventas y soporte previstas.

En Scrum, persona responsable de la lista de producto: ordena sus elementos, los aclara y procura que el equipo trabaje en lo más valioso.

Situación concreta en que alguien usa un producto para alcanzar un objetivo, descrita paso a paso o como un escenario breve.

Método para fijar metas en que el equipo define un objetivo inspirador y entre dos y cinco resultados medibles que indican el avance.

Unidad grande de trabajo, demasiado extensa para un sprint, que se divide en historias de usuario más pequeñas, como admitir varias monedas.

Método de priorización que asigna una puntuación según alcance, impacto, confianza y esfuerzo para comparar ideas distintas.

Método de priorización que clasifica requisitos en cuatro grupos: imprescindibles, convenientes, posibles y fuera de alcance por ahora.

Orden y fechas previstos para las etapas principales de un trabajo, desde el inicio hasta el lanzamiento.

Comprobar mediante pruebas con usuarios, datos o experimentos que una idea, suposición o solución es correcta antes de invertir más recursos.

Documento que describe en detalle el aspecto y el comportamiento de una función para que diseño e ingeniería puedan implementarla correctamente.

Sugerencia de un cliente, usuario o colega para añadir una función o modificar una existente.

Lista compartida de condiciones de calidad que cada trabajo debe cumplir antes de que el equipo lo considere terminado, como estar probado, revisado y documentado.

Trabajo periódico en el que responsable de producto y equipo revisan elementos próximos, los aclaran, dividen los grandes y estiman para prepararlos para un sprint.

Discrepar o resistirse a una petición, decisión o plazo, normalmente con cortesía y razones; también significa mover una fecha a más adelante.

Equipo de personas con habilidades distintas, como producto, diseño, ingeniería y datos, que trabajan hacia el mismo objetivo de producto.

Dar aprobación formal a un documento, diseño o trabajo para que pueda comenzar la siguiente etapa.

Informe breve y periódico que comunica a las partes interesadas qué se terminó, qué viene después y qué riesgos o bloqueos hay.

Decisión formal, normalmente poco antes de lanzar, sobre si un producto o versión está listo para avanzar o debe aplazarse.

Dejar de ofrecer y mantener poco a poco un producto o función, normalmente avisando antes a los usuarios y ayudándolos a migrar a una alternativa.

Métrica que cambia pronto y ayuda a anticipar un resultado futuro, como los inicios de sesión semanales que predicen renovaciones, para que el equipo pueda actuar a tiempo.

Métrica que se vigila durante un experimento o lanzamiento para asegurarse de que el cambio no perjudica algo importante, como velocidad, ingresos o quejas.

Revisar rápidamente errores, solicitudes o incidencias entrantes y ordenarlos por urgencia e importancia, decidiendo cuáles atender ahora, después o nunca.

Práctica de una empresa que utiliza su propio producto internamente, a menudo antes de publicarlo, para descubrir problemas y vivir la experiencia de primera mano.

Técnica de estimación en equipo en la que los participantes revelan sus estimaciones a la vez y debaten las diferencias antes de estimar de nuevo.

Implementación mínima que conecta las principales partes de una arquitectura mediante un flujo pequeño de extremo a extremo.

Práctica colaborativa que reúne perspectivas de negocio, desarrollo y pruebas para aclarar el comportamiento esperado.

Sigla de «application programming interface»: conjunto documentado de reglas que permite a un programa solicitar datos o acciones a otro de forma definida.

URL concreta de una API que recibe solicitudes para una acción, como GET /users para listar usuarios o POST /orders para crear un pedido.

Estilo habitual de API web en el que los recursos tienen URL y se gestionan con métodos HTTP como GET, POST, PUT y DELETE.

Formato de texto sencillo para datos, compuesto por pares clave-valor y listas, utilizado por la mayoría de las API web.

Número de tres cifras en una respuesta HTTP que indica qué ocurrió, por ejemplo éxito, recurso no encontrado o error del servidor.

Datos que transporta una solicitud, respuesta o mensaje, aparte de las cabeceras y la información que los envuelve.

Proceso de comprobar quién es un usuario o sistema, por ejemplo mediante contraseña, token o huella, antes de conceder acceso.

Creado o proporcionado por una empresa o desarrollador externo al equipo, como un servicio de pagos, una biblioteca o una herramienta de análisis.

Paquete de bibliotecas, herramientas y documentación que ayuda a crear aplicaciones para una plataforma o a utilizar un servicio.

Cambio en una API, biblioteca o formato de archivo que hace que el código existente deje de funcionar si no se actualiza también.

Mensaje que un cliente envía a un servidor o una API para pedir una acción, como devolver datos o guardar un registro nuevo.

Mensaje que un servidor o una API devuelve tras recibir una solicitud; suele incluir un código de estado, encabezados y datos, por ejemplo en JSON.

Código secreto único que un programa envía con sus solicitudes para que la API identifique quién la llama y determine qué permisos tiene.

Cadena de caracteres que demuestra que una persona o aplicación ya inició sesión o tiene permiso; se envía con cada solicitud en lugar de la contraseña.

Proceso que determina qué acciones puede realizar una persona o aplicación identificada, por ejemplo leer un archivo o eliminar una cuenta.

Mecanismo por el que un sistema envía automáticamente una solicitud HTTP a la URL de otro cuando ocurre un evento, como un pago exitoso.

Máximo de solicitudes que un cliente puede enviar a una API durante un periodo, para protegerla de sobrecarga o abuso.

Que sigue funcionando con versiones, datos o clientes antiguos después de un cambio, sin obligar a actualizar código o configuración.

Protocolo de transferencia de hipertexto: conjunto de reglas que usan navegadores y servidores para intercambiar solicitudes y respuestas en la web.

Versión segura de HTTP que cifra con TLS la conexión entre el navegador y el servidor para impedir que otras personas lean o modifiquen los datos.