Les 2 principales lacunes du Waterfall model

Waterfall Model

Image via Wikipedia

Pour bien comprendre les méthodologies Agile, il faut tout d’abord comprendre leur place dans le monde de l’optimisation de la performance de travail d’une équipe. Dans ce premier billet, je vous présente la méthodologie communément acceptée comme étant le modèle de base du développement logiciel. Je vous fais part ensuite des problématiques inhérentes à ce modèle de développement. Ces réflexions sont nécessaires afin de voir les besoins pour de nouvelles méthodes de travail, de nouveaux concepts qui changeront à jamais la façon de faire d’une équipe de programmeurs.

Modèle de développement logiciel traditionnel (Waterfall model)

Traditionnellement, le cycle de développement et de livraison d’une application logicielle suit une liste d’étapes en ordre séquentiel. Cette façon de faire à l’avantage de fournir un plan de match définit dès le départ, ce qui résulte la plupart du temps en une gestion budgétaire plus précise pour le client, mais pas nécessairement pour l’équipe de développement. Voici les étapes principales du processus de développement logiciel dans ce contexte:

  1. Analyse des besoins avec le client (Requirement)
  2. Définitions des livrables, spécifications des fonctionnalités (Design)
  3. Établissement d’un budget et d’un échéancier (Planning)
  4. Début du cycle de développement: création d’une première fonctionnalité (Implementation)
  5. Validation et correction (Verification)
  6. Maintenance de cette fonctionnalité au fil du temps (Maintenance)

Typiquement, le processus recommence son cycle entre les étapes 4 à 6, jusqu’à ce que le logiciel soit livré au client. Suite à la livraison, chacune des mises à jour de développement suit à nouveau ces étapes. Ce modèle est plus connu sous le nom de «Waterfall model», dans lequel chaque composante du logiciel est développée séquentiellement, et menée à terme avant qu’une autre fonctionnalité ne soit programmée. C’est le modèle le plus souvent utilisé, mais il présente plusieurs lacunes importantes.

Problématiques liées au Waterfall model

Connaître les besoins du client

En général, l’analyse des besoins du client se fait conjointement avec lui, sur une période qui pourra varier considérablement et s’étendre parfois jusqu’à plusieurs semaines, voir plusieurs mois. Or, ce modèle Waterfall ne tient pas compte de la variable temps. Une fonctionnalité développée, testée puis livrée dans le logiciel arrivera à destination plusieurs mois après qu’elle ait été définie et pensée, pour répondre à un besoin au moment où l’analyse a été  faite. Cependant, et mon expérience de programmeur me l’a démontré trop souvent, la réalité du client peut changer rapidement. Ce modèle de développement ne tient pas compte des besoins changeants du client, de sa réalité d’affaire qui est en mouvement au fil du temps, et des technologies émergentes. Le résultat est que la fonctionnalité est bien livrée selon les spécifications initialement documentées, mais ne correspond plus nécessairement aux besoins réels du client. Plus la durée de vie de l’application est longue, plus le code source de celui-ci se trouve alors alourdi par des  fonctions et routines obsolètes et non-utiles.

Manque de flexibilité

Dans ce modèle de cascade où une fonctionnalité ne peut pas être implémentée n’importe quand et dépend des fonctionnalités précédentes, il n’est pas possible de «changer son fusil d’épaule facilement». C’est d’ailleurs la raison principale pourquoi les développeurs ou designers qui travaillent sur le projet détestent autant les demandes de changements. Ce modèle de Waterfall ne cultive pas le changement. Au contraire, il prône l’immobilisme. L’application n’est souvent pas utilisable par le client tant que tout (ou presque) ne soit terminé à 100%. Je le sais, j’ai été dans cette exacte position pendant de trop longues années. Notre équipe buchait sur le développement d’une application depuis des mois. Puis, le client, se rendant compte que tel ou tel formulaire ou processus n’était plus adéquat, nous envoyait une demande de changement. OUCH*!  Réviser du code vieux de plusieurs semaines alors que nous travaillions sur une nouvelle fonctionnalité. Un changement qui pourrait avoir un impact considérable sur une tonne d’autres fonctionnalités liées. Le cauchemar pour n’importe quel programmeur!

Réflexions

Le modèle de développement logiciel Waterfall est sans doute celui qui nous semble le plus naturel à adopter. Après tout, il est logique. Et instinctivement, c’est ce modèle que nous adoptons pour une foule de projets qui ne sont pas reliés  au développement logiciel. Nous embrassons  ce modèle pour préparer un week-end de camping, pour planifier nos vacances, pour se monter un classeur Excel, etc.

Dans ce billet, je vous ai expliqué quel était le modèle de travail le plus couramment utilisé en développement logiciel. Je vous ai ensuite montré ses deux principales lacunes. L’objectif de tout ça était de vous démontrer la pertinence d’être à la recherche d’un autre modèle de gestion de projet de développement logiciel. C’est en  faisant une rétrospective des projets auxquels j’ai participé dans les dernières années que je me suis mis à réfléchir sur ma façon de travailler. Pendant plus de 10 ans, j’ai souvent été une équipe de un, seul programmeur chez Oriso Solutions où j’évolue depuis 2001. Toutefois, depuis l’an passé, la synergie complète de l’équipe s’est orientée vers notre plateforme iGOvirtual. J’ai eu envie d’en faire plus, en moins de temps. J’ai eu envie d’optimiser non seulement ma façon de programmer, mais ma façon de voir mon rôle de programmeur au sein de notre beau projet. Et c’est quelque part en 2010 que je me suis mis à réfléchir pour rechercher des façons d’optimiser mon travail.

Dans un prochain billet, nous verrons comment j’ai découvert ces autres méthodologies de travail que l’on appelle Agile.

Et vous, avez-vous vécu des expériences où le modèle Waterfall vous limitait? Au contraire, arrivez-vous à bien vous en sortir sur des projets à long termes en utilisant cette méthodologie? Faites-nous en part dans les commentaires!

Publicités
Tagué , , ,

7 réflexions sur “Les 2 principales lacunes du Waterfall model

  1. […] de mon précédent billet, j’ai décrit les deux principales lacunes du modèle traditionnel de développement logiciel, la méthode […]

  2. […] Les histoires sont une composante essentielle à la méthodologie Scrum. Elles offrent une valeur réelle tant pour les développeurs que pour le client lui-même. La liste des histoires, grandissante avec le temps, donne après quelques mois une image très nette et très belle de l’évolution du produit, mais également de l’évolution des besoins et des désirs de l’utilisateur final. Ceci est une donnée très importante que ne peut pas nous fournir les modèle plus statiques de développement comme la méthode Waterfall. […]

  3. […] d’itérations permet de briser le cycle lourd et long de la méthode Waterfall dans laquelle des semaines et des mois peuvent passer entre la livraison de deux mises à jour du […]

  4. […] a été cruciale dans ma métamorphose. C’était la pédale de frein, si je peux dire, au modèle Waterfall que nous utilisions depuis si longtemps. C’est parce que j’ai commencé à dire NON aux […]

  5. […] le savoir, je débutais mon projet en reproduisant fidèlement le modèle Waterfall, celui-là même qui avait fait en sorte que les produits commerciaux que nous avions évalués […]

  6. […] de mon précédent billet, j’ai décrit les deux principales lacunes du modèle traditionnel de développement logiciel, la méthode […]

  7. […] de mon précédent billet, j’ai décrit les deux principales lacunes du modèle traditionnel de développement logiciel, la méthode […]

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Publicités
%d blogueurs aiment cette page :