Salut,
Quand j’ai commencé à m’intéresser à l’eXtreme Programming, c’était en 2002, il y avait une super conf : XP Days.
J’ai encore le jeu de planning poker, édition collector !
On y parlait tech et agilité.
Les deux allaient de pair et c’était évident pour tout le monde.
Et puis un jour, XP Days est devenu Agile France…
Je voyais des extreme programmeurs de la première heure amers et je ne comprenais pas trop pourquoi.
Mais aujourd’hui je comprends mieux : ils voyaient le mouvement évoluer et ils n’étaient pas alignés avec ce qui se passait.
La suite on la connaît : l’agilité a divorcé de la technique.
Elle s’est envolée dans les sphères du management et de la gestion de projet, délaissant la tech qui la cantonnait à l’informatique.
En passant à l’échelle, le mouvement a attiré des gens plus ou moins alignés sur ses valeurs fondatrices.
Il y a quelques années, des voix se sont élevées pour dénoncer des abus.
Le dark agile était né, cristallisant toutes les frustrations liées à l’agilité.
Indéniablement, ça existe. Et à chaque fois que je creusais une anecdote malheureuse, je me faisais cette remarque : on n’a visiblement pas tous la même compréhension de ce qu’est l’agilité.
A ce moment, j’ai arrêté de parler d’agilité. Face à des développeurs souvent en colère, parler d’agilité générait les réactions les plus vives !
Pourtant, l’agilité n’est pas juste une machine à presser encore plus les devs.
C’est avant tout un état d’esprit, un chemin et une manière de travailler à plusieurs.
Et j’ai un truc à t’avouer : je reste agile.
Et il y a peu de personnes avec qui j’arrive à en parler.
Ce sont souvent des développeurs, ou d’anciens développeurs, qui ont interprété l’agilité de la même manière que moi.
Jean-Pierre Lambert fait partie de ces gens, et c’est pour ça qu’on a fait des formations ensemble !
Ironie de l’histoire, le craft suivra le même chemin : le mouvement a le vent en poupe et je commence à entendre des voix qui s’élèvent pour en dénoncer les dérives…
Je te prépare d’ailleurs une vidéo dédiée à ce thème.
Morale de l’histoire : suis ton chemin !
Adopte ce qui te semble pertinent, et délaisse ce qui te semble inadapté.
Mais reste ouvert : avec l’expérience, tu re-visiteras peut-être certains points de vue.
Et si tu veux profiter de l’offre exceptionnelle ‘Merci à Gilles’, viens jeter un œil dans la maison des compagnons.
Tu pourras affûter tes compétences en profitant de l’expérience de Jean-Pierre et la mienne.
C’est une occasion unique de profiter de 4 formations pour même pas le prix d’une avant qu’elles ne soient définitivement retirées de la vente demain soir à minuit.
C’est ici : https://maison.
Benoit Gantaume
Artisan Développeur
Salut Benoît,
J’ai une question. Elle n’est pas totalement en lien avec le sujet pardonne moi.
En fait l’agile me donne envie, j’adhère complètement à cette idée qui est « perdre du temps à millimétrée un projet qui ne se passera pas de la manière escomptée ». Mais en même temps, si je fais un dossier de spec fonctionnelle de 50 pages, un dossier de spec technique de 25 pages, que mon client le valide, et bien, je sais où j’en suis. Je sais combien je facture et mon client sait pourquoi je sais ce que je dois faire et mon client aussi, et du coup, il ne pourra pas me pondre une fonctionnalité implicite que personne n’aurait pu deviner en refusant de la payer (tout est écrit). Comme l’agile m’intéresse beaucoup, ma question, c’est comment tu gères ça en agile ? Comment tu sais ce que tu dois facturer ? Comment ne pas tomber dans les méandres des incompréhensions avec un client qui pense que ? Je ne sais pas si j’ai été clair, mais ton avis m’intéresse fortement. D’ailleurs, je me demande si tu traites aussi de ça dans tes formations ?
Salut,
Ce dont tu parles, c’est le cadre de relation commerciale.
Tu peux être dans un cadre forfaitaire (pas très agile) et t’organiser en méthodes agiles.
L’inverse est aussi vrai.
L’idéal est d’aligner les deux, ou pas.
En tout cas tu peux découpler les deux.
++
D’accord merci
😂😂😂😂