Discussion :

[gangsoleil]

Bonjour,

a/ les equipes auto gerées se generent aussi d'elles memes du boulot (l'agilité se traduit souvent par un refus de tout ce qui ne provient pas de l'equipe ! c'est plutot de la rigidité).

b/ lorsqu'un client exprime un besoin (ex: technique), l'equipe de dev en fait souvent plus (et donc deroule des heures pas forcement vendues). Un peu comme si c'etait un test technique qu'il fallait relever. resultat vecu : on nous demande d'implementer une interface selon 2 protocoles => au final 5 protocoles techniques sont implementés (derive des devs qui se sont faits plaisirs). Le client est content certes car on lui en donne plus que prevu; par contre nous on bouffe la culotte en consommant des heures non vendues.

Ce n'est pas parce que vous appliquez mal agile que la méthode est pourrie.

Pour la demande client, il est normal, et même souhaitable, que l'équipe se pose la question suivante : est-ce utile prendre un peu plus de temps pour faire une interface générique qui nous permettra de supporter d'autres protocoles ou non. Si la réponse est oui, alors il faut l'implémenter.
Mais ça ne veut pas dire implémenter d'autres protocoles.

Ont-ils livré dans les temps, et en respectant les coûts ? Si oui, pas grand chose à redire. Si non, il faut analyser pourquoi, et corriger.

[ZenZiTone]

Ce n'est pas parce que vous appliquez mal agile que la méthode est pourrie.

+1.. Et c'est là que beaucoup d'équipes se vautrent. Mettre en place un backlog, des sprits et des daily ne suffit pas à faire de l'agilité... L'agilité est à la base, des concepts. En découle des méthodes et des outils pour valoriser ces concepts. En théorie, deux équipes différentes ne peuvent appliquer strictement la même méthode suivant les affinités des membres de l'équipe, des clients, des projets..

Beaucoup se leurrent dans l'idée qu'appliquer la méthode scrum permettra rapidement à être plus performant. L'agilité est un état d'esprit, une manière d'aborder les projets.

[Luckyluke34]

<zip>

Je ne vois rien d'inputable aux méthodes agiles dans tout ça.

Agile préconise au contraire une collaboration quotidienne avec le demandeur métier responsable du retour sur investissement du logiciel. C'est à peu près l'inverse de "les devs font ce qu'ils veulent".

Sur l'aspect "jouer avec des technos" et le turnover, ça peut arriver sur n'importe quel type de projet.

[-]

Pour le TDD je suis en désaccord complet, pour le reste ce monsieur a plutôt raison. L'agile mal appliqué est un cancer.

[Saverok]

Pour le TDD je suis en désaccord complet, pour le reste ce monsieur a plutôt raison. L'agile mal appliqué est un cancer.

Peu importe la la méthode et le sujet, lorsque c'est mal appliqué, c'est le bordel.
Du coup, on peut écrire exactement le même type d'article à propos des travers du cycle V est d'une application merdique de celui-ci.

[Glutinus]

Peu importe la la méthode et le sujet, lorsque c'est mal appliqué, c'est le bordel.
Du coup, on peut écrire exactement le même type d'article à propos des travers du cycle V est d'une application merdique de celui-ci.

Les énormes travers du V ?
Les effets Tunnel avec les MOA qui jouent de la balalaika avec les utilisateurs, livrent leurs specs la veille de la mise en recette mais "on repousse pas la MEP".
Les MOA qui veulent pas entendre parler de "lignes", "colonnes", "fonctions" car "je suis pas technique"
Les chefs de projet qui oublient de prendre en compte des contraintes commes des livraisons de serveur
Les équipes de production qui se sentent mal-aimées des développeurs et vice et versa.
Les développeurs geek qui oublient qu'on développe par pour faire du code, mais pour créer des fonctionnalités qui seront utilisées par des utilisateurs, à terme.

