Entrenamiento DTS

Workflow de Equipo

Jira, evidencia, documentación y reglas Unreal para trabajar con un mismo criterio.

Simón Bahamonde

Workflow del equipo

Páginas principales del workflow

Páginas creadas dentro del Workflow Entrenamiento DTS
Formalización Jira

Descripción de Jira como source of truth

La documentación ayuda a entender el sistema, pero el entregable, checklist y criterios que mandan son los que vienen en la tarea asignada.

Para el equipo

Si algo no está claro en la tarea, se pregunta antes de avanzar con una interpretación propia.

DTS-1149

[Programación] Implementar integración tablet

Story bajo una épica del proyecto. La descripción contiene contexto, alcance, entregable mínimo y checklist.

En curso → Review → Done
Qué se formaliza

Jira deja de ser solo seguimiento

Nombres

Épicas, Stories y Bugs deben poder leerse sin abrir la tarea.

Descripción

La tarea debe explicar contexto, alcance, entregable y criterios mínimos.

Evidencia

Review exige algo revisable: PR, archivo, documento, video o build según corresponda.

Referencia

Notion muestra ejemplos y criterios generales. Jira manda en la tarea concreta.

Formato de nombres

Cómo nombramos el trabajo en Jira

Épica [{Proyecto}] [{Área}] Scope

Scope puede ser MVP 1, Feria FIDAE, una entrega interna o un hito claro.

Story / Bug [{Área}] Título

El área visible ayuda a leer el backlog sin abrir cada tarea.

Ejemplos de nombres

El nombre debe decir dónde vive la tarea

Tipo
Formato
Ejemplo
Épica
[{Proyecto}] [{Área}] Scope [STT] [Programación] MVP 1
Épica
[{Proyecto}] [{Área}] Scope [MR Studio] [Bug] Feria FIDAE
Story
[{Área}] Título [Programación] Implementar integración tablet
Bug
[{Área}] Título [Bug] UI activa a través de objetos
Tipos de issue

Story, Bug y Subtask no cumplen la misma función

Story

Trabajo planificado con alcance, entregable y criterios de aceptación.

Bug

Algo esperado no funciona. Debe mostrar problema, reproducción y resultado esperado.

Subtask

Paso recomendado para resolver una tarea mayor. No duplica la descripción de la Story padre.

Formato Story

La Story define trabajo planificado

Cuándo se usa

Cuando hay una pieza de trabajo con intención clara: implementar, integrar, crear, ajustar o documentar algo definido.

## Historia de usuario
## Contexto
## Alcance
## Entregable mínimo
## Checklist mínimo
## Criterios de aceptación
Lo mínimo

Debe quedar claro qué se espera, qué queda fuera y cómo se revisa.

Ejemplo Story

Ejemplo de Story: DTS-1149

DTS-1149

[Programación] Implementar integración tablet

Ejemplo real de Story usando el formato definido.

## Contexto
La tablet necesita integrarse al flujo del nivel para operar la interacción definida.

## Alcance
Implementar la integración de la tablet con el sistema correspondiente.

## Entregable mínimo
PR con la integración funcionando y evidencia de uso.

## Checklist mínimo
[ ] PR creado y linkeado.
[ ] Caso de uso validado en el proyecto en el nivel correspondiente.
[ ] Evidencia visible para Review.

## Criterios de aceptación
La tablet puede usarse en el flujo esperado sin pasos manuales extra.
Formato Bug

El Bug debe permitir reproducir y validar

Cuándo se usa

Cuando algo esperado no funciona. Debe explicar qué falla, cómo verlo y qué resultado se espera después del fix.

## Problema
## Contexto
## Pasos para reproducir
## Resultado esperado
## Resultado actual
## Entregable mínimo
## Checklist mínimo
## Criterios de aceptación
Importante

Si la solución requiere ajustar valores, la entrega debe permitir testearlos en build o flujo jugable.

Ejemplo Bug

Ejemplo de Bug: DTS-1099

DTS-1099

[Bug] UI activa a través de objetos

Ejemplo real de Bug usando el formato definido.

## Problema
La UI puede activarse a través de objetos del escenario.

## Pasos para reproducir
1. Ubicarse frente al objeto que bloquea la interacción.
2. Intentar activar la UI desde detrás o a través del objeto.

## Resultado esperado
La UI solo se activa cuando la interacción corresponde.

## Resultado actual
La UI se activa aunque haya un objeto bloqueando.

## Entregable mínimo
PR con fix y build/evidencia para validar el caso.
Subtasks

Las subtasks son pasos, no mini documentos

Para qué sirven

Ordenan una Story grande en pasos recomendados: brief, arquitectura propuesta, implementación, integración o revisión.

Qué no llevan

No duplican descripción, entregable mínimo ni checklist. Esa información vive en la Story padre.

Ejemplo real de subtasks

Una tarea 3D se divide en pasos concretos

DTS-1133

