Méthode Agile

Méthode AGILE – Retours d’expériences

Voici maintenant plus de 5 ans que SALTO Consulting gère des projets implémentant la méthode AGILE.
Ceux-ci sont de

  • nature (Création d’un nouveau produit, Maintenance d’un produit existant, Intégration de progiciel, etc.),
  • taille (de 100j à plus de 3000j),
  • durée (de 3 mois à 3 ans),
  • domaine fonctionnel (ECommerce, Mise en place d’un back-office Magasin, Mise en oeuvre des processus de ventes et d’achat, etc.)

différents.
Il n’en demeure pas moins que la mise en oeuvre complète ou partielle des éléments ‘clés’ suivants conditionne la réussite de ceux-ci  :

 

1. Des rôles indispensables

A minima, un projet utilisant la méthode AGILE doit intégrer et IDENTIFIER les 3 rôles suivants :

  • Product Owner (PO) : Alimente le Backlog en UserStory – Il est le représentant du fonctionnel
  • Scrum Master : Récolte et analyse les données des sprints passés : Capacitif => Dimensionnement cohérent des sprints
  • Team Member : Il s’agit des membres de l’équipe chargés de la réalisation des UserStory.

Ce que l’on néglige parfois, c’est celui de Scrum Master.
C’est pourtant lui qui permet de reprendre les données ‘historiques’ des sprints, de les analyser (prendre du recul) et d’en tirer des éléments d’amélioration ‘objectifs’ (non discutables) du processus ‘AGILE’ mis en place.
Il contribue ainsi à

  • l’amélioration des processus de réalisation
  • la mise à disposition de chacun de données ‘objectives’
    • Capacitif d’équipe,
    • Rapprochement Story Point et Charges de travail,
    • Cause de blocage, de rupture dans la chaîne de fabrication,
    • Etc.
  • la mise en place d’une relation de confiance entre le fonctionnel et l’équipe AGILE.

 

2. Des rôles parfois nécessaires

En plus des rôles précédemment décrits, il peut s’avérer nécessaire de les compléter avec les 2 rôles suivants (qui ne sont pas des rôles de la méthode AGILE) :

  • Team Leader (ou Leader Technique) :
    Même si les choix de conception, revues de code, déploiements, veille techno etc. sont censés être totalement partagés dans l’équipe de développement, il n’en demeure pas moins que dans certains cas (équipe jeune, environnement technique nouveau), l’intégration d’un Team Leader (plus exactement leader technique) peut s’avérer nécessaire. Il faudra alors s’assurer qu’à terme, tous les membres de l’équipe aient un certain niveau d’autonomie au sein du projet (augmentation de la productivité).
  • DevOps :
    Affecter un rôle de ‘DevOps’ (lien entre le développement, la pré-production et la production) à l’un des membres de l’équipe (ce n’est pas son seul rôle dans le projet) permet d’assurer la ‘fluidité’ des mises en production des réalisations, notamment quand le niveau de maturité de l’outillage ‘DevOps’ (Intégration continue, orchestrateurs de containers, déploiement automatisé, etc.) n’est pas encore suffisant.
    Sans se vouloir exhaustif, la liste qui suit présente les principales problématiques à mettre en oeuvre :

    • Réalisation des jeux de données (sur la base des tests ‘QA’), éventuellement bouchonnés
    • Description du contenu de la livraison (Release Notes),
    • Ecriture des scripts (procédures) à passer lors de la mise en production
    • Mise en oeuvre et maintenance évolutive d’une plate-forme d’intégration continue automatisée (Build, Tests de non régression, Audit de code, Tests de performance, déploiement, etc.)
    • Vérification de la réalisation des pré-requis ‘techniques’ réalisés par des équipes tierces (BDD, VM, Dockerisation, APIs, Batch, etc.)
    • Planification des MEPP et MEP avec l’équipe Production
    • Participation à la MEP (GO – NO GO ‘technique’ de la mise en production – Vérification des résultats de l’intégration continue automatisée ou pas)
    • Faire le bilan de la MEP et de proposer des actions d’amélioration

 

3. Relation de confiance entre le fonctionnel et l’équipe AGILE

Il va sans dire qu’une relation de confiance entre le fonctionnel et l’équipe de réalisation (qu’elle soit méthode AGILE ou pas) est un élément clé de la réussite d’un projet.
Elle évite toute perte de temps à négocier et à se justifier.
Cette relation de confiance se traduit notamment par les éléments suivants :

  • Le fonctionnel (représenté par le PO) ne remet pas en question (négocie pas) les ‘Story Point‘ (charges) fournis par l’équipe (ou son Team Manager).
  • Le Scrum Master s’engage à fournir un capacitif de réalisation (en story point ou charge) de l’équipe à jour au PO et à lui donner toutes les explications nécessaires
  • Le fonctionnel (représenté par le PO) se base sur le capacitif de l’équipe pour construire les sprints
  • L’équipe AGILE s’engage à réaliser le contenu du Sprint et à fournir un contenu de qualité.

 

