Cette compétence prend le contexte de la conversation en cours et la compréhension de la base de code pour produire une spécification. N'interviewez PAS l'utilisateur ; synthétisez simplement ce que vous savez déjà.
Le vocabulaire du gestionnaire de tickets et des étiquettes de triage doit vous avoir été fourni. Si ce n'est pas le cas, 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 de la spécification, et respectez les ADR dans la zone que vous touchez.
-
Esquissez les coutures (seams) auxquelles vous allez tester la fonctionnalité. Les coutures existantes doivent être préférées aux nouvelles. Utilisez la couture la plus haute possible. Si de nouvelles coutures sont nécessaires, proposez-les au point le plus haut possible. Moins il y a de coutures dans la base de code, mieux c'est – le nombre idéal est un.
Vérifiez avec l'utilisateur que ces coutures correspondent à leurs attentes.
- Rédigez la spécification en utilisant le modèle ci-dessous, puis publiez-la dans le gestionnaire de tickets du projet. Appliquez l'étiquette de triage
ready-for-agent– pas besoin de triage supplémentaire.
É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 numérotée LONGUE 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 complète 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 modifications de schéma
- Des contrats d'API
- Des interactions spécifiques
N'incluez PAS de chemins de fichiers spécifiques ou d'extraits de code. Ils peuvent devenir rapidement obsolètes.
Exception : si un prototype a produit un extrait qui encode une décision plus précisément que ne le ferait de la prose (machine d'état, 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. Réduisez aux parties riches en décisions, pas à une démo fonctionnelle, seulement 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 (ne tester que le comportement externe, pas les détails d'implémentation)
- Quels modules seront testés
- Les 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 cette spécification.
Remarques complémentaires
Toute remarque complémentaire sur la fonctionnalité.