Tout d’abord, rappelons le, la gestion de projets en mode agile repose sur 4 piliers : l’équipe, la collaboration, l’acceptation du changement et l’importance de la solution (produit/service). Aujourd’hui c’est l’Agilité Scrum qui est la méthode la plus utilisée mondialement. Mais comment expliquer un tel succès ?
Dans cet article, nous vous livrerons 9 caractéristiques qui font de la méthode Agile un succès hors norme !
Versions de développement et itérations
Les méthodes de développement de logiciels agiles ont deux unités principales de livraison : les versions et les itérations.
Une version se compose de plusieurs itérations, chacune considérée comme un micro-projet en soi. Ainsi, les fonctionnalités, défauts, demandes d’amélioration et autres éléments de travail sont organisés, estimés et hiérarchisés, puis affectés à une version. Enfin, ces éléments de travail sont ensuite affectés par priorité aux itérations.
Vous l’aurez donc compris, le résultat de chaque itération est un logiciel fonctionnel, testé, accepté et les éléments de travail associés. Pour faire simple, c’est le flux continu de nouvelles fonctionnalités testées et en cours d’exécution à chaque itération qui fournit le retour d’information permettant à l’équipe de garder à la fois le projet et le système sur la bonne voie. Et ce n’est donc qu’à partir de ces fonctionnalités qui émergent des itérations de durée fixe (« time boxed ») que vous pouvez obtenir des réponses significatives à vos questions telles que le nombre de tâches accomplies par rapport au mois dernier, vos objectifs, etc.
Ainsi votre équipe peut réellement voir et ressentir comment chaque semaine, chaque jour et chaque heure compte. Tout le monde peut ainsi s’entraider pour rester concentré sur la valeur commerciale la plus élevée possible par unité de temps. À chaque itération, l’équipe planifie, teste et livre un logiciel fonctionnel. À chaque version, l’équipe planifie, teste et déploie des logiciels en production.
N’oubliez pas, afin de livrer un produit avec succès, la communication et la collaboration de l’équipe sont essentielles tout au long du processus de développement agile.
Des logiciels fonctionnels et testés
Fournir des fonctionnalités fonctionnelles et testées est la ligne directrice d’une équipe de développement agile. En effet, les fonctionnalités dites de travail servent de base pour permettre et améliorer la collaboration d’équipe, les commentaires des clients et la visibilité globale du projet. Elles fournissent ainsi, la preuve que le système et le projet sont sur la bonne voie.
Pour cause, dans les premières itérations d’un nouveau projet, l’équipe peut ne pas fournir de nombreuses fonctionnalités instantanément. Ce n’est qu’en quelques itérations, que l’équipe atteint généralement son rythme.
Au fur et à mesure que le système émerge, la conception de l’application, l’architecture et les priorités commerciales sont évaluées en permanence. À chaque étape du processus, l’équipe travaille pour converger vers la meilleure solution d’entreprise, en utilisant les dernières contributions des clients, des utilisateurs et d’autres parties prenantes. Vous vous en doutez, le fait de pouvoir mesurer constamment le succès grâce à un logiciel réel donne à un projet de développement agile un sentiment très différent par rapport aux projets traditionnels. Les programmeurs, clients, gestionnaires et autres parties prenantes sont concentrés, engagés et surtout confiants.
Un développement axé sur la valeur
Comme dit précédemment les méthodes de développement Agile se concentrent rigoureusement sur la création précoce et continue de la valeur commerciale. Il est donc primordial que l’équipe se concentre sur les fonctionnalités du produit en tant qu’unité principale de planification, de suivi et de livraison. De semaine en semaine et d’itération en itération, l’équipe suit le nombre de fonctionnalités testées et en cours d’exécution qu’elle propose. Elles peuvent également nécessiter des documents et d’autres artefacts, mais les fonctionnalités de travail sont primordiales. Cela nécessite à son tour que chaque “fonctionnalité” soit suffisamment petite pour être fournie en une seule itération.
Ce n’est pas tout ! Se concentrer sur la valeur commerciale nécessite également que les fonctionnalités soient hiérarchisées et livrées par ordre de priorité.
Une planification continue et adaptative
Beaucoup de personnes pensent encore aujourd’hui que les méthodes agiles interdisent la planification initiale. Et bien c’est un mythe !
Il est vrai que les méthodes agiles insistent pour que la planification initiale soit tenue responsable des ressources qu’elle consomme. Cependant, la planification agile se base autant que possible sur des données historiques solides et non sur des spéculations.
Ce n’est pas tout, les méthodes agiles insistent pour que la planification se poursuive tout au long du projet. Le plan doit donc démontrer en permanence son exactitude : personne sur un projet agile ne tiendra pour acquis que le plan est réalisable. Ainsi, au lancement du projet, l’équipe de développement fait juste assez de planification pour commencer l’itération initiale et, le cas échéant, pour mettre en place un plan de version de haut niveau des fonctionnalités.
Vous l’aurez compris, l’itération est la clé d’une planification continue.
Considérez chaque itération comme un mini-projet qui reçoit « juste assez » de sa propre planification. Au début de l’itération, l’équipe sélectionne un ensemble de fonctionnalités à implémenter, identifie et estime chaque tâche technique pour chaque fonctionnalité. C’est pourquoi l’estimation des tâches est une compétence agile essentielle.
Enfin, ce même processus de planification se répète à chaque itération.
Une planification à plusieurs niveaux
Il est important de notifier que la planification continue est beaucoup plus précise si elle se produit à au moins deux niveaux :
– Au niveau de la version, en identifiant et hiérarchisant les fonctionnalités qu’il doit y avoir, que vous aimeriez avoir et dont vous pouvez vous passer avant la date limite.
– Au niveau de l’itération, en sélectionnant et planifiant le prochain lot de fonctionnalités à implémenter, par ordre de priorité. Si les fonctionnalités sont trop volumineuses pour être estimées ou fournies en une seule itération, il faut les décomposer davantage.
Ainsi, au fur et à mesure que les fonctionnalités sont hiérarchisées et planifiées pour une itération, elles sont décomposées en des tâches techniques distinctes.
Cette approche est plus simple et plus précise que la planification initiale à grande échelle, car elle aligne le niveau d’informations disponibles sur le niveau de détail nécessaire à ce moment-là. Il n’y a donc pas de suppositions folles sur des fonctionnalités futures, ni de perte de temps.
L’estimation relative
Vous l’avez surement déjà entendu, de nombreuses équipes de développement Agile utilisent la pratique de l’estimation relative des fonctionnalités pour accélérer la planification et éliminer la complexité inutile. Ainsi, au lieu d’estimer les caractéristiques sur un spectre de longueurs unitaires, les membres de l’équipe sélectionnent quelques (3 à 5) catégories d’estimation relatives, ou groupes, et estiment toutes les caractéristiques en fonction de ces catégories.
Par exemple, une fonctionnalité de 3 jours devrait prendre 3 fois plus longtemps qu’une fonctionnalité de 1 jour, tout comme une fonctionnalité de 40 heures prend environ 5 fois plus de temps qu’une fonctionnalité de 8 heures. Le temps et les efforts importants économisés en planifiant avec ce type de processus l’emportent souvent sur les coûts d’estimations imprécises.
Cependant, si une fonctionnalité dépasse une estimation maximale convenue, elle doit être subdivisée en plusieurs fonctionnalités. Donc, si l’équipe détermine que les fonctionnalités ne doivent pas dépasser 5 jours idéaux, alors toute fonctionnalité qui dépasse 5 jours doit être divisée en fonctionnalités plus petites.
Les fonctionnalités émergentes
Comme dit précédemment, au lieu de passer des semaines ou des mois à détailler les exigences avant de lancer le développement, les projets de développement agile hiérarchisent et évaluent rapidement les fonctionnalités, puis affinent les détails si nécessaire. C’est pourquoi, les fonctionnalités d’une itération sont décrites plus en détail par les clients, les testeurs et les développeurs travaillant ensemble.
Enfin, des fonctionnalités supplémentaires peuvent être identifiées, mais aucune fonctionnalité n’est décrite en détail jusqu’à ce qu’elle soit priorisée pour une itération.
Le test continu
Grâce aux tests continus, il est plus simple de mesurer les progrès de manière déterministe et de prévenir les défauts.
Quoi de plus risqué que de reporter tous les tests jusqu’à la fin du projet ? De nombreux projets en cascade ont échoués lorsqu’ils ont découvert, dans une phase interminable de tests et de réparation de projets tardifs, une architecture fatalement défectueuse, des composants ne pouvant être intégrés, des fonctionnalités inutilisables ou des défauts ne pouvant être corrigés à temps.
Mais pas de panique ! C’est là qu’interviennent les tests continus en évitant le risque que cela se produise et la peur constante de celui-ci !
Il existe une multitude de nouveaux outils, techniques et meilleures pratiques pour des tests continus rigoureux. Une grande partie de l’innovation provient de la communauté du développement piloté par les tests (TDD).
Mais quand une fonctionnalité est-elle terminée ? La réponse est simple : lorsque tous ses tests unitaires et tests d’acceptation réussissent et que le client l’accepte. C’est exactement ce qui définit une fonctionnalité testée en cours d’exécution. Il n’y a pas de meilleure source de mesures de projet significatives et hautement visibles.
Une petite équipe interfonctionnelle
C’est bien connu, les petites équipes de développement Agile se sont avérées beaucoup plus productives que les équipes plus importantes, l’idéal allant de cinq à dix personnes.
Si vous devez étendre un projet à plus de personnes, faites tout votre possible pour réduire au maximum les équipes individuelles et coordonner les efforts entre les équipes.
Une équipe de développement agile doit inclure des membres possédant toutes les compétences nécessaires pour livrer avec succès des logiciels, y compris l’analyse, la conception, le codage, les tests, l’écriture, la conception, la planification et la gestion de l’interface utilisateur.
Encore une fois, chaque itération est son propre mini-projet.
Et voilà vous savez maintenant tout sur la Méthode Agile et ses caractéristiques qui font d’elle un réel gage de succès !
À vous de vous lancer dans l’aventure 🙂