[3D] Agregar tele abatible mesón - Mapa de Entrenamiento

Ejemplo real de Story padre con subtasks creadas como pasos de trabajo.

DTS-1171Definir escala y restricciones
DTS-1172Modelar base del asset
DTS-1173Texturizar
DTS-1174Revisar en contexto

La Story padre mantiene el contexto, entregable mínimo y checklist. Las subtasks solo ordenan el trabajo.

Áreas y labels

El campo {Área} se convierte en filtro

Áreas y Labels Jira
Áreas y Labels Jira
Área
Uso
Programación
Implementación, gameplay, interacción, lógica.
Bug
Problemas reproducibles que deben validarse.
Housekeeping
Orden, limpieza o correcciones de cosas subidas mal.
Selección Recurso
Búsqueda y selección de assets o referencias.
Feeling
Ajustes de sensación, ritmo o experiencia de juego.

Relación con nombres Jira

El {Área} que aparece en el nombre de la épica, Story o Bug debe coincidir con el área/label usado para ordenar y filtrar el trabajo.

[{Proyecto}] [{Área}] Scope
[{Área}] Título
Cómo usar áreas

Área visible en el nombre, label para filtrar

Programación

Implementación de sistemas, interacción, gameplay, lógica o integración técnica.

Bug

Problemas que deben entrar como Bug/Error y tener reproducción.

Housekeeping

Arreglos de cosas subidas mal, orden, limpieza o correcciones de mantenimiento.

Selección Recurso

Búsqueda o selección de recursos antes de integrarlos al proyecto.

Review y Done

Review no es “terminé”; es “puede revisarse”

1Trabajo

El equipo resuelve la tarea.

2Evidencia

El equipo deja PR, archivo, video, build o documento según la tarea.

3Review

El Producer valida contra lo pedido en Jira.

4Done

El Producer pasa a Done o devuelve a En curso si falta algo.

Equipo: llega hasta dejar la tarea en Review Producer: revisa y decide Done / En curso
Qué pasa en Review

Review es revisión, no aprobación automática

1

Desde Review toma Producer / Lead

El ejecutor deja evidencia y mueve la tarea a Review. Desde ahí se valida contra lo pedido en Jira.

2

Primero se revisa si cumple el mínimo

Si falta PR, archivo, build, documento o evidencia pedida, vuelve a En curso con comentario.

3

Después se evalúa el resultado

Si el contenido está aceptado, pasa a Done. Si cumple el formato pero el trabajo no sirve, también vuelve a En curso.

Cumplir el checklist permite revisar; no garantiza que la tarea quede aceptada.

Evidencia

Review necesita una referencia concreta

PRProgramación, integración, arte integrado, fixes técnicos.
BuildCuando hay que probar un flujo o validar parámetros.
VideoExportado o YouTube no listado cuando el entregable principal es audiovisual.
DocumentoBrief, arquitectura propuesta, investigación o documentación.
ArchivoZip, asset o fuente cuando corresponde al tipo de entrega.
SnapshotObligatorio cuando la tarea incluye Blueprints.
Plantillas y entregables

Los requisitos mínimos vienen en la tarea

Para quien ejecuta

Leer la descripción completa. El entregable mínimo y checklist son la guía directa para saber qué subir a Review.

Para Leads / Producer

La página de plantillas sirve como referencia para revisar ejemplos, documentos esperados y tipos de tarea.

Arquitectura: Brief + Propuesta Integración: PR Build / Release: build usable
Cómo leer una tarea

Antes de trabajar, revisar cuatro partes

01

Contexto

Por qué existe la tarea y dónde se usa.

02

Alcance

Qué entra y qué no entra en este trabajo.

03

Entregable mínimo

Qué debe quedar linkeado o adjunto al pasar a Review.

04

Criterios

Cómo se valida que el trabajo está terminado.

La página de plantillas ayuda a entender ejemplos. La tarea asignada define qué se entrega en ese caso específico.

Tipos de tarea

Tareas que se entregan con PR

Feature de Programación

Entregable mínimo: PR/MR al proyecto o plugin correspondiente.

[ ] PR/MR creado. [ ] Rama correcta. [ ] Estructura de carpetas respetada. [ ] Nomenclatura de archivos/assets respetada. [ ] Variables, funciones y eventos nombrados correctamente. [ ] Si toca Blueprints, Snapshot Unreal exportado y linkeado.

Integración

Entregable mínimo: PR/MR de integración al proyecto o plugin correspondiente, con integración disponible y evidencia suficiente para revisar.

[ ] PR/MR de integración creado. [ ] Assets ubicados en carpetas correctas. [ ] Referencias funcionando. [ ] Evidencia disponible. [ ] Si toca Blueprints, Snapshot Unreal exportado y linkeado.

Arte Integrado

Entregable mínimo: PR/MR con los assets integrados en el proyecto o Gym de Arte cuando aplique.

