Bonjour,
Je suis tombé sur cette article.
Je voulais avoir un peu votre avis la dessus.
A mon sens il évoque beaucoup de facteur dans l’article : des languages trop haut niveau, une mauvaise vision d’ensemble qu’il associe à l’agilité.
Pensez-vous que c’est de l’agilité mal appliquée ? Où qu’en effet l’agilité peut etre un frein ?
J’en ai fait la lecture également ce matin.
Si je reconnais une part de vérité dans les propos de Mokie Marlinspike, je considère davantage qu’il s’agit d’un problème d’application du manifeste. Rien n’indique dans ce manifeste et des frameworks de ne pas s’intéresser au bas niveau. Je ne crois pas non plus que ce soit l’agilité, apparu seulement en 2001, qui soit à l’origine de cet éloignement
J’ai deux remarques sur cet article :
Toute personne qui gère une organisation d’ingénierie aura une philosophie de gestion qui est, d’une manière ou d’une autre, en aval, dérivée, dans la zone ou liée d’une manière ou d’une autre à la méthode agile.
Si on parle de « Agile trademark » pourquoi pas, mais dans les fait 99% des organisations qui se disent agile ne le sont pas. Donc affirmer tout le monde est lié à l’agile et que c’est la cause de tous les maux me semble être un argument particulièrement spécieux.
Les étudiants en programmation n’apprennent pas les langages de bas niveau ni comment interagir avec le code machine, mais seulement des langages de haut niveau qui facilitent le développement d’applications, mais qui laissent les ingénieurs sans le contexte nécessaire pour comprendre comment leurs pièces du puzzle s’intègrent dans un ensemble plus vaste et largement interconnecté.
A mon avis il faut mettre le doigt plutôt sur le développement massif « d’écoles de programmation » en ligne. La plupart fournissent une formation superficielle où on t’apprend - en quelques semaines - à écrire du code plutôt qu’à programmer. Mais il y a deux remarques complémentaires à faire :
Des formations académiques, sérieuses et complètes, ça existe encore partout de le monde. Seulement on ne peut pas « fabriquer » autant d’ingénieurs de niveau master que de les centaines de codeurs qui sorte d’un petit dojo qui « diplôme » 30 personnes toutes les 6 semaines. Le développement de ces structures répond à la logique de nombreuses entreprises qui voulaient embaucher des cohortes de développeurs. Avant de les jeter à la poubelle l’année dernière ;
Le marché américain est hautement dérégulé et ça arrange bien les employeurs de ne pas faire de différence entre un développeur qui sort d’une école de codage et qui sait vaguement écrire du TypeScript, et celui qui a un master en informatique avec un cursus complet : systèmes, réseaux, signal, microprogrammation, microprocesseurs, différents langages, … Le problème n’est pas le même en France où le diplôme est roi, et où ingénieur diplômé a un certain avantage dans son taux d’employabilité. Je pense que la situation est également très différente au Canada où la profession est réglementée. Il serait intéressant d’avoir l’avis de nos confrères québécois sur la question.
En conclusion, je pense que l’auteur se trompe en accusant l’agilité car peu d’organisation sont vraiment agiles. Le problème sous-jacent sur lequel il met le doigt c’est plutôt la traditionnelle dualité ingénieurs/codeurs.
@ArwynFr, j’ai l’impression que tu supposes que l’agilité ne peut pas être mise en cause pour le fait que peu d’organisations sont vraiment agiles. A mon avis, on a récolté ce qu’on a semé.
Cet article m’a également intrigué.
Avis court : L’agilité tue l’innovation mais pas pour les raisons données par l’article.
Avis moyen : Pour voir de vraies raisons sur pourquoi l’agilité ne permet pas de générer de l’innovation de rupture, je peux donner deux pistes :
Avis un peu plus long :
Ben là je veux bien que tu m’expliques comment l’agilité pourrait rendre les gens moins créatifs sachant que y’a trois pelés dans le monde qui en font vraiment et que pour tous les autres « Agile » c’est juste la même chose qu’avant avec des mots différents.
Dans ton argumentation tu parles d’innovation de rupture mais il me semble que l’article ne parle pas de ça. Un autre élément qui explique aussi les difficultés, c’est que depuis 40 ans on passe d’un modèle d’infrastructure informatique très centralisé à un modèle très distribué (internet, CPU multicores, cloud, orchestration). Ca rend les fameux systèmes sous-jacents plus complexes qu’avant, et donc plus difficiles à appréhender du point de vue du développeur logiciel.
Tu mélanges plusieures choses qu’il faut bien séparer : Tu confonds créativité et innovation et tu ajoutes le problème de la fausse agilité.
L’agilité tue l’innovation de rupture en prônant dans les faits une démarche où un objectif lointain est visé et on essaie de l’atteindre par petits pas rapides en ajustant au fur et à mesure. Cela peut paraitre contre-intuitif mais avoir un objectif lointain limite les opportunités d’innovation de rupture. Cela ne rend pas impossible mais diminue les chances. Déjà, un objectif rend aveugle aux autres opportunités rencontrés en chemin (cf. Cécité d'inattention — Wikipédia). Ensuite, généralement une innovation de rupture était inexprimable par les utilisateurs (« Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient dit des chevaux plus rapides » Henry Ford). Ensuite, la plupart des produits échouent sur le marché. Enfin, la grande majorité des découvertes et innovations se font plus par sérendipité.
Pour un peu plus d’explications : Product Management Contextuel | William Bartlett | Oct, 2023 | Medium.
Je l’ai dit que je fait un pas de côté par rapport à l’article puisque je ne suis pas d’accord avec le raisonnement de Marlinspike.
Comme Clayton Christensen et d’autres, je distingue innovation de rupture et innovation incrémental. L’agilité ne favorise pas la première, mais bien la seconde.
C’est ce que j’ai dit. C’est un aspect de la commoditisation.