.projectstore / méthode / 2
L'industrie a inventé cela il y a longtemps.
Les agents l'ont rendu bon marché.
Des ADR, des revues, un backlog, des critères d'acceptation, des liens de l'objectif jusqu'au code. Les équipes d'ingénierie matures travaillent ainsi depuis vingt ans. ProjectStore n'en invente rien.
D'où vient chaque élément
- 1969RFC : des décisions écrites et numérotées, puis discutées au grand jour.
- 1992DO-178B : en avionique, chaque exigence doit être reliée au code et à un test.
- 1995Scrum : le travail sous forme de backlog, ordonné et visible.
- 1999XP : les user stories, et des critères d'acceptation qui disent quand une story est terminée.
- 2007Kanban pour le logiciel : un tableau qui montre ce qui est en cours.
- 2011ADR, Michael Nygard : un court fichier par décision d'architecture.
- présentLes agents de codage : chaque étape prend quelques minutes. Sans les artefacts, chaque session repart de zéro.
Un projet, beaucoup de mains. Le même socle pour toutes.
Un ADR dit ce qui a été décidé et ce qui a été écarté. Une spec dit comment cela doit fonctionner. Un epic et ses stories disent ce qui se construit et quand chaque partie est terminée. Le tableau montre ce qui est en cours.
Avec eux, un ingénieur qui arrive demain, un relecteur d'une autre équipe et un agent dans une session neuve partent tous de ce que savait la première personne. C'est pourquoi les équipes qui bâtissent de gros systèmes tiennent ces documents depuis des décennies.
Le processus a toujours eu de la valeur. Ce qui coûtait cher, c'était que des humains en assurent chaque étape.
Le processus fonctionne. Ses documents sont ce qu'une entreprise conserve de plus précieux après un projet : pourquoi le système est construit ainsi, ce qui comptait comme terminé, où se trouve chaque fonctionnalité dans le code. Mais quand des humains l'appliquent à la main, il est lent. Un ADR demande un après-midi d'écriture et une semaine pour être relu. Les documents prennent du retard sur le code. Le tableau ne correspond plus à la réalité. Alors les équipes prennent des raccourcis, et « agile » devient une excuse pour ne rien écrire.
Quand les artefacts manquent, c'est pareil avec les personnes et avec les agents : des questions réglées reviennent, personne ne sait dire pourquoi le code est comme il est, et chaque nouvel arrivant commence par deviner.
Les agents, c'est l'inverse. Rédiger un ADR, découper un epic en stories ou vérifier un diff au regard des critères demande à un agent quelques minutes, pas des jours. Ce qui manque à un agent, c'est ce que les humains ont naturellement : la mémoire d'une session à l'autre, un contexte partagé avec les collègues, le lien entre un objectif et le code. Chaque nouvelle session part de zéro et tranche à nouveau ce qui était déjà réglé.
le processus des humains+la vitesse des agents=ProjectStore
ProjectStore réunit les deux. La vitesse des agents rend le vieux processus bon marché pour la première fois. Ses documents, rangés dans des fichiers à côté du code, donnent aux agents ce qu'ils n'ont jamais eu : le contexte du projet, relié en amont aux objectifs et en aval au code. La règle veut qu'un second agent, qui n'a pas écrit le brouillon, relise chaque étape. La vitesse y gagne une mémoire, et la mémoire une vérification.
Six étapes, à la main et dans ProjectStore.
| Étape | La pratique et son âge | Par des humains | Dans ProjectStore |
|---|---|---|---|
| Décisionpourquoi | ADR, Michael Nygard, 2011. Avant cela, comités d'architecture et revues de conception. | Un après-midi d'écriture, une semaine dans la file de revue. Les alternatives écartées restent dans la tête de quelqu'un. | L'agent le rédige en une minute. Un critic indépendant cherche les points faibles. Vous validez. Résultat : un fichier daté, qui garde aussi ce qui a été écarté. |
| Contratcomment | Spec, document de conception, RFC. Les RFC sont numérotées depuis 1969 ; les documents de conception sont la norme dans les grandes entreprises. | Une semaine à écrire, et périmée à la release. Personne ne vérifie que le code y correspond encore. | Une spec décrit le comportement attendu sous forme de règles numérotées. Ses vérifications s'appliquent à chaque story qu'elle couvre. Une story ne peut pas être close tant que sa spec reste un brouillon. |
| Backlogquoi | Product backlog de Scrum, 1995. User stories d'XP, 1999. Kanban pour le logiciel, 2007. | Des réunions d'affinage du backlog. Le tableau s'écarte de la réalité en une semaine, parce qu'il est tenu à la main. | Chaque fichier de story porte son propre statut. Le tableau, les index et la carte des liens sont construits à partir de ces fichiers. S'ils divergent, une seule commande les reconstruit. |
| Planoù | Conception technique, analyse d'impact. Le tech lead regarde où cela s'insère dans le code existant. | Où les fonctionnalités précédentes ont été implémentées dans le code, seul le tech lead le sait. Et il est en vacances. | Le planner regarde où les epics précédents ont été implémentés dans le code. Il dit où le changement a sa place et quoi réutiliser. Le plan est ajouté à la story. |
| Acceptationpreuve | Critères d'acceptation, Definition of Done. XP et Scrum, début des années 2000. | Un cycle de QA en fin de sprint. « Terminé » sur simple déclaration ; critères vérifiés par sondage. | Le reviewer vérifie le diff au regard de chaque critère et demande une preuve : un test, une commande exécutée, une ligne de code. Pas de preuve, pas de clôture. |
| Traçabilitéliens | Traçabilité des exigences. Obligatoire en avionique depuis la DO-178B (1992) et dans le logiciel médical. | Une matrice Excel « exigence → code → test » que personne ne met à jour après la deuxième release. | Chaque story est reliée en amont à son epic, à ses ADR et à ses specs, et en aval à son code. La preuve figure sous chaque critère d'acceptation. La carte des liens et la carte du code sont générées : personne ne les tient à jour à la main. |
Les liens qu'un agent obtient sans effort : de l'objectif à la preuve
- objectifEpicCHECKOUT · pourquoi on le faitepic:
- pourquoiADRla décision et les options écartéesadr: [ ]
- commentSpecle comportement attenduspecs: [ ]
- quoiStoryplan et critères d'acceptationcode_refs:
- oùCodesrc/billing/cards/ · là où vivent déjà les epics précédents— preuve :
- preuvePreuvestests/cards.test.ts:58 · par critère
Les liens figurent dans l'en-tête de chaque fichier, et la preuve est une ligne sous chaque critère d'acceptation. L'agent remplit tout cela au fil du travail. La carte des liens montre à quoi chaque document est relié. La carte du code indique où vit le code de chaque epic. Une nouvelle session, un nouveau modèle ou un nouveau collègue part de cette chaîne, pas de zéro.
Install the projectstore plugin from https://github.com/SmartAndPoint/ProjectStore and set it up for this project.