Fiche explicative projet Agile

Lexique  

• Backlog ou Backlog produit : représente l’ensemble des besoins recueillis pour créer le produit désiré. Il est composé de Features, d’User Stories et de tâches.  
• User story ou US (aussi appelé Ticket) : décrit une partie d’une fonctionnalité.  
• Bug : un défaut de conception de l’application à l'origine d'un dysfonctionnement ou résultat du non-respect de l’User Story.  
• Sprint : cycle de développement court permettant de développer un nombre fini d’User Stories documentées et affinées. Une fois défini, un sprint ne peut pas être modifié.  
• Product Owner : personne en charge de la vision du produit. Il se charge de créer et gérer le backlog. Il prend les décisions sur les priorités des User Stories et sur les User Stories à développer pendant les sprints.  
• Chiffrer une User Story ou définir un effort / une charge : l’équipe de développement définit le temps nécessaire pour développer une User Story. De même, l’équipe de test définit la charge nécessaire pour tester chaque User Story.  
• Cérémonie Agile : une réunion qui constitue un des rituels clés de l’Agilité

Les rôles de l’équipe Agile

  Les rôles de l’équipe Agile sont les suivants :

• Le client présente les besoins métier de l’application, la stratégie de l’entreprise (les utilisateurs visés, etc.) et donne ses retours sur l’application au fur et à mesure des développements.  
• Le Product Owner est en charge de la vision produit. Il fait le lien entre le client et l’équipe de développement et de test.  
• Le Scrum Master est le garant de l’avancement de l’équipe dans les meilleures conditions possibles (organisation des cérémonies Agile, mise en place d’amélioration, etc.)  
• Le développeur code l’application et corrige les bugs.  
• Le testeur teste les nouveaux développements mis à disposition par les développeurs.

Le rôle du client

  Le client est en lien permanent avec le Product Owner afin de lui :  

• Présenter les différents besoins à contenter via l’application en cours de développement.
• Partager régulièrement la stratégie produit / de l’entreprise
• Partager régulièrement les hypothèses qu’il souhaite valider
• Le client sera impliqué par le Product Owner dans la définition et la priorisation du backlog.
• Le client valide les User Stories dès qu’elles sont rédigées par le Product Owner. Si besoin, il ajoute des commentaires afin de demander des modifications des US rédigées.
• Il participe à la revue de sprint après chaque fin de sprint et réalise les tests fonctionnels de l’application afin de s’assurer que l’application correspond à ses attentes.

Les avantages d’un projet Agile

 

• Le client faisant partie intégrante de l’équipe Agile, la communication permanente entre le prestataire et le client apporte une réelle capacité d’adaptation de l’équipe et de l’application en fonction des retours / informations donnés par le client.  
• Les livrables étant réguliers, un projet Agile est plus facile à piloter. Le suivi de l’avancement est meilleur.  
• Il est possible de publier une première version de l’application très rapidement et obtenir les premiers retours des utilisateurs.  
• Les besoins initiaux ne sont pas figés. Ils évoluent en fonction de retours utilisateur / du client et de la stratégie de l’entreprise. De même, la priorité des User Stories inscrites au backlog peut être modifiée, des US peuvent être ajoutées ou retirées du backlog par le Product Owner. La flexibilité est au cœur de la méthodologie.  
• En Agile, le Product Owner est focalisé sur l’apport de valeur ajoutée à l’utilisateur de l’application. Le rapport réponse à un besoin / coût de développement est ainsi bien meilleur que pour un projet classique.  
• En testant plus régulièrement, les défauts de l’application sont identifiés rapidement et plus facile à corriger. La qualité de l’application est alors meilleure.

Les erreurs à éviter

  Attendre le développement de plusieurs ou de tous les sprints avant de tester l’application est une erreur avec un grand impact. Les tests doivent être réalisés pour chaque sprint. En ne testant pas l’application lui-même, le client prend de la distance avec l’application et est moins capable de remonter des besoins métier et des utilisateurs au Product Owner. De plus, il ne valide pas les User Stories développées. Ceci qui ne permet pas d’avoir une vision claire de l’avancée du projet et de publier les sprints régulièrement.   Vouloir modifier le contenu d’un sprint en cours de développement. Une fois le sprint commencé, tout sprint démarré et les User Stories qui le compose ne peuvent plus être modifiés. Si de nouveaux besoins se font ressentir, il sera nécessaire de créer une nouvelle User Story pour formaliser ce besoin et suivre le cycle classique de validation et chiffrage.   Il n’est pas nécessaire de livrer chaque sprint en production. Un sprint est un cycle de développement potentiellement livrable mais il n’est pas toujours pertinent publier en production chaque sprint. En effet, malgré les tests, le risque d’apparition d’erreurs est présent pour toute nouvelle publication d’une version de l’application.   Attendre la fin du développement de tous les sprints avant de publier l’application en production. En effet, il est important de mettre l’application en les mains de l’utilisateur final le plus tôt possible afin d’obtenir ses retours / analyser ses comportements.   Vouloir mettre en place des User Story très complexes. Dans ce cas, il est toujours préférable de développer une première US simple reprenant l’essence du besoin et de l’agrémenter de fonctionnalités lors de futurs cycles de développement.   Vouloir développer toute nouvelle idée lors du prochain sprint est une erreur récurrente. Même s’il est motivant de vouloir concrétiser une nouvelle idée, il est important d’identifier sa valeur ajoutée pour l’utilisateur. En fonction, le Product Owner l’ajoutera au backlog en faisant en sorte que les US prioritaires restent celles apportant le plus de valeur ajoutée.  

Daily meeting

  Le Daily meeting, aussi appelé Stand-up meeting, est une réunion très courte, de maximum 15 minutes. Elle a lieu tous les jours à une heure fixe.   Durant cette réunion, chaque personne de l’équipe de développement et de test présente son avancement et ses difficultés suivant ce canevas :  

• Ce que j’ai fait depuis le dernier daily meeting
• Ce que je vais faire dans les prochaines 24h
• Les difficultés que je rencontre (non obligatoire).
• Cette réunion est l’occasion de suivre l’avancement du projet et de
• La présence du client et du Product Owner au daily meeting est préférable mais n’est pas obligatoire.

Rétrospective

  La rétrospective a lieu à chaque fin de sprint.   Cette réunion rassemble uniquement les équipes de développement, de test, le Scrum Master et le Product Owner. Les événements ayant eu lieu au cours du sprint sont discutés lors de cette réunion : blocage, gain/perte de temps, choix techniques pris, etc.   Le but de cette réunion est de trouver, collectivement, des actions à mettre en place améliorer l’équipe et la gestion du projet.   Le client n’est pas convié à cette réunion.

Revue de sprint

  Le Product Owner fait, au client, une démonstration fonctionnelle des développements réalisés par l’équipe au cours du dernier sprint. Cette réunion est généralement réalisée dans les jours suivant la fin d’un sprint. Cette réunion est l’occasion pour le client de suivre l’avancée du projet.

Affinage

  L’« Affinage » est une réunion pendant laquelle l’équipe de développement estime le temps nécessaire pour réaliser des User Stories identifiées par le Product Owner.   Si une équipe de test est affectée au projet, elle participera à l’affinage et estimera le temps nécessaire pour faire les tests pour chacune des US.   Cette réunion est l’occasion pour les équipes de poser leurs questions au Product Owner et de lever des manquements dans les User Stories. L’affinage est réalisé régulièrement avant chaque début de sprint (recommandation : 2 jours ouvrés avant le début d’un nouveau sprint).   Si le client rédige des User Stories, il sera convié aux affinages pour présenter ses US et répondre aux questions.