Generación de WBS de Implementación
Propósito
WBS es QUÉ se debe implementar, no una estimación de esfuerzo.
No saltes de la prosa de TDD directamente a tareas genéricas.
Las entradas deben incluir diseños detallados VERIFICADOS.
Requisito
→ Brecha
→ TDD
→ Artefacto de Diseño
→ Diseño Detallado VERIFICADO
→ Tarea WBS
→ Verificación
Entradas
- requisito autoritativo
- análisis de brecha verificado
- TDD verificado
- registro de artefactos de diseño
- todos los diseños detallados
DD_VERIFIED - informes de verificación de diseño detallado
- diseño de pruebas si está disponible
- repositorio actual
1. Derivación de Tareas
Deriva las tareas únicamente a partir de decisiones de diseño verificadas.
Categorías de tareas:
- código de producción
- API/contrato
- integración
- datos/persistencia
- configuración
- migración/compatibilidad
- pruebas
- compilación/despliegue
- documentación
- limpieza solo si lo requiere el diseño aprobado
No agregues refactorizaciones "agradables de tener".
2. Granularidad de las Tareas
Una tarea debe ser lo suficientemente pequeña para tener:
- un resultado claro
- anclajes concretos de fuente/diseño
- dependencias explícitas
- criterios de finalización verificables
Pero no dividas ediciones mecánicas en docenas de microtareas sin sentido.
3. IDs Estables
Usa:
WBS-001, WBS-002, ...
3A. Identidad Semántica WBS ↔ Diseño
La trazabilidad no se satisface simplemente porque una fila de WBS contenga un ID de Artefacto existente.
Para cada tarea de WBS, identifica su entregable de implementación principal y demuestra que el/los artefacto(s) de diseño referenciado(s) son dueños de ese entregable.
Cadena semántica requerida:
título / objetivo / entregable principal de la tarea WBS
↔ nombre del artefacto en el registro + responsabilidad
↔ unidad(es) de implementación propiedad de la DD VERIFICADA
↔ decisión de diseño del TDD
Reglas:
- Una referencia de ID de Artefacto es necesaria pero no suficiente.
- Que un tipo/clase/interfaz sea meramente mencionado, importado, referenciado o enlazado desde una DD no prueba que el artefacto sea dueño de esa unidad de implementación.
- Si el entregable principal de una tarea WBS es un tipo subordinado, debe cumplirse una de estas:
- el registro/DD declara explícitamente ese tipo subordinado dentro del ámbito del artefacto propietario, o
- la descomposición del artefacto de diseño debe revisarse para rastrearlo por separado.
- No mapees una tarea titulada para el componente/tipo A a un artefacto cuya responsabilidad registrada es el componente/tipo B a menos que el artefacto sea explícitamente dueño de A.
- Si no se puede probar la propiedad semántica, detente con
WBS_BLOCKED_DESIGN_GAP; no fabriques un mapeo a partir de prosa de TDD cercana.
Antes de emitir la WBS, crea una tabla de consistencia interna/externa:
| ID WBS | Entregable Principal | IDs de Artefacto Referenciados | Responsabilidad del Registro | Unidad Propiedad de la DD | ¿Coincidencia Semántica? | Evidencia |
|---|
Umbral requerido:
identidad semántica WBS ↔ artefacto = 100%
4. Tabla WBS
| ID WBS | IDs de Artefacto de Diseño | Tarea | Ancla de Fuente Existente / Ubicación Propuesta | Tipo de Cambio | Dependencias | IDs de Requisito | Referencias TDD/DD | Verificación | Criterios de Finalización |
|---|
Tipo de Cambio:
- AÑADIR
- MODIFICAR
- ELIMINAR
- CONFIGURAR
- MIGRAR
- PROBAR
- DOCUMENTAR
- VERIFICAR
5. Grafo de Dependencias
Deriva el orden de implementación a partir de las dependencias de artefactos y las dependencias de código/ejecución.
Crea:
| ID WBS | Depende de | Razón de la Dependencia | Fuerte/Débil |
|---|
Detecta dependencias circulares.
No inventes el orden solo por el orden de los archivos.
6. Mapeo de Verificación
Cada tarea que modifique código necesita una ruta de verificación.
Mapea a:
- prueba existente para actualizar
- nuevo ID/punto de vista de prueba
- verificación de fuente/compilación
- verificación de ejecución/integración
- verificación manual solo cuando la automatización no sea factible
7. Trazabilidad
Crea:
| ID de Requisito | ID de Brecha | ID de Decisión TDD | ID de Artefacto | DD | IDs WBS | IDs de Prueba/Verificación | Cobertura |
|---|
Ningún artefacto de diseño verificado puede quedar huérfano.
8. Compuerta WBS
Antes de WBS_READY_FOR_VERIFICATION:
[ ] todos los artefactos DD_VERIFIED tienen cobertura de tareas de implementación/verificación
[ ] cada tarea WBS se mapea de vuelta al diseño verificado
[ ] el entregable principal de cada tarea WBS coincide semánticamente con la responsabilidad/unidad propiedad de su(s) artefacto(s) referenciado(s)
[ ] ninguna tarea se basa en un símbolo de DD/TDD meramente mencionado como prueba de propiedad del artefacto
[ ] los anclajes de fuente/ubicaciones propuestas son concretos
[ ] las dependencias son explícitas
[ ] las tareas que modifican código tienen criterios de finalización y verificación
[ ] el trabajo de configuración/migración/documentación/pruebas está incluido cuando es requerido
[ ] no se agregó arquitectura/refactorización no aprobada
[ ] no hay una brecha de fuente ALTA/CRÍTICA oculta dentro de una tarea
Estados:
- WBS_READY_FOR_VERIFICATION
- WBS_BLOCKED_DESIGN_GAP
- WBS_BLOCKED_SOURCE_GAP
Importante
NO estimes horas/días/puntos de historia en esta habilidad. La estimación de esfuerzo es un asunto separado.