Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
C'est une interprétation extrême du principe « Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. » parmi les 12 principes sous-jacents au manifeste agile.Envoyé par Luckyluke34
À mon avis, un chef de projet qui donne les priorités dans les grandes lignes est compatible avec l'agilité.
Tu auras remarqué que je quotais Jitou sur un point précis :
"cela m'aide à mieux organiser mes objectifs pour la journée et je crois que mon chef de projet y gagne beaucoup en visibilité sur son équipe"
Sous-entendu : le chef de projet est quelqu'un qui flique quotidiennement les tâches individuelles de chaque membre de son équipe. Et les méthodes agiles l'y aident.
Non ! C'est même l'inverse. Un chef de projet ainsi décrit n'a pas sa place dans une organisation agile, c'est contre-productif. En agile, tout le monde a une visibilité sur l'avancement du produit, ce n'est pas une personne qui a une visibilité sur une équipe qu'elle micromanage.
Un chef de projet qui se contente de donner les priorités (sur quoi d'ailleurs ?) dans les grandes lignes n'est pas un chef de projet au sens où on l'entend le plus souvent dans les entreprises. Et c'est rarement l'attitude qu'un chef de projet "classique" va spontanément adopter si on le met à la tête d'une équipe dans un contexte agile. Les dizaines de récits sur l'agilité mal appliquée par le management qui peuplent ce forum sont là pour en témoigner.À mon avis, un chef de projet qui donne les priorités dans les grandes lignes est compatible avec l'agilité.
En Agile, et même surtout en Agile, il est indispensable de mesurer régulièrement la vélocité de l'équipe (et son évolution) et donner des points d'avancement au client et à la direction.
Le purs théoriciens de l'Agile vivent dans un monde éthéré où l'argent n'existe pas et où le temps est une notion aléatoire et infinie (je caricature un peu mais pas tant que ça).
Bref, quelqu'un doit rendre des comptes, ce qui est, à mon sens, normal.
L'idéal de la méthode Agile serait que chacun assure ces tâches à tour de rôle car tout le monde a une vision de l'avancement mais dans les faits, on a une personne dédiée qui est là pour se prendre les skuds et autres joyeusetés car le projet n'avance pas assez vite ou ne prend pas la direction souhaitée, ...
Ce gus, c'est le CP.
Appelle le comme tu le souhaites mais saches qu'il est tjrs là.
Personnellement, je n'ai encore jamais vu une équipe 100% autogérée et auto-animée.
A un moment donné, l'équipe a besoin d'un leader qui entraîne les autres et lors des débats, on a besoin de quelqu'un qui sache faire la synthèse et puisse trancher si le consensus n'est pas là où s'il met trop de temps à se définir.
On ne change pas une methode qui marche
Une étude révèle que le taux d'échec des projets logiciels agiles est supérieur de 268 %
268 % de taux d'échec en plus pour les projets logiciels agiles, selon une recherche qui fait suite aux échecs catastrophiques de logiciels de plus en plus présents dans l'esprit du public.
Une étude menée auprès de 600 ingénieurs logiciels britanniques et américains révèle que les projets qui adoptent les pratiques du Manifeste Agile ont 268 % plus de chances d'échouer que ceux qui font le contraire. L'étude démontre que les taux d'échec des projets de logiciels agiles peuvent être divisés par 6,5 en utilisant une nouvelle méthodologie d'ingénierie d'impact. L'adoption de l'ingénierie d'impact pourrait permettre d'économiser 115 milliards de dollars américains par an en dépenses de R&D inutiles aux États-Unis et les contribuables britanniques pourraient économiser environ 7 milliards de livres sterling par an sur les projets gouvernementaux de changement numérique qui n'aboutissent pas.
Le développement agile de logiciels est un état d'esprit qui découle des valeurs convenues par l'Agile Alliance, un groupe de 17 praticiens du logiciel, en 2001. Comme l'indique leur Manifeste pour le développement agile de logiciels, les praticiens accordent de l'importance aux valeurs suivantes : les individus et les interactions plutôt que les processus et les outils, un logiciel fonctionnel plutôt qu'une documentation exhaustive, la collaboration avec les clients plutôt que la négociation de contrats, la réaction au changement plutôt que le suivi d'un plan.
Le Manifeste Agile existe depuis plus de 21 ans maintenant, mais la recherche empirique sur l'impact réel de ses valeurs sur l'industrie reste lacunaire, malgré une étude récente montrant que 81 % des décideurs au Royaume-Uni et 89 % aux États-Unis sont préoccupés par le respect des délais de livraison des projets de logiciels dans leur organisation.
Une nouvelle étude menée pour un nouveau livre, Impact Engineering, a montré que 65 % des projets de logiciels adoptant les pratiques d'ingénierie des exigences Agile ne parviennent pas à être livrés dans les délais et dans les limites du budget, avec un niveau de qualité élevé. En revanche, les projets qui adoptent une nouvelle approche d'ingénierie d'impact décrite dans le nouveau livre n'échouent que dans 10 % des cas.
Le taux d'échec des projets logiciels agiles est supérieur de 268 %
L'étude, menée par Junade Ali PhD CEng FIET et J.L. Partners, a vu la participation de 600 ingénieurs en logiciel (250 au Royaume-Uni et 350 aux États-Unis). Le travail sur le terrain s'est déroulé du 3 au 7 mai 2024. J.L. Partners est membre du British Polling Council et respecte ses règles.
Selon les auteurs, "la signification statistique des données de l'étude montrant que les projets utilisant les pratiques de l'ingénierie d'impact sont plus performants que tous les autres est si forte que la probabilité que cette conclusion soit incorrecte équivaut à lancer six fois consécutivement le chiffre six sur un dé à six faces, dès la première tentative" (les probabilités sont très faibles).
Trois des quatre pratiques énumérées dans le Manifeste Agile sont "le logiciel de travail plutôt qu'une documentation exhaustive", "la collaboration avec le client plutôt que la négociation d'un contrat" et "la réponse au changement plutôt que le suivi d'un plan". Toutefois, la nouvelle étude a révélé que les projets qui disposaient d'un cahier des charges ou d'exigences documentées avant le début du développement avaient 50 % de chances de plus de réussir que ceux qui n'en disposaient pas, que les projets qui avaient des exigences claires avant le début du développement avaient 97 % de chances de plus de réussir et que les projets qui ne nécessitaient pas de modifications importantes des exigences à la fin du processus de développement avaient 7 % de chances de plus de réussir.
D'autres pratiques ont également contribué à la réussite des projets. Les projets dans lesquels l'ingénieur logiciel a déclaré se sentir psychologiquement en sécurité pour discuter des problèmes et les résoudre rapidement lorsqu'ils apparaissent avaient 87 % plus de chances de réussir que ceux qui n'en avaient pas. Les projets dont les exigences se fondaient précisément sur un problème réel avaient 54 % plus de chances de réussir que les autres.
Il est intéressant de noter que l'étude n'a pas révélé de différence statistiquement significative entre la réussite des personnes travaillant sur un seul projet et celles travaillant sur plusieurs projets, bien que la réduction des travaux en cours soit un élément clé de la méthodologie de développement de logiciels Lean. Toutefois, des recherches antérieures menées par le Dr Ali ont montré que 83 % des ingénieurs en informatique déclarent souffrir d'épuisement professionnel, la "charge de travail élevée" en étant la principale raison.
Cette étude intervient alors que les défaillances logicielles catastrophiques sont de plus en plus présentes dans l'esprit du public. Dans son précédent ouvrage intitulé "How to Protect Yourself from Killer Computers", le Dr Ali a étudié de nombreux cas de logiciels mortels dont les causes techniques ont été attribuées à des problèmes de conception logicielle, notamment des avions effectuant des "plongées mortelles", des accidents de voiture mortels et des surdoses de radiations mortelles dans les hôpitaux.
En effet, le système informatique Horizon était l'un des premiers projets à grande échelle à utiliser une méthodologie Agile, à savoir le développement rapide d'applications, qui a été condamnée par les ingénieurs de Fujitsu qui ont témoigné dans l'enquête publique (Terence Austin et le dénonciateur David McDonnell) comme étant à l'origine des problèmes techniques dus à l'absence d'un processus solide d'ingénierie des exigences.
Charles Cipione, l'expert technique qui a témoigné dans le cadre de l'enquête, a résumé la situation en disant que "si vous n'avez pas une bonne conception, cela ne fonctionnera pas correctement". L'incapacité à résoudre ces problèmes et les tentatives de dissimulation ont conduit au scandale des Postes, décrit comme la plus grande erreur judiciaire de l'histoire britannique, liée à de multiples suicides de personnes emprisonnées à tort, dont une femme enceinte.
L'étude a également révélé, de manière inquiétante, que les ingénieurs en logiciel du Royaume-Uni avaient 13 % de chances en moins de se sentir capables de discuter et de résoudre les problèmes que ceux des États-Unis, ce qui représente la plus grande différence de toutes les pratiques d'ingénierie entre les deux pays. Cette constatation fait suite à une étude réalisée en novembre 2023 par Engprax, selon laquelle 75 % des ingénieurs en informatique au Royaume-Uni ont subi des représailles après avoir signalé des actes répréhensibles.
Junade Ali, auteur de l'ouvrage Impact Engineering, a déclaré :
Source : Engprax
Avec 65 % des projets adoptant des pratiques agiles qui ne sont pas livrés à temps, il est temps de remettre en question le culte de l'Agile. Nos recherches ont montré que ce qui compte lorsqu'il s'agit de livrer un logiciel de haute qualité dans les délais et dans les limites du budget, c'est un processus solide d'ingénierie des exigences et la sécurité psychologique nécessaire pour discuter et résoudre les problèmes lorsqu'ils apparaissent, tout en prenant des mesures pour prévenir l'épuisement des développeurs. C'est un élément fondamental de la philosophie de l'ingénierie d'impact.
« Impact Engineering » est désormais disponible sur Amazon en format Kindle eBook et en livre de poche. Ce roman d'entreprise est basé sur des études de cas réels de transformations personnelles et organisationnelles utilisant la méthodologie de l'ingénierie d'impact et un cadre psychologique nouvellement développé pour réaliser des transformations réussies, en plus d'un chapitre décrivant la base scientifique sous-jacente de la méthodologie.
Et vous ?
Pensez-vous que cette étude est crédible ou pertinente ?
Voir aussi :
Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités
Ouais ben c'est facile quand t'as un bon cahier des charges et des exigences claires dès le début…
Ça ne doit pas être le cas de la majorité des projets de logiciels.
Mon job actuel consiste à ajouter des fonctionnalités dans des logiciels existants, donc c'est forcément de la gestion de projet agile et du dialogue avec le client.
Il y a un client qui rédige un ticket Redmine et il faut traiter sa demande.
Ça fonctionne comment sans méthode agile ?
Ils utilisent le Cycle en V ?
Ils finissent la conception à 100% avant d'écrire la première ligne de code ?
Et à la fin le client dit vraiment "vous m'avez livré exactement ce que j'ai demandé il y a 3 ans, ça répond parfaitement à mes besoins actuels" ?
Dans cette publicité pour le livre Impact Engineering, je lis :
Donc, la définition de l'échec, c'est que le projet soit livré après une échéance fixée à l'avance ou dépasse un budget fixé à l'avance ?Today, new research conducted for a new book, Impact Engineering, has shown that 65% software projects adopting Agile requirements engineering practices fail to be delivered on time and within budget, to a high standard of quality. By contrast, projects adopting a new Impact Engineering approach detailed in a new book released today only failed 10% of the time.
Pour fixer de manière réaliste une échéance et un budget à l'avance, on y arrive moins difficilement quand on a une spécification ? Merci Captain Obvious !
Parmi les projets dans lesquels j'ai travaillé, dans le plus agile d'entre eux, les clients payaient un abonnement pour le logiciel et ce dernier avait régulièrement de nouvelles fonctionnalités. Il y avait assez peu de planification. Le choix des fonctionnalités à ajouter dépendait surtout des besoins du moment des clients les plus importants. Dans ce contexte, mesurer le succès ou l'échec par le respect d'une estimation de délai n'avait souvent pas de sens, car le délai était souvent ASAP.
Les succès, c'est quand des clients sont contents et restent, ce qui permet d'attirer de nouveaux clients. Les échecs, c'est quand des clients partent.
La méthode Agile ça marche, modulo que le développement soit fait en interne, et que l'équipe en charge du projet soit suffisamment stable, mature et redondante afin d'anticiper les éventuels turn-over.
Mets un prestataire externe dans l'équation, et tout tombe à l'eau.
Agile ou pas, ce qu'il faut à un moment, ce sont des spécifications écrites quelque part. J'ai l'impression que la méthode agile est un prétexte pour na jamais écrire de documentation technique. Je ne comprend même pas comment on peut penser que ça peut fonctionner.
Comment vous pouvez savoir si tel comportement dans le logiciel est normal ou pas s'il n'est documenté nulle part. C'est encore pire quand le turnover est important: ceux qui détenaient la connaissance se sont barrés et les nouveaux arrivants se débrouillent comme ils peuvent.
Avec les méthodologies Agile/SCRUM, j'ai l'impression de passer plus de temps en réunion mais un projet doit surtout partir sur des bases saines :
- dans quel environnement l'application doit fonctionner afin de faire le bon choix au niveau architecture et technologies (serveurs/client lourd/client léger, partie sécurité, dimensionnement... on a pas systématiquement besoin d'AWS/GCP/...)
- si applicable avoir une idée des améliorations/usages futurs qui peuvent impacter le point 1
- les fonctionnalités en mettant de l'importance sur les données d'entrée nécessaires et ce qui doit être produit par le système
Après une équipe de développement est autonome quand :
- les priorités sont identifiées
- les fonctionnalités sont identifiées avec les bonnes informations dedans. Le design de l'interface graphique ne devrait pas être imposé par le client mais plutôt partir de suggestions.
- il y a des pipelines de tests comme ça les corrections se font dans la foulée
Il faut de la documentation technique, mais pas toujours au point de détailler la totalité du fonctionnel comme dans une spécification.
C'est possible, mais il y a plein de conditions à réunir :
• Il existe des cas où les détails de certains algorithmes ne sont pas communiqués au client, donc n'ont pas besoin d'être dans la documentation utilisateur.
• Il y a aussi des cas où les personnes de l'entreprise qui ont la connaissance métier savent lire du code. Ça arrive plus souvent quand l'entreprise est petite.
• À partir d'un certain niveau de qualité, le code fait partie de la doc pour les personnes qui savent lire du code. Ce niveau de qualité est rarement atteint, mais ça arrive.
• Comment savoir si un comportement d'un logiciel est normal ou accidentel ? Par les tests automatisés. Si un comportement est présent dans un test automatisé, normalement, c'est qu'il est intentionnel. Les contre-exemples sont les characterization tests. Mais, si un test est un characterization test, il faut qu'il soit décrit comme tel.
En résumé, ne pas dupliquer l'intégralité du fonctionnement du logiciel dans des spécifications, ça peut très bien marcher avec une petite équipe de développeurs d'élite pour certains projets.
Un autre point avec lequel il faut faire attention, c'est que la majorité des développeurs ne savent pas maintenir à jour de la documentation, surtout si cette dernière est volumineuse. Ils galèrent déjà beaucoup à maintenir à jour une petite documentation. Dans un projet typique, il y a d'un côté du code qui est à jour mais pas vraiment compréhensible, et de l'autre une documentation qui n'est pas à jour.
Cependant, quand des personnes qui ne développent pas sont spécialisées sur l'écriture de spécifications, dans mon expérience, elles arrivent mieux à maintenir à jour ces spécifications, étant donné qu'elles ne sont pas occupées avec le code.
Un turnover élevé est toujours néfaste pour la productivité.
Quand un système n'est pas compréhensible sans la connaissance tribale, effectivement, les dégâts sont encore plus élevés.
J'aimerai connaitre, parmis la part des projets "Agile" ayant échoué, quels sont les projets vraiment Agile et quels sont les projets ou un caoch agile grassement payé s'est pointé en déroulant son template et en collant des réunions à tour de bras parce que c'est marqué dans le Scrum Guide...
On s'est mis à faire de l'agile car les méthodes de gestion projet classique type Waterfall ou cycle en V ne s'adaptaient pas aux projets portant sur des techno emergente ou des marché inconnue. Il y a beaucoup de projet où on ne sait juste pas ce que le logiciel est censé faire et où même le client n'es sais foutre rien, (quoi qu'il puisse en penser). C'est là qu'Agile a un intéret. Il permet de piloter un système cahotique par itération successive.
Pour un system connue, contrain et un marché stable comme l'aéronautique, le médical, etc... Agile a beaucoup moins d'intéret. Il faut arréter de vouloir trouver une formule magique qui marche partout.
Ô surprise... Suffit de lire le manifeste pour deviner que permettre d'ajouter sans fin des idées fantaisistes à un projet au budget inextensible est le meilleur moyen de tuer un projet.
Moxie Marlinspike : Agile tue l'innovation en confinant les développeurs dans des boîtes noires d'abstraction
« Agile tue l'innovation en confinant les développeurs dans des boîtes noires d'abstraction qui limitent la créativité et la compréhension des systèmes sous-jacents »
affirme l'un des développeurs de Signal
Moxie Marlinspike regrette l'absence inquiétante de l'innovation dans le développement logiciel moderne. L'entrepreneur américain pense que la cause principale de cette perte d'innovation est le développement Agile. Il a fait valoir que les méthodes Agile, largement adoptées au cours des deux dernières décennies, ont confiné les développeurs dans des "boîtes noires d'abstraction" qui limitent la créativité et la compréhension des systèmes sous-jacents. Cette approche aurait laissé de nombreux ingénieurs logiciels incapables de faire plus qu'un travail dérivé, ne possédant pas la compréhension profonde nécessaire aux développements révolutionnaires.
Moxie Marlinspike est cryptographe américain, chercheur en sécurité informatique et entrepreneur. Il est l'un des cocréateurs de l'application de messagerie chiffrée Signal et le cofondateur de la Fondation Signal. Lors de son passage à la conférence Black Hat 2024, Marlinspike a fait un bilan peu élogieux du développement logiciel moderne. Marlinspike a déclaré que le développement logiciel moderne n'encourage ni ne favorise l'innovation et est confronté à une complexité inutile. Selon le chercheur en sécurité, les bonnes pratiques de développement ont été progressivement perdues au cours des vingt dernières années.
Marlinspike pense savoir exactement ce qui est à blâmer : le développement Agile. « Nous avons passé les vingt dernières années à intégrer des personnes dans des logiciels en les plaçant dans des couches d'abstraction de boîtes noires, puis dans des organisations composées de couches d'abstraction de boîtes noires », a déclaré Marlinspike. Selon lui, cette approche "basée sur les boîtes noires d'abstraction" prive les développeurs de la liberté nécessaire à l'innovation :
En gros, Marlinspike affirme que "les ingénieurs en logiciel n'ont pas pu faire mieux que d'être des produits dérivés". Le PDG de Thistle Technologies, Window Snyder, s'est fait l'écho de ces préoccupations. Selon Snyder, ces équipes "boîte noire" ont tendance à manquer de visibilité sur certains aspects fondamentaux du fonctionnement de leurs propres produits. Snyder déplore le fait que plusieurs programmeurs se ruent sur les langages de haut niveau qui facilitent le développement d'applications, et à la fin, ils n'ont plus aucune connaissance des langages de bas niveau et des interactions avec le code machine.
Snyder affirme : « 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é ». À ce propos, Marlinspike a fait valoir que les chercheurs en cybersécurité, qui sondent régulièrement les abstractions de surface, sont mieux placés pour stimuler l'innovation dans le développement de logiciels.
« Alors que l'ingénierie logicielle a passé les dernières décennies à s'efforcer de devenir plus rapide, plus flexible et, par extension, plus abstraite, les chercheurs en sécurité ont fait le contraire. La sécurité est le processus qui consiste à regarder à travers les abstractions afin de comprendre comment les choses fonctionnent, ce qu'elles contiennent, et parfois de les comprendre mieux que les personnes qui les ont construites au départ. Ce que j'essaie de dire, c'est que sans le savoir, je pense que vous, les personnes présentes dans cette salle, avez en fait hérité de leur Terre », a déclaré Marlinspike lors de son intervention.
Selon certains rapports, le problème souligné par Snyder et Marlinspike pourrait s'aggraver avec la profusion d'outils d'IA de génération de code. « Il y a de la magie dans le développement de logiciels », affirme Marlinspike, en ajoutant que la compréhension approfondie du fonctionnement est analogue à la maîtrise de la sorcellerie dans le monde d'Harry Potter, où le talentueux peut changer le monde avec rien d'autre que ses connaissances et une baguette magique.
Le développement agile de logiciel est un état d'esprit qui découle des valeurs convenues par l'Agile Alliance, un groupe de 17 praticiens du logiciel, en 2001. Comme l'indique leur Manifeste pour le développement agile de logiciels, les praticiens accordent de l'importance aux valeurs suivantes : les individus et les interactions plutôt que les processus et les outils, un logiciel fonctionnel plutôt qu'une documentation exhaustive, la collaboration avec les clients plutôt que la négociation de contrats, la réaction au changement plutôt que le suivi d'un plan. Mais pour beaucoup de critiques, l'approche Agile ne marche pas.
La récente sortie de Marlinspike fait à de nombreuses autres plaintes selon lesquelles le développement logiciel a perdu tout son charme d'antan. Une étude menée auprès de 600 ingénieurs logiciels britanniques et américains a révélé que les projets qui adoptent les pratiques du Manifeste Agile ont 268 % plus de chances d'échouer que ceux qui font le contraire. L'étude démontre que les taux d'échec des projets de logiciels Agile peuvent être divisés par 6,5 en utilisant une nouvelle méthodologie d'ingénierie d'impact. Pourtant, de nombreuses équipes d'ingénierie se tournent systématiquement vers les méthodes Agile.
Selon l'étude, l'adoption d'une ingénierie d'impact pourrait permettre d'économiser 115 milliards de dollars par an en dépenses de R&D inutiles aux États-Unis et les contribuables britanniques pourraient économiser environ 7 milliards de livres sterling par an sur les projets gouvernementaux de changement numérique qui n'aboutissent pas. Certains experts affirment que l'approche Agile conduit les organisations vers une technique beaucoup plus importante.
Par ailleurs, l'approche Agile n'est peut-être pas le seul facteur qui limite l'innovation dans le développement logiciel moderne. Dans une analyse détaillée publiée le mois dernier, Avery Pennarun, ancien ingénieur de Google et PDG de la société de VPN Tailscale, a sévèrement critiqué les pratiques modernes de développement de logiciels. Pennarun affirme que le développement logiciel moderne est submergé par une complexité inutile et des "frais généraux inutiles".
Selon Pennarun, ce phénomène est dû à "une focalisation erronée" sur l'évolutivité pour des tâches qui en ont rarement besoin. Il met en cause : la mise à l'échelle, les conteneurs, le cloud computing, etc. Il oppose les pratiques de développement actuelles à l'efficacité de la programmation dans les années 90, où des systèmes plus simples pouvaient gérer des charges de travail substantielles rapidement et efficacement sans l'infrastructure gonflée que l'on voit aujourd'hui.
Source : Moxie Marlinspike
Et vous ?
Voir aussi
Ce n'est pas vrai, j'ai eu des cours sur les langages bas niveau lors de mon master informatique.
Mais d'un autre côté c'est vrai que je ne me rappelle pas de grand chose.
Qu'est-ce que c'est une "méthodologie d'ingénierie d'impact" ?
J'ai recherché vite fait et je n'ai rien trouvé.
L'approche agile peut fonctionner pour plein de projets.
La collaboration avec les clients, un logiciel fonctionnel, la réaction au changement, je trouve ça plutôt cool.
En tout cas c'est adapté à ce que je fais, puisque je corrige ou j'ajoute des fonctionnalités dans des logiciels existants. Donc il y a des réunions régulières, parfois un client dit "dans ce scénario nous n'obtenons pas le résultat attendu" ou "nous avons besoin d'une nouvelle fonctionnalité" et lors de la réunion suivante on montre la progression au client. (quand ce sont des petites modifications il y a une livraison avant la réunion suivante)
====
Au moins les méthodes agiles ne sont pas le cycle en V, je n'aime pas le cycle en V.
Apparemment selon ce blog https://http103.medium.com/impact-en...w-c6625d97ccc7 ça vient de ce bouquin https://www.amazon.co.uk/Impact-Engi.../dp/1068605723 . Les critiques disent que c'est du baratin dans une prose à la GPT qui se résume à "écrire les spécifications avant de coder" plus sur des critiques infondées d'agile.
Si ça c'est révolutionnaire (comme le présente l'éditeur), alors il faut relire Jean-Raymond Abrial l'inventeur de la méthode b et ce qu'il pense des cycles classiques de développement. C'est assez drôle. https://www.01net.com/actualites/jea...er-173964.html
Je confirme
Je suis développeur senior dans tous les languages, et depuis qu'on a adopté la méthode agile c'est clairement la cata. J'ai toujours l'impression d'avoir la tête dans le guidon. Les sprint ne correspondent a rien, ça n'a aucun sens en terme de développement. Cette méthode a ete inventé par des javaistes, qui sont pour la plupart incompetent. Ils ont donc pondu une méthode d'incompetent. Le pire c'est que par l'intermédiaire des scrum ils propagent leur idée comme une religion. Tant qu'il y aura des pigeons pour payer cette méthode prolifera comme un poison.
Il existe des méthodes agiles qui ne reposent pas sur des sprints. (Kanban, Extreme Programming, Lean Software Development, Continuous Delivery/Continuous Integration)
Les sprints c'est un truc important dans SCRUM.
Il y a des itérations en Extreme Programming mais l'accent n'est pas mis la dessus.
En utilisant une méthode agile pour gérer un projet on peut répondre rapidement aux besoin du client.
Le client arrive, il dit "je veux cette fonctionnalité", les développeurs implémentent ce que la client à demandé, lors de la réunion suivante les développeurs montrent la fonctionnalité au client "Voilà exactement ce que vous avez demandé" et le client "Ah ben finalement ce n'était pas qu'il me fallait, j'ai mal exprimé mon besoin".
Donc c'est cool parce que le client voit rapidement ce qu'il demande, le projet peut ainsi répondre correctement aux besoins réels du client.
Ce n'est que mon opinion...
Bonjour à tous.
Nous voici donc avec une discution commencée en 2018 et qui "repart" en 2024. Intéressant... Je n'avais pas participé à l'époque, car la discussion ressemblait plus à une guerre de religion qu'a autre chose.
J'ai maintenant une certaine expérience, et des méthodes, j'en ai vu passer, du moins "théoriquement".
Sans penser avoir "la solution" à la difficulté de réussir un projet "logiciel", j'ai, au fil du temps, remarqué plusieurs choses. Je les cite en vrac.
- La "compétence" ou "formation" des "développeurs" a grandement diminué depuis qlq décénies. Je ne sais pas à quoi cela est dû exactement, c'est juste une constatation que j'ai faite. D'autres n'ont peut être pas ce ressentiment, et peut-être que cela dépend du domaine dans lequel on bosse.
- Faire appel à la sous-traitance a toujours été un fiasco. Un sous-traitant n'est pas là pour touver une "bonne solution" à un projet, mais à prendre tous les raccourcis possible pour livrer "au plus vite" quelque chose qui "ressemble" à une solution. Que cette solution puisse ou pas "évoluer" dans le temps long ne fait pas partie des préoccupations. C'est même le contraire, afin de se rendre "indispensable" au "client", s'assurant la/les mises à jour.
- De plus en plus (ça doit être l'époque qui veut ça), des mots magiques "sortent du lot" (pour l'instant c'est l'IA), et il faut utiliser ces nouvelles "religions" pour se sentir exister ou être "à la pointe du progrès".
- De plus en plus de couches se sont glissées entre le besoin et la réalisation de ce besoin. Au point de parfois même "inventer un besoin" pour justifier le rôle d'un "Poste".
- Pour monter en salaire, l'expérience n'est pas valorisée, et la seule solution et de soit changer de boîte, soit grimper dans la hiérarchie de l'entreprise. Et là, ça devient plus un jeu politique que technique, et les "camas" des "camas" auront toujours l'avantage, ce n'est plus une question de compétence.
- Très vite arrive le "principe de peters", à savoir que l'on arrête de monter lorsque l'on est arriver à un point ou l'on n'est plus compétent. Un bon développeur (pour gagner plus), tente de passer chef de projet, là ou il sera éventuellement médiocre. L'entreprise perd un "bon développeur" et gagne un "mauvais chef de projet". Il suffirait d'augmenter le salaire des "bons développeurs" pour éviter la chose, mais sauf dans une entreprise où le "logiciel" est au coeur du métier, "l'informaticien" ne sera jamais valorisé, c'est juste une "ressource" comme disent les RH, pensant qu'on remplace un "développeur" par un autre "développeur" comme on change une chaise par une autre.
- On complexifie inutilement les "porblèmes a solutionner", mais aussi "la manière dont on les solutionne".
Les méthodes permettent au "superviseur" du projet à avoir des graphiques et des "choses" a montrer à ses supérieurs. Un projet ne profite pas plus d'une méthode que d'une autre.
En fait, la seule chose qui compte pour qu'un projet réussisse, c'est la communication entre les membres de l'équipe, savoir dire "non", savoir expliquer pourquoi ce "non", privilégier le bons sens, et s'en tenir au principe KISS. Il faut également savoir garder les gens là où ils sont le plus utiles à l'entreprise, et donc ne pas privilégier la montée dans la hiérarchie pour la montée en salaire.
Avec le temps, j'en suis arriver à la conclusion qu'il ne faut pas de "méthode", ni de "documentation" (souvent générée automatiquement et pas à jour, un code source clair, limpide et simple vaut 1000x toutes les documentations), mais énormément d'échange et d'intéraction, pour comprendre les problèmes (qui n'en sont peut-être pas). Une fois un problème bien cerné, implémenter une solution limpide et le plus simplement possible.
Perso, je garde à jour un simple document, évolutif, dans lequel se trouve (1) ce que l'on fait, (2) pourquoi on le fait, et (3) comment on l'a fait. Le comment on l'a fait est mixte de "problème/solution" (expliquer le problème, et comment on le résout).
BàV et Peace & Love.
Là où je me retrouve quelque part dans le contexte de cet article, tout en n'étant pas d'accord avec l'opinion défavorable d'Agile de l'auteur : pour réussir, il faut décloisonner, si on a par exemple une API dans Azure et un middleware de messages vers d'autres applications, il faut un minimum de connaissance technique partagée pour réussir plus efficacement l'analyse de la résolution de problèmes qui concernent les deux éléments. Et là, l'article postule que l'équipe chargée de la sécurité a accès à tout, mais l'équipe de l'API et celle du middleware seraient chacune dans sa boîte noire... C'est de là que viennent les frustrations, si les gens ne savent plus communiquer, ne font plus l'effort de communiquer et ne s'intéressent plus à ce qu'il y a à la marge des autres boîtes noires.
En tant que dév senior dans le domaine .NET, je suis intéressée par beaucoup de choses qui gravitent autour de mes projets Agile, aussi bien fonctionnel que technique, et franchement je suis très satisfaite de la façon dont nous utilisons efficacement l'agilité, nous ne ressentons pas de lourdeur inutile, nous respections les sprints, ceux en amont sont rassurés par les delivery boards qui planifient plusieurs sprints à l'avance et mettent en avant les dépendances. On a attendu des années avant d'être efficaces sur ce dernier point mais c'est parce qu'on a changé de scrum master qu'ils ont enfin réussi à mettre en place certaines choses désirées depuis longtemps, en trouvant comment utiliser les outils.
Répondre avec citation
Partager