Dans mon dernier article, j’ai expliqué que chaque présentation devrait toujours commencer par le “Pourquoi” (Lisez le ici). En suivant mon propre conseil, cet article démarrera en expliquant le “Pourquoi” des méthodologies de gestion de projet et essentiellement des méthodes agiles.
Avant de démarrer, sachez que ce cet article n’est pas une présentation dédiée aux méthodes Agiles, vous n’apprendrez absolument pas à mettre en place ces méthodes en lisant cette page.
Cet article vous permettra, plutôt, de comparer 2 représentants des 2 mouvements les plus utilisés en développement logiciel, les méthodes agiles et les méthodes classiques traditionelles (“Cascade”et “Cycle en V”). Mais il vous aidera également à comprendre en quoi la méthode Agile Scrum pourra propulser votre idée vers le succès. Ci-dessous, j’ai choisi de comparer le populaire framework SCRUM pour représenter l’Agilité et la très répandue méthode du “Cycle en V” pour représenter les méthodes traditionnelles.
Pourquoi SCRUM a t-il été créé ?
Il y a quelques années, les gros projets logiciels avaient tendance à finir en retard et à exploser les budgets.
Cela était du à certaines limites des méthodologies utilisées à cette époque, les méthodes de projet “Cascade” ou celle du “Cycle en V”. Ces deux méthodologies sont maintenant souvent considérées comme non appropriées pour de gros projets car elles nécessitent avant le démarrage, une énorme planification. Cependant, ces méthodes restent encore extrêmement efficaces pour de petits projets bien définis.
Un peu de définition …
La méthodologie “Cascade” (Waterfall) est basée sur un cycle de vie séquentiel et linéaire. Cela signifie que chaque phase doit être finalisée intégralement avant que la phase suivante ne démarre.
- Récupération des besoins : Cahier des charges et spécifications.
- Design : Interface graphique et expérience utilisateur
- Développement : Codage et tests unitaires
- Tests : Jouer les tests
- Livraison : Déploiement du produit fini
Méthode du Cycle en V
La méthode du “Cycle en V” (V-Model) est basée, quant à elle, sur un cycle de vie en V et fournit un parcours séquentiel pour éxécuter chaque phase du processus.
Ci-dessous, voici les 3 phases principales du “Cycle en V” et l’ordre des étapes séquentielles nécessaires avant d’obtenir un produit fini.
- La phase de vérification :
- Expression de besoins
- Specifications fonctionnelles
- Specifications techniques
- Maquette de Design
- Design détaillé
- La phase de développement
- La phase de validation (Assurance Qualité) :
- Tests unitaires
- Tests d’intégration
- Tests du système
- Acceptation des tests
- Garantie
Les modèles “Cascade” ou “Cycle en V” sont de parfaites méthodologies pour de petits ou moyens projets logiciels bien définis mais ils peuvent avoir des conséquences dramatiques sur des longs projets logiciels ou les expressions de besoins peuvent drastiquement évoluer dans le temps et rendre obsolétes des produits à peine finalisés.
Avec le modèle “Cascade”, un projet logiciel moyen, qui est supposé durer 10 mois afin d’être finalisé, démarrera éventuellement son développement 4 mois après avoir complété l’expression de besoins, les spécifications et le design, le développement durera environ 8 mois et 3 mois supplémentaires seront nécessaires pour tester l’intégralité. A la fin, 1,5 années seront écoulées, et le produit fini sera obsoléte car les besoins utilisateurs auront depuis changé.
Conscient des résultats dramatiques et chaotiques que produisaient ces méthodes sur de longs projets logiciels, quelques personnes ont commencé à remettre en question les méthodes “Cascade”.
A la place d’un processus dit “top-down”, Ikurjiro Nonaka et Hirkotaka Takeuchi ont proposé en 1986 une alternative dans laquelle ils ont exposé une nouvelle méthode de gestion de projet plus rapide et plus flexible.
Si l’histoire vous intéresse, ils ont écrit un essai en anglais au sujet de leur théorie dans le “Harvard Business Journal” “New Product Development Game” (https://hbr.org/1986/01/the-new-new-product-development-game)
Dans leur essai, ils ont publié un diagramme très clair montrant l’avantage de parallèliser plutôt que de chainer les phases de développement. Dans ce diagramme, vous pouvez instantanément vous rendre compte que le Type C (Phases paralélisées) permet d’obtenir un produit plus rapidement que le type A (Phases chainées (séquentielles)).
Cet essai lança le début du mouvement sur les méthodologies Agile. Bien sur, le principe derrière celui-ci a évolué plusieurs fois depuis 1986 et l’essai originel a été transformé avant de devenir Scrum au début des années 1990.
Les deux bénéfices inestimables de Scrum
Confrontez-vous au marché rapidement
La méthode Scrum permet d’obtenir un produit à forte valeur ajoutée métier afin de le confronter rapidement à son marché. Ainsi, si vous souhaitez rapidement montrer un prototype à vos utilisateurs, Scum est sans aucun doute, le choix idéal!
Itérer avec Scrum définira petit à petit vos spécifications et vos besoins clients grâce aux retours utilisateurs obtenus à chacune des itérations majeures.
Scrum vous forcera automatiquement à prioriser le développement des fonctionnalités les plus importantes avec les valeurs métiers les plus fortes. Ces priorités évolueront également d’itération en itération transformant l’expression de besoin constamment afin de suivre la demande de vos utilisateurs.
Vous obtiendrez rapidement un produit viable minimaliste prêt à être présenter à son marché potentiel.
Apportez du bien-être au travail pour vos équipes
Ce qui motive tout salarié dans son travail est d’obtenir de l’autonomie, de la compréhension, de l’estime, de la reconnaissance et de la transparence. (Dan Pink‘s bestselling book Drive )
Les valeurs fondamentales de Scrum sont basées sur l’engagement, le respect, le courage, la concentration et l’ouverture. Ce qui signifie que Scrum va progressivement mettre en place une atmosphère de transparence et de confiance parmi les membres de vos équipes. Après chaque itération, La méthode forcera la remise en question de l’équipe mais également une remise en question individuelle de chacun des membres.
Ces derniers progresseront efficacement dans de multiples domaines et cela améliorera au fur et à mesure la productivité de votre projet.
De plus, Les rétrospectives Scrum mesurent le moral de l’équipe. Non seulement, Scrum vous permettra de façon continue d’améliorer votre projet mais également de contribuer au bien-être de vos équipes.
Toutes ces valeurs augmenteront l’engagement des salariés ce qui sera bénéfique à votre projet et à votre société.
Conclusion
J’ai découvert SCRUM, il y a quelques années en étant membre d’une équipe qui l’utilisait, et j’ai vraiment adoré la flexibilité et la transparence que Scrum a procuré au projet et à l’équipe. Cet article ne sera sans doute pas le dernier sur le sujet, j’essaierai de temps à autre d’aller plus loin dans les principes fondamentaux et de partager des bonnes pratiques.
Scrum a été pensé pour promouvoir une atmosphère de confiance, une culture d’amélioration continue avec des objectifs communs bien définis.
Scrum est populaire depuis quelques années, la communauté est divisée en 2 parties, les adorateurs et les “haters”. Beaucoup de gens pensent que l’Agile est LA nouvelle méthode révolutionnaire et qu’il faut l’appliquer à chaque projet de développement logiciel.
Même si je recommande Scrum et les méthodologies Agile dans cet article (Je les utilise moi-même avec mes équipes IT chez Jooxter.com), je reste convaincu qu’elles ne peuvent pas s’appliquer à tous les projets.
Soyez conscient que la méthode Scrum est difficile à mettre en place, elle requiert de la rigueur et beaucoup d’apprentissages avant de savoir comment l’appliquer correctement. N’hésitez pas à vous faire aider, lire la théorie sur Internet ne sera pas suffisant pour comprendre chaque concept et recevoir chaque aspect bénéfique sur votre projet.
Découvrez en plus sur Scrum ici : http://www.scrumguides.org/scrum-guide.html
Jeu de briques
Snake
Pacman
Bubble