Temps de lecture estimé : 64 minutes
Qu’est-ce que la méthode agile et comment l’utiliser ? Comment utiliser les méthodes agiles en tant que développeur ?
La méthode agile est souvent évoquée dans les projets informatiques, et pour cause, elle est quasi partout…
On dit souvent que l’on travaille en agilité ou que l’on applique des méthodes agiles.
Durant mon apprentissage des concepts de programmation avancés, on m’a souvent conseillé de me renseigner sur la gestion de projets web.
Mais qu’est-ce que cela implique de se baser sur la méthode agile pour les développeurs ?
Dans cet article, je te propose de reprendre ensemble les 12 principes du manifeste agile ainsi que ses 4 valeurs.
Le manifeste a été écrit il y a + de 20 ans et il est toujours d’actualité.
Certains pensent que la méthode agile ne fonctionne pas, d’autres ne jurent que par elle…
Regardons cela ensemble !
Avant de définir ce qu’est la méthode agile.
Il faut séparer 3 termes bien différents :
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.
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.
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.
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 !
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é.
La livraison en continu d’un logiciel opérationnel avec du code de qualité garanti également que le projet avance.
Si c’est un peu flou, sache qu’on développe l’ensemble des 12 principes juste en dessous. 👇
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…
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.
L’histoire est assez simple.
Ces 17 informaticiens se sont retrouvés ensemble pour des vacances au ski.
L’idée derrière ce rassemblement était de trouver une solution aux échecs nombreux de la gestion de « projet classique ».
Le manifeste agile est écrit et est également appelé « Agile Manifesto ».
Voici le site internet officiel : https://agilemanifesto.org.
La vérité, c’est que les méthodes agiles ne sont pas parfaites.
En revanche, le manifeste agile lui, est je trouve fondamentalement bien écrit
Le manifeste agile a changé beaucoup de choses pour les biens des développeurs.
Bien sûr des dérives ont émergé, comme pour tout.
Mais personnellement, je pense que sa création est une bonne chose.
Voici donc le manifeste anti-agile présenté sous une forme humoristique.
Je ne pouvais pas parler de la méthode agile sans mentionner ce dernier.
Agile a été propulsé au-devant de la scène ces dernières années.
Des entreprises se sont mises à faire des formations, des certifications même.
Cependant comme le manifeste reste sujet à interprétation, et même si on peut être convaincu du bien-fondé de ce dernier…
Le mettre en application est une tout autre histoire.
Je suis devenu "chef de projet" au bout de 3 mois après avoir signé mon premier CDI.
Sans aucune expérience, j’ai appris sur le tas, avec toutes les méthodes que je pouvais trouver et l’expérience de mes collègues.
Si j’avais dû appliquer les méthodes agiles à ce moment-là, ça aurait été catastrophique.
Pas assez formé (une formation de 2 jours n’aurait rien changé), pas assez mature, pas assez expérimenté…
Dans tous les cas, ça aurait été un échec.
La mise en application des méthodes agiles est délicate et requiert de l’expérience.
Ce ne sont pas de simples outils.
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.
« 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.
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 !
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 ».
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.
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.
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.
La documentation doit être faite au fur et à mesure que le développement avance.
Ni trop en amont. Ni trop en aval.
La méthode agile souhaite que la documentation soit simple, efficace, facilement maintenable.
Elle n’est pas censée (au sens agile) être exhaustive.
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…
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 :
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…
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.
Un chef de projet « agile »
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.
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.
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 !
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.
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.
On a tous notre vision de ce qui est rapide.
Personnellement, je livre le plus tôt possible.
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.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
1er principe du manifeste agile en anglais.
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.
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.
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 !
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.
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.
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.
Pour donner quelques exemples simples, il m’est arrivé d’avoir des releases en cours pendant plusieurs mois dans ces 3 situations :
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.
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.
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 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.
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.
Business people and developers must work together daily throughout the project.
4ème principe du manifeste agile en anglais.
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.
Sur les projets sur lesquels je bosse, j’essaye toujours de faire au mieux pour éviter la frustration.
La frustration et la démotivation sont tes pires ennemis pour garder une équipe soudée.
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 :
Bref, c’est loin d’être toujours facile…
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.
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 :
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 de console.log().
On vous voit !
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.
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.
6ème principe du manifeste agile.
Parlons-en !
Depuis le COVID en France, beaucoup de développeurs sont en télétravail.
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 !
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 !
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.
Ce face-à-face, il passe le plus souvent par un appel ou une visio.
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.
Ce face-à-face nécessite de se voir réellement.
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 !
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.
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.
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.
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 :
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.
Working software is the primary measure of progress.
7ème principe du manifeste agile en anglais.
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.
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…
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.
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.
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.
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 ?
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.
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.
Coder de manière qualitative se travaille et s’apprend.
La dette technique se paye toujours.
Ce que tu gagnes au début tu le payeras à la fin…
Continuous attention to technical excellence and good design enhances agility.
9ème principe du manifeste agile en anglais.
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 à :
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.
Simplicity–the art of maximizing the amount of work not done–is essential.
10ème principe du manifeste agile en anglais.
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.
The best architectures, requirements, and designs emerge from self-organizing teams.
11ème principe du manifeste agile en anglais.
À 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 :
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.
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 :
Il est là l’intérêt du feedback !
Devenir plus efficace…
S’améliorer en continu finalement.
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.
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.
C’est la méthode agile la plus populaire, notamment en France.
Elle est tellement populaire qu’elle est également utilisée dans d’autres métiers !
Elle n’est plus seulement réservée à la conduite de projet informatique.
Dans une organisation Scrum, il n’y a pas de rôle « à tout faire ».
Voici une liste des outils les plus populaires de la méthode Scrum.
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.
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.
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).
Ce sont des réunions très courtes d’environnement 15 minutes dans lesquelles on discute :
Ceci permettant notamment de :
On est ainsi capable au jour le jour de s’assurer du planning grâce au temps passés VS le temps restant à faire.
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.
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.
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.
http://www.extremeprogramming.org
Voici une liste des outils les plus populaires de la méthode Extreme Programming.
Le TDD comme phisolphie !
On écrit d’abord les tests qui doivent échouer.
Ils sont la garantie de la demande client, du besoin fonctionnel.
C’est au fur et à mesure que tes tests passent que tu peux constater de l’avancement du logiciel.
Toujours aller au plus simple !
(Un article entier sera dédié au TDD car c’est une manière de penser très différente du développement « classique »)
Coder à deux pour être plus efficace.
Cette pratique n’est pas seulement réservée aux développeurs juniors, mais bien à l’ensemble des développeurs.
Personnellement, je trouve ça cool de temps en temps.
En revanche faire cela 100% du temps n’est pas très fun…
Le BDD (pour Behavior Driven Development) permet de créer des tests fonctionnels avec une langue vivante, le français par exemple.
Ce code permet de lancer des tests réels car il sera interprété avec un contexte.
Ce sont de vrais tests fonctionnels !
Pour en savoir plus sur Behat.
DDD signifie Domain Driven Design.
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.
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.
Les rôles dans Kanban sont assez simples.
Outre les développeurs, il existe deux types de rôles :
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.
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.
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.
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 :
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.
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 :
Ce workflow de livraison permet en parallèle de la liste des tâches de s’assurer de la bonne livraison du code.
Ces avantages et ces inconvénients ne sont pas les seuls quand on parle de la méthode agile.
En revanche ce sont pour moi les principaux.
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.
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 !
Les clients sont souvent impatients de découvrir le résultat de nos développements.
C’est normal pour plusieurs choses :
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.
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.
La méthode agile, outre sa mauvaise application comporte également quelques « failles ».
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.
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.
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 !
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.
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.
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.
Plutôt que de rajouter de l’agilité, on définit des processus rigides qui sont à la décharge du développeur.
Plus de pression, plus de fonctionnalités à livrer dans un laps de temps plus court…
C’est tout le contraire de l’agile qu’ils ont voulu créer.
Andy Hunt dénonce également que l’application des méthodes agiles est trop rigide.
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é.
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…
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
https://www.developpez.com/actu/204756/Les-developpeurs-devraient-abandonner-les-methodes-agiles-selon-Ron-Jeffries-l-un-des-signataires-du-Manifeste-Agile/#post10257875
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)
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.
À 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 ?
Pour lire plus de contenu similaire dans le même thématique.
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 🙂