LLM et Agilité : pourquoi les opposer ?
Parce qu'on développe plus vite, il n'y aurait plus besoin d'Agilité ? Cette idée trahit une mauvaise compréhension de ce qu'est l'Agilité.
Parce qu'on développe plus vite, il n'y aurait plus besoin d'Agilité ? Cette idée trahit une mauvaise compréhension de ce qu'est l'Agilité.
Le problème, c'est que la base de comparaison (Waterfall) conduit à un logiciel qui ne répond pas au besoin des utilisateurs…
Ne demandez plus « combien de temps ça va prendre ? », demandez-vous plutôt si vous pouvez découper encore un peu plus votre travail.
Il y a des MVP à 10000€, d'autres à 10 millions d'Euros. L'objectif est le même, acquérir de vrais utilisateurs, mais tout dépend du marché.
Pour insuffler un changement durable, mieux vaut convaincre qu'ordonner. Cependant, ce changement prend du temps et nécessite des personnes autonomes.
User Story ou tâche technique ? Derrière une querelle de mots, l'arbitrage entre la valeur d'aujourd'hui et celle de demain.
Quand les « usagers » sont maltraités par une entreprise en situation de monopole, il y a matière à monter une entreprise concurrente.
« C'est bien d'apprendre de ses erreurs. Il vaut mieux apprendre des erreurs des autres. » Warren Buffett parle d'investissement, je vous parle de sprints.
Les méthodologies séquentielles ne fonctionnent pas pour l'informatique de gestion, principalement à cause de l'effet tunnel. L'alternative ? L'Agilité.
Si vous ne deviez garder qu'une chose de l'Agilité, gardez la rétrospective. Lieu de l'amélioration continue, elle ouvre à la résolution de problèmes.
L'ADR permet de rationaliser les décisions d'architecture d'une équipe et d'éviter qu'elles ne soient sans cesse remises en question.
L'Agilité est l'art du « comment », le Product Management celui du « quoi ». L'un sans l'autre ne sert à rien : ce sont l'avers et le revers d'une même pièce.
« Le lean n'est pas un système de production, c'est un système d'apprentissage » : cette phrase m'a mis le pied à l'étrier pour comprendre le Lean.
Le Walking Skeleton a pour vocation de poser des fondations saines pour aller au MVP en minimisant la dette technique. Une étape que l'on gagne à formaliser.
Une erreur serait de croire que la conception fonctionnelle est l'apanage du PM : on réfléchit mieux à plusieurs et sur base d'exemples concrets.
Le Trunk-Based Development, tout droit issu de l'Extreme Programming, est une excellente alternative à GitFlow, mais étudiez bien les prérequis.
Un POC permet de valider une idée d'ordre marketing ou technique, tandis que le MVP vise à acquérir vos premiers utilisateurs.
Il y a projet parce qu'on se projette sur une fin à atteindre. Un produit n'a pas de fin et se développe au gré du feedback de ses utilisateurs.
Mon principal reproche à Scrum, c'est qu'il ne dit rien de la conception fonctionnelle. Si vous voulez que ça marche, c'est à vous de compléter.
« As a user, I want to connect to the database, So that I'm connected to the database. » Super, ou pas : on doit pouvoir faire mieux que ça.
Plutôt que de faire des estimations, qui sont correctes comme une pendule cassée (qui donne la bonne heure 2 fois par jour), découpez votre travail.
En se popularisant, l'Agilité a été dévoyée, devenant synonyme de micro-management et de pratiques absurdes. Pourtant, on a plus que jamais besoin d'Agilité.