Dans les métiers des technologies de l’information, rare est celui qui n’a jamais entendu parler de l’agilité. Cependant la mise en place de l’agilité est parfois difficile, notamment dû à la multitude d’interprétations possibles. Pour cette raison, nous publierons ici quelques articles sur ce sujet. Commençons par définir ce que c’est l’agilité.

Définition de l’agilité

L’origine du terme Agile remonte au Manifeste Agile (2001). C'est une publication pour laquelle dix-sept experts du domaine du développement logiciel se sont réunis. Le but était de débattre les points communs entre leurs différentes méthodes de développement. Ainsi nait le Manifeste se basant sur quatre valeurs et douze principes présentés ci-dessous :

Valeurs de l'agilité

1. Les Individus et leurs interactions plus que les processus et les outils ;

2. Des logiciels opérationnels plus qu'une documentation exhaustive ;

3. La collaboration avec les clients plus que la négociation contractuelle ;

4. L'adaptation au changement plus que le suivi d'un plan.

Les auteurs du Manifeste reconnaissent la valeur des éléments à droite du “plus que”. Mais, ils priorisent clairement les éléments à gauche. Ainsi, l’agilité ne signifie pas une absence complète de processus. Mais, la mise en place uniquement des processus qui améliorent et soutiennent les interactions entre les individus.

En décrivant chaque valeur plus en détail :

1. Les Individus et leurs interactions, plus que les processus et les outils ;

1. Les outils et les processus sont importants, mais il est plus important que des personnes compétentes travaillent ensemble efficacement. Un exemple serait : l’entreprise veut mettre en place des protocoles pour la réalisation des interactions entre les différentes équipes, mais le protocole lui-même prend du temps à réaliser. Ceci arrive souvent dû au fait que l’organisation mette en place ses processus en anticipant le besoin, et pas forcément de la façon la plus efficiente. Une approche agile pour ceci pourrait être de laisser les interactions se mettre en place naturellement, puis venir formaliser dans un processus si cela s’avère nécessaire ;

2. Des logiciels opérationnels, plus qu'une documentation exhaustive ;

• Une bonne documentation est utile pour aider les gens à comprendre comment le logiciel est construit et comment l'utiliser, mais le principal point de développement est de créer un logiciel, pas une documentation. L’organisation des demandes d’évolution par les utilisateurs en User Stories est la matérialisation de cette valeur, une fois que ça représente une documentation suffisante pour que le développeur puisse travailler sur le logiciel ;

3. La collaboration avec les clients, plus que la négociation contractuelle ;

• Un contrat est important mais ne remplace pas une collaboration étroite avec les clients pour découvrir ce dont ils ont besoin. Dans les autres méthodologies de gestion de projet informatique, le travail de développement ne commence qu’après une longue étape de négociation du contrat. Le client doit spécifier toutes ses demandes avant que tout développement soit fait. Dans une implémentation agile, le travail de développement peut commencer sans que tout soit forcément défini, et avoir le client en tant que collaborateur permet à ce que celui-ci fasse évoluer les demandes par rapport à l’évolution de sa propre compréhension du sujet. Bien sûr qu’’il subsiste un contrat au sens commercial du terme avec une approche agile. Dans cette troisième valeur du Manifeste Agile, la notion de contrat concerne plus la façon de travailler au quotidien avec le client. Il est important de mettre en place une relation de travail avec les différentes parties prenantes du client plus collaborative qu’une relation client/fournisseur.

4. L'adaptation au changement, plus que le suivi d'un plan.

• Un plan de projet est important, mais il ne doit pas être trop rigide pour tenir compte des changements technologiques ou environnementaux, des priorités des parties prenantes et de la compréhension des gens du problème et de sa solution. Ce n’est pas pour dire que dans l’agile il n’y a pas de plan, mais que ceux si sont adaptés régulièrement, à chaque cycle de développement, afin d’apporter le maximum de valeur par rapport aux besoins du client. Les courtes périodes de temps dans lesquelles s’organisent le développement permet que ces changements puissent être rapidement pris en compte, et qu’à la fin le logiciel soit plus en accord avec l’évolution du besoin du client.

Principes de l'agilité

1. La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

Comme à la fin de chaque itération (sprint) d’un projet en Scrum, il y a la livraison d’un nouveau code opérationnel, le client s’aperçoit de la valeur que lui apporte le travail réalisé, et est content de pouvoir observer continuellement le progrès du logiciel. A noter qu’il en serait de même avec d’autres approches agiles comme Kanban qui prône aussi des livraisons régulières du produit. Ce format de travail permet que les utilisateurs aient souvent du code qui réponde à leur besoin présent, évitant ainsi qu’il se passe des dérives entre le développement et le besoin du client qui peut changer;

