Génération du WBS d'Implémentation
Objectif
Le WBS décrit CE QUI doit être implémenté, pas une estimation d'effort.
Ne passez pas directement de la prose TDD à des tâches génériques.
Les entrées doivent inclure des conceptions détaillées VÉRIFIÉES.
Exigence
→ Écart
→ TDD
→ Artefact de Conception
→ Conception Détaillée VÉRIFIÉE
→ Tâche WBS
→ Vérification
Entrées
- exigence faisant autorité
- analyse d'écart vérifiée
- TDD vérifié
- registre des artefacts de conception
- toutes les conceptions détaillées
DD_VERIFIED - rapports de vérification de conception détaillée
- conception de test si disponible
- dépôt actuel
1. Dérivation des Tâches
Dérivez les tâches uniquement à partir de décisions de conception vérifiées.
Catégories de tâches :
- code de production
- API/contrat
- intégration
- données/persistance
- configuration
- migration/compatibilité
- tests
- construction/déploiement
- documentation
- nettoyage uniquement si requis par la conception approuvée
N'ajoutez pas de refactorisation "nice to have".
2. Granularité des Tâches
Une tâche doit être suffisamment petite pour avoir :
- un résultat clair
- des ancres source/conception concrètes
- des dépendances explicites
- des critères de complétion vérifiables
Mais ne divisez pas les modifications mécaniques en dizaines de micro-tâches insignifiantes.
3. Identifiants Stables
Utilisez :
WBS-001, WBS-002, ...
3A. Identité Sémantique WBS ↔ Conception
La traçabilité n'est pas satisfaite simplement parce qu'une ligne WBS contient un ID d'artefact existant.
Pour chaque tâche WBS, identifiez son livrable d'implémentation principal et prouvez que le(s) artefact(s) de conception référencé(s) possède(nt) ce livrable.
Chaîne sémantique requise :
Titre / objectif / livrable principal de la tâche WBS
↔ nom de l'artefact du registre + responsabilité
↔ unité(s) d'implémentation possédée(s) par la DD VÉRIFIÉE
↔ décision de conception TDD
Règles :
- Une référence d'ID d'artefact est nécessaire mais pas suffisante.
- Le fait qu'un type/classe/interface soit simplement mentionné, importé, référencé ou lié depuis une DD ne prouve pas que l'artefact possède cette unité d'implémentation.
- Si le livrable principal d'une tâche WBS est un type subordonné, l'un des éléments suivants doit être vrai :
- le registre/DD déclare explicitement ce type subordonné dans le périmètre de l'artefact propriétaire, ou
- la décomposition de l'artefact de conception doit être révisée pour le suivre séparément.
- Ne mappez pas une tâche intitulée pour le composant/type A à un artefact dont la responsabilité enregistrée est le composant/type B, sauf si l'artefact possède explicitement A.
- Si la propriété sémantique ne peut pas être prouvée, arrêtez-vous avec
WBS_BLOCKED_DESIGN_GAP; ne fabriquez pas de mapping à partir de prose TDD proche.
Avant d'émettre le WBS, créez un tableau de cohérence interne/exposé :
| ID WBS | Livrable Principal | ID Artefact Référencé | Responsabilité du Registre | Unité Possédée par DD | Correspondance Sémantique ? | Preuve |
|---|
Seuil requis :
Identité sémantique WBS ↔ artefact = 100%
4. Tableau WBS
| ID WBS | ID Artefact de Conception | Tâche | Ancre Source Existante / Emplacement Proposé | Type de Changement | Dépendances | ID Exigence | Références TDD/DD | Vérification | Critères de Complétion |
|---|
Type de Changement :
- AJOUTER
- MODIFIER
- SUPPRIMER
- CONFIGURER
- MIGRER
- TESTER
- DOCUMENTER
- VÉRIFIER
5. Graphe de Dépendances
Dérivez l'ordre d'implémentation à partir des dépendances d'artefact et des dépendances de code/exécution.
Créez :
| ID WBS | Dépend de | Raison de la Dépendance | Fort/Faible |
|---|
Détectez les dépendances circulaires.
N'inventez pas d'ordre uniquement à partir de l'ordre des fichiers.
6. Mapping de Vérification
Chaque tâche modifiant du code nécessite un chemin de vérification.
Mappez à :
- test existant à mettre à jour
- nouvel ID/point de vue de test
- vérification source/construction
- vérification d'exécution/intégration
- vérification manuelle uniquement lorsque l'automatisation n'est pas réalisable
7. Traçabilité
Créez :
| ID Exigence | ID Écart | ID Décision TDD | ID Artefact | DD | ID WBS | ID Test/Vérification | Couverture |
|---|
Aucun artefact de conception vérifié ne peut être orphelin.
8. Porte WBS
Avant WBS_READY_FOR_VERIFICATION :
[ ] tous les artefacts DD_VERIFIED ont une couverture de tâche d'implémentation/vérification
[ ] chaque tâche WBS correspond à une conception vérifiée
[ ] le livrable principal de chaque tâche WBS correspond sémantiquement à la responsabilité/unité possédée de son(ses) artefact(s) référencé(s)
[ ] aucune tâche ne repose sur un symbole DD/TDD simplement mentionné comme preuve de propriété d'artefact
[ ] les ancres sources/emplacements proposés sont concrets
[ ] les dépendances sont explicites
[ ] les tâches modifiant du code ont des critères de complétion et une vérification
[ ] le travail de configuration/migration/docs/test est inclus lorsqu'il est requis
[ ] aucune architecture/refactorisation non approuvée n'a été ajoutée
[ ] aucun écart source ÉLEVÉ/CRITIQUE n'est caché à l'intérieur d'une tâche
Statuts :
- WBS_READY_FOR_VERIFICATION
- WBS_BLOCKED_DESIGN_GAP
- WBS_BLOCKED_SOURCE_GAP
Important
N'estimez PAS les heures/jours/story points dans cette compétence. L'estimation d'effort est une préoccupation distincte.