Réalisation : Méthodes agiles ou méthodes classiques

Méthodes agiles - Méthodes classiques

Méthodes agiles – Méthodes classiques

Aujourd’hui, lorsqu’on démarre un projet informatique, un chef de projet a, à sa disposition, plusieurs types de méthodes de développement. En-dehors du fait d’être connue ou pas du chef de projet et de l’équipe projet, chacune de ces méthodes présente des avantages et des inconvénients qu’il convient de connaître pour faire le choix le plus pertinent pour la réussite du projet.

Dans cet article, nous n’allons pas faire une présentation exhaustive de toutes les méthodes de développement existantes. En fait, nous allons nous concentrer sur les deux grandes familles de méthodes existantes aujourd’hui : l’approche classique avec le fameux cycle en V et l’approche agile avec des méthodes comme SCRUM.

L’approche classique

L’utilisation de l’approche classique et du cycle en V remonte aux origines de l’informatique. En fait, cette approche est calquée sur les méthodes de gestion de projets dans l’industrie lourde utilisée dans les années 50-60 où il était indispensable que les différentes tâches du projet se succèdent étant donné le manque de souplesse dans la réalisation de certaines tâches.

Maintenant, il faut reconnaître que c’est une méthode assez simple à mettre en oeuvre et très efficace dans la pratique. En effet, le fait qu’elle soit constituée de phases successives permet, d’une certaine manière, de sécuriser la réalisation de l’ensemble du projet, chaque phase ne commençant qu’à partir du moment où la phase précédente est finalisée ou quasiment finalisée.

Les différentes phases du « cycle en V » sont, dans l’ordre :

  • L’expression des besoins : Cette phase consiste à recueillir l’ensemble des besoins des utilisateurs.
  • Les spécifications fonctionnelles : Cette phase consiste à définir, de manière aussi précise que possible, toutes les fonctions et contraintes associées qui se retrouveront dans la réalisation finale
  • Les spécifications techniques : Cette phase consiste à définir, de manière aussi précise que possible, les réponses techniques qui seront apportées à chaque spécification fonctionnelle
  • Le développement/la réalisation : Cette phase correspond à la réalisation technique du projet
  • Les tests unitaires : Cette phase consiste à valider la réalisation technique par rapport aux spécifications techniques
  • Les tests d’intégration : Cette phase consiste à valider la réalisation technique par rapport aux spécifications fonctionnelles
  • La recette applicative : Cette phase consiste à valider la réalisation technique avec les utilisateurs.

Si le cycle en V est rassurant à utiliser dans le sens où il marque bien un début, une fin et une progression, son application dans les faits est souvent assez différente.

Ainsi, si vous réalisez un projet en lots, vous pourrez alors intégrer chaque lot dans un « cycle en V » et votre projet pourra être vu, au final, comme une succession de « cycles en V ». Mais, il est aussi fort probable que vous ayez été en mesure de lancer plusieurs lots en parallèle et dans ce cas, vous allez devoir superposer vos « cycles en V ».

De plus, une fois le projet livré, il est probable que celui-ci reçoit des demandes d’évolutions sous la forme d’une maintenance corrective ou sous la forme d’un nouveau projet. Et, dans ce cas, vous vous retrouverez à gérer de nouveaux « cycles en V ».

Enfin, une fois la phase de recette applicative terminée, il vous faudra vous occuper de la mise en production et en exploitation de votre projet et donc prendre en charge et gérer d’autres tâches qui ne font pas partie du « cycle en V ».

Aussi, si de manière générale, on parle de « cycle en V », ceci relève d’un abus de langage, car ce n’est pas un véritable cycle figé et absolu. En fait, il vaut mieux parler de méthode en V ; ce qui permet d’envisager son utilisation dans d’autres cadres.

De manière générale, les trois principaux avantages de la méthode en V sont :

  • Une méthode connue de tous (ou presque) et simple à mettre en oeuvre.
  • Une méthode qui peut convenir à tous les types de projets.
  • Une méthode qui dispose d’un formalisme bien défini qui facilite le suivi du projet.