Et vous savez quoi ? Des problèmes surviendront aussi en agile tant qu'on n'arrivera pas à communiquer entre équipes.

[Jacti]

Il ne faut pas confondre TDD et les tests unitaires, au sens classique, qui eux sont indispensables car ils servent à mesurer le pourcentage de couverture du code.
Ecrire des tests unitaires avant d'écrire le code est tout simplement de la foutaise.

[Stéphane le calme]

Agile est-il mort ? Pour un ingénieur « Le développement "agile" avec lequel nous sommes coincés aujourd'hui est une blague »,
il souligne ses dysfonctionnements dans les processus de développement en entreprise

Depuis ses débuts dans les années 2000, l'agilité a profondément transformé la manière dont les entreprises abordent la gestion de projets et le développement logiciel. Elle ne se résume pas à des pratiques ou des outils, mais représente une philosophie basée sur des principes fondamentaux qui mettent l’accent sur la flexibilité, la collaboration, et l’orientation client. Pourtant, plus de deux décennies après la publication du Manifeste Agile, cette approche est à la croisée des chemins : célébrée pour ses succès, mais critiquée pour ses dérives.

Aux origines de l’agilité : une révolution managériale

En 2001, dix-sept experts du développement logiciel se réunissent à Snowbird, dans l’Utah, pour répondre à un problème majeur : les méthodes traditionnelles de gestion de projet, comme le cycle en V ou la méthode Waterfall, s’avéraient inefficaces face à des environnements incertains et changeants. Le résultat de cette rencontre fut le Manifeste Agile, un texte court, mais révolutionnaire, articulé autour de quatre valeurs qui ont été déclinées en douze principes afin d'aider opérationnellement les équipes qui souhaitaient les suivre.

En s'appuyant sur leur expérience combinée du développement logiciel, les dix-sept signataires du manifeste ont proclamé qu'ils attachaient de l'importance « aux individus et leurs interactions plutôt qu'aux processus et aux outils », « à un logiciel fonctionnel plutôt qu’à une documentation exhaustive », « à la collaboration avec les clients plutôt qu'à la négociation contractuelle » et « à l’adaptation au changement plutôt qu'à l'exécution d’un plan ». Cela signifie que les éléments à gauche du mot « plutôt » dans chaque citation sont réputés avoir plus de valeur que ceux à droite, bien qu'il y ait aussi de la valeur dans ces derniers. Ces quatre citations sont appelées les quatre « valeurs » du manifeste agile.

Ces valeurs traduisent une rupture avec les approches rigides et une volonté de recentrer le travail sur ce qui génère réellement de la valeur : les équipes, les produits, et les besoins évolutifs des utilisateurs.

Un succès retentissant

L’agilité a rapidement gagné en popularité, portée par des méthodologies comme Scrum, Kanban, ou Extreme Programming (XP). Ces frameworks apportaient des outils concrets pour implémenter les principes agiles dans les organisations. Dans les années 2010, l’agilité a commencé à s’étendre bien au-delà du développement logiciel, touchant des domaines tels que le marketing, les ressources humaines et même la gestion stratégique.

L’agilité aujourd’hui : succès et critiques

Malgré ses nombreux succès, l’agilité n’a pas été épargnée par les critiques. Si elle a permis à des entreprises comme Spotify ou Amazon d'atteindre des niveaux impressionnants d’innovation et de réactivité, elle a également été victime de détournements et de dérives qui en dénaturent l’esprit.

Les succès de l’agilité

• Une meilleure gestion de l'incertitude : Les approches agiles permettent aux équipes de s’adapter rapidement aux changements, en livrant régulièrement des incréments de valeur.
• Une collaboration renforcée : Grâce à des pratiques comme les stand-ups quotidiens et les rétrospectives, l'agilité favorise une communication transparente et continue entre les membres des équipes.
• Un focus sur l’utilisateur : En impliquant le client tout au long du processus, l’agilité garantit que les produits répondent réellement à leurs besoins.

