Cette compétence prend le contexte actuel de la conversation et la compréhension de la base de code pour produire un cahier des charges. N'interviewez PAS l'utilisateur ; synthétisez simplement ce que vous savez déjà.
Le tracker de tickets et le vocabulaire des étiquettes de triage doivent vous avoir été fournis. Sinon, dites à l'utilisateur d'exécuter /setup-matt-pocock-skills.
Processus
-
Explorez le dépôt pour comprendre l'état actuel de la base de code, si ce n'est pas déjà fait. Utilisez le vocabulaire du glossaire du domaine du projet tout au long du cahier des charges et respectez les ADR (Architecture Decision Records) dans la zone que vous touchez.
-
Esquissez les seams (points de test) auxquels vous allez tester la fonctionnalité. Les seams existants doivent être préférés aux nouveaux. Utilisez le seam le plus haut possible. Si de nouveaux seams sont nécessaires, proposez-les au point le plus haut que vous pouvez. Le moins de seams dans la base de code est préférable – le nombre idéal est un.
Vérifiez avec l'utilisateur que ces seams correspondent à ses attentes.
- Rédigez le cahier des charges en utilisant le modèle ci-dessous, puis publiez-le sur le tracker de tickets du projet. Appliquez l'étiquette de triage
ready-for-agent– pas besoin de triage supplémentaire.
<modèle-spec>
Énoncé du problème
Le problème auquel l'utilisateur est confronté, du point de vue de l'utilisateur.
Solution
La solution au problème, du point de vue de l'utilisateur.
User Stories
Une liste LONGUE et numérotée de user stories. Chaque user story doit être au format :
- En tant qu', je veux <fonctionnalité>, afin de <bénéfice>
Cette liste de user stories doit être extrêmement exhaustive et couvrir tous les aspects de la fonctionnalité.
Décisions d'implémentation
Une liste des décisions d'implémentation qui ont été prises. Cela peut inclure :
- Les modules qui seront construits/modifiés
- Les interfaces de ces modules qui seront modifiées
- Des clarifications techniques du développeur
- Des décisions architecturales
- Des changements de schéma
- Des contrats API
- Des interactions spécifiques
N'incluez PAS de chemins de fichiers spécifiques ou d'extraits de code. Ils pourraient devenir obsolètes très rapidement.
Exception : si un prototype a produit un extrait qui encode une décision plus précisément que la prose ne le peut (machine à états, réducteur, schéma, forme de type), intégrez-le dans la décision concernée et notez brièvement qu'il provient d'un prototype. Limitez-vous aux parties riches en décisions, pas une démonstration fonctionnelle, juste les éléments importants.
Décisions de test
Une liste des décisions de test qui ont été prises. Incluez :
- Une description de ce qui constitue un bon test (tester uniquement le comportement externe, pas les détails d'implémentation)
- Quels modules seront testés
- Des précédents pour les tests (c'est-à-dire des types de tests similaires dans la base de code)
Hors périmètre
Une description des éléments qui sont hors périmètre pour ce cahier des charges.
Notes complémentaires
Toutes notes complémentaires sur la fonctionnalité.
</modèle-spec>