Les méthodes agiles : méthodes de gestion de projet informatique [#2/6]

InfleXsys Les méthodes agiles : méthodes de gestion de projet informatique

Pour commencer, on parle de "la méthode Agile", mais en réalité, il y a des méthodes agiles qui ont toutes pour origine le Manifeste Agile : celui-ci a été rédigé en 2001 par un comité d’experts et énumère des principes clés permettant de « mieux développer des logiciels ».

Le manifeste valorise en particulier :

  • « les individus et leurs interactions plus que les processus et les outils ;
  • des logiciels opérationnels plus qu’une documentation exhaustive ;
  • la collaboration avec les clients plus que la négociation contractuelle ;
  • et l’adaptation au changement plus que le suivi d’un plan »*.

 

Objectifs des méthodes agiles

Les méthodes dites « agiles » ont pour objectif d’améliorer la productivité des équipes de développement et répondent aux problématiques induites par les méthodes traditionnelles qui s’appuient sur un cycle de développement en V ou sur un cycle en cascade. Voyons pourquoi et comment :

Modèle du cycle en cascade (hérité du BTP)**

Méthodes Agiles versus Méthodes traditionnelles en V ou en cascade
Développement informatique : méthode traditionnelle en cascade

Dans cette approche, les étapes sont effectuées les unes après les autres (de la même manière qu’on ne peut construire la toiture d’une maison avant ses fondations).

Ici, tout est anticipé et planifié dans un cahier des charges, c’est pourquoi on parle aussi de « méthode prédictive ».

Le client ne voit la solution que lorsque l’intégralité des fonctionnalités répondant aux exigences initialement définies ont été développées et testées.

 

 

 

Modèle du cycle en V**

Méthodes Agiles versus Méthodes traditionnelles en V ou en cascade
Développement informatique : méthode traditionnelle en V

Ici, les étapes sont également effectuées de manière séquentielle les unes après les autres, mais ce modèle permet en cas d’anomalie détectée, de limiter le retour aux étapes précédentes : chaque étape de la ligne ascendante correspond en effet à une étape de la phase descendante.

Ce modèle offre un peu plus de réactivité que le modèle en cascade, sans toutefois résoudre la problématique de réduction du délai entre l’analyse des besoins initiale et la recette.

 

 

 

 

Le grand défaut de ces méthodes traditionnelles est en effet la lenteur avec laquelle elles permettent de produire une application que l’on peut mettre entre les mains d’utilisateurs (elles n’impliquent d’ailleurs pas les utilisateurs en cours de développement) et le manque de réactivité en cas de modification ou d’anomalie détectée (les tests interviennent trop tard dans le processus).

 

Projet de développement d’application mobile : pourquoi s’appuyer sur une méthode Agile

Dans le cadre de projets mobiles, on peut difficilement s’appuyer sur les méthodes de développement classiques : car aujourd’hui tout va très vite. Les directions Métier sont soumises au rythme effréné auquel le marché évolue (rythme souvent imposé par les clients dont les exigences ne cessent d’augmenter). On ne peut donc pas imaginer qu’il se passe plusieurs mois entre l’expression des besoins et la mise en production d’une solution.

Pour répondre à cette problématique, la majorité des équipes de développement utilise donc les méthodes agiles qui reposent sur un cycle de développement « itératif, incrémental et adaptatif » :

  • itératif car le processus de développement (codage, tests) est appliqué plusieurs fois sur des portions de l’application ; chacun de ces « micro-cycles » de développement donnant lieu à une « recette », c’est à dire à la présentation au client (ou aux utilisateurs) d’une partie fonctionnelle du logiciel attendu ;
  • incrémental car chacune des itérations vient compléter la portion d’application développée sur le cycle précédent (sans remettre en question le code : on dit qu’il n’y a pas de « régressions »).
  • et adaptatif car les méthodes agiles prennent en compte l’évolution naturelle des besoins des clients et considèrent que dans un projet de développement, tout ne peut pas être anticipé. Il ne s’agit évidemment pas de remettre en question l’expression initiale des besoins, mais plutôt de tenir compte des remontées qui sont faites par l’utilisateur à l’occasion du test d’une version intermédiaire de l’application (issue d’une incrémentation) : la mise en situation peut en effet l’amener à faire évoluer sa demande initiale ; ce qui peut induire une adaptation du développement dans les itérations suivantes.

En réalité, les principes émis par le Manifeste Agile ont été sujets à bien des interprétations. Ce qui fait qu’il existe plusieurs variantes de méthodes agiles, dont la plus connue et la plus utilisée est Scrum.

Cette variante se caractérise par un jargon bien particulier ; elle s’appuie par exemple :

  • sur des réunions quotidiennes appelées « scrums » (« scrum » en anglais signifie « mêlée », comme au rugby) réunissant toute l’équipe de développement,
  • sur des cycles de développement appelés « sprints »,
  • et sur 3 acteurs principaux que sont : le(s) développeur(s), le product owner (propriétaire du produit, c’est-à-dire en général le chef de projet, côté utilisateurs ou client) et le scrum master (chef de projet aussi, mais cette fois du côté de l’équipe de développement).

 

Pour en savoir + :

 

Vous avez un projet de développement d'application mobile ? N’hésitez pas à nous contacter.

 

Sources

* Manifeste Agile : http://agilemanifesto.org/iso/fr/manifesto.html

** Schémas issus de l'article Wikipedia : https://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement_(logiciel)

 

Articles similaires