Les critiques envers l’agilité

• La "superficialité agile" : Dans de nombreuses organisations, l’agilité est réduite à un ensemble de cérémonies ou d'outils (sprints, burn-down charts) sans réelle compréhension des principes fondamentaux.
• Une rigidité paradoxale : Certains frameworks, comme SAFe (Scaled Agile Framework), sont perçus comme trop lourds et bureaucratiques, en contradiction avec l’esprit de flexibilité promu par l’agilité.
• La marchandisation : La multiplication des certifications agiles a créé une industrie lucrative, parfois déconnectée des besoins réels des équipes et des entreprises.
• Une mauvaise intégration culturelle : Dans des structures hiérarchiques traditionnelles, les principes agiles peinent souvent à s’imposer face à des résistances au changement.

Les défis de l’agilité à l’ère moderne

L’agilité se trouve confrontée à des enjeux nouveaux, liés à l’évolution rapide des environnements professionnels et technologiques.

1. La complexité croissante des organisations : Dans les grandes entreprises, la mise en œuvre de l’agilité à grande échelle est souvent un défi. La coordination entre plusieurs équipes, la gestion des interdépendances, et la nécessité de satisfaire des parties prenantes multiples rendent l’application des principes agiles plus difficile.
2. La montée de l’intelligence artificielle : L’émergence de technologies comme l’intelligence artificielle (IA) ou le machine learning (ML) redéfinit les cycles de développement. Comment concilier les approches agiles avec des disciplines où l’expérimentation et la recherche prennent parfois le pas sur la livraison itérative ?
3. Les attentes sociétales : Dans un monde de plus en plus axé sur la durabilité et la responsabilité sociale, l’agilité doit évoluer pour inclure des préoccupations éthiques et environnementales.

Pour un ingénieur, Agile est mort

« Le développement "agile" avec lequel nous sommes coincés aujourd'hui est une blague - un désordre étouffant orchestré par des imposteurs qui ne reconnaîtraient pas un logiciel de qualité s'il les frappait au visage. Nous sommes noyés sous le poids de chefs de produit, de managers et de propriétaires qui n'ont jamais écrit une ligne de code et qui, pourtant, dictent d'une certaine manière la manière dont les logiciels doivent être construits. Leurs rituels insignifiants et leurs réunions interminables tuent la créativité et étouffent le progrès, nous enlisant dans la bureaucratie.

« Alors que nous perdons du temps dans ces processus futiles, le paysage technologique évolue plus vite que ces soi-disant « experts agiles » ne peuvent organiser leur prochaine réunion inutile. L'intelligence artificielle se profile, prête à bouleverser l'industrie. Elle balayera non seulement les intermédiaires inutiles, mais aussi les ingénieurs unidimensionnels qui mettent en œuvre des tickets Jira sans se poser de questions. Dans un monde dominé par l'IA, seuls survivront ceux qui allient une compréhension technique approfondie à une vision fine de l'entreprise et du produit. Il est temps de repenser la façon dont nous collaborons et construisons des logiciels.

« La véritable collaboration ne peut être imposée par des cérémonies creuses ; elle naît d'une passion authentique et d'une mission partagée. Nous avons besoin d'ingénieurs farouchement dévoués, de personnes qui saisissent à la fois les complexités du codage et la vision globale du produit. Nous avons besoin d'équipes pointues et agiles qui pensent de manière indépendante et agissent sans hésitation. Il est temps d'éliminer les couches de bureaucratie inutile et de faire confiance aux vrais experts, ceux qui construisent réellement les produits.

« Il ne s'agit pas de ménager les susceptibilités ou de maintenir un statu quo brisé. Il s'agit de déclencher une révolution pour créer quelque chose qui fonctionne vraiment, quelque chose dont nous pouvons tous être fiers. Nous devons avoir le courage de tout remettre en question, de tirer les leçons de nos échecs et de tracer une nouvelle voie. L'avenir appartient à ceux qui ont l'audace de s'adapter et d'innover, et non à ceux qui s'accrochent désespérément à des processus dépassés comme à un radeau de sauvetage

