Apparue dans les années 1980, le cycle en V est la méthode de gestion de projet dite “traditionnelle”. Elle repose sur le fait de découper un projet en une succession d’étapes : analyse des besoins, rédaction des spécifications fonctionnelles, réalisation, tests unitaires, tests d’intégration, tests de validation et tests d’acceptation. Chaque étape est associée à une phase de validation. Ses principaux avantages reposent sur sa facilité de mise en œuvre et son effet tunnel qui évite de retourner en arrière. Mais cet effet tunnel est aussi ce qui lui est reproché car cela ne laisse pas la place aux modifications en cours de développement et donc à l’adaptabilité et à la réactivité. Et le problème, aujourd’hui, c’est qu’il est complexe de prévoir toutes les situations et donc de mettre des exigences en face.
C’est ce manque de flexibilité qui a permis à la méthode Agile de se développer et de se démarquer. Cette dernière prône notamment la communication et la collaboration entre des équipes auto-organisées et pluridisciplinaires tout en plaçant le client au cœur du projet. Elle fait suite à l’observation d’un taux d’échec élevé des projets dans les années 1990. En 2001, 17 experts en développement logiciel se réunissent aux Etats-Unis et mettent en commun leurs méthodes respectives, créant alors le « Manifeste Agile ».
Considéré comme la définition canonique du développement agile, le Manifeste Agile est constitué de quatre valeurs et de douze principes fondateurs.
« Nous découvrons de meilleures approches du développement logiciel en le pratiquant et en aidant les autres à le pratiquer. Ce travail nous a amenés à accorder de l'importance :
aux individus et leurs interactions plutôt qu'aux processus et aux outils ;
à un logiciel fonctionnel plutôt qu’à une documentation exhaustive ;
à la collaboration avec les clients plutôt qu'à la négociation contractuelle ;
à l’adaptation au changement plutôt qu'à l'exécution d’un plan.
Cela signifie que, bien qu'il y ait de la valeur dans les éléments situés à la fin, notre préférence se porte sur les éléments qui se trouvent en première partie de phrase. »
1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
2. Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
3. Livrez fréquemment un logiciel fonctionnel, dans des cycles de quelques semaines à quelques mois, avec une préférence pour les plus courts.
4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
5. Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
6. La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face-à-face.
7. Un logiciel fonctionnel est la principale mesure de progression d'un projet.
8. Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
9. Une attention continue à l'excellence technique et à un bon design.
10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
11. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
12. À intervalles réguliers, l'équipe réfléchit aux moyens possibles de devenir plus efficace. Puis elle s'adapte et modifie son fonctionnement en conséquence.
Plutôt que de fixer des objectifs à long terme, la méthodologie agile repose sur des objectifs à court terme. Tout est fait au fur et à mesure. Et la satisfaction du client étant la priorité, chaque étape est validée par ce dernier. Cela permet ainsi de s’adapter plus facilement et plus rapidement en cas de modifications ou d’imprévus et de répondre à ses attentes. Il y a une véritable relation et collaboration entre l’équipe et le client qui permet à chacun d’avancer efficacement et d’être sur la même longueur d’ondes.
L’approche agile est une méthode de gestion de projet très souple et très flexible. Tout est adaptable, ou presque. La qualité l’est peut-être un peu moins, mais tout ce qui concerne le scope, le budget et le temps de réalisation peut facilement être modifié, en fonction de la méthode employée (Scrum, Kanban). Cela permet d’être plus réactif en cas de problèmes, d’augmenter la performance de l’équipe, mais aussi de gagner en contrôle sur le produit final et donc d’en améliorer sa qualité. Et qui dit un produit final de qualité, dit des utilisateurs comblés, plus propices à dépenser !
Attention, l’agilité n’est pas une solution magique que l’on peut appliquer à toutes les organisations et tous les projets. Pour que cela marche, il faut remplir certaines conditions : une culture organisationnelle qui favorise la collaboration et qui ne repose pas sur des structures trop rigides, une équipe pluridisciplinaire et un client disponible et prêt à s’impliquer dans le projet.
Aussi, il existe quelques limites à l’agilité. Par exemple, si l’absence de processus bien défini favorise l’indépendance des équipes, cela peut aussi les distraire. Il est donc important de mettre en place des moyens pour coordonner chaque acteur et également des moyens pour mesurer l’avancement, en définissant notamment des indicateurs clés de performance, afin de ne pas trop se perdre. D’autre part, par l’imprévisibilité de la méthodologie agile, il est difficile de déterminer le coût, les ressources nécessaires et le temps du projet et ça, il faut le prendre en compte avant de se lancer.
Et si la méthode Agile semble la "meilleure" solution, elle n'est en réalité pas en opposition avec le cycle en V qui reste très adapté selon le projet. Tout est question de contexte et il convient donc d’étudier les deux méthodes pour déterminer laquelle est la plus adaptée à son projet.
Quant à la question : « comment inscrire la méthodologie agile dans le domaine du test », cela fera l’objet d’un prochain article ! Il faut bien qu’on vous donne envie de revenir 😉