project-management

Déclencheurs

• gestion de projet
• décomposition de tâches
• analyse de spécification
• création de listes de tâches
• tâches de développement
• critères d'acceptation
• définition du périmètre
• décomposition du travail
• planification de projet
• estimation de tâches
• analyse des exigences
• exigences techniques
• périmètre du projet
• priorisation des tâches
• tâches de sprint
• planification du développement

Instructions

Une fois activé, convertir les spécifications en tâches de développement structurées et actionnables avec un périmètre réaliste et des critères d'acceptation clairs.

Analyse de spécification

• Lire attentivement le fichier de spécification réel.
• Citer les exigences exactes -- ne pas ajouter de fonctionnalités de luxe ou premium qui ne sont pas spécifiées.
• Identifier les lacunes ou exigences peu claires et les signaler.
• Se souvenir : la plupart des spécifications sont plus simples qu'elles ne le paraissent d'abord.

Création de liste de tâches

• Décomposer les spécifications en tâches de développement spécifiques et actionnables.
• Chaque tâche doit être implémentable par un développeur en 30-60 minutes.
• Inclure des critères d'acceptation pour chaque tâche.
• Utiliser knowledge_write pour sauvegarder les listes de tâches et suivre la progression du projet.
• Utiliser goal_create pour fixer les jalons du projet.

Extraction de la pile technique

• Extraire la pile de développement de la spécification.
• Noter le framework CSS, les préférences d'animation, les dépendances.
• Inclure les exigences des composants et les besoins d'intégration.
• Spécifier les détails d'intégration spécifiques au framework.

Règles de périmètre réaliste

• Ne pas ajouter d'exigences de luxe ou premium sauf si explicitement dans la spécification.
• Les implémentations basiques sont normales et acceptables.
• Privilégier les exigences fonctionnelles en premier, le polissage en second.
• La plupart des premières implémentations nécessitent 2-3 cycles de révision.
• Ne jamais s'engager sur des délais irréalistes.

Apprentissage par l'expérience

• Se souvenir des défis et motifs des projets précédents.
• Noter quelles structures de tâches fonctionnent le mieux pour les développeurs.
• Suivre quelles exigences sont couramment mal comprises.
• Construire une bibliothèque de motifs de décomposition de tâches réussie.

Normes de qualité des tâches

• Les tâches doivent être immédiatement actionnables par un développeur.
• Les critères d'acceptation doivent être clairs et testables.
• Référencer le texte exact des exigences dans les descriptions de tâches.
• Inclure les fichiers à créer/modifier pour chaque tâche.
• Spécifier les dépendances éventuelles entre les tâches.

Livrables

Format de liste de tâches

Project: [Name]
Specification Summary: [Key requirements quoted from spec]
Technical Stack: [Exact requirements]
Target Timeline: [From specification]

Task 1: [Name]
Description: [Specific, actionable description]
Acceptance Criteria:
- [Testable criterion 1]
- [Testable criterion 2]
Files to Create/Edit: [Specific file paths]
Reference: [Section of specification]

Task 2: [Name]
...

Quality Requirements:
- Mobile responsive design
- Form functionality works
- All components use supported props
- Screenshot testing included

Métriques de succès

• Les développeurs peuvent implémenter les tâches sans confusion.
• Les critères d'acceptation des tâches sont clairs et testables.
• Aucun débordement de périmètre par rapport à la spécification originale.
• Les exigences techniques sont complètes et précises.
• La structure des tâches mène à la réussite du projet.

Vérification

• Le livrable de cette phase existe en tant qu'artefact concret (doc, ticket, tableau, repo) et son emplacement est partagé, non décrit
• Chaque engagement a un propriétaire nommé, une date limite et une définition d'achèvement qu'une autre personne que l'auteur pourrait vérifier
• Les risques sont énumérés avec vraisemblance/impact et une atténuation nommée, non comme une puce générique « risques : TBD »
• Les dépendances envers d'autres équipes/fournisseurs/agents sont explicites ; un accusé de réception de chaque dépendance est enregistré ou marqué « en attente »
• Les critères de succès pour la phase suivante sont numériques ou sinon objectivement testables
• Un critère de retour en arrière / kill-switch / « nous arrêterons si X » est écrit avant le début du travail