Entrega por hitos
El workflow describe un proyecto que se define una vez y se construye hasta entregarlo. Muchos proyectos no se contratan así: se parten en bloques que se venden, se construyen y se cobran por separado —lo que el cliente llama “la fase 2”—.
Un hito es un corte del alcance, no del proceso. Las siete fases se corren igual; lo que hay que resolver es qué se hace una sola vez para todo el proyecto, qué se repite en cada hito y qué queda cerrado cuando uno se entrega. Este documento aplica solo cuando el proyecto tiene más de un hito: con uno solo, el workflow ya lo describe entero.
La regla corta: el alcance se parte en hitos; el proceso no. La fundación, el entendimiento y el backlog son del proyecto completo; la definición detallada y la construcción son del hito en curso.
Hito, fase y etapa
Tres palabras que la conversación mezcla y que en Argui nombran cosas distintas:
| Término | Qué nombra | Cuántos hay |
|---|---|---|
| Fase | Un tramo del proceso: fases 0 a 6, con sus pasos F{fase}.{paso} |
Siempre 7 |
| Etapa | Un paso del ciclo de OpenSpec dentro de un change: proposal → specs → design → apply → verify → qa | Siempre las mismas |
| Hito | Un bloque de alcance que se define, se construye, se entrega y —casi siempre— se cobra aparte | Los que el proyecto tenga |
Cuando el cliente dice “fase 2”, habla de un hito. Vale la pena corregir el término en la primera reunión: si las dos numeraciones conviven, nadie sabe si “vamos en la fase 3” significa que se está validando el prototipo o que se arrancó el tercer bloque contratado.
Numeración. Los hitos se identifican H-1, H-2, … y el identificador es estable: un hito
que se reprioriza conserva el suyo. Como los RF-*, viaja con el contenido —no con el orden—.
Qué se corre una vez y qué se repite
| Fase | Alcance | Cómo |
|---|---|---|
| 0 · Fundación | Una vez | Un repositorio, un CLAUDE.md vivo, un fork de OpenSpec para todo el proyecto. El hito 2 no arranca un proyecto nuevo. |
| 1 · Entendimiento ✋ | Una vez, sobre el alcance total | El problema se entiende completo de entrada. El punto 3 de la plantilla —alcance y no-alcance— es donde nace el mapa de hitos. Entender solo el hito en curso produce arquitectura que el siguiente tiene que romper. |
| 2 · PRD inicial ✋ | Una vez, con profundidad desigual | Un solo PRD (Product Requirements Document) para el proyecto: los requisitos del hito en curso completos, los de los siguientes como contorno. |
| 3 · Prototipo ✋ | Por hito | Se maqueta y se valida lo que se va a construir. De los hitos siguientes, solo lo que haga falta para vender o para no cerrarse puertas. La dirección de diseño nace en el primero y sirve para todos. |
| 4 · Preparación | La maquinaria una vez; el backlog crece | Arquitecto, estándares, agentes y ciclo personalizado se montan una sola vez. El backlog es una sola cola: el corte entre hitos es prioridad y dependencia, no un archivo aparte. |
| 5 · Iteración ✋ | Por hito | El ciclo no cambia. Los ítems del hito en curso son los que están arriba en la cola. |
| 6 · Evolución | La puerta de los hitos siguientes | Cuando un hito se entrega y hay corte real, el producto entra en evolución continua y el hito siguiente re-entra por el triaje. |
El principio que ordena la tabla es la profundidad desigual: todo el alcance se conoce, no todo se define al mismo nivel. Definir el hito 3 al detalle antes de construir el 1 es trabajo que se va a tirar —y compromiso que se va a incumplir—.
El mapa de hitos
El artefacto es una tabla, no un documento nuevo. Nace en el Documento de Entendimiento
(F1.2), dentro de alcance y no-alcance, y con el prototipo aprobado pasa al PRD de negocio
(F3.4), que es el contrato con el cliente:
| Hito | Promesa | Incluye | Deja fuera | Habilita |
|---|---|---|---|---|
H-1 |
Lo que el usuario puede hacer al terminarlo | RF-1, RF-4, RF-7 |
Lo que se pospone, con su hito destino | Qué desbloquea para el siguiente |
H-2 |
… | RF-2, RF-9 |
… | … |
Tres reglas lo mantienen honesto:
- Cada requisito declara su hito.
RF-4 · H-1. Es el mismo mecanismo de trazabilidad por ID estable de la fase 3: el requisito se mueve de hito sin perder su insignia en el prototipo ni su referencia en las specs. - Cada ítem del backlog declara su hito, junto a su
Origen. Una sola cola, ordenada; el hito es un atributo del ítem, no un backlog aparte. - Tres niveles de definición conviven: el hito en curso, definido y validado; el siguiente, con su promesa y sus requisitos enunciados; los demás, nombrados. Lo que está en el nivel equivocado se nota rápido —un hito lejano con specs, o el hito en curso con una sola línea—.
Encadenados o con corte
Lo decide una pregunta: ¿el hito termina en manos de sus usuarios antes de que empiece el siguiente?
Encadenados. El equipo pasa del último ítem de un hito al primero del siguiente sin soltar el producto. El hito es un corte de alcance y de facturación, no un evento del proceso: se marca un release trazable, se revisa el mapa de hitos y el ciclo de la fase 5 continúa con los ítems que ya están en la cola. No hay re-entrada ni carril que elegir.
Con corte real. El hito se entrega, se acepta y casi siempre pasan semanas o meses. El backlog del hito se agota, el producto entra en evolución continua y el hito siguiente llega como trabajo nuevo por la recepción y el triaje. Basta una de estas señales para que el corte sea real:
- Despliegue a producción con usuarios de verdad.
- Aceptación formal, cobro o cierre de contrato.
- Pausa de más de unas semanas, o cambio del equipo que construye.
- El hito siguiente depende de lo que el actual aprenda en producción.
La última señal es la que más cambia el resultado: cuando existe, cerrar el alcance del hito siguiente por adelantado apaga justo el lazo runtime → planificación que lo haría valer.
El cierre de un hito ✋
Un hito con corte real no cierra cuando el último ítem se archiva, sino cuando queda esto:
- La deuda aplazada, capturada. Todo lo que se pospuso “para el hito siguiente” ya está como
candidato en el backlog con su
Origen, escrito en el momento en que se aplazó (fuente 3 de la fase 6). Si no, el hito siguiente arranca haciendo arqueología de conversaciones. - El release, trazable. Tag y entrada en el CHANGELOG del proyecto, con la versión y el git SHA (el hash del commit) que el monitoreo etiqueta (Estándares §7).
- El PRD de negocio, al día. El hito entregado queda marcado como tal y su alcance real —no el prometido— es el que queda escrito.
- El design system, canónico. Se consolidó en el primer hito y los siguientes lo consumen; no se reabre la dirección de diseño salvo decisión explícita registrada.
- El prototipo, apagado. Si se publicó para que el stakeholder lo abriera, se baja al cerrar (Prototipo). El del hito siguiente es un artefacto nuevo sobre el mismo andamiaje.
- Las métricas del hito, cerradas. Las de entrega (Métricas) se cortan por hito: son el dato con el que se estima y se cotiza el siguiente.
- Una auditoría corrida (Operaciones) antes de abrir el hito siguiente. El drift entre specs y código que dejó un hito se hereda al que viene si nadie lo mira.
El hito siguiente no se abre con el anterior sin cerrar. Es el mismo principio del gate de la fase 5 —nada arranca con sus dependencias abiertas— aplicado al tamaño del hito.
La apertura del hito siguiente
Entra por el triaje de la fase 6, y el carril lo decide su tamaño:
| Qué es el hito nuevo | Por dónde entra |
|---|---|
| Continuación acotada del mismo producto | Loop de validación liviano: actualizar el PRD → maquetar el slice con el design system canónico → validar ✋ → derivar ítems → ciclo de la fase 5 |
| Área de producto nueva —otro tipo de usuario, otro dominio, otra superficie— | Re-correr las fases 1–4 para esa rebanada: entendimiento, PRD y prototipo de lo nuevo sobre la fundación que ya existe. No se repiten la fase 0 ni la maquinaria de la 4 |
Dos entradas particulares:
- El hito se vendió con el prototipo y la venta se cerró meses después. El punto de re-entrada
es
F3.5—refinamiento del prototipo—, que existe para eso: convierte el prototipo que sirvió para vender en la especificación visual del hito que se va a construir. - El hito anterior lo construyó otro equipo, sin Argui. No es fase 6 todavía: es un onboarding brownfield —arqueología y specs recuperadas de las zonas que el hito nuevo va a tocar— y desde ahí, la fase 6 normal.
Lo que rompe la forma
- Un backlog por hito. Dos colas dejan de ver las dependencias entre ellas, y el diagrama de progreso deja de ser el mapa del proyecto.
- Un repositorio o un CLAUDE.md por hito. Parte el historial, duplica los estándares y obliga a mantener dos veces lo que era una sola fuente de verdad.
- Repetir las fases 0 y 4 en cada hito. La maquinaria ya está montada; lo único que se actualiza es lo que la puesta al día de versión indique.
- Entender solo el hito que se está vendiendo. El no-alcance del hito 1 tiene que saber que el hito 2 existe; si no, la decisión barata de hoy es la reescritura de mañana.
- Prometer el detalle de los hitos lejanos. Lo que se compromete es su promesa y su frontera, no su especificación.