Skip to main content

​
La Méthodologie Agile

L’Agilité est un état d’esprit basé sur le Manifeste Agile (2001), qui privilégie la collaboration, la livraison de valeur rapide et l’adaptation au changement. Principes Clés
  • Individus et interactions plus que les processus et les outils.
  • Logiciel fonctionnel plus qu’une documentation exhaustive.
  • Collaboration avec le client plus que la négociation contractuelle.
  • Acceptation du changement plus que le suivi d’un plan.
Scrum (L’implémentation Agile la plus courante) Scrum est un cadre de travail qui permet aux équipes d’aborder des problèmes complexes et adaptatifs en livrant des produits avec la plus grande valeur possible. Il est basé sur des itérations courtes et fixes appelées Sprints (généralement 1 à 4 semaines).
Concept ScrumRôleBonne Pratique (À Faire)Erreur à Éviter (Anti-Pattern)
SprintUn cycle de développement de durée fixe.Maintenir une durée de Sprint constante pour créer un rythme prévisible.Changer la durée du Sprint ou le contenu après son lancement (Scope creep).
Product BacklogListe unique et priorisée des fonctionnalités et exigences.Maintenir le backlog DEEP (Détaillé, Estimé, Émergent, Priorisé).Avoir un backlog obsolète, non estimé ou priorisé par le développeur et non par la valeur métier.
Daily Scrum (Mêlée)Réunion quotidienne de 15 minutes pour synchroniser l’équipe.Se concentrer sur les obstacles et le plan du jour pour atteindre l’Objectif du Sprint.Faire un compte rendu au Scrum Master ou transformer la réunion en session de résolution de problèmes.
RétrospectiveRéunion de fin de Sprint pour inspecter l’équipe et le processus.Adopter des actions concrètes et mesurables pour améliorer le prochain Sprint.Pointer du doigt les individus (blâme) ou ne pas donner suite aux actions décidées.

​
Le Système Kanban

Kanban (mot japonais signifiant “panneau visuel” ou “carte”) est une méthode qui se concentre sur la visualisation du travail et la limitation du travail en cours (WIP) pour améliorer le flux. Principes Clés
  1. Visualiser le Flux de Travail : Utiliser un tableau (physique ou numérique) avec des colonnes représentant les étapes du processus (À Faire, En Cours, En Revue, Terminé).
  2. Limiter le Travail en Cours (WIP - Work In Progress) : Définir un nombre maximum de tâches dans chaque colonne “En Cours”. C’est le principe fondamental de Kanban.
  3. Mesurer et Gérer le Flux : Se concentrer sur le temps de cycle (temps nécessaire pour qu’un ticket passe de “Début” à “Terminé”).
  4. Politiques Explicites : Définir clairement ce que signifie “Terminé” pour chaque étape du flux.
Concept KanbanRôleBonne Pratique (À Faire)Erreur à Éviter (Anti-Pattern)
Limites WIPNombre maximum de tickets dans une colonne “En Cours”.Respecter strictement la limite. Si une colonne atteint sa limite, les développeurs aident à résoudre le goulot d’étranglement avant de commencer un nouveau travail (Pull System).Ignorer les limites WIP pour “se montrer occupé” ou démarrer plusieurs tâches en parallèle.
Tableau VisuelReprésentation graphique du flux (les colonnes).S’assurer que les tickets ne restent jamais sans bouger (stagnation). Utiliser le code couleur pour indiquer les urgences ou les bloqueurs.Avoir des colonnes ambiguës ou un flux trop complexe (trop de colonnes).
Temps de CycleLe temps écoulé entre le début du travail et la livraison.Mesurer ce temps et l’utiliser comme indicateur principal de performance (pas la vélocité).Se concentrer uniquement sur le nombre de tickets terminés sans tenir compte de la durée de chaque ticket.
Diagramme de Flux Cumulatif (Cumulative Flow Diagram - CFD) Le CFD est l’outil visuel le plus important en Kanban, permettant de voir la stabilité du flux, les goulots d’étranglement (accumulation verticale) et le temps de cycle (distance horizontale entre les lignes).

​
Gestion du Cycle de Vie d’un Ticket (Work Item)

Quel que soit la méthodologie, chaque élément de travail (Ticket, User Story, Bug) doit suivre un cycle de vie standardisé dans l’outil (Jira, Trello, Azure DevOps, etc.). Cycle de Vie Type d’un Ticket
  1. Backlog/Todo : Le ticket est créé, mais n’est pas prêt à être travaillé.
  2. Ready : Le ticket a été discuté, estimé et est prêt pour le développement.
  3. In Progress : Un développeur y travaille activement.
  4. In Review : Le code est terminé et attend une revue de code (Peer Review).
  5. Testing/QA : Le ticket est déployé dans un environnement de test et est à vérifier.
  6. Test OK : Le ticket est déployé dans un environnement de test et est vérifié.
  7. Done/Deployed : Le ticket est en production et la valeur est livrée.
Bonnes Pratiques de Gestion des Tickets
AspectBonne Pratique (À Faire)Erreur à Éviter (Anti-Pattern)
TailleDécouper les tickets en petites unités (idéalement 1 à 3 jours de travail maximum) pour une livraison rapide.Créer des tickets monolithiques appelés “Épic”, dont la taille décourage le démarrage.
DéfinitionInclure une Définition de Prêt (Definition of Ready) : critères pour savoir si un ticket peut être commencé (ex: estimé, designs attachés, critères d’acceptation clairs).Commencer le travail sur un ticket sans comprendre l’intégralité du besoin ou les cas d’erreur.
AcceptationInclure une Définition de Terminé (Definition of Done - DoD) : critères pour qu’un ticket soit considéré comme livré (ex: code revu, tests passés, documentation mise à jour, déployé en staging).Considérer le travail comme “Terminé” dès que le développeur a fini de coder sur sa machine locale.
TransparenceMettre à jour le statut du ticket en temps réel (déplacement sur le tableau) pour une transparence totale du flux.Laisser les tickets stagnants ou les déplacer en masse à la fin de la semaine.