Méthode Agile : Le manifeste vu par un développeur

  Temps de lecture : 51 min.
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é.

Que l’on applique des méthodes agiles.

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 !

  1. Méthode Agile : Définitions
  2. Qui a écrit le manifeste Agile ?
    1. Le manifeste anti-agile
  3. Les 4 valeurs du manifeste agile
    1. Les individus et leurs interactions
    2. Des logiciels opérationnels
    3. La collaboration avec les clients
    4. L’adaptation au changement
  4. Les 12 principes du manifeste agile
    1. Livrer rapidement
    2. Accueillir positivement les changements
    3. Livrer fréquemment
    4. Travailler ensemble
    5. Des personnes motivées
    6. Dialoguer en face-à-face
    7. Un logiciel opérationnel
    8. Un rythme de développement soutenable
    9. La qualité de code
    10. La simplicité est essentielle
    11. Des équipes auto-organisées
    12. L’amélioration continue
  5. Exemples de méthodes agiles
    1. Scrum
    2. Extreme Programming
    3. Kanban
  6. Top 3 des avantages et des inconvénients
    1. Pourquoi la méthode agile a échoué
    2. Pourquoi la méthode agile fonctionne
  7. Conclusion

Méthode agile : les définitions

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 la méthodologie agile
  • Le manifeste agile
  • Les méthodes agiles
Qu’est-ce que la méthode agile ?

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 !

Le manifeste agile : Agile Manifesto
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é.

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. 👇

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.

Sondage sur les méthodes de développement utilisé en programmation
https://insights.stackoverflow.com/survey/2018#development-practices

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.

17 signataires du manifeste agile
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 »)
  • Arie van Bennekum (auteur de la méthode DSDM ?)
  • Brian Marick (auteur de plusieurs livres et speaker)
  • Dave Thomas (inventeur des katas de code)
  • James Grenning (contributeur de l’internet, auteur de « Test-Driven Development for Embedded C »)
  • Jeff Sutherland (cocréateur de Scrum)
  • Jim Highsmith (auteur de plusieurs livres sur les méthodologies de développement)
  • Jon Kern (auteur de plusieurs livres et speaker)
  • Kent Beck (inventeur de l’Extreme Programming (XP))
  • Ken Schwaber (cocréateur de Scrum)
  • Mike Beedle (coauteur du premier livre sur Scrum et évangéliste)
  • Martin Fowler (auteur de plusieurs livres sur le développement)
  • Robert C. Martin (auteur de « Clean code » et « Clean architecture »)
  • Ron Jeffries (auteur de plusieurs livres et blogueur)
  • Steve Mellor (contributeur de l’internet, auteur de plusieurs livres)
  • Ward Cunningham (inventeur du Wiki et du terme « dette technique »)

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.

Le manifeste anti-agile et l’agile bashing

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.

Le manifeste anti-agile, le manifeste cascade (waterfall manifesto)
Le manifeste anti-agile « waterfall manifesto » : https://www.waterfallmanifesto.org/?principles

L’application des méthodes agiles fait sa réputation

Agile a été propulsé au devant de la scène ces dernières années.

Des entreprises se sont mis à 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 toute 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 requière de l’expérience.

Ce ne sont pas de simples outils.

Outils Agile
https://stateofagile.com/#ufh-i-615706098-14th-annual-state-of-agile-report/7027494

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 programming 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.

Consultant en méthodes agiles
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’exclue 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
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
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
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
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.

Méthode Agile : Livrer fréquemment et rapidement des fonctionnalités
https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

Que signifie livrer rapidement ?

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.

Manifeste agile valeur 1

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.

Manifeste agile valeur 2

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 utilisent ;
  • 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.

Manifeste agile valeur 3

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.

Manifeste agile valeur 4

« 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 que des réunions hebdos à raison d'un ou deux jours par semaines 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 accords 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 un é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 sortant de nul 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 sur :

  • 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) ;
  • Les outils de travail qui ne sont pas au rendez-vous (un manque de logiciel, un ordinateur peu puissant qui rame…).

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.

Manifeste agile valeur 5

Contrôler le travail de son équipe ?

Ma mère avait souvent l’habitude de dire (en souriant) :

La confiance n'exclue 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 putain de console.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 productif 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.

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 !

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 exclu, 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 lourds, 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.

Manifeste agile valeur 6
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.

