Business people working on desktop computer

Lire cet

article

de blog

Agile VS Waterfall, quelle méthode choisir pour son projet ?

Publié le 19 janvier 2016

0 commentaire Categories : Blog Ecrit par : Cloé Legoubé

Vous avez entendu parler des méthodes Agiles, très populaires dans le milieu informatique ?  Mais Waterfall a aussi fait ces preuves dans d’autres entreprises et vous ne savez plus quelle méthode choisir ? Nous allons deux manières d’aborder la gestion de projet et comment départager les deux : Waterfall versus Agile. Gestion de projet agile ou approche […]

Business people working on desktop computer

Vous avez entendu parler des méthodes Agiles, très populaires dans le milieu informatique ?  Mais Waterfall a aussi fait ces preuves dans d’autres entreprises et vous ne savez plus quelle méthode choisir ? Nous allons deux manières d’aborder la gestion de projet et comment départager les deux : Waterfall versus Agile.

Gestion de projet agile ou approche traditionnelle en « cascade », quelle méthode choisir ?

La méthode agile, tout le monde ou presque ne parle presque plus que de ça dans le petit milieu de la gestion de projet. Derrière ce terme, avouons-le, parfois fourre-tout, se cache pourtant une manière réellement novatrice et efficace d’aborder la conduite de projet.

Pourtant, la gestion de projet plus classique, dite en cascade, a durant de nombreuses années, elle aussi, fait ses preuves. Prenons garde à ne pas être éblouis par les phares aveuglants de la nouveauté. A quoi bon renier la tradition, surtout lorsqu’elle a réussi à traverser aussi solidement l’épreuve du temps ?

Alors plutôt « réac » ou « rad-soc’ » ? Devant ce choix de rupture cornélien, vous êtes perdus ? Essayons donc de gratter soigneusement les étiquettes et examinons d’un peu plus près les tenants et aboutissants de chacune de ces deux approches. Comme bien souvent, tout n’est pas tout noir ou tout blanc. En premier lieu, tout est une question de contexte et il est important d’apprendre à reconnaître sur quel type de terrain vous allez être amené à évoluer. Attention aux dérapages non contrôlés !

Agile et sa philosophie

Pour commencer il faut clarifier un point : Agile est une philosophie sur le développement de logiciel, et non pas une méthodologie sur laquelle repose l’application d’un processus. Agile est un manifeste.

Quelles sont les quatre valeurs fondamentales à privilégier en gestion de projets ?

Conformément aux 4 règles fondamentales d’une gestion de projet Agile, on privilégiera :

  • Les individus et leurs interactionsplutôt que les processus et les outils.
  • Un logiciel qui fonctionneplutôt qu’une documentation exhaustive.
  • Une collaboration avec les clientsplutôt qu’une négociation contractuelle.
  • L’adaptation au changementplutôt que le suivi d’un plan.

Douze principes à ne pas oublier pour une gestion de projet réussie :

  1. La plus importante de vos priorités est de satisfaire votre client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée.
  2. Accueillez positivement les changements de besoins, même tardivement dans l’avancée du projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
  3. Livrez fréquemment un résultat progressif avec des cycles de quelques semaines à quelques mois et une préférence pour les échéances courtes.
  4. Les utilisateurs, ou leurs représentants, ainsi que vos développeurs doivent travailler ensemble quotidiennement tout au long du projet.
  5. Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement de travail et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  6. La méthode la plus simple et la plus efficace pour transmettre l’information à votre équipe de développement reste le dialogue en face à face.
  7. Ayez et utilisez un logiciel adapté pour mesurer l’état d’avancement de votre projet.
  8. Les processus agiles encouragent un rythme de développement qui doit pouvoir être respecté. Ensemble, les commanditaires, les développeurs et les utilisateurs doivent pouvoir maintenir sur la longueur un rythme constant.
  9. Veillez continuellement à ce que le travail réalisé soit d’excellente qualité, autant d’un point de vue technique que visuel.
  10. La simplicité est de rigueur. Minimiser la quantité de travail inutile ou superflue est essentielle.
  11. Laissez vos équipes respirer : les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
  12. Donnez la parole aux experts : à intervalles réguliers, votre équipe doit pouvoir se réunir et réfléchir aux moyens de devenir plus efficace, puis modifier son comportement en conséquence.

(Sources : wikipedia)

Ces principes apportent une vision cohésive au développement de logiciels ou de services informatiques. Il existe de nombreuses méthodes (citons Scrum ou Kanban) qui essayent d’intégrer Agile à l’intérieur d’un process de « jalonnement » selon un modèle d’étapes à suivre. Mais aucune d’entre elles ne parvient à tirer la véritable quintessence d’Agile.

Le comparatif

