En cliquant sur “ Accepter tous les cookies”, vous acceptez le stockage des cookies sur votre appareil pour améliorer la navigation sur le site, analyser la navigation réalisée sur ce site et assister nos efforts marketing. Plus d’informations sur notre politique de stockage des vos données.
Méthode Scrum vs Cycle en V : quelle méthode adopter ?
31
Aug
dgitags.io
Fanny - Consultante Content Marketing
Scrum quoi ? Cycle en V ?
La méthode Scrum et le cycle en V sont deux méthodologies de projet qui ont vu le jour dans les années 1980-1990’s. Le cycle en V a été démocratisé dans les années 1980’s alors que la méthode Scrum a fait son apparition en 1995.
Ces deux méthodes sont deux façons de réaliser un produit mais d’une manière totalement différente.
Vous êtes probablement en train de vous dire : mais qu’est-ce qu’elle raconte ?
Pas de panique !
La team Dgitags va tenter aujourd’hui de répondre à toutes vos questions :
Qu’est-ce que le cycle en V ? Qu’est-ce que la méthode Scrum ?Quels sont les éléments qui les différencient ? Est-ce que l’une est plus efficace que l’autre ?
Si vous souhaitez en savoir plus sur ces deux méthodologies, c’est juste en dessous.
C’est parti !
Présentation du cycle en V
Le cycle en V est une méthode de gestion qui s’est répandue dans les années 1980’s. Elle a été mise en place afin de combler un certain nombre de problèmes régulièrement rencontrés dans les méthodologies dites Waterfall (en cascade).
Explication de la méthode du cycle en V
L’équipe projet commence par la première étape« analyse des besoins et faisabilité » puis termine par la dernière étape « recette ». Cependant contrairement aux méthodes waterfall, le cycle en V propose de retravailler par exemple la conception architecturale si les tests d’intégration ne se valident pas ou de retravailler les spécifications si les tests de validation ne passent pas.
Donc lorsqu’on arrive à une étape et qu’on ne peut pas y répondre correctement, on se doit de retravailler l’étape qui a permis de faire cette étape.
On peut donc revenir en arrière, même s’il n’y a pas de notion d’itération.
De plus, vous avez une équipe projet par ligne.
A savoir :
La lettre« V » provient du fait que le modèle associe chaque phase de développement avec la phase de validation qui lui correspond. Le bras gauche du « V » désigne les tâches relatives à la conception et au développement du système, le bras droit les mesures d’assurance qualité qui lui sont associées. La phase de mise en œuvre du produit se trouve au centre des deux bras, entre les phases de développement et d'assurance qualité.
Source : https://www.ionos.fr/
Avantage de la méthode :
L’avantage principal de cette méthode est qu’elle présente des gains d’échelle en traitant d’un coup, l’ensemble du périmètre du projet.
Inconvénients de la méthode :
Manque de communication : chaque acteur du projet joue son rôle chacun son tour mais ils ne le jouent jamais tous ensemble et communiquent principalement au travers de documents.
Manque de souplesse : pour passer d’une étape à une autre, la précédente doit être terminée. Cela peut donc entraîner des dérives planning et donc de coûts.
Péremption du produit : la durée de ce type de projet est souvent assez longue. Entre temps le besoin peut avoir évolué. Le résultat final ne sera donc plus adapté aux besoins initiaux.
Manque de feedback : si la documentation liée à la conception du produit est incomplète, le produit final ne répondra pas entièrement aux besoins du client et la méthode ne prévoit pas d’opportunité de vérification intermédiaire.
Les risques générés par la méthode du cycle en V a favorisé l’émergence de nouvelles méthodes dites Agile telle que la méthode Scrum.
Présentation de la méthode Scrum
Le mot Scrum (« mêlée » en anglais) fait référence à la mêlée du rugby. En effet, cette méthode se concentre sur l’esprit d’équipe et la volonté d’avancer ensemble vers la réalisation d’un même objectif.
Cette méthode apparait en 1995. Elle est aujourd’hui très populaire. Le Scrum base son fonctionnement sur 3 piliers principaux : la transparence, l’inspection et l’adaptation. D’ailleurs, on parle d’une méthodologie itérative et incrémentale.
Dans la méthode Scrum, le produit est développé par itération de temps (appelé des sprints). Le but est d’amener le client constamment au centre du produit en tentant de le faire intervenir régulièrement pendant tout le cycle de réalisation du projet.
Il y a trois acteurs clés :
Le Product Owner : il a une vision complète du produit,
Le Scrum master : il assure le bon déroulement du projet et rappelle la méthode,
L’équipe Scrum : elle développe le produit.
LeProduct Owner va définir le backlog du produit. Ce backlog est une liste valorisée des fonctionnalités cibles du produit. Au fur et à mesure que le projet se construit, la liste peut évoluer en fonction des besoins. Une fois ce backlog effectué, le premier sprint peut commencer.
Lors d’un sprint, l’équipe Scrum et le Scrum master, font un point sur le développement du produit et débute chaque journée par une « mêlée »durant laquelle ils rappellent les objectifs du jour. Les sprints sont en général fixés toutes les 2/3 semaines.
A la fin de chaque sprint, le client ainsi que le Product Owner évaluent le produit partiellement livrable afin de le valider ou d’indiquer les modifications à réaliser qui seront ajoutées au backlog du produit.
Avantages de la méthode :
Produit final qui sera proche des attentes du clients puisque tout au long du processus de développement, les évolutions et les besoins sont pris en compte.
Communication facilitée grâce au sprint régulier et grâce à l’intervention du Scrum Master qui est là pour faciliter le lien entre chaque parties prenantes.
Risques de la méthode :
Manque de documentation : comme cette méthode s’adapte aux besoins du client, le projet évolue assez souvent. Certaines informations peuvent donc se perdre ou ne pas bien être mises à jour. Une fois le projet finalisée, il faut faire attention aux informations qui seront transmises aux équipes de maintenance. Elles devront être à jour.
Mauvaise interprétation de la méthode Scrum et des « mêlées quotidiennes » : cette méthode peut s’avérer complexe à comprendre. En effet, elle est quand même très différente des méthodes de management traditionnel. Il faut donc s’assurer qu’elle soit bien comprise par les équipes. De plus, si la méthode est mal expliquée, les mêlées quotidiennes seront perçues comme un outil de flicage.
A ne pas confondre !
Agile est une méthodologie de développement basée sur une approche itérative et incrémentale. Scrum est l’une des implémentations de la méthodologie agile.
Passons maintenant à une comparaison plus approfondie de ces deux méthodes.
« Cycle en V » vs « SCRUM »
Produit vs Projet
Une des différences qui existent entre ces deux méthodes est la suivante : le cycle en V est une méthode de gestion de projet alors que le Scrum est une méthode de gestion de produit.
Dans la méthode Scrum, le produit est au centre du projet. Le produit pensé en début de développement ne sera pas le produit livré dans 6 mois.
Tout au long du développement du projet, l’équipe Scrum va présenter son avancée lors des sprints. Les clients pourront faire des feedbacks et faire évoluer certains aspects du projet s’ils ne sont pas convaincus. 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, il faut souvent attendre la recette finale pour envisager des modifications du produit. Un nouveau cycle sera nécessaire pour mettre en place des modifications afin d’améliorer le produit.
Donc en cycle en V, le produit ne sera peut-être pas livrable à la fin du cycle alors qu’en Scrum, le fait de faire intervenir à chaque fois le client permet de livrer un produit qui aura déjà subi de nombreuses modifications et qui sera livrable.
Méthode Scrum vs cycle en V : la documentation
La méthode Scrum peut s’avérer un peu trop évasif sur certains points comme la documentation et la qualité technique. Les équipes Scrum ont tendance à outrepasser la documentation et la qualité technique afin de livrer le produit au plus vite. Cependant ce raisonnement est une erreur.
L’agilité n’a pas pour but de livrer le produit au plus vite, l’agilité veut qu’on livre régulièrement des produits de très grande qualité ce qui est totalement différent.
Vouloir livrer au plus vite, en omettant une documentation de qualité c’est-à-dire écrire au fur et à mesure de l’évolution du projet est finalement anti-agile puisque les équipes de maintenance qui reprendront par la suite le projet risquent d’être perdus si la documentation n’est pas actualisée.
La méthode cycle en V n’a pas réellement ce problème puisque chaque acteur du projet communique essentiellement à travers les documents transmis après chaque étape. La documentation est donc souvent bien mise à jour.
Scrum vs Cycle en V : une question d’époque ?
En cycle en V, on a des rôles bien définit pour la spécification, l’architecture, le développement, les tests, etc. 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.
Au contraire, le Scrum pousse à l’intelligence collective ce qui n’est pas du tout le cas du cycle en V. C’est la raison pour laquelle les développeurs se retrouvent souvent plus dans la méthode Scrum.
C’est donc également une question d’époque puisque le cycle en V était très populaire dans les années 1980’s puisqu’il proposait un modèle totalement adapté à son époque.
Scrum vs Cycle en V : souplesse du modèle
A l’ère de l’ubérisation, le Scrum propose une véritable souplesse dans la création du produit et de son évolution. Le Scrum permet de changer de cap très rapidement et ne pas avoir un projet obsolète lors de sa mise en production.
L’accélération du time-to-market pose aujourd’hui problème à certaines entreprises puisque les besoins évoluent rapidement, de nouveaux besoins apparaissent et les entreprises doivent être sur le qui-vive pour tenter d’y répondre au mieux.
On ne livrera pas le produit final complet plus vite avec le Scrum mais on livrera le minimum acceptable pour lancer le produit bien avant le produit final attendu. On pourra donc tester le produit rapidement et l’améliorer.
Scrum vs Cycle en V : le droit à l’erreur
La notion de l’erreur est très importante en Scrum. Les équipes apprennent de leurs erreurs et peuvent rectifier le tir dès le sprint suivant.
Le fait de pouvoir faire des rectifications rapides en Scrum permet d’accepter plus facilement l’erreur. De plus, elle aura un coût peu significatif. Faire une erreur en cycle V est beaucoup plus couteux.
Par exemple en cycle en V, on ne verra l’erreur fonctionnelle qu’au moment de la recette. Ce qui peut mener à un projet livré obsolète ou bien à un projet qui ne répond pas vraiment aux besoins initiaux.
En Scrum une telle erreur se serait vu rapidement et aurait été rectifié très rapidement.
Scrum vs Cycle en V : la culture d’entreprise
Même si la méthode Scrum semble plus efficace, elle n’est pas toujours adaptée à tout type de projet et à tout type d’entreprise.
Premièrement, une entreprise ne peut pas devenir entièrement agile du jour au lendemain. Il faut du temps et un bon accompagnement pour mettre en place une méthode Scrum. Pour établir une stratégie de changement efficace, il est important de comprendre où se situe l’organisation et de définir les phases de transition en fonction de sa maturité et de son niveau de préparation.
En effet, l’application de méthode agiles tel que la méthode Scrum requiert une grande habilitation des équipes puisque celles-ci doivent réapprendre une certaine façon de travailler. Dans un environnement traditionnel en cascade ou de cycle en V, les équipes s’alignent sur une fonction particulière, par exemple le développement ou les essais, et ont recours à des processus et des modèles, mais sans avoir une vue d’ensemble. Le problème est que l’approche agile requiert de la souplesse, une collaboration étroite des différentes équipes et de la communication. C’est un grand changement.
C’est la raison pour laquelle certaines entreprises traditionnelles (par exemple dans leur méthode de management) n’arriveront pas à adhérer à ce nouveau modèle d’entreprise libérée car la culture d’entreprise souvent paternaliste est trop ancrée dans les mœurs. Un changement aussi profond que celui-ci risque d’être voué à l’échec.
La culture d’entreprise doit donc coïncider avec les méthodes agiles pour fonctionner. Il faut que la culture soit prête à accueillir l’agilité.
Les bonnes questions à se poser pour choisir entre les deux méthodes
Afin de faire un choix entre ces deux méthodologies, vous devez vous poser les questions suivantes :
1/ Est-ce que je suis en mesure de mobiliser une équipe qui pourra participer de manière active à mon projet (pour définir les besoins et tester les développements) ? Si oui, optez pour la méthode Scrum.
2/ Est-ce que je suis complètement en maîtrise du besoin auquel le projet doit répondre et est ce je suis capable de décrire son fonctionnement précis de façon certaine et complète ? Si oui, optez pour la méthode du cycle en V.
La méthode Scrum est donc plus adaptée aux projets complexes sur lesquels on n’a pas de visibilité puisqu’elle apporte davantage de flexibilité et d’adaptabilité aux évolutions demandées ainsi qu’une meilleure gestion des risques.
La méthode de « Cycle en V » permet de mieux cadrer un projet industriel, pour lequel le client a une vision très précise de ce qu’il veut (par exemple : besoins, planning détaillé et anticipation des risques).
Conclusion Scrum vs cycle en V
Si les projets en cycle en V étaient dans les années80/90, une véritable évolution du waterfall pour répondre aux problématiques rencontrées, le Scrum fait exactement la même chose des années plus tard en proposant une méthode plus adaptée encore au contexte actuel.
Le Scrum subira probablement le même type de comparaison avec des méthodes de gestion de projet futures. Ces méthodes seront probablement plus adaptées au contexte dans lequel évolueront nos entreprises futures.
Voilà c’est la fin de cet article. Et oui déjà… Ne vous inquiétez pas, nous revenons bientôt avec encore plus de contenus J
La team Dgitags espère néanmoins que cet article vous aura intéressé et vous aura appris des choses sur ces deux méthodologies.
Au sein de la Tags community, nos équipes ont l’habitude de travailler avec des méthodes agiles. N’hésitez pas à les solliciter si vous avez des questions ou si vous voulez bénéficier de nos services.
La méthode Scrum et le cycle en V sont deux méthodologies de projet qui ont vu le jour dans les années 1980-1990’s. Le cycle en V a été démocratisé dans les années 1980’s alors que la méthode Scrum a fait son apparition en 1995.
Ces deux méthodes sont deux façons de réaliser un produit mais d’une manière totalement différente.
Vous êtes probablement en train de vous dire : mais qu’est-ce qu’elle raconte ?
Pas de panique !
La team Dgitags va tenter aujourd’hui de répondre à toutes vos questions :
Qu’est-ce que le cycle en V ? Qu’est-ce que la méthode Scrum ?Quels sont les éléments qui les différencient ? Est-ce que l’une est plus efficace que l’autre ?
Si vous souhaitez en savoir plus sur ces deux méthodologies, c’est juste en dessous.
C’est parti !
Présentation du cycle en V
Le cycle en V est une méthode de gestion qui s’est répandue dans les années 1980’s. Elle a été mise en place afin de combler un certain nombre de problèmes régulièrement rencontrés dans les méthodologies dites Waterfall (en cascade).
Explication de la méthode du cycle en V
L’équipe projet commence par la première étape« analyse des besoins et faisabilité » puis termine par la dernière étape « recette ». Cependant contrairement aux méthodes waterfall, le cycle en V propose de retravailler par exemple la conception architecturale si les tests d’intégration ne se valident pas ou de retravailler les spécifications si les tests de validation ne passent pas.
Donc lorsqu’on arrive à une étape et qu’on ne peut pas y répondre correctement, on se doit de retravailler l’étape qui a permis de faire cette étape.
On peut donc revenir en arrière, même s’il n’y a pas de notion d’itération.
De plus, vous avez une équipe projet par ligne.
A savoir :
La lettre« V » provient du fait que le modèle associe chaque phase de développement avec la phase de validation qui lui correspond. Le bras gauche du « V » désigne les tâches relatives à la conception et au développement du système, le bras droit les mesures d’assurance qualité qui lui sont associées. La phase de mise en œuvre du produit se trouve au centre des deux bras, entre les phases de développement et d'assurance qualité.
Source : https://www.ionos.fr/
Avantage de la méthode :
L’avantage principal de cette méthode est qu’elle présente des gains d’échelle en traitant d’un coup, l’ensemble du périmètre du projet.
Inconvénients de la méthode :
Manque de communication : chaque acteur du projet joue son rôle chacun son tour mais ils ne le jouent jamais tous ensemble et communiquent principalement au travers de documents.
Manque de souplesse : pour passer d’une étape à une autre, la précédente doit être terminée. Cela peut donc entraîner des dérives planning et donc de coûts.
Péremption du produit : la durée de ce type de projet est souvent assez longue. Entre temps le besoin peut avoir évolué. Le résultat final ne sera donc plus adapté aux besoins initiaux.
Manque de feedback : si la documentation liée à la conception du produit est incomplète, le produit final ne répondra pas entièrement aux besoins du client et la méthode ne prévoit pas d’opportunité de vérification intermédiaire.
Les risques générés par la méthode du cycle en V a favorisé l’émergence de nouvelles méthodes dites Agile telle que la méthode Scrum.
Présentation de la méthode Scrum
Le mot Scrum (« mêlée » en anglais) fait référence à la mêlée du rugby. En effet, cette méthode se concentre sur l’esprit d’équipe et la volonté d’avancer ensemble vers la réalisation d’un même objectif.
Cette méthode apparait en 1995. Elle est aujourd’hui très populaire. Le Scrum base son fonctionnement sur 3 piliers principaux : la transparence, l’inspection et l’adaptation. D’ailleurs, on parle d’une méthodologie itérative et incrémentale.
Dans la méthode Scrum, le produit est développé par itération de temps (appelé des sprints). Le but est d’amener le client constamment au centre du produit en tentant de le faire intervenir régulièrement pendant tout le cycle de réalisation du projet.
Il y a trois acteurs clés :
Le Product Owner : il a une vision complète du produit,
Le Scrum master : il assure le bon déroulement du projet et rappelle la méthode,
L’équipe Scrum : elle développe le produit.
LeProduct Owner va définir le backlog du produit. Ce backlog est une liste valorisée des fonctionnalités cibles du produit. Au fur et à mesure que le projet se construit, la liste peut évoluer en fonction des besoins. Une fois ce backlog effectué, le premier sprint peut commencer.
Lors d’un sprint, l’équipe Scrum et le Scrum master, font un point sur le développement du produit et débute chaque journée par une « mêlée »durant laquelle ils rappellent les objectifs du jour. Les sprints sont en général fixés toutes les 2/3 semaines.
A la fin de chaque sprint, le client ainsi que le Product Owner évaluent le produit partiellement livrable afin de le valider ou d’indiquer les modifications à réaliser qui seront ajoutées au backlog du produit.
Avantages de la méthode :
Produit final qui sera proche des attentes du clients puisque tout au long du processus de développement, les évolutions et les besoins sont pris en compte.
Communication facilitée grâce au sprint régulier et grâce à l’intervention du Scrum Master qui est là pour faciliter le lien entre chaque parties prenantes.
Risques de la méthode :
Manque de documentation : comme cette méthode s’adapte aux besoins du client, le projet évolue assez souvent. Certaines informations peuvent donc se perdre ou ne pas bien être mises à jour. Une fois le projet finalisée, il faut faire attention aux informations qui seront transmises aux équipes de maintenance. Elles devront être à jour.
Mauvaise interprétation de la méthode Scrum et des « mêlées quotidiennes » : cette méthode peut s’avérer complexe à comprendre. En effet, elle est quand même très différente des méthodes de management traditionnel. Il faut donc s’assurer qu’elle soit bien comprise par les équipes. De plus, si la méthode est mal expliquée, les mêlées quotidiennes seront perçues comme un outil de flicage.
A ne pas confondre !
Agile est une méthodologie de développement basée sur une approche itérative et incrémentale. Scrum est l’une des implémentations de la méthodologie agile.
Passons maintenant à une comparaison plus approfondie de ces deux méthodes.
« Cycle en V » vs « SCRUM »
Produit vs Projet
Une des différences qui existent entre ces deux méthodes est la suivante : le cycle en V est une méthode de gestion de projet alors que le Scrum est une méthode de gestion de produit.
Dans la méthode Scrum, le produit est au centre du projet. Le produit pensé en début de développement ne sera pas le produit livré dans 6 mois.
Tout au long du développement du projet, l’équipe Scrum va présenter son avancée lors des sprints. Les clients pourront faire des feedbacks et faire évoluer certains aspects du projet s’ils ne sont pas convaincus. 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, il faut souvent attendre la recette finale pour envisager des modifications du produit. Un nouveau cycle sera nécessaire pour mettre en place des modifications afin d’améliorer le produit.
Donc en cycle en V, le produit ne sera peut-être pas livrable à la fin du cycle alors qu’en Scrum, le fait de faire intervenir à chaque fois le client permet de livrer un produit qui aura déjà subi de nombreuses modifications et qui sera livrable.
Méthode Scrum vs cycle en V : la documentation
La méthode Scrum peut s’avérer un peu trop évasif sur certains points comme la documentation et la qualité technique. Les équipes Scrum ont tendance à outrepasser la documentation et la qualité technique afin de livrer le produit au plus vite. Cependant ce raisonnement est une erreur.
L’agilité n’a pas pour but de livrer le produit au plus vite, l’agilité veut qu’on livre régulièrement des produits de très grande qualité ce qui est totalement différent.
Vouloir livrer au plus vite, en omettant une documentation de qualité c’est-à-dire écrire au fur et à mesure de l’évolution du projet est finalement anti-agile puisque les équipes de maintenance qui reprendront par la suite le projet risquent d’être perdus si la documentation n’est pas actualisée.
La méthode cycle en V n’a pas réellement ce problème puisque chaque acteur du projet communique essentiellement à travers les documents transmis après chaque étape. La documentation est donc souvent bien mise à jour.
Scrum vs Cycle en V : une question d’époque ?
En cycle en V, on a des rôles bien définit pour la spécification, l’architecture, le développement, les tests, etc. 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.
Au contraire, le Scrum pousse à l’intelligence collective ce qui n’est pas du tout le cas du cycle en V. C’est la raison pour laquelle les développeurs se retrouvent souvent plus dans la méthode Scrum.
C’est donc également une question d’époque puisque le cycle en V était très populaire dans les années 1980’s puisqu’il proposait un modèle totalement adapté à son époque.
Scrum vs Cycle en V : souplesse du modèle
A l’ère de l’ubérisation, le Scrum propose une véritable souplesse dans la création du produit et de son évolution. Le Scrum permet de changer de cap très rapidement et ne pas avoir un projet obsolète lors de sa mise en production.
L’accélération du time-to-market pose aujourd’hui problème à certaines entreprises puisque les besoins évoluent rapidement, de nouveaux besoins apparaissent et les entreprises doivent être sur le qui-vive pour tenter d’y répondre au mieux.
On ne livrera pas le produit final complet plus vite avec le Scrum mais on livrera le minimum acceptable pour lancer le produit bien avant le produit final attendu. On pourra donc tester le produit rapidement et l’améliorer.
Scrum vs Cycle en V : le droit à l’erreur
La notion de l’erreur est très importante en Scrum. Les équipes apprennent de leurs erreurs et peuvent rectifier le tir dès le sprint suivant.
Le fait de pouvoir faire des rectifications rapides en Scrum permet d’accepter plus facilement l’erreur. De plus, elle aura un coût peu significatif. Faire une erreur en cycle V est beaucoup plus couteux.
Par exemple en cycle en V, on ne verra l’erreur fonctionnelle qu’au moment de la recette. Ce qui peut mener à un projet livré obsolète ou bien à un projet qui ne répond pas vraiment aux besoins initiaux.
En Scrum une telle erreur se serait vu rapidement et aurait été rectifié très rapidement.
Scrum vs Cycle en V : la culture d’entreprise
Même si la méthode Scrum semble plus efficace, elle n’est pas toujours adaptée à tout type de projet et à tout type d’entreprise.
Premièrement, une entreprise ne peut pas devenir entièrement agile du jour au lendemain. Il faut du temps et un bon accompagnement pour mettre en place une méthode Scrum. Pour établir une stratégie de changement efficace, il est important de comprendre où se situe l’organisation et de définir les phases de transition en fonction de sa maturité et de son niveau de préparation.
En effet, l’application de méthode agiles tel que la méthode Scrum requiert une grande habilitation des équipes puisque celles-ci doivent réapprendre une certaine façon de travailler. Dans un environnement traditionnel en cascade ou de cycle en V, les équipes s’alignent sur une fonction particulière, par exemple le développement ou les essais, et ont recours à des processus et des modèles, mais sans avoir une vue d’ensemble. Le problème est que l’approche agile requiert de la souplesse, une collaboration étroite des différentes équipes et de la communication. C’est un grand changement.
C’est la raison pour laquelle certaines entreprises traditionnelles (par exemple dans leur méthode de management) n’arriveront pas à adhérer à ce nouveau modèle d’entreprise libérée car la culture d’entreprise souvent paternaliste est trop ancrée dans les mœurs. Un changement aussi profond que celui-ci risque d’être voué à l’échec.
La culture d’entreprise doit donc coïncider avec les méthodes agiles pour fonctionner. Il faut que la culture soit prête à accueillir l’agilité.
Les bonnes questions à se poser pour choisir entre les deux méthodes
Afin de faire un choix entre ces deux méthodologies, vous devez vous poser les questions suivantes :
1/ Est-ce que je suis en mesure de mobiliser une équipe qui pourra participer de manière active à mon projet (pour définir les besoins et tester les développements) ? Si oui, optez pour la méthode Scrum.
2/ Est-ce que je suis complètement en maîtrise du besoin auquel le projet doit répondre et est ce je suis capable de décrire son fonctionnement précis de façon certaine et complète ? Si oui, optez pour la méthode du cycle en V.
La méthode Scrum est donc plus adaptée aux projets complexes sur lesquels on n’a pas de visibilité puisqu’elle apporte davantage de flexibilité et d’adaptabilité aux évolutions demandées ainsi qu’une meilleure gestion des risques.
La méthode de « Cycle en V » permet de mieux cadrer un projet industriel, pour lequel le client a une vision très précise de ce qu’il veut (par exemple : besoins, planning détaillé et anticipation des risques).
Conclusion Scrum vs cycle en V
Si les projets en cycle en V étaient dans les années80/90, une véritable évolution du waterfall pour répondre aux problématiques rencontrées, le Scrum fait exactement la même chose des années plus tard en proposant une méthode plus adaptée encore au contexte actuel.
Le Scrum subira probablement le même type de comparaison avec des méthodes de gestion de projet futures. Ces méthodes seront probablement plus adaptées au contexte dans lequel évolueront nos entreprises futures.
Voilà c’est la fin de cet article. Et oui déjà… Ne vous inquiétez pas, nous revenons bientôt avec encore plus de contenus J
La team Dgitags espère néanmoins que cet article vous aura intéressé et vous aura appris des choses sur ces deux méthodologies.
Au sein de la Tags community, nos équipes ont l’habitude de travailler avec des méthodes agiles. N’hésitez pas à les solliciter si vous avez des questions ou si vous voulez bénéficier de nos services.
Connaissez vous l'UX Writing ? Mélanie, UX Writer d'expérience au sein de la communauté Tags vous parle de cette discipline peu connue encore en France.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Heading 2 + Figure
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
This is a sample caption
Heading 3
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Heading 4
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Heading 5
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Praesent egestas neque eu enim. Fusce fermentum odio nec arcu. Phasellus ullamcorper ipsum rutrum nunc.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Aenean tellus metus
Maecenas egestas arcu quis
Etiam rhoncus
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Praesent egestas neque
Phasellus ullamcorper ipsum
In auctor lobortis lacus
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
