Le mode agile est de plus en plus utilisé aujourd’hui, notamment la méthode Scrum. Mais de quoi s’agit-il ? Découvrez la description d’une procédure générique utilisée chez AViSTO pour mieux comprendre.

Sommaire :

• Qu’est-ce que la méthode agile ?
• Méthode agile scrum exemple

Qu’est-ce que la méthode agile ?

Les méthodes agiles s’opposent aux méthodes traditionnelles de gestion de projet, perçues comme trop rigides. Le terme « agile » est consacré par le Manifeste pour le développement agile de logiciels en 2001. Il s’agit d’un texte rédigé par dix-sept experts du développement d’applications informatiques estimant que le cycle de développement en cascade ne permet plus d’obtenir des résultats satisfaisants. Les méthodes agiles consistent à impliquer largement le client et offrent une grande flexibilité. En effet, par une planification à court terme, elles permettent de s’adapter aux imprévus et aux demandes du client.

Les méthodes agiles sont pensées pour valoriser :

• Un logiciel opérationnel plus qu’une documentation exhaustive
• L’adaptation au changement plus que le suivi d’un plan
• Les individus et leurs interactions plus que les processus et les outils
• La collaboration avec les clients plus que la négociation contractuelle

La plus haute priorité de l’équipe Scrum est de satisfaire son client en livrant rapidement et régulièrement des fonctionnalités à valeur ajoutée pour le logiciel.

Les méthodes agiles exploitent le changement pour en faire un avantage. Pour cela, le client et l’équipe doivent travailler ensemble tout au long du projet.

Voici un rapide descriptif de la méthode utilisée par AViSTO pour répondre à ces objectifs.

Le mode Agile et la méthode SCRUM

AViSTO utilise l’une des méthodes agiles les plus connues : la méthode Scrum. Elle est constituée de :

• 3 rôles (Product Owner, Scrum Master et Equipe de Développement)
• D’artefacts (Product Backlog, Sprint Backlog, Burndown Charts)
• Des timeboxes
• Des règles et des outils

Pour Marius, ingénieur JAVA chez AViSTO, la méthodologie Agile est composée d’un ensemble de bonnes pratiques qui permettent de rapprocher les développeurs et les demandeurs (ex : les clients). La qualité du code produit est ainsi améliorée, tout en offrant la visibilité et la transparence nécessaires. Scrum est plus un cadre autour de la méthodologie Agile qui définit les règles du jeu afin que les parties impliquées se retrouvent tout au long du projet. Cette visibilité est nécessaire des 2 côtés : les développeurs et les clients ont besoin de valider que le projet va continuellement dans le bon sens. Selon lui, c’est un « générateur de confiance ».

Voici, concrètement, comment fonctionne la réalisation d’un projet en méthode Scrum.

L’équipe Scrum : rôles

Product Owner

Un ingénieur de l’équipe ou le client peut tenir le rôle de Product Owner. Ses responsabilités concernent la gestion du Product Backlog ; autrement dit, de l’ensemble des fonctionnalités à réaliser.

Scrum Master

L’un des membres de l’équipe a le rôle de Scrum Master. Il est le garant du respect de la méthodologie. C’est généralement le chef de projet (qui a la responsabilité de la tenue des réunions de pilotage) mais cela n’est pas obligatoire.

Equipe de Développement

L’équipe de développement est l’équipe AViSTO.

La caractéristique principale d’une équipe Scrum est qu’elle est auto-organisée. En particulier, il n’y a pas de responsabilité hiérarchique, même vis-à-vis du Scrum Master. L’équipe entière est ainsi responsable de la réalisation, et non chaque individu en fonction de ses compétences particulières.

Elle participe activement à la gestion du Sprint Backlog.

Artifacts

Product Backlog

Le Product Backlog est une liste ordonnée par importance (par rapport à la valeur fonctionnelle estimée pour les utilisateurs) de travaux à réaliser (aussi appelés « user story ») pour créer et maintenir le produit. Cette liste est gérée par le Product Owner. L’équipe AViSTO estime chaque « user story » en charge (Jours-Hommes).

Sprint Backlog

Le Sprint Backlog est la liste des travaux prévus pour un sprint et son suivi. Le Sprint Backlog est géré par l’équipe de développement. Un simple tableau et des post-its peuvent être utilisés en tant que Sprint Backlog. AViSTO utilise un outil web.

Burndown Charts

Les Burndown Charts sont des diagrammes de suivi de l’activité par sprint. Il s’agit d’un outil de pilotage important pour l’équipe de développement.

Timeboxes

Les timeboxes représentent les évènements ou les slots de temps prévus tout au long du projet. On peut citer les sprints (unité de temps), les sprint plannings (réunions pour définir les user stories), les daily scrums (réunions journalières de l’équipe de développement) etc.

Gestion de Projet

En dehors de ces timeboxes purement Scrum, le pilotage et la gestion du projet s’appuient sur deux instances :

• Le Comité de projet qui gère le suivi opérationnel de l’avancement du projet
• Le Comité de pilotage qui s’occupe de la gestion du contrat, du projet et des arbitrages

Suite à chaque réunion est préparé un compte-rendu intégrant le résumé des décisions prises et un plan d’actions détaillé rédigé par le chef de projet AViSTO et validé par le client.

Le compte-rendu s’appuie sur un tableau de bord projet qui permet de consolider et d’archiver différents éléments (liste des intervenants, journal du projet, liste des entrées attendues et leur suivi etc.).

Les informations du tableau de bord permettent d’identifier les risques de dérives et d’enclencher des alertes projets, qui donneront lieu à des actions préventives dont la mise en œuvre est suivie lors des points d’avancement (Comité de projet).

Règles et Outils Méthode Scrum

Suivi du Product Backlog et du Sprint Backlog

AViSTO utilise un outil web pour le suivi du Product Backlog et du Sprint Backlog. Cet outil très simple et rapide d’utilisation permet de partager efficacement l’information.

Test Driven Development

AViSTO met en place une réalisation Test Driven Development lorsque le projet s’y prête.

Cela signifie que les tests sont écrits avant l’implémentation des règles.

Le cycle de développement préconisé par Test Driven Development comporte cinq étapes :

• Ecrire un premier test
• Vérifier qu’il échoue (car le code qu’il teste n’existe pas), afin de vérifier que le test est valide
• Ecrire juste le code suffisant pour passer le test
• Vérifier que le test passe
• Refactoriserle code, c’est-à-dire l’améliorer tout en gardant les mêmes fonctionnalités

L’intérêt de cette méthode est de s’assurer, pour des exigences fonctionnelles complexes, que le test a bien été écrit par rapport au besoin et non par rapport au résultat du développement. On s’assure ainsi de disposer de tests de non-régression efficaces.

Le code de l’outil est plus sûr et plus fiable à l’aide de cette méthode.

Une question ? Un projet à nous soumettre ? N’hésitez pas à nous contacter !