« Ce manifeste est un cri de guerre pour tous ceux qui en ont assez des dysfonctionnements actuels. Il s'adresse à ceux qui croient que les ingénieurs qualifiés sont les véritables moteurs de l'innovation et les créateurs de produits significatifs. Nous devons nous libérer des chaînes des méthodologies obsolètes et adopter une approche plus dynamique, dirigée par les ingénieurs, du développement de logiciels. L'avenir même de notre industrie dépend de notre volonté de nous adapter, d'innover et de collaborer véritablement, et pas seulement d'accomplir les rituels vides des pratiques dites "agiles" ».

« Agile est un cancer », pour Erik Meijer, qui estime qu'il doit être banni une fois pour toutes

Erik Meijer, un développeur célèbre de l’écosystème .NET, qui s’est notamment fait remarquer par la création de LINQ et ses travaux sur le langage C#, Visual Basic, Volta et le framework Reactive Extensions (Rx), a fait des déclarations acerbes contre Agile, lors d’une conférence en Finlande : « Agile est un cancer que nous devons éliminer de l’industrie », a déclaré celui-ci.

Meijer critique surtout le fait que l’application de l’agilité dans des projets fait « beaucoup plus parler sur le code, que d’écrire le code ». Erik Meijer s’en prend particulièrement à la méthode Scrum, qui entraine des « interruptions inutiles ». Selon celui-ci, les « Scrum Meeting » sont des interruptions ennuyeuses, au mieux des mécanismes de contrôle subtil utilisés par les gestionnaires pour conduire une équipe, en donnant l’illusion d’un leadership partagé. « Nous devons cesser Scrum et Agile. Nous sommes des développeurs. Nous devons écrire du code », a affirmé Meijer.

Meijer continue sa diatribe en s’attaquant aux TDD. « C’est tellement ridicule. Pensez-vous que vous pouvez modéliser les échecs réels qui se produisent pendant la phase de production ? », s’est interrogé Meijer, avant de répondre. « Non. » Il préconise un cycle où le logiciel est déployé, et les erreurs fixées lorsqu’ils sont découverts.

Il faut noter que le créateur de Ruby On Rails, David Heinemeier Hansson, s’était aussi attaqué aux TDD, en affirmant que les tests unitaires n’étaient pas bénéfiques.

Au-delà de ces remarques, Meijer s’insurge également par rapport au fait que le terme « Agile » a été détourné et est désormais dénué de tout sens. Il a fini sa présentation en citant Dave Thomas, l’un des signataires du manifeste agile : « Le mot ‘Agile’ a été détourné au point ou il est devenu vide de sens. Et ce qui passe pour une communauté agile est devenu une arène pour les consultants et les entreprises qui veulent vendre leurs produits et services »

Capital One supprime tous les profils Agile de ses effectifs et plus de 1 100 personnes ont été touchées

Après de nombreuses années d'investissement dans les méthodes Agile pour amorcer « convenablement » sa transformation numérique, Capital One pense désormais à réorganiser ses équipes et se sépare des professionnels en méthodes Agile. Une personne au courant de l'affaire a déclaré à Bloomberg que plus de 1 100 employés ont été touchés par cette décision. Ces travailleurs ont été invités à postuler pour d'autres postes au sein de la banque, des centaines de postes étant ouverts dans toute l'entreprise. Selon des documents déposé par Capital One, la société comptait plus de 55 000 employés au troisième trimestre clos le 20 septembre 2022.