4. Mise en place d’un Release Plan donnant de la visibilité sur les réalisations à venir

Même si le contenu des sprints est susceptible d’évoluer (c’est le principe même de l’agilité), il est indispensable d’avoir une visibilité sur les réalisations à intégrer sur 2 à 3 mois à venir, à travers un Release Plan (ou Road Map).
Celui-ci doit permettre de :

  • Anticiper la création des UserStory, de les prioriser et de les documenter
  • Organiser des Workshop entre les Team Members (éventuellement représentés par le Team Leader) et le PO pour lever les manques ou les ambiguïtés qui peuvent subsister au niveau de la documentation des UserStory,
  • Planifier la réalisation des pré-requis (réaliser par des équipes tierces) à la réalisation d’une UserStory (APIs, Maquettes HTML-CSS, Contenus médias, etc.)
  • Faire une macro évaluation des UserStory (sous forme de story point ou de charge),
  • Prioriser les réalisation (ranking du Backlog),
  • Alimenter (encore une fois, même s’il est susceptible de changer) le contenu des 3 ou 4 prochains sprints,

Ce Release Plan est vivant. Il peut être revu, ajusté autant de fois qu’il est nécessaire. Il s’agit bien d’anticiper au delà du sprint à venir et de ne pas tout découvrir au dernier moment.
Par contre, il convient de prendre garde à rester sur un périmètre fixe (défini à l’initialisation du sprint) pour le sprint actif (sauf bug critique, incident de production).

 

5. Les Tests – Incontournables

Rappelons ici que méthode AGILE ou pas, ils sont indispensables.
Ils peuvent être classés en 4 grandes catégories :

  • Les tests unitaires : L’équipe de développement est en charge de leurs réalisations.
    Des outils existent pour la plupart des technologies permettant de les ‘prototyper’ et de vérifier en vérifier la complétude en niveau du code (taux de couverture).
  • Les tests fonctionnels : La MOE (à travers son PO ou sa MOA) les réalisent.
    Idéalement, chaque User Story doit avoir son test fonctionnel ‘écrit’ que l’on doit pouvoir lui associer (pièce jointe à la User Story, lien, sous-tâche, etc.). Ils doivent par ailleurs pouvoir être (re)passés n’importe quand (au niveau du sprint actif une fois la UserStory développée ou ultérieurement pour vérifier les non-régressions) afin de vérifier que le produit est (toujours) conforme aux exigences fonctionnelles.
  • Les tests de non-régressions : Il s’agit d’une sélection ‘pertinente’ (fonctionnalités intégrées dans les processus ‘auto-route’, image de marque, réglementation, etc.) de tests fonctionnels à rejouer à chaque nouvelle livraison.
    Dans la plupart des projets, ils sont réellement effectués s’ils ont été automatisés et intégrés dans une chaîne d’intégration continue ou s’il existe une équipe QA sur le projet dont l’une des missions est de les jouer.
    Ils s’avèrent pourtant primordiaux dans le cadre de la méthode AGILE, les mises en production étant de fait fréquentes augmentant sensiblement les risques de régression.
  • Les tests techniques : Ils consistent à vérifier que le produit répond toujours aux exigences de performance et de stabilité.

 

6. Préparation des sprints

Le but de la préparation d’un sprint est qu’au moment du lancement du sprint, il n’y ai plus de question à se poser sur celui-ci et que l’équipe DEVOPS puisse s’engager en toute ‘sérénité’ sur la MEP de celui-ci dans les temps et la qualité requise.
Théoriquement, au moins si la road map a été réalisée et mise à jour, il ne doit plus y avoir de point fonctionnel à revoir.
Il s’agit donc pour le Team Leader et le PO d’adapter le contenu du sprint en fonction des événements récents de la vie du projet à savoir :

  • intégrer les correctifs ‘non bloquants’ restants du sprint précédent
  • découper éventuellement des UserStory pour que chaque userStory du sprint ait un poids équivalent en terme de ‘StoryPoint’ (ou charge).
    Chaque membre d’équipe est alors amené à réaliser le même nombre de UserStory et les commits sont réguliers.
    La mesure d’avancement est alors plus fiable et facile (un comptage du nombre de UserStory réalisées peut suffire)
  • ré-intégrer dans le sprint les UserStory qui n’ont pas pu être réalisées lors du sprint précédent (ce qui doit être exceptionnel si la roadmap a bien été définie et mise à jour)
  • vérifier la réalisation des pré-requis tiers pour chaque UserStory du sprint en cours de préparation
  • prendre en compte le capacitif ‘actuel’ de l’équipe (congés, absence, dimensionnement, intégration de nouvelles ressources, etc.)