2. Accueillir 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.

Le développement en mode Agile priorise la livraison d’un code de qualité et en accord avec les besoins du client. Si jamais le client exprime des changements de besoins, il vaut mieux donc les incorporer et livrer les changements qu’éviter les changements et livrer un produit qui ne convient pas au besoin actuel du client. Ceci implique d’avoir des pratiques de développement et de test pour assurer la qualité du travail livré, comme par exemple l’automatisation des tests et du déploiement dans une chaîne de Continuous Delivery;

3. Livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

Ce principe vient limiter l’occurrence de l’effet tunnel dans la gestion du projet. Les cycles plus courts permettent à l’équipe de découper le projet en sous-tâches qui peuvent être réalisées dans un seul cycle, ainsi qu’aux utilisateurs d’avoir une vue régulière de l’avancement du projet ;

4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

La collaboration constante avec les utilisateurs va permettre qu’à la fin du projet le résultat soit le plus satisfaisant possible pour le client, une fois qu’il a pu intervenir de manière régulière pendant tout le procès de développement ;

5. Réaliser les projets avec des personnes motivées. Leur fournir l’environnement et le soutien dont ils ont besoin et leur faire confiance pour atteindre les objectifs fixés.

Si les équipiers sont motivés et contents avec leur environnement de travail, ils vont donner un meilleur résultat que dans le cas contraire. Une manière de le faire c’est de leur donner l’autonomie de s’auto-organiser et de prendre leurs propres décisions ;

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.

Il vaut mieux toujours prioriser des méthodes de communication directe, plutôt que d’avoir les informations échangées par email par exemple ;

7. Un logiciel opérationnel est la principale mesure d’avancement.

Sans un logiciel opérationnel n’importe quel autre critère de mesure d’avancement du projet est inutile ;

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.

Il est extrêmement important que la capacité de l’équipe à livrer des évolutions au logiciel à la fin de chaque sprint soit maintenue, pour assurer que le projet aboutisse avec le besoin du client comblé, et aussi pour conserver l’efficience et l’implication des individus sur la construction du produit ;

9. Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.

Il faut que l’équipe soit techniquement capable d’assurer l’absorption des changements. Ceci se produit par des choix de design de code qui acceptent facilement le changement, par des pratiques de développement (ex: TDD, Continuous Delivery) qui limitent les risques de friction du code vis à vis des changements ;

10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

Idéalement le travail réalisé doit être exactement le suffisant pour atteindre les Definition Of Done décrites dans l’User Story ;

11. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.

Ces équipes ont généralement une communication plus ouverte, ce qui engendre un plus grand partage d’idées et permet donc de trouver les meilleures solutions en se basant sur l’intelligence collective ;

À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Comprendre ce qui aurait pu/dû être fait différemment permet à l’équipe de livrer plus rapidement des résultats. La rétrospective est l’un des principaux mécanismes qui permet cette instrospection régulière.

En résumé, la définition de l’agilité selon le Manifeste Agile est un état d’esprit reposant sur des valeurs et des principes, et mis en œuvre par des pratiques, comme les exemples montrés ci-dessus. Pour aller plus loin dans l'agilité vous pouvez vous rapprocher de nos expertises agiles et nous contacter pour être accompagné dans ces méthodologies agiles.

Intérêt de l’agilité

Les pratiques agiles font face dans le monde de l’IT à d’autres méthodes, brièvement décrites ci-dessous :

Modèle Cascade - Waterfall

Le modèle en cascade est une décomposition des activités du projet en phases séquentielles linéaires, où chaque phase dépend des livrables de la précédente et correspond à une spécialisation des tâches. L'approche est typique de certains domaines de la conception technique. Dans le développement de logiciels, il a tendance à être parmi les approches les moins itératives et flexibles, car les progrès se déroulent dans une grande direction ("vers le bas" comme une cascade) à travers les phases de conception, d'initiation, d'analyse, de conception, de construction, de test, de déploiement et de maintenance. C’est un modèle dit incrémental.

Avantages et Inconvénients

AvantagesInconvénientsSimple à utiliser et à comprendreLe logiciel n’est prêt qu’à la fin de la dernière étapeSimplicité de gestion grâce à sa rigidité : chaque phase a un résultat et une revue de processus définisRisques et incertitudes élevés. La rigidité du modèle fait que tout écart par rapport au plan initial soit cher, voire impossibleFacile à classer et à hiérarchiser les tâchesPas le meilleur choix pour les projets complexes. Ceci est dû au fait que l’étape de tests vient tard dans le cycle de développement du projet, et n’importe quelle erreur peut engendrer des délais significatifsParfait pour les petits ou moyens projets où les exigences sont clairesInapproprié pour les projets à long termeFacile à déterminer les points clés du cycle de développementLe client est mis de côté pendant le développement du projet, ce qui peut les rendre inconfortables et mécontents par leur manque d’opinion au final

