Convierte el alcance en hitos

1785. Identidad de la lección

Módulo

4.11 — Producción

Lección

Convierte el alcance en hitos

Tipo académico

Sistemas

Tipo de esquema

texto

Orden

1 del módulo

Tiempo estimado

40–55 minutos, incluida la práctica

1786. Objetivo de aprendizaje

Después de esta lección, podrás convertir una funcionalidad o un segmento jugable acotado en un plan de hitos que identifique dependencias reales, puntos de integración, decisiones de revisión, criterios observables de finalización y, según corresponda, medidas de reversión o contención cuando el hito modifique un estado existente, o una condición documentada para detener o revisar el trabajo cuando no lo modifique.

1787. Por qué importa

Una decisión de producto aprobada todavía no es un plan de producción ejecutable. Un plan de hitos vuelve el trabajo inspeccionable: permite ver qué debe ocurrir primero, dónde hay que tomar una decisión, cómo se conectará el trabajo con el juego existente y qué evidencia cuenta como finalización.

Los cambios en un recorrido ejecutable, una integración, los datos, la configuración o el estado de una versión necesitan una medida segura de reversión o contención. En cambio, un hito de aprobación o descubrimiento puede no modificar ningún estado funcional; en ese caso, la respuesta segura suele ser detener, revisar o bloquear el trabajo posterior. Esta distinción evita inventar reversiones artificiales sin perder claridad en las decisiones de producción.

La misma estructura ofrece a la IA un problema de planificación delimitado, en vez de invitarla a generar una lista de tareas sin prioridad.

1788. Conocimientos previos

Ya deberías poder distinguir una decisión de producto de un detalle de implementación y registrar el razonamiento, los límites y las condiciones de revisión de una concesión, como practicaste en 4.10 L2 — Registra la concesión. También deberías poder describir un segmento jugable acotado según el resultado que debe experimentar el jugador e identificar sus restricciones relevantes. No necesitas un backlog completo ni una implementación terminada.

1789. Concepto central

Un hito es un estado de producción que puede revisarse, no solamente una fecha ni una tarea grande. Describe un resultado significativo, las condiciones necesarias para alcanzarlo, un punto en el que alguien lo inspecciona, las decisiones posibles y la evidencia que respalda esas decisiones.

Construye cada plan de hitos a partir de seis capas:

1. Alcance: ¿Qué resultado para el jugador está incluido y qué queda explícitamente fuera?
2. Dependencias: ¿Qué debe cumplirse antes de que el trabajo posterior pueda completarse, probarse o evaluarse correctamente?
3. Integración: ¿Dónde y cómo se conectará el resultado con un recorrido, sistema, límite de contenido, conjunto de datos, configuración o estado de versión existente?
4. Revisión: ¿Dónde se inspeccionará el resultado y se decidirá si se acepta, modifica, reduce, bloquea o detiene?
5. Respuesta ante fallos: Si el hito modifica un estado ejecutable u operativo existente, ¿qué medida de reversión o contención corresponde, qué condición la activa y qué estado se restaura o aísla? Si se trata de un hito de aprobación o descubrimiento que no modifica ese tipo de estado, ¿qué condición detiene, obliga a revisar o bloquea el trabajo posterior?
6. Evidencia: ¿Qué comportamiento o artefacto observable demuestra la finalización?

Planificar la integración no exige redactar todo el diseño de implementación. Consiste en identificar la conexión que debe comprobarse y, cuando esa conexión modifica un estado existente, la forma segura más pequeña de revertir o aislar el cambio. Un plan de reversión o contención nombra una condición que activa la respuesta, una acción y el estado que se restaurará o aislará. Una condición para detener o revisar el trabajo identifica la evidencia que impide aprobarlo o continuar y la siguiente decisión necesaria.

«Crear el combate, añadir la interfaz y pulir el audio» es una lista de actividades, no un plan de hitos. Reformúlala como un estado revisable, por ejemplo: «el jugador puede completar un encuentro definido, ver el resultado y volver a intentarlo después de fallar». Después indica dónde se conecta con el recorrido existente, cómo se comprobará esa conexión y qué respuesta corresponde si el hito falla.

1790. Modelo mental

Usa Alcance → Dependencia → Integración → Revisión → Respuesta ante fallos → Evidencia.

Una dependencia estricta bloquea la ejecución o evaluación válida. Una preferencia solo indica un orden conveniente. No etiquetes como dependencia toda tarea relacionada.

Un punto de integración no es automáticamente una dependencia. Se convierte en una dependencia estricta cuando el hito no puede probarse o evaluarse correctamente sin esa conexión. Registra la comprobación de integración por separado para no confundir «está conectado» con «está terminado».

Un hito debe ser lo bastante pequeño para revisarlo y lo bastante grande para demostrar un estado de producción significativo. Si no puede demostrarse, probablemente sea una tarea. Si contiene resultados para el jugador que no guardan relación, divídelo. Si modifica un estado existente pero no puedes nombrar una medida creíble de reversión o contención, reduce o aísla el hito antes de ejecutarlo. Si no modifica ningún estado existente, no inventes una reversión: define una condición para detener, revisar o bloquear el trabajo.

1791. Ejemplo concreto

Alcance delimitado: «Crear una secuencia jugable de punto de control en la que el jugador entre en un espacio, use una interacción aprobada, reciba un resultado claro y pueda volver a intentarlo después de fallar».

El primer hito no modifica un recorrido ejecutable; por eso, ante un fallo se detiene y revisa el trabajo en vez de fingir que hay un estado previo del juego que restaurar. Los hitos posteriores sí modifican el comportamiento jugable y, por tanto, necesitan una medida de reversión o contención.