À la place, les ingénieurs et les chefs de produit devront utiliser naturellement les routines Agile. « Le rôle Agile dans notre organisation technique était essentiel pour nos premières phases de transformation, mais à mesure que notre organisation mûrissait, la prochaine étape naturelle était d'intégrer les processus de livraison Agile directement dans nos pratiques d'ingénierie de base », a déclaré Capital One. Depuis des années, l'entreprise investit dans la technologie du cloud qui, selon elle, lui permettra d'améliorer ses produits et son ratio d'efficacité, une mesure clef de la rentabilité qui indique combien il en coûte pour produire un dollar de revenu.

« Les décisions qui affectent nos associés, en en particulier celles qui impliquent des suppressions de rôles, sont incroyablement difficiles. Cette annonce n'est pas une réflexion sur ces personnes ou sur le travail qu'elles ont accompli au nom de notre organisation technologique. Leurs contributions ont été essentielles à la maturation de notre modèle de fourniture de logiciels et à notre transformation technologique globale », a déclaré la société dans le communiqué. Les suppressions de postes interviennent également à un moment où les entreprises technologiques et les entreprises financières réduisent leurs effectifs et ralentissent les embauches.

Source : Agile is dead

Et vous ?

Les valeurs du Manifeste Agile sont-elles toujours pertinentes dans les organisations modernes ? Selon vous, Agile est-elle dépassée ? Est-elle devenue un problème pour les équipes d'ingénierie ?

À votre avis, Agile contribue-t-elle à l'accumulation de la dette technique ? Pourquoi ?

Comment équilibrer la liberté d’action des équipes avec les contraintes stratégiques ou budgétaires des entreprises ?

L’agilité est-elle compatible avec des environnements où la hiérarchie reste très marquée ?

Quels sont les plus grands défis que vous avez rencontrés dans l’application des pratiques agiles dans votre organisation ?

L’agilité est-elle toujours adaptée dans des secteurs hors IT, comme la finance, l’industrie ou le marketing ?

Quelle alternative proposez-vous à Agile ? Pourquoi ?

Voir aussi :

« 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

[sevyc64]

« Agile est un cancer », pour Erik Meijer,

Entièrement d'accord avec ce monsieur.

[pyros]

Toute les personnes qui critiquent l'agile critiquent en fait l'implémentation "cargo culte" d'agile.

Ils se pleignent des cérémonie, des organigramme, de la pression de délivrer à chaque sprint, du ticketing a outrance, des outils et j'en passe. Mais je n'ai jamais vue personne se plaindre de devoir adresser la dette technique en continue, d'avoir des retours client régulier, d'être en capaciter de livrer rapidement, d'avoir une communication direct, etc...

Je rappel les principe de l'agilité:

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L’adaptation au changement plus que le suivi d’un plan

Toutes les critiques concernent les parties de droite, ce que l'agilité est justement censée éviter.

[jeromejerome]

Je suis dans une entreprise qui se dit agile et qui applique une méthodologie de travail en waterfall. Le daily scrum ne sert qu'à fliquer les salariés. Le PO fait du secrétariat. Pour critiquer agile il faut l'avoir compris. Le commentateur qui veut s'adonner à la passion du code, c'est gentil, moi aussi j'ai des passions, mais la réalité du projet c'est pas des scribouillards d'un côté et des codeurs de l'autre. La réalité s'est une équipe qui fait une pour réaliser un projet et le PO a besoin du dev. Agile le dit lui même plus d'interaction moins de processus et d'outils, les artefacts agile sont des outils dont on peut se passer le cas échéant. Même avec l'IA, l'agilité est possible tout dépend de l'attendu fixé.
Agile n'est pas mort mais les patrons et les managers le font grave souffrir.

[Eye_Py_Ros]

Critiquer l'agile devient un marronnier de l'actu informatique. Après plusieurs expériences, voici mon analyse :

Le plus gros problème d'Agile c'est ceux qui l'utilisent sans comprendre comment on conçoit du logiciel.