Les cas d’usage pour la méthode en Cascade :

• Les besoins sont précisément documentés ;

• La définition du produit est stable ;

• La pile de technologies est prédéfinie, ce qui la rend non dynamique ;

• Aucune exigence ambigüe ;

• Le projet est court en délai et pas techniquement complexe.

Cycle en V

Le modèle du Cycle en V résume les principales étapes à suivre en conjonction avec les livrables correspondants dans le cadre de validation du système informatisé ou le développement du cycle de vie du projet. Il décrit les activités à réaliser et les résultats à produire lors du développement du produit. Ce modèle est issu du modèle en cascade dont il reprend l'approche séquentielle des phases, en l’enrichissant d’activités de validation pour chaque composant élémentaire de la phase de production. C’est aussi un modèle dit incrémental, venant renforcer l’étape de validation du modèle en cascade pour assurer une meilleure qualité.

AvantagesInconvénientsChaque étape du modèle Cycle en V a des résultats précis, donc sont faciles à contrôlerManque de flexibilitéLes tests et la vérification ont lieu dès les premières étapesSi jamais il y a des changements en cours du projet, la documentation des besoins ainsi que des tests doivent être mises à jourBon pour les petits projets où les exigences sont statiques et clairesRisques de dérive du projet (coût, qualité, délai...) relativement importants. Dû au fait qu’il n’y a pas de logiciels intermédiaires à valider avec le client, il se peut que le comportement final ne soit pas en accord avec ses attentes

Méthodes Incrémentales et Itératives

Les méthodes décrites ci-dessus sont incrémentales, ce qui pourrait être décrit par les images suivantes :

Les images ci-dessus nous montrent que dans une méthode incrémentale, nous avons une vue de l’objet final tel qu’on le veut. Cependant, à aucun moment avant la toute fin nous n’avons quelque chose d’utilisable.

Des adaptations de ces méthodes sont aussi possibles en ajoutant des itérations aux étapes de développement, ce qui reviendrait aux résultats ci-dessous :

En comparaison aux méthodes incrémentales, les méthodes itératives commencent avec une idée initiale moins claire de l’objet final. Les premières étapes sont déjà cadrées par l’idée initiale, et sont ensuite raffinés jusqu’à l’obtention d’un résultat validé.

En contrepartie à ça, les méthodes agiles sont décrites comme étant itératives & incrémentales :

Ici nous avons une méthode qui part du même principe que l’itératif, de commencer par une idée pas très claire sur le résultat final. Cependant, le développement du projet se fait par des parties qu’une fois complétées sont considérées comme étant finies, comme pour les projets incrémentaux.

Conclusion

L’agilité est un concept qui existe depuis une vingtaine d’années déjà, mais qui continue à être peu/mal appliquée dans la pratique.

Les méthodes agiles offrent plus de flexibilité aux projets quand comparés aux méthodes plus rigides couramment utilisées. Ainsi elle se différencie par des logiciels mieux conçus par rapport aux besoins des utilisateurs, vu la proximité de ceux-ci tout le long du procès de conception. L’augmentation de l’efficacité du travail de l’équipe de développement (par l’autonomie garantie aux professionnels), l’interaction constante avec les utilisateurs du logiciel, ainsi que des cycles de développement et livraison courts sont les clés de la réussite des projets menés en méthodes agiles.

Grâce aux multiples itérations, les coûts des changements de besoins (aussi connus comme coûts du délai) sont moindres par rapport aux projets en Cycle en V.

Pour commencer un projet en suivant une méthodologie agile, le planning initial peut et doit être minimaliste, voire quasi inexistant. Une vision du produit souhaité, ainsi qu’une première description des fonctionnalités à plus forte valeur sont suffisants pour pouvoir commencer le projet.

Permettre aux clients d’avoir progressivement des solutions à leurs problèmes revient aussi à une plus grande satisfaction avec le travail réalisé par les développeurs.

J’espère que cet article pourra vous être utile pour avoir une meilleure compréhension de ce qu’est l’agilité, et de quelques exemples de pratiques qui peuvent être adaptées dans votre travail. Le prochain article sera au sujet du rôle de Product Owner dans une équipe agile. Ce rôle a souvent des facettes moins connues et ça sera l’occasion de les aborder. Suivez attentivement le blog d'invivoo pour ne pas passer à côté. 😉

Pour toute question ou commentaire relatif à cet article, n’hésitez pas à me laisser un message ci-dessous.