«Pulir» no es un hito útil por sí solo. Un trabajo de pulido concreto solo debe incluirse cuando tenga un motivo, un alcance delimitado, una decisión de revisión, evidencia y una respuesta ante fallos que corresponda al cambio.

1792. Flujo de trabajo con IA

Usa la IA como crítica del plan, no como autoridad que define el alcance o la finalización.

1. Escribe tú el límite del alcance, las exclusiones, las restricciones y el registro de la decisión de producto.
2. Pide a la IA que proponga dependencias que puedan faltar, comprobaciones de integración, decisiones de revisión, condiciones de fallo y criterios verificables, sin añadir funcionalidades, plataformas, contenidos ni pulido no solicitado.
3. Clasifica cada hito: ¿modifica un recorrido ejecutable, una integración, los datos, la configuración o el estado de una versión? Si la respuesta es sí, exige una medida de reversión o contención. Si es no, exige una condición para detener, revisar o bloquear el trabajo.
4. Rechaza las preferencias presentadas como dependencias estrictas, las reversiones inventadas y las respuestas que no restauren, aíslen o protejan un estado conocido.
5. Pide a la IA que cuestione el plan con trabajo oculto entre sistemas, supuestos de integración, cambios irreversibles e hitos demasiado grandes para revisar.
6. Redacta tú la tabla final y registra qué sugerencias aceptaste, modificaste o rechazaste.

Ejemplo de prompt:

Dado este alcance delimitado de producción, sus exclusiones, restricciones y la concesión de producto registrada, propón hitos revisables. Para cada uno, indica los prerrequisitos reales, el límite y la comprobación de integración, la decisión de revisión y la evidencia observable de finalización. Si el hito modifica un recorrido ejecutable, una integración, los datos, la configuración o el estado de una versión, propón una condición que active una medida de reversión o contención y la acción correspondiente. En caso contrario, propón una condición para detener, revisar o bloquear el trabajo. No amplíes el alcance y separa las suposiciones de los hechos.

La responsabilidad de verificar el plan sigue siendo del desarrollador. La IA no puede inspeccionar un resultado para el jugador ni demostrar que un estado restaurado o aislado sea seguro.

1793. Errores comunes

• Convertir departamentos o actividades —programación, arte, audio, pruebas o pulido— en hitos en vez de resultados revisables.
• Tratar cualquier orden conveniente como una dependencia estricta.
• Considerar la integración una entrega final en vez de una conexión que debe comprobarse durante la producción.
• Exigir una reversión ficticia para un hito de aprobación o descubrimiento que no modificó ningún estado funcional.
• Escribir «revertir si falla» sin nombrar la condición que activa la reversión, la acción y el estado que se restaurará o aislará.
• Usar criterios subjetivos como «funciona», «se siente bien» o «está pulido» en vez de evidencia observable.

1794. Práctica guiada

Crea un plan de hitos para un alcance delimitado de tu proyecto o utiliza la secuencia del punto de control del ejemplo.

1. Escribe una frase que describa el resultado para el jugador.
2. Enumera tres exclusiones explícitas.
3. Identifica al menos cuatro resultados o condiciones necesarios.
4. Representa las dependencias estrictas y el orden preferente mediante un diagrama etiquetado o una lista textual. Por ejemplo: «El hito C depende de A y B; B debe completarse antes que C, mientras que hacer A antes que B es solo una preferencia». No dependas únicamente del color ni de la posición espacial.
5. Agrupa el trabajo en tres o cuatro hitos revisables.
6. Para cada hito, identifica el recorrido, sistema, límite de contenido, conjunto de datos, configuración o estado de versión implicado y define una comprobación de integración.
7. Añade a cada hito un punto de revisión y una posible decisión: aceptar, modificar, reducir, bloquear o detener.
8. Clasifica la respuesta ante fallos de cada hito. Cuando modifique un estado existente, define la condición que activa la reversión o contención, la acción y el estado restaurado o aislado. En los demás casos, documenta la condición que detiene, obliga a revisar o bloquea el trabajo posterior.
9. Escribe al menos dos criterios observables de finalización para cada hito.
10. Simula un fallo que afecte a un estado modificado y muestra la respuesta de reversión o contención. Si el plan no contiene ningún hito de ese tipo, simula una condición fallida de aprobación o descubrimiento y muestra cómo se detiene o revisa el trabajo.
11. Pide a la IA que cuestione el plan y registra una sugerencia aceptada y otra rechazada, con sus razones.

Toma una decisión deliberada sobre el alcance: aplaza un elemento atractivo que no sea necesario para el resultado delimitado y explica por qué.

1795. Validación y evidencia

1796. Ideas clave

• Un hito es un estado de producción revisable, no una fecha ni una tarea de departamento.
• Las dependencias estrictas son condiciones que realmente bloquean el trabajo; las preferencias no lo son.
• Planificar la integración consiste en identificar un límite existente y una conexión que pueda comprobarse.
• La reversión o contención es necesaria cuando un hito modifica un estado ejecutable u operativo existente.
• Los hitos de aprobación o descubrimiento necesitan condiciones explícitas para detener, revisar o bloquear el trabajo cuando no se ha modificado ningún estado.
• Cada hito necesita una decisión de revisión y evidencia observable de finalización.
• La IA puede cuestionar el plan, pero el desarrollador es responsable de las decisiones finales.

1797. Próxima lección

Continúa con 4.11 L2 — Gestiona el riesgo antes de que el calendario se vuelva ficción, donde utilizarás este plan de hitos para identificar riesgos de producción y asignar fechas de mitigación o decisión.

1798. Comprobación