Le ‘goal‘ du sprint est alors clairement défini et l’équipe peut se focaliser et s’engager sur sa seule réalisation

 

7. Organiser les Sprints

Sans aller jusqu’à reproduire le Cycle en ‘V’, il apparaît profitable d’organiser les sprints avec les étapes suivantes :

  • Lancement du sprint (1/2j) : PO (ou le Team Leader) lance le sprint avec son équipe par une revue des user story intégrées à celui-ci. Chacun sait ce qu’il y a à faire et ce qu’il peut faire
  • Réalisation (2 semaines minimum) : Au fil des réalisations, l’équipe réalise les UserStory dans l’ordre des propriétés (Ranking du sprint). Elle effectue les tests unitaires et intégre les user story au fil de leur réalisation.
  • Tests : A chaque user story intégrée, le PO (ou sa MOA), passe les tests fonctionnels et identifie d’éventuelles anomalies qu’il priorise et surtout classe comme bloquant ou pas. Dans le cas d’une anomalie bloquante, l’équipe la corrige lors du sprint.
  • Préparation de la MEP (1/2j) : Une fois le GO MEP donné par le PO, l’équipe documente la MEP (Release Notes, procédures et scripts spécifiques, etc.).

 

8. Workflow de réalisation simple et efficace

La mise en place de workflow d’état des UserStory permet d’avoir une vision claire de l’état d’avancement du sprint (surtout si l’on utilise les KANBAN).
Cependant, une tendance forte est de multiplier les ‘états’. Or, la vraie question à se poser est de savoir si un état représente bien une étape d’avancement dans le processus de développement d’une UserStory.
En tout état de cause, les états ‘utiles’ et ‘systèmatiques’ rencontrés sont :

  • Open : La UserStory est ouverte
  • In progress : La UserStory est en cours de développement
  • Ready to test : La UserStory est développée et prête à être testée
  • Done : La UserStory est développée et les tests fonctionnels la concernant ont été passés avec succés. Elle est donc prête à être buildée pour mise en pré-production ou production.
  • Blocked : La UserStory est bloquée (manque de spécifications, en attente d’une autre UserStory, en attente d’un pré-requis, etc.)

L’avantage de ces états est qu’ils sont également applicables pour les anomalies, en effet, il suffit de remplacer, dans ce qui précéde, ‘UserStory’ par ‘Anomalie’ et ‘développée’ par ‘corrigée’ . Dans le cas du ‘Blocked’ les causes peuvent être un manque de description de l’erreur, du contexte dans lequel elle s’est produite (Scénario de test – Etape du test – Jeux d’essai, etc.).

Il existe souvent les états ‘Validated’, ‘Refused’ qui sont plutôt des informations (pourquoi ne pas utiliser alors une étiquette). En effet, le fait de retrouver une User Story (ou Anomalie) dans un sprint suppose qu’elle a été validée (enfin, il faut l’espérer) et si elle est refusée, elle restera dans le backlog et donc ne sera pas visible dans le Kanban (scrum) du sprint.

Toujours est-il que la définition d’un état peut avantageusement être complétée par des critères mesurables d’atteinte de l’état (ex : Done : Taux de couverture des tests de 90% – Respect des normes de développement – Taux de performance atteinte sur l’environnement de pré-production – Présence d’une documentation technique – etc.).

 

9. Polyvalence des équipes

En dehors du fait que cela permet de palier aux absences des membres de l’équipe, cela permet aussi à chacun de faire le travail de l’autre et donc de s’apercevoir des contraintes qui pèsent sur ses tâches et de mieux comprendre les exigences qu’il peut avoir (Ne fais pas à autrui ce que tu n’aimerais que l’on te fasse).
La mise en oeuvre typique de cette notion est la revue de code : L’équipe de développement fait des revues régulières sur les codes de ses collègues permettant non seulement de partager la connaissance des réalisations des autres (limitation du cloisonnement et échanges sur les bonnes pratiques) mais aussi des réduire le nombre d’anomalies.

 

10. Outils collaboratifs

Enfin, la méthode AGILE permettant de réaliser des versions de produits sur des cycles courts et de pouvoir faire évoluer les besoins à la demande (Time to market),

  • partager en permanence les informations sur
    • le stock des UserStory et des anomalies (BACKLOG)
    • le contenu des sprints à venir (ROAD MAP)
    • l’état d’avancement des UserStory (et des anomalies) du sprint actif (KANBAN)
    • les procédures à appliquer (WIKI),
    • les questions et les réponses apportées (FAQ),
    • les trucs et astuces (HOW TO),
  • échanger en live sur une problématique (CHAT),
  • décider sans avoir besoin de se réunir au même endroit (CallConf, WebConf)

sont des besoins ‘quotidiens’ nécessitant donc la mise à disposition des équipes des outils communs ‘collaboratifs’, l’idéal étant d’avoir un seul outil couvrant l’ensemble de ces problématiques d’échange et de partage.