Audit du codebase
La valeur d'un audit réside dans le classement et les preuves, pas dans la longueur. Un constat sans chemin de fichier, résultat de requête, numéro de PR ou nombre de lignes est une hypothèse — étiquetez-le comme tel.
Ancrer l'audit dans le code et la production, pas dans les documents
Les notes de projet, les plans et les documents d'état sont des points de contrôle, pas des autorités. Commencez par eux pour apprendre ce qui a été prétendu, puis vérifiez par rapport à la réalité : le commit en direct, l'état de la base de données, les vérifications de PR, les têtes de branches.
Lorsque les documents et le code sont en désaccord, ce désaccord est en soi un constat — souvent le plus précieux de l'audit.
Une affirmation concernant la production nécessite une requête contre la production. Associez cela à un skill de porte de vérification pour la mécanique.
Structure
# Audit de <Périmètre> (AAAA-MM-JJ)
## TL;DR
<Les trois choses qui comptent, et ce que vous feriez en premier.>
## Partie 1 — Ce que vous ne voyez pas (angles morts, classés)
## Partie 2 — Capacités manquantes (classées, chacune avec une estimation d'effort approximative)
## Partie 3 — Capacités existantes nécessitant une amélioration (classées)
## Partie 4 — Changements architecturaux (classés, en français simple)
## Partie 5 — Si je dirigeais les 30 prochains jours
## Liste de vérification (écarts constatés lors de l'audit)
Classez tout. Une liste non classée de 40 constats est une liste inexploitable de 40 constats.
Vérifier les échafaudages dormants avant d'estimer
Attachez une estimation d'effort approximative à chaque lacune et dites ce qui la rend bon marché ou coûteuse.
Le constat d'audit le plus précieux est généralement celui-ci : la plupart des "lacunes" à forte valeur ajoutée représentent des jours de travail, pas des semaines, car les échafaudages existent déjà dans le dépôt sans appelants. Une fonctionnalité déjà construite à 80 % est une décision complètement différente d'une fonctionnalité qui ne l'est pas.
Cherchez la chose avant de déclarer qu'elle manque. Une fonction sans appelant est le cas canonique — le code est là, rien ne l'invoque, et chaque document d'état décrit la fonctionnalité comme absente.
La liste de vérification
Chaque audit se termine par les écarts qu'il n'a pas pu résoudre. Chaque entrée nomme :
- ce qui a été prétendu
- ce qui a été observé
- quelle requête ou vérification le trancherait
C'est la section que la session suivante utilise réellement. Écrivez-la même lorsqu'elle est courte.
La section explicitement pas utile à faire
Nommez ce que vous avez examiné et délibérément rejeté, avec la raison.
Les audits qui ne font qu'ajouter au backlog rendent le backlog inutile. Un constat que vous avez examiné et écarté vaut plus qu'un constat que vous ne mentionnez jamais, car il empêche l'audit suivant de le soulever à nouveau.
Les éléments retenus ne sont pas des lacunes
Tout ce qui est déjà marqué comme délibérément différé, ou retenu pour une décision humaine explicite, est retenu volontairement. Ne le listez pas comme une lacune.
Ré-exposer un élément retenu délibérément comme constat est ainsi que les décisions retenues sont exécutées par accident.
Résultat
Écrivez l'audit à l'endroit où le projet les conserve. S'il remplace un audit précédent, dites lequel et ce qui a changé — un dossier d'audits doit rester lisible comme une séquence, pas comme un tas.