Découverte de la méthode AGILE

Découverte de la méthode Agile

 

2001 fût l’année de la création du Manifeste Agile qui est un document créé par plusieurs développeurs d’applications qui cherchaient un nouveau moyen de travailler trouvant que le mode « Cycle en V » ne répondaient plus aussi bien aux attentes des organisations.

Ces dernières années, la méthode Agile est de plus en plus mise en place au sein des entreprises (pas seulement en informatique).

 

1. Les principes de l’agilité

Il existe 12 principes fondamentaux :

  • La satisfaction client est la priorité
  • Savoir accueillir les demandes de changement
  • Apporter régulièrement des versions opérationnelles
  • Créer une coopération permanente entre le Client et l’équipe projet
  • Avoir une équipe composée de membres motivés
  • Privilégier le dialogue en face à face
  • Mesurer l’avancement du projet avec les fonctionnalités de l’application
  • Travailler à un rythme constant et soutenable par tous les acteurs
  • Porter une attention continue à l’excellence de la conception ainsi qu’à une bonne qualité technique
  • Privilégier la simplicité en évitant le travail inutile
  • Responsabiliser au plus les équipes
  • Améliorer l’efficacité, le comportement, les processus de l’équipe à intervalles réguliers afin d’être plus efficace

 

2. Les acteurs

On peut définir les acteurs en 3 groupes distincts.

2.1) Product Owner

Le Product Owner appelé aussi régulièrement PO, est la personne qui fait le lien entre le client et l’équipe. Il récupère les besoins exprimés par le client et les soumet à l’équipe à l’aide du Backlog. C’est un membre de l’équipe qui sera sollicité lors des réunions Agile afin d’avoir des précisions sur les différentes tâches à réaliser (appelées User Story).

2.2) L’équipe de développement

C’est elle qui réalise les développements au sein du projet.

2.3) Scrum Master

Le synonyme de Scrum Master en français est « facilitateur ». C’est le garant de la méthodologie SCRUM. Le Scrum Master est là pour aider l’équipe à avancer en cherchant des moyens de l’améliorer. Il n’est pas considéré comme un supérieur mais plutôt comme un coach et s’assure que le PO et l’équipe se comprennent bien et arrivent à travailler ensemble.

 

3. Les Sprints

Un Sprint au sein d’un projet Agile est l’intervalle de temps durant laquelle les différents acteurs vont concevoir, tester et livrer les nouvelles fonctionnalités. La durée se définit avec tous les acteurs (généralement elle est de 2 semaines mais peut aller jusqu’à 1 mois).

3.1) Sprint Planning

Au début d’un Sprint, il y a ce que l’on appelle le Sprint Planning. Lors de cette cérémonie, le PO va présenter le Backlog à l’ensemble de l’équipe. Ce Backlog est constitué de Story (la Story est une définition d’une fonctionnalité). Ces Story sont au préalable priorisées par le PO et elles ont déjà été « pesées » par l’équipe pour lui donner un poids (qui va correspondre au temps que l’on pense passer dessus) lors de ce que l’on appelle le Poker Planning. L’équipe, en fonction de sa vélocité (elle représente la charge que l’équipe peut consommer au sein d’un Sprint), va définir le nombre de Story à réaliser lors de ce Sprint (on dit aussi qu’elle s’engage à réaliser).

3.2) Daily

Tous les jours durant le Sprint, il y a ce que l’on appelle le DSTUM (Daily STand Up Meeting). Cette réunion a pour but de définir pour chaque acteur qu’est ce qui a été fait la veille, quels sont les éventuels points de blocage et sur quoi nous allons travailler aujourd’hui.

3.3) Sprint Review

Le Sprint Review se déroule à la fin du Sprint. Lors de cette cérémonie, l’équipe montre tout ce qui a été fait. Cela permet au client d’avoir un visuel, de voir ce qui a été fait de façon concrète. L’autre avantage est qu’il peut donner directement son ressenti sur ce qui a été réalisé à l’équipe de développement.

3.4) Rétrospective

Pour finir, nous avons la Rétrospective. Cette cérémonie permet de faire un retour sur le Sprint qui a eu lieu. Chacun va donner son ressenti sur le Sprint, dire ce qu’il a aimé, ce qu’il a moins aimé et pourquoi. Cela permet de déceler ce qui a pu poser problème et quels sont les axes d’améliorations à mettre en place afin que le prochain Sprint se déroule mieux. C’est pourquoi, en général, l’équipe va essayer de définir des actions SMART à réaliser.

SMART, qui signifie intelligent en anglais, est un acronyme qui signifie : Specific, Measurable, Assignable, Realistic, Time-related.

Specific : L’action doit être la plus précise possible, pour qu’elle puisse être atteignable.

Measurable : L’action doit être mesurable (quantifiable). On doit être capable de définir combien de temps cela va prendre.

Assignable : L’action doit être attribuée à une personne qui sera en charge de mettre en place cette action.

Realistic : L’action doit être réaliste. Cela ne sert à rien de partir sur une action qui ne pourra être réalisée.

Time-related : L’action doit avoir une date butoir où elle devra être mise en place. Cela permet d’éviter de repousser l’action à un autre moment.