- Si vous concevez une base logicielle d'abord et que le reste des implémentations est modulaire, faire de l'agile c'est fun et cool. Vous pouvez faire de l'extrême dev, inclure l'utilisateur et le client dans la boucle et réussir a envoyer en prod de la fonctionnalité chaque semaine avec un taux de rôle back très faible (par ce que le client n'a pas documenté son environnement et que certaine fonctionnalité c'est au doigt mouillé ).

- Si vous ne savez pas concevoir de logiciel et que vous commencez par trier les post it et voter par lequel commencer, car vous êtes un bon manager super sympa, team building et compagnie. C'est l'échec assuré, a chaque sprint vous serez en train de réécrire intégralement la solution ou faire un creepi pasta pour avoir un semblant de fonctionnalité qui arrive a fonctionner ensemble avec une dette technique exponentielle et des stories qui consomme toujours plus de points les unes que les autres jusqu'au turn over des équipes par ce qu’une fonctionnalité simple devient un enfer à intégrer.
Et passer le reste du temps à expliquer au client pourquoi ça ne marche pas que ce n’est pas de votre faute, mais que c'est agile le coupable et chialer pour avoir des sous.

On ne commence pas le dev juste avec une liste de course utilisateur. On commence le dev par poser les bases d'une archi qui va permettre d'accueillir l'agile (après avoir pris connaissance des besoins métier en large et en travers sur le moment).
Voilà ce qui manque à + de 90% des projets agile par ce que le management n'a jamais dépassé le tuto du zero en termes de dev .
Ajouter un post it ne va pas faire spawn par magie une fonctionnalité dans un logiciel.

Le jour ou les gens ajouteront en 1re étape d'un projet Agile, poser le minimum viable, fondation, kernel appli (ou autre nommage qui plaira) avant de lancer la course....
les choses prendront une tournure différente.
Accuser une méthode par ce que l'on ne comprend rien / ne maîtrise pas ce que l'on fait .... soyons honnête, c'est plus un pb d'incompétence qu'autre chose.

Aucune méthode n'est magique, aucune par une incantation secrète ne permet d'invoquer le produit que l'on est censé concevoir.
Mais bon, les managers en carton a bon dos, les PO sorties d'école de commerce qui veulent expliquer la vie au dev .....

Une méthode ce n’est pas une recette de cuisine, c'est plus la logistique avec lequel on va exécuter la recette de cuisine.
La recette de cuisine est (presque) propre à chaque projet.
Agile, ce n’est pas une architecture projet, c'est une méthode de travail.
c'est peut être la chose la plus importante à dire

Tout comme le cola et l'Orangina on leur recette (secrète ), mais pourrait théoriquement être produit dans la même usine.

Ceux qui parle de je vais utiliser mvc pour mon projet, je vais faire mon projet en agile, je vais utiliser la dernière techno à la mode par ce que c'est sur demain tout fonctionnera uniquement avec ça c'est l'avenir (tout en étant "junior dans le dev").... n'ont jamais amener un projet à terme.






-----
Pour nous le combat, le plus dur, reste à faire comprendre dans les projets pourraves que ce n’est pas agile qui va faire disparaître la dette technique et les bugs comme par enchantement.
Encore moins lors de MCO sur un legacy à chier d'une solution qui aurait jamais du exister, car c'est une aberration et corriger chaque bug un par un est une quête sans aucun sens.
À moins que vous soyez un Mozart du code.

Pour les projets neufs, que les Dev commencent à prendre un peu d'audace et s'assure que leur 1er sprint soit de poser les bases du projet par l'ajout d'un sprint "app kernel" et ne pas passer 3h philosophique c'est quoi le meilleur post it que l'on va faire en 1er par ce qu'il faut présenter le ppt à 15h en plénière

[pyros]

Agile, ce n’est pas une architecture projet, c'est une méthode de travail.

Oui, mais cette méthode méthode de travail peut être utilisé pour concevoir une architecture.
Cf cette conf vachement intéressante qui balaye un peu le principe du "Il faut à tout prix faire des fondation solide avant de faire les features:

[DrHelmut]

C'est vrai que c'est devenu un marronnier de taper sur l'agilité, les méthodes agiles ou scrum en particulier, alors qu'au final le problème décrit n'est pas là.

Évidement que certaines organisations manageriales détournent le modele, ce n'est pas nouveau. Il y a bien des directeurs qui comparent la productivité de leurs équipes en regardant... Le nombre de story points réalisés chaque trimestre par équipe 😆
J'ai même connu des boîtes il y a plus de 10 ans ou les devs avaient leur prime indexés sur la réussite des sprint goal ET la completion de chaque sprint...

Bref, tout ça pour dire que taper sur la théorie alors que le problème vient des gens qui l'interprète mal voire la détourne, et de ce fait s'écartent totalement de l'agilité et de ses principes fondateurs, faut arrêter, c'est fatiguant et contre-productif.

[Jacti]

Le développement "agile" est la plus grande fumisterie de l'informatique.
C'est à la fois comique et triste de voir que des informaticiens puissent prendre cette approche au sérieux.
Je suis entièrement d'accord avec Erik Meijer qui dit que "Agile est un cancer que nous devons éliminer de l'industrie".
Je n'ai, pour ma part, jamais cru à cette pseudo-méthode qui n'est praticable que pour des "projets" de deux mois, au mieux. Je suis conscient d'être un peu radical mais c'est pour mieux "secouer le cocotier"
Soyons un peu sérieux et pratiquons des méthodes éprouvées :
https://swehb.nasa.gov/display/SWEHBVD
https://fr.wikipedia.org/wiki/ISO/CEI_12207

PS : Je suis conscient d'être un peu radical mais c'est pour mieux "secouer le cocotier"

[vivid]

C'est bizarre me je me méfie de tout ce qui est pompeux, je sais pas pourquoi
du bon sens.. ajuster le tir, c'est quand même intellectuellement plus gratifiant, que d'appliquer une recette a la lettre.

[pyros]

Le développement "agile" est la plus grande fumisterie de l'informatique.
C'est à la fois comique et triste de voir que des informaticiens puissent prendre cette approche au sérieux.
Je suis entièrement d'accord avec Erik Meijer qui dit que "Agile est un cancer que nous devons éliminer de l'industrie".
Je n'ai, pour ma part, jamais cru à cette pseudo-méthode qui n'est praticable que pour des "projets" de deux mois, au mieux. Je suis conscient d'être un peu radical mais c'est pour mieux "secouer le cocotier"
Soyons un peu sérieux et pratiquons des méthodes éprouvées :
https://swehb.nasa.gov/display/SWEHBVD
https://fr.wikipedia.org/wiki/ISO/CEI_12207

PS : Je suis conscient d'être un peu radical mais c'est pour mieux "secouer le cocotier"

Houuu, ça sent le vieu papi réac qui jure que par le cycle en V et la hiérarchie pyramidal

Blague à part, ce type de process marchent dans des industries lourdes et quand tu connais à l'avance tes contrainte. Mais sur des industrie plus légère où le cient change d'avis toutes les 2 semaines avec un marché très dynamique, tu peux pas passer 6 mois à écrire un cahier des charges.

Au passage, les booster d'ariane 6 ont été conçus en cycle agile, avec des cycle de 3 mois. Avant ils étaient sur des cycle de 5 ans, et passer en cycle court leur a permis de sortir de l'ronière où ils étaient embourbé depuis 10 ans.

Agile est un outils, au même titre que waterfall, cycle en V, etc... Quand tu as un clou, tu utilise un marteau. Quand tu as une vis, tu utilise un tourne-vis.

[gblaquiere]

Ça me fait penser a un président qui disait: la démocratie est le pire des régimes a l'exception de toutes les autres.

Et pour l'agilité ? C'est la pire des méthodes a l'exception de toutes les autres?

