Lorsque l’on doit expliquer la différence entre une méthode agile type Scrum et une méthode plus classique type cycle en V, on en revient souvent à dire que :
· l’agilité est plus souple
· le projet agile est piloté par la valeur
· le cycle en V n’est ni l’un ni l’autre
· Le cycle en V a un effet tunnel et accumule les retards.
Cette comparaison est très simplificatrice et laisse croire que les méthodes agiles, sont, en tout point, meilleures que le cycle en V. Ce n’est évidemment pas le cas ! Chaque méthode a ses forces et ses faiblesses.
Afin de bien comprendre les différences entre ces méthodes j’affectionne l’utilisation des exemples.
Voici l’exemple que j’ai choisi pour cet article :
Projet : construire un pont sur le Rhin afin de rejoindre les 2 rives et éviter aux automobilistes un détour de 10km (40 minutes aux heures de pointes).
Méthode cycle en V :
· On fait les plan et intervenir les architectes et on vérifie la conformité aux normes (durée : 6 mois).
· On commence la construction par les piliers (durée : 4 mois).
· On finit la construction, on vérifie l’ensemble des normes de construction (durée : 7 mois)
· On annonce l’ouverture et prépare l’arrivée des automobilistes (durée : 1 mois)
· Ouverture du pont
Bilan : Le projet dure 18 mois. Les automobilistes peuvent éviter leur détour au bout de 18 mois.
Méthode agile :
Attention, cela n’est pas forcément instinctif. Il faut revenir à la base. Quel est le souhait des automobilistes ? Le souhait n’est pas avoir un point ! Non, le souhait est de ne plus avoir à faire 40 minutes de trajet supplémentaire tous les matins.
Le projet de point en méthode agile serait donc comme suit :
· Faire venir (ou acheter) 1 ou plusieurs bateaux pour faire des allers-retours et permettre aux automobilistes de passer la rive (certes moins vite qu’avec un pont, mais beaucoup plus qu’en faisant le détour) (durée : 2 mois)
· On fait les plan et intervenir les architectes et on vérifie la conformité aux normes (durée : 6 mois)
· Pendant que les bateaux font leurs allers-retours et que de l’argent commence à rentrer, le pont est construit, en commençant par les piliers (durée : 6 mois car il ne faut pas déranger les bateaux).
· On finit la construction, on vérifie l’ensemble des normes de construction à chaque étape (durée : 9 mois, toujours pour ne pas déranger les bateaux)
· On annonce l’ouverture prochaine aux utilisateurs des bateaux (1 mois)
· Ouverture du pont.
Bilan : Le projet dure 24 mois soit 6 mois de plus que le cycle en V. Ce même projet coûte également plus cher car il a fallu acheter ou louer les bateaux. Par contre le service de traverser le fleuve a été rendu au bout de 2 mois au lieu de 18 (mais ont accès au pont au bout de 24 mois).
Conclusion :
A scope égal une méthode agile coûte plus cher que du cycle en V (notamment avec les tests qui demandent beaucoup plus de temps et d’investissements).
Par contre la méthode agile permet de proposer son offre plus tôt. Dans mon exemple, si 2 ponts sont construits par 2 entreprises différentes, il y a fort à parier que la méthode agile soit un gros avantage concurrentiel, les utilisateurs ayant pris l’habitude d’aller à cet endroit pour traverser le pont.
Chaque méthode a donc ses forces et ses faiblesses. Quel est l’intérêt de faire de l’agile s’il n’y a qu’une manière d’ouvrir le service et que le scope est le même dans tous les cas (ex : un satellite à envoyer dans l’espace) ?
Comme toujours, lorsqu’il y a un choix à faire il faut se demander pourquoi on fait ce choix et pas l’autre. Ce n’est pas parce que on parle moins de cycle en V en ce moment que cette méthode n’est plus efficace. N’oubliez jamais de réfléchir !
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
2 Responses
Intéressant mais il manque des éléments à prendre en compte à mon sens 🙂
En agile, une rentrée d’argent arrive plus rapidement et peut en parti couvrir les frais de la location des bateaux voir de dégager de la marge qui permette : en + de construire le pont. ET à minima le service est assuré via les bateaux si des problemes se poursuivent lors de la construction du pont. Dans l’autre cas, nous n’avons pas de plan B. Le cycle en V est alors un centre de cout car on a rien tant que le projet n’est pas fini contrairement à la deuxième version. Et si on se rend compte que la construction du pont est un gouffre, on peut itérer sur nos bateaux : des bateaux plus rapide ?, plus grand ? ….
Autre point, tant que le pont n’est pas entièrement fini, on n’est pas certain que notre hypothèse soit juste : est-ce que l’on aura vraiment suffisamment de traffic via le pont pour amortir son cout ? Et si c’est pas le cas, on a un pont qui a couté une fortune et qui se revele un gouffre financier : le feedback est trop tardif au final. Le but de l’agilité est de vérifier nos hypothèses beaucoup plus rapidement et s’adapter en fonction. Je commence petit, et si finalement cela se revele avoir de la valeur, on voit plus grand…