Manifeste agile valeur 7

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.

Méthode Agile : Principe 7 du Manifeste - Un logiciel opérationnel est la principale mesure d’avancement
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

C’est la loi de Hofstadter.

Les retards dans les projets sont « normaux »

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…

Quoiqu’il en soit, quand on finit par bourriner à la fin, c’est souvent un manque d’anticipation.

Mais encore faut-il pouvoi anticiper…

Manifeste agile valeur 8

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 diminue 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étence) 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 part 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.

Manifeste agile valeur 9

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…)
  • Adopter le TDD
  • Mettre en place de la CI

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…

La version originale en anglais

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 rigides 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.

Manifeste agile valeur 10

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.

Manifeste agile valeur 11

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.

Manifeste agile valeur 12

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.

Méthodes agiles et pratiques les plus populaires
https://stateofagile.com/#ufh-i-615706098-14th-annual-state-of-agile-report/7027494

Scrum

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.

https://scrumguides.org

5 valeurs de Scrum

  • 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évu.

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

5 valeurs de l’Extreme programming

  • Communication : Une excellente communication entre les membres de l’équipe est obligatoire (le coach en est garant).
  • Simplicité : On pense KISS avant tout, on anticipe les problèmes, pas les besoins.
  • Feedback (client, utilisateur, développeur) : Tout le monde doit fournir des feedbacks, et ce le plus tôt possible.
  • Courage : XP est un framework techniquement complexe à utiliser, il faut avoir le courage d’aller jusqu’au bout de la démarche.
  • Respect : Il faut respecter les membres de son équipe mais également « les autres » (ceux qui ne font pas d’XP notamment).

Rôles

  • Vérificateur : Vérifie qu’aucun problème n’intervient dans le projet, qu’il soit technique ou fonctionnel.
  • Représentant client : Écrit les user-stories, priorise les devs, fait les tests fonctionnels : il détient le besoin client.
  • Développeur : Participe au projet notamment en chiffrant les US. Sinon, son rôle reste uniquement technique.
  • Testeur : Une personne dédiée aux tests dans l’équipe, travaille de concert avec le représentant client et le développeur.
  • Coach : Aide à appliquer la méthodologie agile grâce à l’Extreme Programming. Il planifie les meetings et globalement les interactions des équipes.

Outils

Voici une liste des outils les plus populaires de la méthode Extreme Programming.

TDD et encadrement

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 »)

Le pair programming

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…

BDD

Le BDD (pour Behavior Driven Development) permet de créer des tests fonctionnels avec une langue vivante, le français par exemple.

BDD avec Extreme Programming via Behat
Exemple d’utilisation du BDD avec l’outil Behat

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

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.

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 le 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.

Kanban, un outil de la méthode agile
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.

En revanche ce sont pour moi les principaux.

Méthode agile : les bénéfices par les utilisateurs
https://stateofagile.com/#ufh-i-615706098-14th-annual-state-of-agile-report/7027494

Avantages 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 inclut 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 développeurs doivent abandonner la méthode agile
https://ronjeffries.com/articles/018-01ff/abandon-1/

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.

L'échec de la méthode agile
https://toolshed.com/2015/05/the-failure-of-agile.html

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 disait 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.

The Standish Group

Méthode agile vs Cycle en cascade
https://www.standishgroup.com/chaosReport/index

State of Agile survey

Méthode agile : Succès et mesures
https://stateofagile.com/#ufh-i-615706098-14th-annual-state-of-agile-report/7027494

Agile Dimensional Model for a Data Warehouse Implementation

Analyse de l'implémentation des méthodes agiles dans un projet de BI
https://www.rcs.cic.ipn.mx/2018_147_3/Agile%20Dimensional%20Model%20for%20a%20Data%20Warehouse%20Implementation%20in%20a%20Software%20Developer%20Company.pdf

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 ravis d’avoir ton avis en commentaire.

T’es plutôt agile ? Ça marche pour toi ?

On a tous des poins 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

https://www.developpez.com/actu/204756/Les-developpeurs-devraient-abandonner-les-methodes-agiles-selon-Ron-Jeffries-l-un-des-signataires-du-Manifeste-Agile/#post10257875

(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 la 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 plaise à 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 ?

❤️ Tu as aimé cet article ?️

J'ai mis un moment à l'écrire... Ce serait top si tu pouvais le partager à la communauté !