Les trois principaux inconvénients de la méthode en V sont :

  • Les besoins des utilisateurs doivent être clairement connus et énoncés dès le début du projet sinon il est impossible de réaliser les spécifications fonctionnelles et techniques
  • Des difficultés dans la prise en compte des évolutions des demandes des utilisateurs pendant la réalisation du projet (la remise à jour des spécifications alors qu’on est dans la phase de réalisation ne sera jamais simple à gérer).
  • Un nécessaire formalisme assez poussé pour réussir.

L’approche agile

Les méthodes agiles sont des méthodes qui sont apparues, il y a de cela de nombreuses années, pour principalement s’affranchir de la « rigidité » de la méthode en V notamment au niveau de la prise en compte des besoins des utilisateurs.

Cette méthode a surtout pris son envol avec l’explosion des développements web pour lesquels il fallait produire de nouvelles applications sans se baser sur un existant et sans savoir vraiment comment serait l’application finale. On partait d’une idée générale et au fur et à mesure de réalisations successives, on arrivait à l’idée finale.

En fait, les méthodes dites agiles s’apparentent à des méthodes itératives dans lesquelles les fonctionnalités et donc les besoins des utilisateurs seraient affinés au niveau de chaque itération.

La mise en place de ce type de méthode nécessite d’avoir :

  • Une équipe projet capable de travailler sans cahier des charges bien défini
  • Des animateurs de projets, aussi bien au niveau technique qu’au niveau fonctionnel, capable d’entraîner l’équipe projet et surtout capable de faire évoluer rapidement le projet en fonction des besoins et des attentes des utilisateurs.
  • Une réactivité très forte des utilisateurs pour apporter des compléments d’informations à l’équipe projet.
  • Une forte capacité à se remettre en cause régulièrement pour, éventuellement, revoir complètement certaines parties déjà réalisées.
  • Le découpage du projet en phases courtes (de 1 à 4 semaines) représentant chacune un « run » avec des objectifs fonctionnels à atteindre ; le travail réalisé devant être finalisé et testé lorsqu’on arrive à la fin de chaque « run ».

De manière générale, on recommande souvent à ce que l’équipe projet soit totalement isolée des autres équipes informatiques et fonctionnelles de l’entreprise afin que celle-ci n’ait pas d’interférences avec l’extérieur qui remettraient en cause la réalisation des différents « runs ».

De manière pratique, ce type de fonctionnement n’a aucun intérêt si le projet est bien défini dès le départ ; c’est-à-dire s’il dispose d’un cahier des charges complet. De même, pour les projets ayant de nombreuses contraintes dès le départ, ce type de méthode fonctionne généralement assez mal, car la réactivité attendue sera beaucoup trop contrainte.

De manière générale, les trois principaux avantages de la méthode en V sont :

  • Une méthode adaptée aux projets contenant une partie d’incertitudes sur les besoins réels des utilisateurs.
  • Une méthode qui permet de rapidement avoir des résultats et donc de rapidement pouvoir se positionner sur la suite du projet.
  • Une méthode qui bien adaptée aux nouveaux projets.

Les trois principaux inconvénients de la méthode en V sont :

  • Une méthode qui nécessite d’avoir une équipe projet apte à la mettre en oeuvre
  • Une méthode qui repose énormément sur les capacités des personnes qui vont animer le projet.
  • Une méthode qui ne s’adapte pas très bien aux projets de maintenance ou d’évolution fonctionnelle d’un existant

Au final méthode en V ou méthode agile ?

La réponse la plus simple consiste à dire que si le contenu du projet est bien défini, la méthode en V est la méthode la plus pertinente. Si le contenu du projet est plus vague et s’il est possible d’avoir une équipe projet adaptée alors, la méthode agile sera la plus pertinente. Maintenant, il ne faut pas être complètement dogmatique pour une méthode ou une autre. En fait, il faut savoir parfois faire des mélanges entre les différentes méthodes en fonction des tâches à réaliser et des personnes concernées dans l’équipe projet. De cette manière, il devient possible d’avoir les avantages des deux méthodes tout en limitant leurs inconvénients.

Ce contenu a été publié dans Réalisation, avec comme mot(s)-clé(s) , , , . Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *