ASH Method : Analyse-Solutioning-Handoff
Un workflow complet pour répondre à tout type de projet/idée de développement en informatique. L'idée est de mettre en place 9 étapes qui s'enchainent pour arriver à maximiser la réussite d'un développement.
Les étapes sont :
- Initialisation
- Analyse
- Architecture
- Planification
- Execution
- Revue
- Resolution
- Test
- Finalisation
Pour chaque étape on va associer un rôle (analyste, développeur, etc...), une certaine quantité de règles (Obligation et Interdiction) et un objectif. Chaque étape aura donc sa propre description dans son propre fichier. Au début du fichier on expliquera quelles sont les conditions à remplir pour pouvoir passer à une autre étape ainsi que le nom du fichier qui contient la description de l'étape suivante. On peut également imaginer une condition d'échec qui permet de recommencer à une étape précédente.
Le workflow tourne autour d'un fichier WORKFLOW_STATE.md qui sera modifié à mesure qu'on avance par chaque rôle.
C'est ici qu'on va expliquer le fonctionnement de notre workflow. Cette phase permet d'échanger avec l'utilisateur et de brainstormer. Il faut détecter les ambiguïtés et pousser l'utilisateur à bien expliquer. On va explorer des idées ou limites auxquelles il n'a pas forcement pensé.
Analyse du répertoire de travail. Exploration des fichiers. Comprendre les patterns et les standards qui sont utilisés.
C'est ici qu'on définit les choix techniques avant de planifier les tâches. Le rôle est celui de l'Architecte.
Sous-tâches :
- Choix techniques : sélection des frameworks, langages, librairies à utiliser
- Structure du projet : organisation des dossiers et modules
- Interfaces et contrats : définir comment les composants communiquent entre eux
- Schémas : diagrammes de flux, modèles de données si pertinent
- Risques techniques : identifier les points bloquants potentiels
La sortie est un document d'architecture validé par l'utilisateur.
C'est ici qu'on va produire la todo list de tâches. On va décomposer fichier par fichier avec des tâches unitaires. L'idée est qu'il ne faut pas qu'il y ait de tâches qui incluent plusieurs fichiers à la fois ou plusieurs idées en même temps.
Dans le WORKFLOW_STATE.md on va produire un tableau avec les colonnes :
- État : case à cocher
- ID : identifiant unique de la tâche (T1, T2, etc.)
- Nom : nom court de la tâche
- Description : ce qu'on cherche à faire
- Dépendances : liste des IDs des tâches prérequises (ex: T1, T2)
- Résolution : explication de comment la tâche a été résolue (ou pourquoi elle a échoué)
Les tâches doivent être exécutées en respectant l'ordre des dépendances.
C'est le développeur qui va exécuter tâche par tâche en interrogeant la todo list. En cas d'échec il faut notifier pourquoi ce n'est pas faisable dans la colonne explicative. Un échec est acceptable si le fait de résoudre la tâche risque de casser le reste du projet.
C'est ici qu'on valide et examine la qualité du travail réalisé. Le rôle est celui du Reviewer.
Sous-tâches :
- Vérification automatique : lint, typecheck, formatage (pas les tests)
- Cohérence avec la codebase : respect des patterns et standards existants
- Qualité du code : lisibilité, maintenabilité, absence de code mort
- Analyse des échecs : examiner les tâches marquées comme échouées dans la todo list
Condition d'échec : si des tâches ont échoué pour des raisons de conception, proposer un retour vers l'étape Analyse ou Architecture.
Si la Revue a retourné des "issues" alors on résout les problématiques identifiées.
Création et exécution des tests. Si des tests ne passent pas, deux possibilités :
- Soit le test est mal écrit
- Soit c'est un problème de conception → retour vers l'Analyse ou l'Architecture
Ici on fait un résumé de ce qui a été fait et on propose de sauvegarder les résultats avec l'outil utilisé, comme git par exemple avec github.