A l’opposé, il y a la gestion en cascade (en anglais Waterfall), un modèle à suivre pour tout développement logiciel classique. Ici, pas de manifeste ou de principe; cependant, comme Agile et Waterfall apparaissent souvent en contradiction, les principes du modèle en cascade sont à l’opposé de ceux d’Agile.

Ainsi nous pouvons comparer Agile et Waterfall de cette manière :

– parler des mérites d’Agile qui sont ne pas compatibles avec Waterfall

– passer en revue les bénéfices et inconvénients de Waterfall comparativement à la méthode Agile.

Le développement de services informatiques remet en question des décennies de gestion de projet. La plupart des industries ont besoin de procédés linéaires. En général, les étapes se suivent les unes après les autres. Ces étapes sont réalisées maintes fois par des centaines d’entreprises. Waterfall convient parfaitement à ce type de gestion de projet.

Pour le développement de logiciel, cela fonctionne différemment : il s’agit d’un apprentissage, d’une découverte, d’une capacité à commencer quelque chose sans savoir s’il y aura une finalité. A partir de ce postulat, il est logique de découper le problème en sous-problèmes. Ainsi, lorsqu’on s’attaque à un projet de développement, il vaut mieux le fractionner en plusieurs petits milestones à franchir(ou jalons).

Agile présente l’avantage d’être flexible : toutes les parties étant sollicitées, des changements peuvent être rapidement intégrés au projet. Néanmoins, comme le degré de sollicitation, d’implication est élevé, le projet peut devenir très prenant. Certains acteurs du projet prennent parfois un rôle central si bien que si l’un d’entre eux quitte le navire avant la fin du projet, les autres passagers s’en retrouvent lésés, causant un véritable problème pour l’avancement du projet.

A contrario, Waterfall, permet d’estimer précisément le budget et l’emploi du temps d’un projet.

Néanmoins sa rigidité est un problème et il est très difficile de changer la trajectoire d’un projet lancé en mode Waterfall.

 

Le degré d’incertitude : l’élément clé pour choisir votre méthode

Au début de chaque projet, il faut identifier les tenants et les aboutissants, les problèmes et la manière de les résoudre. Sont ainsi définis le cahier des charges, les tâches, les users stories, et tous les aspects spécifiques au projet qui sont également à prendre en compte. Parfois les parties prenantes ont les idées claires sur leurs besoins, les enjeux, les problèmes et autres facteurs de complexités du projet, mais souvent elles n’ont qu’une vague idée de ce qu’elles veulent, notamment parce qu’elles ne parlent pas le même langage technique. Cette variable joue un rôle important dans l’évaluation du degré d’incertitude d’un projet.

Il faut donc tenter de lever le voile sur certaines zones d’ombres et se poser les bonnes questions :

  • L’équipe a-t-elle des problèmes précis à résoudre ?
  • L’équipe dispose-t-elle des moyens pour les résoudre ?
  • L’équipe a-t-elle déjà résolu des problèmes similaires ?
  • Quelqu’un a-t-il déjà résolu ces problèmes ?
  • L’équipe peut-elle en discuter avec cette personne pour qu’elle partage son expérience ?
  • Les problèmes sont-ils susceptibles d’évoluer avant le début du projet ou en cours de projet ?

Toutes ces données permettent de qualifier et positionner le projet par rapport à son « degré d’incertitude », et, en conséquence, la magnitude des risques qui en résultent. Le principe est simple : plus le projet avance, moins l’incertitude est grande. Avant le début du projet, l’incertitude est à son maximum pour les parties prenantes car celui-ci n’a pas encore pris forme. A l’inverse, à la fin du projet, quand tout a été accompli, plus aucune incertitude ne demeure. Ainsi tout au long du projet, l’incertitude peut se modéliser par une courbe décroissante.

L’incertitude…Voici donc l’élément clé !

Le choix entre Agile et Waterfall doit se faire en fonction du degré d’incertitude. Si la majorité des problèmes est connue dès le début du projet et que ceux-ci ne sont pas susceptibles d’évoluer selon l’avancement du projet, cela signifie que le degré d’incertitude est faible. Ainsi Waterfall est la meilleure solution pour mener à bien ce projet.

Dans le cas contraire, si les problématiques sont vagues et non définitives, alors Agile est la solution. Néanmoins un travail interne est à mener : chaque organisation doit définir le degré d’incertitude que les membres sont prêts à assumer.

Il est finalement impossible de comparer la qualité des approches Agile et Waterfall puisque les 2 méthodes s’adressent à des projets et des enjeux différents :

Nous conseillons Waterfall pour des projets statiques, contrairement à Agile, lequel conviendra mieux à des petits projets évolutifs.

Il est d’une importance capitale que chaque organisation arrive à définir l’approche qui fonctionnera le mieux en interne et qui permette de créer une cohésion réelle et durable entre les membres de leur équipe-projet.

Laisser un commentaire

Votre adresse email ne sera pas publiée

Pour écrire votre message, vous pouvez utiliser ces attributs et tags HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>