La méthode agile ou méthodologie agile définie une approche pour mener à bien un projet informatique grâce aux principes et aux valeurs du manifeste agile. La méthode agile est jugée comme « la méthode » de gestion de projet moderne pour des équipes plus heureuses. Depuis sa création en 2001, plusieurs des signataires l’ayant imaginé se sont rétractés.
Qu’est-ce que le manifeste agile ?
Le manifeste agile est un ensemble de 4 valeurs sur lesquelles ont émergé 12 principes par 17 informaticiens aussi appelés les signataires originels du manifeste ; en Février 2001. Le manifeste agile se présente comme un guide pour les équipes (développeurs, mais pas que) dans le cadre de la réalisation d’un projet informatique.
Qu’est-ce que les méthodes agiles ?
Les méthodes agiles sont des méthodes qui découlent de la philosophie du manifeste agile. Elles sont censées donner des outils ou un cadre afin de pouvoir appliquer un ou plusieurs des 12 principes tout en respectant également les 4 valeurs.
#
Quel est l’intérêt d’utiliser la méthode agile pour un projet informatique ?
Les inventeurs des méthodes agiles ont tenté de trouver une solution au fait que bon nombre de projets informatiques échouent avant même d’être livrés en production.
C’était le cas en 2001, et c’est toujours le cas aujourd’hui !
https://agilemanifesto.org
Globalement, les méthodes agiles sont décrites comme plus proche du client et de l’utilisateur.
On utilise le terme « user-centric » (centré sur l’utilisateur).
L’idée est d’être super réactif aux demandes du client grâce à des cycles de développement très courts.
L’intérêt ?
Comme tous les développeurs le savent, le client va souvent changer d’avis au cours d’un projet (et c’est bien normal).
De même, les estimations de début de projet sur le planning sont rarement respectées au fur et à mesure que le projet avance (et change).
En fonctionnant avec des cycles plus courts, on serait ainsi capable de mieux anticiper les changements dans le projet.
Et de pouvoir « tenter de livrer » de vraies fonctionnalités en un temps donné.
Si c’est un peu flou, sache qu’on développe l’ensemble des 12 principes juste en dessous. 👇
#
Agile n’est pas Scrum ou Extreme Programming
Une des méthodes agiles les plus populaires (si ce n’est la plus populaire) est Scrum.
Scrum est donc une implémentation du manifeste agile (un framework), qui tente d’appliquer les principes et les valeurs du manifeste agile en proposant un cadre, une méthode.
On la qualifie de méthode agile.
Il faut savoir que le manifeste n’est qu’une suite de 4 valeurs et de 12 principes.
Il ne fournit ni méthode, ni outil, ni pratique, ni quoique ce soit d’autre.
C’est pour cela que les méthodes agiles sont arrivées.
Ce sont des outils pour aider l’équipe projet à fonctionner en mode agile.
Scrum est donc (entre autres), une méthode, une méthodologie, un framework…
Tout comme le sont Extreme Programming, Kanban, BDD ou Crystal Clear.
Ces outils agiles, bien qu’issus du manifeste ne sont pas absolus.
C’est d’ailleurs la raison pour laquelle plusieurs signataires du manifeste agile se sont finalement rétractés.
Le manifeste agile étant une liste de principes et de valeurs, ces derniers sont libres à interprétation.
Et c’est là tout le problème…
Les outils dont je te parle ici peuvent être mal ou partiellement appliqué.
Voire eux-mêmes mal conçus.
L’application de la méthode agile ne peut donc pas être la même dans toutes les entreprises…
#
Qui a écrit le manifeste Agile ?
Au total, 17 informaticiens se sont réunis pour tenter de mettre sur la table leurs méthodes de développement afin d’en faire un processus, une méthode.
La méthode agile est née !
Voici les 17 informaticiens qui ont élaboré les méthodes agiles.
En février 2001, les 17 informaticiens suivants ont imaginé le manifeste agile
Andrew Hunt (coauteur de « The Pragmatic Programmer: From Journeyman to Master »)
Alistair Cockburn (auteur de l’architecture hexagonale et de la méthode « Crystal clear »)
Pour beaucoup de développeurs, la méthode agile ne fonctionne réellement que si quelqu’un d’expérimenté tente de l’appliquer dans son équipe.
Les méthodes agiles ne sont pas qu’une simple suite d’outils et de méthodes.
Il y a une méthodologie derrière, des valeurs, des principes…
La méthode agile souhaite démocratiser la compréhension du développement pour éviter ce genre de situation :
J’espère que les deux développeurs là-bas qui font du pair vont produire deux fois plus de code.
Tout le monde ne comprend pas l’intérêt des méthodes agiles
Il faut sensibiliser les équipes et la direction au métier de développeur.
C’est essentiel dans la méthode agile.
L’agilité ne doit pas être imposée mais choisie
« On va faire de l’agile parce que c’est bien ».
Cette phrase bien que réaliste illustre un léger manque de clairvoyance.
La méthode agile a été conçue par et pour des développeurs.
Son adoption pour qu’elle soit réussie doit faire consensus.
La décision de choisir les méthodes agiles doit venir de l’équipe, pas d’une seule personne.
Attention donc à son application / imposition par des consultants extérieurs à l’équipe.
Le changement peut ou ne pas être bien accueilli si les valeurs de l’équipe sont détruites pour y instaurer un nouveau cadre.
Et cela, même si les bénéfices sont connus de tous.
Le choix de la méthode agile est une décision commune.
C’est la meilleure manière de garder une équipe proactive et motivée !
Le manifeste agile n’est pas parfait
Les valeurs du manifeste sont discutables, comme cela l’est pour toute valeur d’ailleurs.
Faire le choix d’un outil c’est aussi accepter ses défauts.
Prenons par exemple :
« Accueillez positivement les changements de besoins, même tard dans le projet ».
Principe agile numéro 2
En thoérie oui, en pratique, c’est compliqué.
Tout projet demande de l’anticipation, il faut prévoir les équipes, affecter les bonnes personnes, gérer les arrivées et les départs.
Seulement si un changement massif arrive en milieu ou en fin de projet, il n'est pas dit que l'équipe puisse y répondre : par manque de développeurs à affecter au projet, par manque de compétences, par manque de spécification.
Bref, faire un virage à 180° n’est jamais facile.
On peut accueillir positivement le changement oui.
Mais dans les faits, on fait ce qu’on peut pour faire « au mieux ».
#
Manifeste Agile : les 4 valeurs
Chaque valeur du manifeste est orientée ainsi :
<élément à privilégier> plus que <autre élément (moins) important>
Attention, le manifeste agile n’exclut pas du tout la partie de droite (la partie moins importante).
C’est simplement que l’on préfère mettre l’accent sur la première partie.
Plutôt que sur la deuxième.
Ça a l’air bête dit comme ça, mais je t’assure que ça ne l’est pas.
Parfois on va tellement loin dans une interprétation que l’on pourrait être tenté de quasi-exclure la partie de droite.
Elle reste tout de même importante.
#
Valeur 1 : Les individus et leurs interactions plus que les processus et les outils
Cette première valeur du manifeste agile se veut bienveillante à l’égard des collaborateurs qui travaillent sur le projet.
Le monde a tendance à déshumaniser le travail de développeur.
On parle de ressource, d’IED, d’ETP pour qualifier des développeurs.
Oui, on est parfois traité comme des objets.
La méthode agile veut justement inclure le développeur non pas comme une ressource, mais une partie importante du projet.
Manifeste Agile principe 1
Un développeur qui doit comprendre le but fonctionnel de ce qu’il fait, les intentions de la demande, là où la livraison va nous amener.
Il doit cerner le besoin.
Le « pourquoi » il code quelque chose.
À titre perso ça me rend dingue que les développeurs ne soient pas plus inclus sur le fonctionnel.
J’ai déjà entendu.
« Franchement je codais en fonction du ticket mais je ne comprenais rien à ce que ça allait faire. »
Un développeur perdu.
C’est typiquement ce que l’on veut éviter !
Les développeurs doivent pouvoir comprendre ce qu’ils font pour pouvoir donner eux aussi leur avis.
Remettre le développeur au cœur du métier et l’inclure dans le projet, c’est la première valeur.
#
Valeur 2 : Des logiciels opérationnels plus qu’une documentation exhaustive
La documentation doit être faite au fur et à mesure que le développement avance.
Ni trop en amont. Ni trop en aval.
Si tu fais ta documentation trop tôt : tu vas devoir y revenir, car ton développement aura évolué.
Si tu fais ta documentation trop tard : elle ne sera pas viable, car tu risques d’y avoir oublié des éléments.
La méthode agile souhaite que la documentation soit simple, efficace, facilement maintenable.
Elle n’est pas censée (au sens agile) être exhaustive.
Manifeste Agile principe 2
Il vaut mieux se concentrer sur un logiciel impeccable plutôt qu’une documentation impeccable.
L’idée derrière, c’est de ne pas se cacher derrière l’écriture de la documentation pour ne pas avancer sur le projet.
Mais ne me fais pas dire ce que je n’ai pas dit.
La documentation est essentielle !
Mais le moment de l’écrire l’est tout autant.
Donc pas en fin de projet ou au départ d’un collaborateur…
#
Valeur 3 : La collaboration avec les clients plus que la négociation contractuelle
Ce que l’on entend par collaboration, c’est d’inclure le client au proche de l’équipe de développement afin que le feedback soit immédiat (ou presque !).
Et…
De ne pas s’arrêter sur les termes du contrat.
La méthode agile anticipe que les besoins changent au cours du projet, il ne faut pas rester rigide.
Bien entendu, il faut toujours s’entendre avec le client sur :
La faisabilité du projet techniquement
Le planning
Les deadlines
Le budget
Les décalages, de l’ajout de fonctionnalités
Les user-stories / le cahier des charges / les spécifications fonctionnelles
La contractualisation
…
Manifeste Agile principe 3
Le projet ne doit pas être uniquement défini par son cahier des charges initial.
Il est évolutif en fonction des demandes (des besoins) du client.
Ce même client doit donc faire partie de l’équipe projet.
Le client, la MOA, la MOE, les développeurs (et plus si affinités) doivent communiquer un maximum entre eux.
Avoir les équipes fonctionnelles et techniques dans la même pièce permet d’avancer beaucoup plus rapidement et de réduire les risques d’incompréhension…
#
Valeur 4 : L’adaptation au changement plus que le suivi d’un plan
Cette dernière valeur suit de près la valeur précédente.
Comme tu le sais le client change d’avis ; parfois beaucoup.
Rien de plus normal, c’est humain.
Le concept, c’est de ne pas se dire :
Purée il fait chier le client, il ne sait jamais ce qu’il veut…
Un chef de projet « énervé »
Mais plutôt :
Les amis, on a un changement sur le ticket xxx via l’User Story xxx. Le client préférerait finalement xxx. Nous en avons discuté ensemble, il est au courant des avantages / inconvénients mais cette solution est indispensable pour sa stratégie de xxx.
Un chef de projet « agile »
Gardons le plan initial comme une ligne directrice.
Cette ligne n’est pas obligatoirement droite.
Elle peut être sinueuse, voire dans le pire des cas faire une boucle.
Manifeste Agile principe 4
La méthode agile sait que les changements vont arriver, alors autant s’y adapter vu que l’on devra s’y confronter.
Généralement l’objectif restera inchangé.
Il y aura simplement quelques ajustements de ladite ligne au cours du projet.
Par expérience, les personnes sachant s’adapter rapidement au besoin du client font des clients ravis.
Les besoins peuvent se remplacer, se substituer, changer…
Ne soyons pas rigides aux changements !
#
Manifeste Agile : les 12 principes
Le manifeste agile élaboré par nos 17 signataires comporte 12 principes.
Comme ce sont des principes, ils dépendent surtout de l’interprétation que l’on en fait.
En règle générale, la théorie est assez facile à interpréter !
C’est dans la pratique que le manifeste agile a du mal à faire sa place.
On discutera des méthodes agiles en tant qu’outils un peu plus bas.
Voici la théorie imaginée en 2001.
#
1) Livrer rapidement et régulièrement des fonctionnalités
Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
1er principe du manifeste agile.
Ce principe agile souhaite que les développeurs livrent fréquemment de nouvelles versions du logiciel sur lequel ils travaillent.
Tout l’intérêt, c’est que chaque nouvelle version se doit d’être fonctionnelle.
Il ne s’agit pas de livrer en continu une branche develop dégueulasse.
Mais plutôt de livrer un flux continu de (petites) nouvelles fonctionnalités sans casser les précédentes.
Dès que j’ai un set de 2 ou 3 tickets prêts et que leur recette technique est validée.
Je les merge pour les livrer en recette (sur le serveur d’intégration ou de préproduction quand il n’y en a pas).
Cela permet d’être beaucoup plus serein sur les dernières fonctionnalités à livrer avant la mise en production.
Tout livrer d’un coup fait peur à tout le monde, aux développeurs comme au client.
Livrer une grosse fonctionnalité comporte toujours un risque, même minime.
Alors en livrant rapidement et régulièrement des fonctionnalités, le client est content car il voit les développements avancer.
Et comme l’application a été testée et recettée tout au long des devs.
Tu sais qu’elle fonctionne bien.
Et ton client aussi.
La version originale en anglais
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
1er principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Confirmer les hypothèses de développement ;
S’assurer rapidement que les fonctionnalités créées correspondent à la demande client ;
Identifier les régressions au fil de l’eau et non tout à la fin pendant le rush…
Voir son projet avancer rend l’équipe consciente et heureuse ;
Les livraisons sont plus faciles à organiser car plus courtes ;
On recueille du feedback plus rapidement par le client, il y a donc moins de risque de décalage.
#
2) Accueillir positivement les changements de besoin du client
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.
2ème principe du manifeste agile.
Les changements d’avis du client… Un bonheur pour les développeurs.
On n’a pas du tout l’impression d’avoir travaillé pour rien !
Outre la frustration que cela provoque parfois, les changements font partie intégrante de notre boulot.
C’est comme ça.
Peu importe où tu iras, ce sera plus ou moins le cas.
Tu t’en rends moins compte, mais même quand tu bosses sur un projet perso.
Tu changes d’avis aussi.
C’est humain, et c’est normal.
Le problème dans le changement de notre code
C’est toujours compliqué de devoir casser une fonctionnalité pour y inclure une nouveauté.
On supprime rarement toute la fonctionnalité.
Généralement, on la modifie (beaucoup).
Le point positif, c’est que si tu as livré fréquemment (cf. le premier principe Agile).
Tu auras eu du feedback plus vite.
Tu pourras donc changer la fonctionnalité plus rapidement…
Avant que le château de cartes ne s’écroule !
Il faut aussi refactorer le code, tout au long du projet d’ailleurs.
Mais ça ne devrait pas être un problème.
Cette étape, parfois un peu relou, est obligatoire.
Ça fait partie du jeu, de toute manière, tu aurais dû le faire tôt au tard.
Le changement est un avantage
Pour ton client c’est clairement un avantage, car sa vision stratégique à l’instant T est mise en avant.
Cela lui permettra peut-être de rattraper un concurrent ou d'améliorer son chiffre d'affaires...
Mais c’est aussi le cas pour toi.
Savoir s’adapter est essentiel pour être compétitif.
C’est aussi une qualité incroyable que de savoir switcher d’approches.
En un mot : ce n’est pas grave.
Ton client paye pour le changement.
Et à moins que ton client ne paye pas ou qu’il change d’avis tous les jours (auquel cas il ne sait pas ce qu’il veut et il faut l’accompagner).
Accueillir positivement le changement devra se faire de préférence sans douleur.
Avec ou sans toi !
Accompagner le client dans le changement
Là où les projets risquent de finir à la poubelle…
C’est si ton client manque de budget pour prendre le temps de faire un changement proprement.
Dans les sociétés de services on connaît beaucoup ça.
Et si tu ne prends pas garde, chaque changement peut avoir un effet dévastateur.
Si la refactorisation du code n’est pas bien faite et immédiate…
Tu engendres de la dette technique alors que le projet n’est même pas encore livré en production.
Fais ça quelques fois par mois et dans 6 mois ton projet est inutilisable, personne ne voudra bosser dessus (voir principe 5).
La méthode agile veut accueillir positivement le changement oui, mais encore faut-il que cela soit bien fait.
La version originale en anglais
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
2ème principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Faire plaisir au client (oui, c’est un avantage ! Le rendre heureux nous rend heureux) ;
Avoir une architecture souple et modulaire, c’est un pas de plus vers l’excellence technique ;
Le changement est inévitable, alors autant l’accepter pour qu’il se passe sans douleur.
#
3) Livrer fréquemment un logiciel opérationnel
Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
3ème principe du manifeste agile.
Cela rejoint le principe 1 du manifeste Agile.
Alors pour éviter de paraphraser et résumer le principe en une phrase.
Faire des releases courtes.
Fini les releases monstrueuses de 6 mois qui, au moment de les merger, donnent des sueurs froides à toute l’équipe.
Ce n’est pas une règle absolue car ce n’est pas toujours possible.
Mais l’idée est de tendre vers cet objectif au maximum.
Livrer fréquemment n’est pas toujours possible
Pour donner quelques exemples simples, il m’est arrivé d’avoir des releases en cours pendant plusieurs mois dans ces 3 situations :
Une montée de version importante ou une migration du framework (c’est toujours long, les tests sont nombreux et le développement doit se faire en parallèle) ;
Un blocage technique notamment dû aux serveurs que l’application utilise ;
Une attente plus longue d’une API tierce fournie par un autre prestataire ça peut être très, très, très long…).
Si jamais tu es dans un cas comme celui-ci, mon conseil serait :
Merger le plus fréquemment la branche de production sur la branche de développement.
Naturellement, ça à ses limites.
Et si jamais ce n’est pas possible, il faut re-prioriser.
Plus ton backlog sera petit (la liste des tâches de la version en cours triées par priorité), plus tu pourras t’assurer que l’ensemble des fonctionnalités soient livrables et de qualité.
Planifier à trop grande échelle c’est souvent se mettre des bâtons dans les roues niveau planning.
Les tâches ne prennent jamais le temps que l’on avait estimé…
Et ça, la méthode agile le sait.
La version originale en anglais
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
3ème principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Garantir au client des livrables plus qualitatifs ;
Assurer le planning ;
Du feedback rapide, encore et toujours ;
Bonus : Comme livrer est une plaie sans intégration continue, cela force les équipes à adopter un workflow moderne.
#
4) Travailler ensemble tout au long du projet
Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
4ème principe du manifeste agile.
Une chose que l’on voit trop souvent :
Le client qui va utiliser l’application nous ramène les spécifications, elles sont revues avec l’équipe et pouf, le projet démarre.
Dès lors, on ne reverra le client qu’à la fin du projet.
La client (l’utilisateur) n’a pas été impliqué dans la réalisation du projet.
Ceci va poser plusieurs interrogations.
Les spécifications auront-elles été « interprétées » ou « comprises » ?
Le besoin aura-t-il été réellement compris, puis couvert ?
Le client découvre son projet à la fin, est-ce que ce sera conforme à ce qu’il a imaginé ?
Est-ce que les futurs utilisateurs de l’application seront satisfaits ?
…
Les développeurs doivent donc dialoguer avec les utilisateurs.
C’est primordial à la bonne conduite du projet !
La méthode agile en général se veut tournée vers le dialogue, pour tous les participants du projet.
« Tout au long du projet »
Si l’équipe projet comporte 10 personnes, les 10 doivent-elles assister à toutes les réunions ?
Sur les équipes projets nombreuses, certaines personnes font généralement le pont avec les équipes techniques.
Cela permet d’éviter les réunions avec le(s) client(s) à plus de 7 ou 8 personnes.
D’ailleurs, au-delà de 5 ou 6 personnes on peut se demander si la réunion est vraiment productive…
Aussi, si ce n’est pas utile à l’avancement du projet, le client ne doit pas forcément être présent.
Je pense que des réunions hebdos à raison d'un ou deux jours par semaine avec le client suivant la charge, ainsi qu'un compte rendu de fin de semaine est un must.
C’est pour moi le bon dosage entre trop et pas assez.
On garde ainsi tous les membres du projet impliqué à 100% dans sa réalisation.
Sans pour autant prendre tout le temps du client !
Comme ça de l’autre côté, les équipes projets peuvent s’organiser comme elles le veulent, notamment grâce aux daily meetings.
La version originale en anglais
Business people and developers must work together daily throughout the project.
4ème principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Les développeurs et l’équipe au sens large sont conscients du besoin client ;
Les utilisateurs eux, sont en accord avec les propositions des développeurs ;
Aucun écart de sortie ne sera constaté, étant donné que tout le monde s’est mis d’accord en amont ;
Si un membre d’une équipe part d’un côté ou de l’autre, ce dernier est aussitôt intégré dans la réalisation du projet ;
On garde le cap sur le besoin client le besoin des utilisateurs.
#
5) Réaliser le projet avec des personnes motivées
Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
5ème principe du manifeste agile.
Cela semble être une évidence hein ?
Eh bien ça ne l’est pas !
Entre les projets déjà pourris par la dette technique au bout de 6 mois et les renforts d’équipes sortants de nulle part…
Les développeurs ne sont pas toujours heureux et motivés de bosser sur les projets.
Encore plus quand il faut faire de la maintenance de vieilles applications sur lesquelles personnes ne veut bosser (mais ça, c’est un autre débat) !
Le concept de motivation est tellement propre à chaque individu, que pour le coup, c’est difficile de faire plaisir à tout le monde.
Comment éviter la frustration des développeurs ? (et garder une équipe motivée !)
Sur les projets sur lesquels je bosse, j’essaye toujours de faire au mieux pour éviter la frustration.
Je liste les pistes techniques sur les tickets pour éviter que les développeurs tournent en rond ;
Personne n’est fliqué, j’impose juste un workflow pour le statut des tâches et la livraison en recette qui doit comprendre des tests ;
Le code de tout le monde est vérifié via des Merge / Pull Requests (y compris celui du lead developer) ;
Les décisions sont prises par l’équipe, même si le lead peut trancher ;
La confiance est posée sur la table : prends tes responsabilités, propose des choses, prends des initiatives !
La frustration et la démotivation sont tes pires ennemis pour garder une équipe soudée.
Il faut gérer les problèmes avec tact…
Comme la méthode agile souhaite garder des utilisateurs motivés tout au long du projet, on doit donc gérer avec tact sûr :
Les choses que personnes ne veut faire ;
Les retours de recette ko (notamment les oublis de fonctionnalité dans les tickets) ;
La non-visibilité de ton équipe (avec le COVID et le remote c’est pire), parfois tu n’as pas de réponse sur le chat avant 1 ou 2 h, ou tu découvres après-coup qu’une personne est en congé ;
L’environnement en lui-même qui n’est peut-être pas parfait (dette technique, complexité, client exigeant etc) ;
La méthode agile veut inclure une équipe motivée afin d’avoir les meilleurs résultats possibles.
C’est loin d’être évident, mais il faut tout faire pour.
C’est ça le management agile.
Contrôler le travail de son équipe ?
Ma mère avait souvent l’habitude de dire (en souriant) :
La confiance n'exclut pas le contrôle.
Autant te dire que tu avais plutôt à être sûr du résultat de tes fractions !
En tant que responsable projet, on doit garder un œil sur la bonne tenue du projet.
Cela passe notamment par vérifier :
La qualité du code produit ;
Le temps alloué à chaque fonctionnalité ;
Le nombre de fonctionnalités livrées en fonction du temps estimé (si ça cloche, il y a un souci du côté de l’estimation ou du côté du développement) ;
J’essaye d’être au clair avec tout ça, même si les erreurs arrivent souvent.
Nous restons des humains.
J’essaye donc de donner le maximum de liberté à mon équipe, même si je me dois de la guider également.
Cela implique parfois de pester contre le manque de rigueur…
Notamment ceux qui commitent des putains deconsole.log().
On vous voit !
La version originale en anglais
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
5ème principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Une équipe motivée est bien plus productive et performante ;
Travailler avec des gens contents d’être là est un réel bonheur (pour toute l’équipe) ;
La frustration nuit à toute l’équipe, pas seulement à la personne concernée ;
L’hostilité n’a jamais rien de bon, ça finira toujours par retomber sur quelqu’un.
#
6) Dialoguer en face-à-face le plus possible
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.
Qu’est-ce qu’à prouver la mise en place du remote ?
Que les communications n’étaient pas si dégradées que ça.
Oui les équipes ont dû s’adapter ! Et comme pour tout changement, il faut prendre le temps.
Je fais toujours partie de ceux qui pensent que post-COVID, le remote se sera démocratisé.
Et encore plus pour les développeurs.
Voyons si l’avenir me donne raison !
Le télétravail casse-t-il ce principe agile ?
C’est une vraie bonne question.
Personnellement, je trouve que dialoguer en face-à-face est la meilleure façon de résoudre un problème ou d’avancer dans un schéma complexe.
C’est une histoire de ressenti, mais pas que.
Dans toutes les conversations en visio, dès qu’il y a plus de 4 interlocuteurs, c’est le bazar.
La visio, c’est le décalage de son, d’images, des problèmes techniques…
La communication non verbale intervient beaucoup moins.
Dès lors, certains se sentent exclut, parfois on parle en même temps, d’autres fois on ne peut même pas en placer une…
Pour moi, les réunions en visio ne sont pas toujours l’idéal dès que les interlocuteurs sont nombreux.
Mais ceci est à relativiser.
Des tas d’entreprises ne bossent qu’avec des équipes en remote.
Et tu sais quoi ?
Ça marche !
Comment privilégier le face-à-face ?
Commençons par dire qu’il faut faire au mieux.
L’écrit ne fonctionne pas toujours, notamment lorsque les échanges sont animés.
On se perd dans Slack, les mails sont un processus assez lourd, le téléphone fait souvent le job en 1 to 1, mais les autres membres de l'équipe n'en ont généralement pas connaissance...
Le vocal non plus ne fonctionne pas toujours, notamment lorsque beaucoup de choses sont dites et qu’il faut les organiser pour la suite.
Ou que les personnes autour de la table sont nombreuses.
Qui écrit le compte rendu de réunion déjà ?
Il faut utiliser le meilleur outil en fonction de ses besoins.
Et la meilleure approche consiste à n’exclure personne autant que possible.
Le face-à-face à distance
Ce face-à-face, il passe le plus souvent par un appel ou une visio.
Je l’utilise dès qu’il faut clarifier quelque chose qui n’est pas clair ;
Quand ça devient compliqué d’ordonner ses pensées sur le chat ;
Si un document a besoin d’être explicité (un compte rendu, une présentation PPT, …) ;
Quand une alerte doit être levée ;
…
Le reste du temps, j’utilises des moyens de communications asynchrones.
Certains me diront que l’on peut faire tout cela par mail.
Certes.
Mais je ne pense pas que ce soit le plus efficace.
Le face-à-face en présentiel
Ce face-à-face nécessite de se voir réellement.
Dès qu’un sujet important doit être abordé (un changement conséquent dans l’équipe, une nouvelle arrivée sur le projet, une synchronisation client… choisis ce qui est important pour toi) ;
Quand il y a besoin de signer des papiers ?
C’est tout.
Comme les enjeux sanitaires ne nous permettent pas de faire beaucoup mieux.
Je me suis restreint à ces cas-ci depuis plus d’1 an, et ça aussi ça marche plutôt bien !
La version originale en anglais
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
6ème principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Gagner en communication ;
Rassure le client d’avoir un « vrai interlocuteur » ;
Permet de ne pas créer d’incompréhensions (c’est souvent le cas sur le chat) ;
La sociabilisation est importante (surtout en ce moment) ;
L’échange en direct est le plus rapide et probablement le plus efficace pour véhiculer une idée.
#
7) Un logiciel opérationnel
Un logiciel opérationnel est la principale mesure d’avancement.
7ème principe du manifeste agile.
Tout est dit !
Si l’application sur laquelle tu es en train de travailler est terminée à 90%.
Alors 90% des fonctionnalités doivent être 100% fonctionnelles.
Si jamais tu estimes avoir livré 90% de l’app, mais que seules 50% des fonctionnalités sont opérationnelles…
On peut d’ores et déjà supposer que l’estimation du reste à faire n’est pas celle que tu penses.
Et que quelque part dans le planning, ça va dépasser.
Tu dois connaître le dicton :
Je viens de terminer mon application à 90%, j'espère que la seconde moitié des développements se passera tout aussi bien.
L’avantage de séparer en cycle de « petites » fonctionnalités.
C’est justement de pouvoir se concentrer sur la qualité et le bon fonctionnement de ces dernières.
Comment estimer le réel avancement ?
C’est parfois le genre de truc que l’on fait à vue d’œil sur les projets…
Sur des petits projets cela peut passer, mais dès qu’il y a trop de complexité en jeu, le risque de décalage planning devient trop important.
Les outils de ticketing aident beaucoup en ce sens.
La plupart sont capables de générer un Burn Down Chart ou équivalent.
https://en.wikipedia.org/wiki/Burn_down_chart
La courbe bleue représente l’idéal : soit 27 tâches en 20 jours
La courbe rouge représente le temps passé : au début cela a pris légèrement plus de temps qu’estimé, tout comme à la fin et un rééquilibrage a été fait au milieu (comme c’est souvent le cas)
Ce système se base sur une réévaluation continue du reste à faire.
Aussi, au jour le jour, tu peux simplement remplir une feuille Excel avec le temps :
Estimé (initialement)
Réellement consommé
Restant (temps réellement restant + temps restant estimé)
Le Burn Down Chart peut aider à mieux rentrer dans son planning en mesurant les tâches validées jusqu’ici.
Un logiciel opérationnel est la principale mesure d’avancement, donc.
La version originale en anglais
Working software is the primary measure of progress.
7ème principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Pour le client, 90% terminé signifie 90% des fonctionnalités livrées (pas 70% car il reste de petites coquilles à corriger) : on reste conforme à ses attentes ;
Cela permet de mieux ajuster le planning en fonction du reste à faire ;
Les user-stories sont aussi là pour aider, il faudrait livrer 100% de la fonctionnalité en cours avant d’en commencer une autre (on essaye de s’en tenir à ça du moins) ;
Livrer en recette quelque chose d’à moitié terminé est tout sauf un gage de qualité, il vaut mieux ne rien livrer.
#
8) Un rythme de développement soutenable (pas de rush)
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.
8ème principe du manifeste agile.
Le dépassement…
En temps ou en coût, c’est quelque chose que l’on rencontre quasiment systématiquement dans un projet.
Il est impossible d’arriver à estimer justement le temps de développement d’un projet au jour près.
Il y a toujours des imprévus
De la complexité non anticipée
Des évolutions qui viennent changer le besoin initial
Très rares sont les projets auxquels j’ai participé où on ne rush pas à la fin…
Parfois, j’ai pu absorber la partie de travail en plus.
D’autres fois j’ai dû la répercuter sur mes équipes…
Globalement, on se retrouve souvent dans la merde à cause des deadlines fixes, imposées par le client et / ou par l’entreprise.
Le discours de l’entreprise peut également jouer un rôle pour gagner la confiance d’un client.
"On n'est pas comme les autres, on respecte nos engagements sur les délais"
Et ce, même si les délais paraissent compliqués à tenir dès le début des développements.
Du coup, les équipes se retrouvent dans le rush à la fin pour terminer, voire pire, tout au long du projet.
C’est totalement contraire à la méthodologie agile.
On fatigue les équipes, on les démotive, la qualité de code ne sera probablement pas au rendez-vous…
Quoi qu’il en soit, quand on finit par bourriner à la fin, c’est souvent un manque d’anticipation.
Mais encore faut-il pouvoir anticiper…
Le rush tue les développeurs à petit feu
Tu as déjà dû entre le terme « burn-out » ou surmenage.
Ça arrive généralement aux développeurs à la fin de la livraison d’un projet.
Quand la pression retombe…
Paf.
Ton corps te signifie qu’il n’en peut plus et te plonge dans une sorte d’état léthargique pour t’obliger à ralentir.
Les rushs de fins de projets sont clairement stressants et personne ne les aime.
Qu’ils soient imposés par l’entreprise ou qu’on les fasse par conscience professionnelle, on n’en sort jamais vraiment indemne.
La pression et la fatigue diminuent la qualité et augmente le risque de bug.
Tu passes donc encore plus de temps à coder.
Cela s’inscrit dans un cercle vicieux duquel tu ne sors généralement pas avant la mise en production.
Paf.
C’est le burn-out.
L’entreprise détient la solution
En tant que développeur, on subit les deadlines.
C’est au chef d’entreprise de préserver les équipes.
Nous sommes désolés, mais nous ne pourrons tenir les délais qui s'annoncent trop serrés pour livrer du travail de qualité. Nous pouvons cependant déporter certaines fonctionnalités moins importantes dans un second lot.
Quelqu’un doit prendre les choses en main pour éviter de casser le moral des équipes.
Les décalages planning arrivent quasi-systématiquement et la méthodologie agile en est consciente.
Le client et l’entreprise doivent en être conscients également.
Quand c’est possible on peut faire rentrer d’autres devs sur le projet pour compenser.
En revanche la complexité que cela induit en plus (notamment la montée en compétences) n’est souvent pas envisageable à un stade trop avancé.
Ainsi, on se retrouve parfois bloqué et livré à soi-même.
La seule solution étant de travailler davantage…
C’est la triste réalité.
La plupart des collaborateurs se noieront avant de demander de l’aide.
La version originale en anglais
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
8ème principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Préserver son équipe du stress la rend beaucoup plus productive (et heureuse) ;
Les rushs nuisent à la qualité générale du projet ;
Le burn-out est une réalité bien présente chez les développeurs, et c’est dévastateur ;
Il vaut mieux préserver ses équipes que son client ;
Les projets sont des marathons, pas des sprints.
#
9) Une attention continue à la qualité de code
Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.
9ème principe du manifeste agile.
La méthode agile au sens large se veut axée sur la qualité.
Aussi, la qualité des livrables passent d’abord par une certaine « excellence technique ».
Oui, on peut regrouper beaucoup de choses là-dedans et la manière d’y arriver est parfois compliquée.
Notamment car il faut la définir…
Qu’est-ce que l’excellence technique ?
Développeurs et qualité de code
Crevons directement l’abcès.
Un développeur junior, de par son expérience, n'aura pas la même qualité de code qu'un senior.
C’est logique et c’est dit.
En ayant conscience de ça, il faut organiser les équipes projets en fonction.
On en voit des projets faits par uniquement par des juniors.
Souvent la dette technique s’accumule dès le début du projet.
On doit refactorer sur de longs mois avant de rendre le projet viable.
Si tant est qu’on souhaite le rendre viable !
Le marché est ce qu’il est, c’est vrai qu’il y a beaucoup de juniors…
Mais l’excellente technique passe également par la formation.
Si ton équipe est peu expérimentée, il va falloir mettre davantage l’accent sur la formation.
Rien d’offusquant, il faut juste l’avoir en tête.
Tout le monde a d’ailleurs besoin de formation, même les seniors.
C’est simplement que les juniors en ont davantage besoin.
Les outils sont là pour aider
La bonne nouvelle.
C’est que la qualité de code que tu produis peut être améliorée avec des outils et des processus simples.
Faire des reviews de code par les autres membres de l’équipe avant de livrer
Le pair-programming aide beaucoup
Utiliser des linters / fixers sur le projet
Définir les standards de code dès le début du projet
Faire des tests (non-régression visuelle, unitaires, fonctionnelles…)
Continuous attention to technical excellence and good design enhances agility.
9ème principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Bien coder rend heureux :
Un projet techniquement excellent comportera beaucoup (beaucoup) moins de bugs, pour le plus grand plaisir du client et des équipes ;
La qualité s’apprend et se pratique, c’est un stade clairement atteignable pour peu que l’on se forme ;
Il faut toujours se remettre en question sur le code que l’on produit ;
Le refactoring se fait tout au long du projet ;
Respecter au mieux les bonnes pratiques est obligatoire.
#
10 ) La simplicité est essentielle
La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
10ème principe du manifeste agile.
C’est probablement le principe du manifeste agile le plus abstrait.
Tout comme l’acronyme KISS (Keep It Stupid Simple => Rend le super simple), le but est de rendre la résolution de problème simple.
Tout le monde déteste les choses compliquées !
Un listener qui attend un event qui lui va trigger un helper dans un service appelé en Ajax depuis le Contrôleur.
J’ai rien compris en écrivant cela et ça n’a probablement aucun sens.
Pourquoi ?
Car ce n’est pas simple.
Ce que je viens de décrire va être complexe à :
Lire
Comprendre
Implémenter
Modifier
Déboguer
Il faut donc tendre, dans ton code comme dans tes process, à un maximum de simplicité.
Cela s’applique également à la gestion de l’équipe ou au suivi du projet.
Le process trop rigide de gestion de projet, les réunionites, les outils complexes alors que le besoin est simple…
Tout ça doit être minimisé à son utilisation la plus basique, la plus simple.
C’est très difficile de faire des choses qui soient simples pour tout le monde.
En informatique généralement, le moins tu écris de code pour faire une action.
Le mieux ce sera.
L’ajout de code ajoute de la complexité…
La réutilisation de code doit toujours être privilégiée, souviens-toi de DRY ( Don’t Repeat Yourself – Ne te répète pas).
Enfin, ne laisse jamais de code inutile en te disant « on en aura probablement besoin plus tard ».
Ce code (tout comme les // TODO) va rester à jamais dans l’application car personne n’osera le supprimer ne connaissant pas les impacts.
La version originale en anglais
Simplicity–the art of maximizing the amount of work not done–is essential.
10ème principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Une meilleure lisibilité dans le code ;
De meilleures performances à l’exécution ;
Une maintenance plus facile (il faut penser à son soi futur) ;
Un respect des bonnes pratiques va souvent de paire avec la simplicité ;
Pas de duplication de code, de todos ou d’optimisations prématurées.
#
11) Les meilleures idées émergent d’équipes auto-organisées
Les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées.
11ème principe du manifeste agile.
Une équipe autoorganisée est une équipe où tout le monde prend part au projet, notamment à sa réalisation technique.
C’est-à-dire que les choix ne sont pas imposés par un lead ou un chef de projet.
La méthode agile souhaite que chacun apporte sa pierre à l’édifice grâce à son expertise dans le projet.
Que ta spécialité soit le frontend, le backend, UI/UX, l’administration système ou la gestion du projet, tout le monde doit participer pour être plus efficace.
Les responsabilités sont ainsi partagées par spécialité pour le bien du projet.
On ne doit pas appliquer les directives reçues « d’en haut ».
C'est à l'équipe de décider des choix technologiques pour le projet, pas au CTO (par exemple) qui aurait vu le projet une fois avant le démarrage.
L’équipe doit appliquer ses propres directives en fonction de ses réflexions sur le besoin du client.
Tout ceci apportera flexibilité, spontanéité et implication dans le projet.
La version originale en anglais
The best architectures, requirements, and designs emerge from self-organizing teams.
11ème principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Des équipes impliquées à la réalisation du projet du client ;
De meilleures décisions stratégiques car elles émergent du cœur du projet ;
Une réelle envie de bien faire ressort de ce principe : booster la motivation de ses collaborateurs est essentiel.
#
12) L’amélioration continue
À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
12ème principe du manifeste agile.
On pourrait traduire ce principe par : « auto-amélioration de l’équipe ».
L’idée reste d’évoluer en continu sur ses choix dans :
Les processus utilisés
Le code
L’architecture
Les décisions techniques
Rien n’est figé et rien n’est immuable !
Comme d’habitude en agile, tout peut être changé si le besoin s’en fait ressentir.
À ce titre on dit souvent que l’on doit factoriser le code en continu.
Ce sont les petites actions qui font de grandes choses.
Il ne faut donc pas tout remettre en question sous principe de l’amélioration continue.
Le but est de faire de petits fixes pour corriger ta trajectoire au fur et à mesure.
Pas de mettre un gros coup de volant à 90°, bien que parfois nécessaire.
Réunions de fin de projet
C’est quelque chose qui, j’ai l’impression, passe souvent à la trappe !
On vient de finir le projet, on est encore dans le rush…
Et paf, on enchaîne sur un autre.
On ne prend pas assez le temps de se poser et de se demander.
Qu'est-ce qui a marché / n'a pas marché dans la réalisation du projet ?
On ne prend pas assez de notes des problèmes rencontrés pendant les différentes releases.
Du coup ?
Il y a de grandes chances que l’on recommence les mêmes erreurs la fois prochaine.
Si tu penses que l’humain évolue tout seul, tu as probablement raison… et tort.
Cela dépend des individus, pour moi les réunions de fins de projets sont essentielles pour :
Faire le bilan sur le planning et les délais
Prendre le ressenti des équipes (était-ce compliqué ? qui est en burn-out ? on recommence ?)
Apprécier les retours du client
Tenter d’améliorer ce qui n’a pas fonctionné (une mauvaise archi, une mauvaise interprétation des specs…)
S’améliorer en tentant quelque chose de différent la prochaine fois
Il est là l’intérêt du feedback !
Devenir plus efficace…
S’améliorer en continu finalement.
La version originale en anglais
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
12ème principe du manifeste agile en anglais.
✅ Récapitulatif : Avantages du principe
Tenir compte des erreurs passées pour ne plus les refaire à l’avenir ;
Prendre le temps de faire le bilan pourra permettre de coller aux besoins de chacun ;
Tout le monde échangeant librement sur son ressenti, on voit les choses sous un autre angle ;
Les clients suivants apprécieront de ne pas subir les erreurs faites dans ce projet-ci.
#
Exemples de méthodes agiles
Nous venons de détailler les 4 valeurs ainsi que les 12 principes du manifeste agile.
Si tu es toujours dans le coin, bravo.
Je suis persuadé que ces principes peuvent grandement aider les développeurs.
Pour aider justement à appliquer ces principes, des méthodes et des outils ont vu le jour.
Parmi les méthodes existantes, la plus connue en France est sans doute SCRUM.
Comme il en existe d’autres, voici un tour d’horizon de 3 méthodes agiles utilisées en entreprise pour la conduite de projets informatiques.
Engagement : Autonomie, force de proposition, les équipes s’engagent pour la réussite du projet.
Courage : Savoir dire non aux fonctionnalités qui décalent le planning, défendre le temps allouer à son projet…
Focus : Concentration sur les objectifs à atteindre, sur le produit développé, sur les résultats attendu.
Ouverture : Être ouvert aux outils proposés par Scrum, même s’ils sont différents de nos outils habituels.
Respect : Une belle valeur pas toujours bien comprise. La plupart du temps, elle commence par une hiérarchie horizontale, sans titre.
Rôles
Le PO ou product owner représente le client, il annonce les priorités et est garant des spécifications fournies par le client. Il valide les fonctionnalités.
Le scrum master est le chef d’orchestre de l’équipe, il s’assure que les processus soient bien exécutés tout comme de la communication entre les membres de l’équipe.
Les équipes techniques (les développeurs, architectes logiciels / admin sys etc) ne s’occupent que de leur partie technique respective.
Dans une organisation Scrum, il n’y a pas de rôle « à tout faire ».
Outils
Voici une liste des outils les plus populaires de la méthode Scrum.
Les users stories (US)
Décrit l’expérience utilisateur avec le même vocabulaire que celui qui l’utilise pour se familiariser avec l’environnement du client. C’est le product owner qui aide en ce sens.
"En tant que ... je suis capable de ... dans la mesure où ..."
Généralement des tests accompagnent ces US.
Backlog (ou product backlog)
On est capable de découper ces user-stories en tâche / exigences (c’est ce que l’on voit dans le ticket).
Le périmètre est entièrement défini en amont avec une estimation au plus proche de la réalité car relativement courte.
Une fois le backlog validé par le client, le PO et l’équipe au sens large : on attaque un sprint.
Sprint
Ce sont des itérations, des cycles de développement très courts.
Les tâches sont toujours ordonnées par priorité.
Un sprint se déroule généralement en un maximum de 6 semaines.
Le plus court est généralement le plus efficace (car les estimations de temps de développement sont très souvent inexactes).
Les scrum / daily meetings, stand-up meetings
Ce sont des réunions très courtes d’environnement 15 minutes dans lesquelles on discute :
Avancée de la veille
Ce qui doit être fait aujourd’hui
Les problèmes actuels ou point de blocage à anticiper
Ceci permettant notamment de :
Mesurer l’avancement
Améliorer la qualité des livrables
Garantir les délais
On est ainsi capable au jour le jour de s’assurer du planning grâce au temps passés VS le temps restant à faire.
Poker planning
Une réunion où tous les membres de l’équipe sont invités à estimer la complexité d’une tâche.
Chacune des personnes (souvent techniques) dispose d’un jeu de carte.
À l’annonce de la fonctionnalité chacun brandi sa carte en expliquant pourquoi il juge la tâche à ce niveau de complexité.
Cela permet d’éviter au mieux des estimations de temps de développement inexactes.
Review / réunion de fin de sprint
Un peu à la manière des réunions de fin de projet, le sprint review permet de faire un tour d’horizon sur ces dernières semaines afin d’apporter un maximum de feedbacks.
Des démos sont généralement planifiées avec le product owner ou le client.
Le reste à faire est re-priorisé et re-planifié durant le prochain sprint.
#
Extreme Programming (XP)
Tout comme Scrum, on se base sur des itérations, des cycles de développement plutôt courts.
Chaque journée débute par un daily également.
En revanche, il n’y a pas de meeting de fin de sprint de prévue.
On se base sur l’amélioration continue à son extrême, c’est-à-dire d’annoncer les problèmes dès qu’ils surviennent.
XP est un framework articulé autour de la performance technique.
Si Scrum peut être appliqué à la gestion de projet au sens large, Extreme Programming lui est très orienté sur la partie technique.
En effet le cœur de la bataille reste la production de code.
Et quoi de mieux pour un projet réussi qu’un code d’une qualité irréprochable.
C’est ce vers quoi l’Extreme Programming essaye de tendre.
D’ailleurs, la méthode XP est souvent préférée par les développeurs aguerris à Scrum car elle se concentre justement sur la partie technique.
Pour faire simple, c’est le domaine du client qui prime pour construire l’architecture de l’outil.
Les règles de nommages sont un exemple bien connu.
On se retrouve avec des noms comme client, customer, user dans le code, alors que tous désignent la même chose : un utilisateur.
Il faut se concentrer sur le domaine client, avoir un contexte clair et définie.
Le modèle de données doit par exemple refléter les besoins du client.
Créer un modèle trop générique est contraire au DDD.
#
Kanban
Scrum et Extreme programming sont des frameworks, des cadres.
Dans ces frameworks, on trouve des outils.
Le tableau Kanban est un de ces outils agiles.
Le framework Kanban existe lui aussi et s’articule autour des tableaux que l’on verra ci-dessous.
6 pratiques de la méthode Kanban
Visualiser : Un tableau très explicite avec l’état des tâches (par exemple à faire, en cours, terminé) dont les colonnes permettent à tous les membres de l’équipe de connaître l’état d’avancement du projet.
Limiter le nombre de tâches en cours : À tout commencer en même temps on ne finit rien… Il faut résoudre les points de blocages le plus rapidement possible et anticiper les suivants
Gérer le flux : L’avancement doit être mesuré et reporter dans le tableau Kanban. La visibilité n’a de sens que si tout le monde voit l’avancée du flux.
Rendre les normes de processus explicites : Le process doit être clair pour tout le monde. Les règles permettront de savoir par exemple quand changer une tâche de colonne.
Mettre en place des boucles de rétrospection : On doit s’assurer de ce qui a été livré afin de valider le statut final de ladite tâche. Des tests et autres actions sont utilisés en ce sens.
S’améliorer en continu : Communiquer tous ensemble permet d’améliorer la fluidité des échanges et d’améliorer le workflow en place. Le besoin fonctionnel est souvent évoqué ce qui facilite grandement la communication des équipes.
Rôles
Les rôles dans Kanban sont assez simples.
Outre les développeurs, il existe deux types de rôles :
Service Request Manager (SRM) : Gère la demande client, le besoin, les fonctionnalités importantes. C’est lui qui alimente le tableau Kanban. Il maintient également les process en place.
Service Delivery Manager (SDM) : Est responsable du workflow de livraison. Gère la WIP limit et les daily standup meetings lorsqu’il y en a.
Le fait d’avoir simplifié les deux rôles avec d’un côté la MOA et de l’autre la MOE met les choses aux claires sur qui fait quoi dans l’équipe.
Outils
Tableaux Kanban
Des outils comme Trello, Notion, Jira Agile permettent d’utiliser les tableaux Kanban.
Kanban est un système de gestion de tâches (de features) à faire avancer tout au long des développements.
Cette approche se veut transparente et clairement explicite pour tout le monde.
Généralement le tableau Kanban est exposé à la vue de tous les membres de l’équipe.
De cette manière, tout le monde sait où en est le projet.
Utilisation de Kanban en tant qu’outil de la méthode agile
On peut travailler de manière complexe avec Kanban en se focalisant sur l’amélioration continue et la fluidité des releases.
C’est pourquoi cet outil est parfois utilisé dans la méthode Scrum durant les sprints.
La différence majeure avec le framework Scrum, c’est que le framework Kanban se base sur une livraison continue.
Un immense tableau de fonctionnalités est mis en forme et organisé pour livrer en flux continu.
Classes de service
Les classes de services sont utilisées afin d’affecter une priorité à une tâche dans le tableau Kanban.
Voici les 3 types de service :
Standard : On place ici les fonctionnalités / corrections non impactantes pour le client ;
Date de livraison fixe : Des tâches importantes à envoyer en production pour le client. Le décalage de ces tâches n’est pas souhaité ;
Urgence : Tâches à résoudre immédiatement.
WIP Limits
Les WIP Limits pour Working In Progress limits permettent de définir un nombre maximum de tâches en cours.
L’idée ici c’est de ne pas avoir plus de X tâches en parallèle afin de ne pas se disperser.
Le multitâche rend souvent les choses plus lentes et complexes.
Workflow
Le processus de livraison est clairement défini.
Une fois une tâche commencée, elle est placée dans le workflow afin de pouvoir la déployer.
Le workflow peut se décomposer avec ces étapes :
À faire
Développement
Revue de codes
Tests
Déploiement
Terminé
Ce workflow de livraison permet en parallèle de la liste des tâches de s’assurer de la bonne livraison du code.
#
Top 3 des avantages et inconvénients de la méthode agile
Ces avantages et ces inconvénients ne sont pas les seuls quand on parle de la méthode agile.
De nombreuses études relèvent que la méthode agile (si elle est bien appliquée) fonctionne très bien en entreprise.
Elle est en revanche plus efficace sur une certaine taille d’équipe projet.
1) Un logiciel de qualité
S’il y a bien quelque chose sur lequel la méthode agile se concentre, c’est la qualité.
La qualité du code, des livrables, de la recette, de la compréhension du besoin client…
Fournir au client un produit conforme à ses attentes devrait être la principale priorité des équipes.
Même avec des changements soudains, la méthode agile est capable de délivrer quelque chose de fiable.
Si tant est qu’elle soit bien utilisée.
Avoir un logiciel de qualité se répercute sur la confiance que le client nous apporte.
Mais également sur la satisfaction des utilisateurs du produit.
On a tout à y gagner !
2) Des releases plus rapides
Les clients sont souvent impatients de découvrir le résultat de nos développements.
C’est normal pour plusieurs choses :
Découvrir un nouveau logiciel est exaltant
Vérifier que le résultat est conforme à la demande
Commencer à utiliser l’outil le plus rapidement possible (car il en a besoin)
Avancer face aux concurrents
Grâce à la méthode agile, on est capable de livrer des morceaux de codes 100% fonctionnels, semaines après semaines.
Le client peut ainsi commencer à utiliser son logiciel bien plus rapidement que si on avait attendu une « grosse release ».
C’est un avantage énorme pour le client, mais aussi pour les équipes.
Le stress de livrer un ensemble de fonctionnalités donné à une date donnée est vraiment important.
En livrant en continu quelque chose de fonctionnel on évacue directement ce stress.
3) De la flexibilité pour tout le monde
En agilité, on est réactif à la demande du client.
Si son besoin change, on change la direction du projet.
Quitte à déprioriser ou à relayer des fonctionnalités en temps 2.
Tout ceci se fait en accord avec le client.
C’est lui qui décide de ses priorités et tout le monde en sera satisfait.
Être agile ne veut pas dire changer d’avis chaque semaine.
Être agile ce n’est ne pas être fermé aux changements.
C’est voir comment on peut faire pour éviter la friction et s’engager sur une nouvelle voie de manière fluide.
Le client est en général très reconnaissant lorsque l’on « inclut des items non prévus à la dernière minute ».
Il sait que ce n’est évident pour personne, car lui aussi est inclus dans l’équipe projet.
#
Inconvénients de la méthode agile
La méthode agile, outre sa mauvaise application comporte également quelques « failles ».
1) La documentation
Ce qu’on reproche le plus à la méthode agile, c’est de privilégier le code à la doc.
C’est totalement en vrai en théorie, mais en pratique… Je ne suis pas certain que cela soit justifié.
Des projets sans documentation, utilisant agile ou pas, j’en ai vu passer.
Et j’imagine que toi aussi.
Le manque de doc est un problème récurrent sur les projets en informatique.
Elle est parfois inexistante, dispatchée à plusieurs endroits, en double, mal exprimée, inutile…
C’est un sujet à part entière qui se doit d’être traité correctement.
Agile ou pas.
2) L’exigence demandée aux équipes
La méthode agile veut inclure tous les participants au projet… dans le projet.
C’est-à-dire appréhender le besoin, comprendre le fonctionnel, être force de proposition…
Pour chacun des membres de l’équipe !
Tout ça ne plaît pas forcément à tout le monde.
« Je suis designer moi, pas chef de projet »
On peut en théorie demander l’implication de tous les membres de l’équipe pour la réussite du projet.
En pratique, certaines personnes seront moins investies que d’autres, peu importe la raison.
C’est une faiblesse de la méthode agile dans la mesure où pour réussir, la méthode a besoin que tous les acteurs soient tournés vers la résolution du problème du client.
Si lesdits acteurs commencent à s’en désintéresser…
On perdra en performance.
3) Le manque de visibilité
Les cycles de développement agiles sont relativement courts.
C’est la méthode qui veut ça.
Dès lors, cela devient compliqué de planifier à 18 ou 24 mois…
Mais qui fait ça ? (c’est ce que tu te demandes sans doute)
Ce besoin est réel, notamment pour les sociétés de services qui font de la régie ou sur de très gros projets ou refontes.
On doit planifier ne serait-ce que 5 ou 6 personnes sur parfois 2 ans.
C’est très compliqué, pas souvent juste, mais c’est faisable.
Évidemment il y a une marge d’erreur importante, c’est pour cela que l’on réévalue la planification chaque trimestre par exemple.
La planification long terme laisse peu de place aux changements (de besoin, d’orientation, de charge de travail etc).
Alors que la méthode agile se veut justement ouverte aux changements.
Cette incompatibilité est à anticiper !
Attention aux phases de rush…
Parfois on peut augmenter la charge allouée à un projet (rajouter des développeurs).
Parfois on ne peut pas.
Une des dérives serait de constamment rajouter des personnes sur le projet au fur et à mesure que le client rajoute des fonctionnalités.
Puis de les enlever lorsque le « rush » est passé.
Si on suit cette logique, on casse les principes agiles : il faut maintenir un cycle de développement constant.
Peut-être que la méthode agile ne convient pas au client qui souhaite un gros turnover sur son projet.
Ici aussi, il faut anticiper.
#
Les méthodes agiles ont-elles échoué ?
Ces dernières années, certains des signataires initiales du manifeste agile se sont rétractés.
Ils ne remettent pas en cause le manifeste agile en lui-même.
Ni même les méthodes agiles au sens large.
Mais plutôt la manière dont elles sont utilisées.
Le problème avec le manifeste agile, c'est que ce n'est qu'un manifeste sans document explicatif, il est sujet aux interprétations du lecteur.
Libre à la personne qui le lit de le mettre en place comme il le souhaite.
Et c’est sûrement ça le fond du problème.
Ron Jeffries & Andy Hunt, ont abandonné le manifeste agile
Ils semblent tous les deux d’accord avec la raison de cet échec.
Pour Ron Jeffries, les méthodes agiles dans les entreprises sont imposées, et non appliquées comme il le faudrait.
Les personnes qui utilisent mal agile suivent les directives des méthodes à la lettre, notamment pour qu’on ne leur reproche rien.
Mais la méthode agile ne propose pas de réflexion toute faite, type « quand ceci arrive, faire cela ».
Alors de fait, ça ne peut pas fonctionner.
De plus, les personnes qui mettent en place la méthode agile doivent pour lui être des personnes avec de l’expérience et un niveau de compétence élevé.
La culture agile est souvent critiquée par manque de connaissance
Est-ce que tu as déjà entendu la phrase :
C'est agile, normal que ça ne marche pas !
Pour certains d’entre nous, être agile c’est arriver sur un projet sans specs et la jouer au feeling grâce aux itérations courtes.
Alors oui forcément, dans ces conditions ça ne peut pas marcher…
Agile ne veut pas dire sans processus.
C’est une mauvaise interprétation du manifeste… Encore une !
L’expérience générale montre que la méthode agile fonctionne bien, notamment sur des projets plus courts.
Sans pour autant appliquer un framework au quotidien, l’utilisation des principes agiles et des outils peuvent réellement améliorer la satisfaction de tous les partis.
Il ne reste plus qu’à essayer…
#
Pourtant, la méthode agile fonctionne…
Ce n’est pas moi qui le dit, mais les études !
Ces études tendent à démontrer que si la méthode agile est correctement appliquée.
Les bénéfices pour les équipes (et pas seulement les développeurs) sont bien présents.
Ceci rejoint également ce que les signataires originels du manifeste disaient plus haut.
Ce n'est pas le manifeste qui pose problème, c'est son application.
Je rejoins assez cette idée.
Et pour appuyer mes propos, voici quelques études qui en parlent.
Bien sûr, je pense que l’on pourrait trouver des études qui démontrent le contraire.
On trouve surtout ce que l’on cherche !
Néanmoins, je suis certain comme beaucoup d’autres développeurs, que la méthode agile apporte réellement de nombreux bénéfices pour les équipes techniques ET pour le client.
Tout le monde n’est pas d’accord avec ça.
C’est pour ça que je serais ravi d’avoir ton avis en commentaire.
T’es plutôt agile ? Ça marche pour toi ?
On a tous des points de vue différents.
Pour finir sur une note d’humour, voici la méthode agile vue par un développeur :
Client : J’ai besoin d’une table MOA : On a besoin d’une table MOE : Fais une table Développeur : J’ai fait une table MOE : Il a fait une table MOA : Voilà votre table Client : Mais la table ne passe pas ma porte… MOA : Il faut que la table passe la porte (voyons c’est évident) MOE : La table doit passer la porte ! Développeur : Voilà, la table passe la porte
(avec lequel je ne suis pas du tout d’accord soit dit en passant, mais c’est marrant)
#
Conclusion
Avec cet article je t’ai donné ma vision de la méthode agile.
Mon interprétation en tant que développeurs de ses principes, de ses valeurs.
De pourquoi je pense que le manifeste agile est une réelle plus-value pour les développeurs.
Par contre, dans mon quotidien, je ne suis pas le manifeste agile à la lettre.
Tous les clients ne sont pas compatibles avec son fonctionnement.
Mettre l’accent sur la qualité, mettre en avant le feedback, inclure l’ensemble de l’équipe à la mission du projet…
Autant de choses qui me plaisent à moi.
Mais pas à tout le monde.
#
Mettre en place la méthode agile dans son entreprise ?
À défaut de tout vouloir passer en agile via un framework comme Scrum ou XP, je conseille plutôt de commencer avec des outils.
Daily Meetings, Poker Plannings, Kanban, TDD, Pair Programming…
Le changement sera moins brutal pour l’entreprise et sans doute mieux accueilli par les équipes déjà en place (personne n’aime les changements brutaux et imposés).
La méthode agile et ses outils peuvent nous permettre une meilleure qualité à tous les niveaux.
Qu’on les aime où non, ces méthodes font partie de notre quotidien.
Alors la méthode agile, pour ou contre ?
Newsletter 🚀 La console
📩 Chaque lundi, je partage 1 nouveau truc de développeur que j'ai appris cette semaine.
Tu es développeur et tu souhaites devenir lead developer ? Voyons comment tu y peux y arriver avec des conseils simples et efficaces.
Devenir expert en dev
4 commentaires
Merci pour cet article très bien documenté. Mais pour moi, il y a une hérésie : parler de LA méthode agile. Elle n’existe pas. Il y a des méthodes agiles. Agile est un concept que l’on applique au travers de méthodes.
Après, quand utiliser Agile? Lorsqu’on est confronté à un gros projet comportant de nombreux points d’incertitude ou de flou. L’agilité permet de se rapprocher au plus près du besoin du client tout au long du développement.
Par contre, pour un projet clairement défini, avec un périmètre restreint, une méthode agile est à déconseiller à cause de son côté chronophage.
👏👏👏 waaaw ! J’ai aimé. Merci pour ton article bien documenté et les explications sont assez claires. C’est l’article le plus clair et illustratif que j’ai lu sur ** METHODE AGILE**.
Vraiment Merci. Je ne regrette pas d’avoir mis du temps sur cet article 👏👏😊😊
Merci pour cet article très bien documenté. Mais pour moi, il y a une hérésie : parler de LA méthode agile. Elle n’existe pas. Il y a des méthodes agiles. Agile est un concept que l’on applique au travers de méthodes.
Après, quand utiliser Agile? Lorsqu’on est confronté à un gros projet comportant de nombreux points d’incertitude ou de flou. L’agilité permet de se rapprocher au plus près du besoin du client tout au long du développement.
Par contre, pour un projet clairement défini, avec un périmètre restreint, une méthode agile est à déconseiller à cause de son côté chronophage.
Merci pour ton commentaire !
Effectivement « la méthode agile » est un abus de langage, on devrait parler de méthodologie agile. Mais de là à qualifier ça d’hérésie 🙂
Tu n’utiliserais pas de méthodes agiles sur un projet avec un périmètre déjà clairement établi ? Même dans une réalisation au forfait ?
C’est intéressant, on a tous notre manière de faire.
👏👏👏 waaaw ! J’ai aimé. Merci pour ton article bien documenté et les explications sont assez claires. C’est l’article le plus clair et illustratif que j’ai lu sur ** METHODE AGILE**.
Vraiment Merci. Je ne regrette pas d’avoir mis du temps sur cet article 👏👏😊😊
Merci beaucoup pour ton commentaire 🙂