Sinon on fait quoi a la place?

[esperanto]

Les succès de l’agilité

• [...]
• Un focus sur l’utilisateur : En impliquant le client tout au long du processus, l’agilité garantit que les produits répondent réellement à leurs besoins.

C'est une blague?

Avant, j'avais un contact direct avec les utilisateurs. Ils m'appelaient, on parlait métier, ils me décrivaient leurs besoins et les idées qu'ils avaient, je réfléchissais sur le plan technique et je les rappelais pour définir ce qui était possible ou pas.
Aujourd'hui toute idée doit être soumise au business analyst qui va en parler au functional analyst qui va en parler au technical analyst qui va en parler à mon chef de projet qui va ouvrir un ticket JIRA avec une spec dans un document word où tous les intermédiaires ont bien pris soin de garder leurs track changes histoire que ce soit bien lisible.

• Une collaboration renforcée : Grâce à des pratiques comme les stand-ups quotidiens et les rétrospectives, l'agilité favorise une communication transparente et continue entre les membres des équipes.

Non, les stands up quotidiens, ça consiste à donner le numéro des tickets achevés et en cours (même si l'info se trouve déjà dans JIRA) pour tout autre chose il faut réclamer une réunion supplémentaire sinon on est accusé de faire déborder le stand up.
Ou alors, avant de me dire que je n'ai rien compris je voudrais que DrHelmut m'explique comment convaincre mon manager à l'origine de la méthode que c'est lui qui n'a rien compris...

Nous sommes noyés sous le poids de chefs de produit, de managers et de propriétaires qui n'ont jamais écrit une ligne de code et qui, pourtant, dictent d'une certaine manière la manière dont les logiciels doivent être construits.

Meijer critique surtout le fait que l’application de l’agilité dans des projets fait « beaucoup plus parler sur le code, que d’écrire le code ».

C'est bien cela. Non seulement je n'ai plus accès aux utilisateurs dont pourtant le métier m'intéressait (même si je restais pour ma part sur la partie technique) mais en plus je dois me coltiner un manager qui est encore moins intéressé par le métier des utilisateurs, et qui veut juste connaître le nombre de story points affectés à chaque ticket.
C'est pourtant ce gars-là qui va décider du nombre et de la nature des couches de l'application, et de tous les outils "nécessaires" (dont les tests unitaires cités par ailleurs). Au final parfois il m'arrive de mettre une heure à corriger un bug et trois à remplir toutes les applications de gestion (qui bien que provenant du même éditeur vont mal communiquer entre elles) parce que je dois mettre la même information à trois endroits et dans trois formats différents. Ce qui ne dispense évidemment pas de répéter une quatrième fois pendant le stand up qui est supposé intéresser tout le monde.

Encore une étape et j'apprendrai que soi disant je ne fous rien de la journée (ou alors j'aurais presque envie d'installer ce truc pour leur montrer l'étendue du désastre de la méthodologie...)

[KlmIsgonnaRockYou99]

Piloter en Agile demande Ã* mon sens dÂ’avoir une expérience solide en développement mais pas seulement. Beaucoup de soft skills en jeu pour que la recette aboutisse.
Une méthode s’impose peu importe laquelle. C’est comme une architecture projet, elle s’adapte au produit. Pas l’inverse. Et les options sont légions.
Confondre management et méthodes est hélas apparemment très courant. Et les PO en papier qui se transforment en secrétaires comme j’ai pu le lire, sont certainement ceux qui faute d’xp se replient sur leur fonction plutôt que remplir leur rôle de facilitateur et de vulgarisateur entre toutes les parties prenantes du produit.
Peut être que c’est obsolète, peut être que c’est generationel ou culturel. Mais comme le bon sens commun n’existe pas et que les ressorts de la communication entre humains (oui les devs sont aussi humains) restent excessivement complexes, on a pas trouvé mieux pour le moment.
Mes 2 centimes.