Voici un article pour tous ceux qui désirent bien comprendre la différence entre Scrum vs Cycle en V. Pour certains la réponse est évidente mais pour d’autres les différences ne sont pas tout à fait clair.
Nous allons profiter de cet article pour bien analyser les grandes différences entre un scrum et un cycle en v.
Le cycle en V en quelques mots
Le cycle en V était une méthode de gestion de projet très en vogue il y a 20 ans ; elle s’est popularisée dans les années 80. D’ailleurs, cette méthode de gestion de projet cycle en V n’était pas toujours bien appliquée. Voici le cycle requis pour réaliser un projet cycle en V :
Il faut bien comprendre que cette méthode cycle en v était très populaire dans le passé. Elle apportait des réponses évidentes aux gros soucis rencontrés par les projets dit « waterfall ».
Concept du cycle en V
L’équipe réalise le projet en allant de la première étape « analyse des besoins et faisabilité » à la dernière étape « recette » de façon assez classique. Cependant contrairement aux méthodes waterfall, le cycle en V propose de retravailler par exemple la conception détaillée si les tests unitaires ne se valident pas ou de retravailler les spécifications si les tests de validation ne passent pas.
On est certes sur un système proche du waterfall mais le cycle en V cassait les codes longtemps imposés par les projets en méthode waterfall en s’autorisant des corrections en live à différents niveaux comme le montre le schéma ci-dessus.
Le Scrum en quelques mots (bien différent du cycle en V)
Scrum est une méthode dite « agile » apparue en 1995. Elle est devenue très populaire depuis 10 ans au point de faire croire à beaucoup de monde que l’agilité est le scrum ce qui n’est évidement pas le cas.
Le Scrum base son fonctionnement sur 3 piliers principaux : la transparence, l’inspection et l’adaptation. On parle d’ailleurs d’une méthodologie itérative et incrémentale.
En scrum, le produit est développé par itération de temps (appelé des sprints) . La méthode amène le client constamment au centre du produit en tentant de le faire intervenir régulièrement dans le courant du développement.
Article : Qu’est-ce que le scrum ?
Scrum vs Cycle en V
Scrum est 100% produit, le cycle en V 100% projet
Pour commencer, je vais vous dire que le Cycle en V est une méthode de gestion de projet alors que le Scrum est une méthode de gestion de produit. Vous ne voyez pas la différence ?
Un Scrum bien appliqué base son énergie sur le produit lui même. Le produit pensé en début de développement ne sera pas le produit livré dans 6 mois… Pourquoi ?
En fin d’itération (2 semaines pour 80% des équipes en Scrum), l’équipe Scrum va inviter les utilisateurs clés et les parties prenantes à venir voir le travail réalisé afin qu’ils lui fassent des feedbacks intéressants. L’équipe prendra en compte ceux-ci pour améliorer le produit lors des prochaines itérations.
Sachant qu’il est quasiment impossible d’avoir pensé au produit parfait dès le départ, le produit ne sera pas totalement celui qu’on avait imaginé en début de projet.
Dans le Cycle en V, l’aspect un peu waterfall persistant amène souvent à attendre la recette finale pour envisager des modifications du produit ; un nouveau cycle sera nécessaire pour revoir un grand nombre d’amélioration.
Quand on aura un produit final identique au produit imaginé en cycle en V, le produit ne sera peut-être pas livrable ; hors en Scrum, le fait de faire intervenir à chaque fois le client permet de livrer un produit qui aura déjà subi de nombreuses modifications (choses inutiles supprimées et améliorations ajoutées).
Le cycle en V devra attendre la phase produit final + améliorations pour envisager de mettre le produit en production. Le scrum aura déjà permis depuis pas mal de temps d’avoir le produit en production.
D’ailleurs en Scrum, nous mettrons à jour le produit en production régulièrement (toutes les 2 semaines dans le cas idéal) ; c’est pour ça qu’on dit que le Scrum accélère le time-to-market.
Vitesse de développement en théorie identique
Je pense qu’il est important de le rappeler ; certaines entreprises vendent l’agilité comme une façon de développer un produit 4 fois plus vite… C’est évidement une erreur à ne pas commettre.
Comme le montre le schéma précédent, on aura pas le même produit au bout de 6 mois, mais il n’y aura pas plus de développement non plus.
Le seul phénomène que j’ai constaté à certains moments mais qui n’est que temporaire et qui ne le sera plus dans 10 ans : la motivation des développeurs sur certains projets Scrum est des fois bien augmenté du fait d’utiliser voire de tester une méthode de travail à la mode ; cela va augmenter temporairement la productivité de l’équipe… Le phénomène serait identique si une autre méthodologie de gestion de projet devenait à la mode dans quelques années.
Considérons ce dernier cas comme particulier et considérons vraiment que la vitesse de développement est potentiellement très proche.
Le Scrum est en théorie plus basée sur la gestion des obstacles. Cependant rien n’empêche les équipes de le faire également de façon très réactive en cycle en V ; on mettra donc les deux méthodologies à égalité sur ce point.
Scrum parfois trop évasif (cycle en v plus stricte ?)
Scrum a le défaut aujourd’hui d’être un peu trop évasif sur certains points comme la documentation et la qualité technique. Si le Scrum avait volontairement été évasif sur ces points sans pour autant les renier, beaucoup d’équipes ont profité de cela pour outrepasser la documentation et la qualité technique afin de livrer au plus vite…
C’est une très grosse erreur, l’agilité n’a pas pour but de livrer tout au plus vite ; l’agilité veut qu’on livre régulièrement des produits de très grande qualité ce qui est bien différent.
Tenter de livrer au plus vite en omettant une documentation de qualité (écrite au fur et à mesure) et une qualité technique irréprochable est totalement anti-agile.
Le Scrum aime la communication (plus qu’en cycle en V ?)
On le voit régulièrement, le rôle des développeurs en Scrum a changé. On ne parle d’ailleurs pas d’un développeur mais d’une équipe de développeurs. Le Scrum pousse à l’intelligence collective ce qui n’est pas du tout le cas du cycle en V.
En cycle en V, on a des rôles bien définit pour la spécification , l’architecture, le développement, les tests… Aujourd’hui les développeurs acceptent de moins en moins cette façon de faire ; ils apprécient nettement plus d’être des acteurs du produit bien au delà du développement. La nouvelle génération très difficile à manager au passage s’y retrouvent beaucoup plus.
Cela n’est pas une critique au cycle en V qui proposait un modèle totalement adapté à son époque.
La souplesse comme axe d’accélération ?
Le Scrum propose une véritable souplesse dans la création du produit et de son évolution. A l’heure où l’uberisation des métiers fait extrêmement peur, le Scrum permet de changer de cap très rapidement ; il permettra de ne pas avoir un projet « obsolète » lors de sa mise en production.
Si avant le problème ne se posait pas, aujourd’hui on voit bien que l’accélération de ce time-to-market est essentiel pour un grand nombre d’entreprises dont les plus grands groupes français qui ont la réputation d’être totalement noyé dans leurs processus.
On ne livrera pas le produit final complet plus vite avec le Scrum mais on livrera le minimum acceptable (MMF) pour lancer le produit bien avant que le produit final attendu (en cycle en V). On pourra donc tester le produit rapidement et l’améliorer comme le montrait le schéma précédent.
Le droit à l’erreur
Comme me soulignait Alan D. sur Linkedin, la notion de l’erreur est très importante en Scrum. Les équipes apprennent de leurs erreurs en Scrum et peuvent rectifier la trajectoire dès l’itération suivante.
Le fait de pouvoir faire des rectifications rapides en Scrum permet d’accepter plus facilement l’erreur qui aura un coût peu significatif. Une même erreur en cycle en V peut coûter extrêmement cher.
Par exemple en cycle en V, on ne verra l’erreur fonctionnelle qu’au moment de la recette ; on pouvait même se retrouver à s’apercevoir que le projet était obsolète ou qu’il ne répondait pas du tout au besoin initial.
En Scrum une telle erreur se serait vu rapidement et aurait été rectifié dans les plus brefs délais.
Conclusion scrum vs cycle en V
Si les projets en cycle en V étaient dans les années 80/90, une véritable évolution du waterfall pour répondre aux problématiques rencontrées, le Scrum fait exactement la même chose 20 ans plus tard en proposant une méthode plus adaptée encore au contexte actuel.
Le Scrum vivra probablement le même type de comparaison avec des méthodes de gestion de projet futures. Ces méthodes seront plus adaptées au contexte dans lequel seront nos entreprises dans le futur.
Il est d’ailleurs fort possible que cette rupture créée par le cycle en V par rapport au waterfall très classique ait été une source d’inspiration pour les méthodes agiles comme Scrum.
Lien utile : blog agile en anglais
2 Rétroliens / Pings