[ ] PR/MR creado. [ ] Assets en carpetas correctas. [ ] Nomenclatura aplicada cuando corresponda. [ ] Sin archivos temporales o innecesarios.
Tipos de tarea

Ejemplos de documentación pesada

No son los únicos documentos posibles. La guía incluye otros formatos como decisión de diseño, playtest, reunión documentada, capacitación y QA; acá vemos dos casos donde la estructura pesa más.

Arquitectura

Entregable mínimo: Brief de Arquitectura y Propuesta de Arquitectura Final aceptados.

[ ] Brief de Arquitectura revisado antes de trabajar la propuesta final. [ ] Propuesta de Arquitectura Final incluye diagramas/UMLs según corresponda. [ ] Componentes, clases y responsabilidades quedan claros. [ ] Riesgos y mitigaciones relevantes quedan documentados.

Investigación

Entregable mínimo: documento de investigación con conclusión clara y próximos pasos recomendados.

[ ] Pregunta inicial o problema investigado queda explícito. [ ] Opciones, hallazgos o referencias relevantes quedan documentadas. [ ] La conclusión permite tomar una decisión o definir el siguiente paso. [ ] Riesgos, dudas o pendientes importantes quedan visibles.
Tipos de tarea

Selección de recursos y video

Selección Recurso

Entregable mínimo: documento con opción recomendada, alternativas revisadas y criterio de selección.

[ ] Necesidad del recurso queda explicada. [ ] Opciones comparadas quedan linkeadas o identificadas. [ ] La opción recomendada queda justificada. [ ] Costos, licencias o restricciones relevantes quedan mencionadas cuando aplique.

Edición Audiovisual

Entregable mínimo: video exportado o YouTube no listado.

[ ] Video disponible y accesible para revisión.
Tipos de tarea

Builds y arte empaquetado

Arte Empaquetado

Entregable mínimo: zip o paquete disponible para integración manual.

[ ] Zip o paquete disponible. [ ] Estructura acordada. [ ] Sin archivos temporales o innecesarios. [ ] Si el zip contiene proyecto Unreal, no incluir Binaries, Saved, Intermediate, DerivedDataCache ni carpetas generadas/locales equivalentes.

Build / Release

Entregable mínimo: build generada y accesible para revisión.

[ ] Build disponible en una ubicación accesible. [ ] Versión, rama o commit de origen indicado. [ ] Plataforma objetivo indicada. [ ] Instrucciones mínimas para ejecutar o probar incluidas. [ ] Se indica si la build es para QA, revisión interna, demo o entrega.
Gitea

El flujo Git se mantiene

No se generaron cambios al flujo Gitea de proyectos.

El ajuste concreto es para plugins precompilados: compilar con el .bat creado y subido en el proyecto base de plugins dentro de Tools/.

Unreal

Reglas obligatorias en Unreal

Si no se respeta la nomenclatura o el scaffolding definido, el trabajo puede volver a En curso.

Meta

No es que a todos les guste el mismo formato. La meta es tener consenso para trabajar, revisar y mantener proyectos sin formatos paralelos.

Regla

No crear estructuras propias si ya existe un criterio del equipo. Si el caso no calza, se conversa.

Unreal

Qué vuelve a En curso

Estos casos se devuelven cuando impiden revisar, mantener o integrar el trabajo bajo el estándar del equipo.

Carpetas propias

Crear estructuras paralelas al scaffolding acordado.

Nombres fuera de regla

Assets sin prefijo, nombres ambiguos o abreviaciones no definidas.

Assets mezclados

Props, materiales y texturas sin relación clara cuando ya corresponde separar por entidad.

Blueprint sin evidencia

Tareas con Blueprints sin snapshot o evidencia revisable.

Crecimiento de carpetas

Profundizar cuando resuelve un problema real

Proyecto chico

Game/
  Core/
  Art/
  Maps/
  UI/

Crece mal

Game/Art/
  Mesh_Chair
  T_Chair
  MI_Chair
  SM_Table
  T_Table_BaseColor
  MI_Table
  SM_Locker
  T_Locker_N
  MI_Locker
  SM_Extinguisher
  T_Extinguisher_ORM
  MI_Extinguisher
  SM_Keyboard
  T_Keyboard
  MI_Keyboard
  SM_Monitor
  T_Monitor_AO
  BP_DoorButton
  NS_Dust
  WBP_DebugPanel
  ...

Crece bien

Game/Art/Props/
  Chair/
    Meshes/
    Textures/
    Materials/
  Table/
    Meshes/
    Textures/
    Materials/

No se profundiza por verse ordenado. Se profundiza cuando mejora lectura, revisión, ownership o mantenimiento.

Si una regla no calza con un caso real, se conversa y se ajusta como equipo.

No se inventa un formato paralelo.
Referencias

Links para revisar después

Workflow Entrenamiento DTS Workflow Jira Entrenamiento Áreas y Labels Jira Plantillas de Tareas Nomenclatura Unreal Estructura de Carpetas Unreal
1 / 13