IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

  1. #21
    Membre extrêmement actif
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juillet 2010
    Messages
    403
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Juillet 2010
    Messages : 403
    Points : 1 419
    Points
    1 419
    Par défaut
    Le problème c'est la panique.

    Quand tout le monde est d'accord en début de projet, on va appliquer une méthode agile (Scrum, X our Y), tout est beau, chacun applique cela comme il faut.

    Puis dès que les problèmes se pointent, ce qui fait l'intérêt de l'agilité disparaît. On reprend les mauvaises habitudes, on promet au client une deadline à l'ancienne, on bourre les sprints, on multiplie les points quotidiens, on ne respecte plus l'organisation en place, bref c'est la merde.

  2. #22
    Membre expert
    Avatar de Alexandre T
    Homme Profil pro
    Chef de projets AMO
    Inscrit en
    Mai 2002
    Messages
    1 213
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projets AMO
    Secteur : Transports

    Informations forums :
    Inscription : Mai 2002
    Messages : 1 213
    Points : 3 001
    Points
    3 001
    Par défaut
    Plutôt que de jouer à Jean-Pierre Coffe et de crier : "c'est de la m#$§e;", je m'intéresserai aux 15% de projets qui réussissent pour comprendre ce qu'ils ont en commun et essayer d'en tirer des conclusions intéressantes.

  3. #23
    Membre extrêmement actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    Mai 2015
    Messages
    429
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2015
    Messages : 429
    Points : 1 630
    Points
    1 630
    Par défaut
    Quel est votre avis sur le sujet ?

    Que la "méthode SCRUM" n'est que ça, une méthode parmi tans d'autres et que ce n'est surement pas la "faute" à une méthode si un projet échoue, mais uniquement à ceux qui ont choisie de l'utilisé sur un projet sur laquelle elle n'était pas adapté.
    Les principes même de l' "Agilité" consiste avant même le choix de la méthode de dev, à bien choisir nos outils en fonction du contexte.
    Inutile de vouloir imposé une méthode à tous les projets, je peut vous garantir que ça ne fonctionnera pas.

    Êtes-vous ou pas du même avis que Gene Bond ? Que pensez-vous de ses arguments ?

    Plutôt oui et je pense que le monsieur à bien comprit que le problème ne venait pas de la méthode, mais de ça mise en oeuvre à géométrie variable avec des besoins maladif de copie de l'existant (au niveau des projets).
    Chaque projet existe dans un contexte unique, partant de là il fait très bien le constat que le cœur de l' "Agilité" réside dans l'adaptation et pas dans le copier collée systématiques.
    Malheureusement c'est bien le copier coller qui à cours dans la plupart des projets, après tous si une méthode a bien fonctionné précédemment, pourquoi ne fonctionnerait elle plus ? (Réponse : Le contexte)

    Quelle méthode Agile utilisez-vous et quelles sont les difficultés que vous rencontrez souvent ?

    Aucune, personnellement, je pense que l' "Agilité" rime avec adaptabilité en conséquence de quoi, je m'adapte au projet ce qui revient à ne pas avoir de méthode puisque non reproductible pour un autre cas.
    Après, il ne faut pas confondre méthode et bonne pratique.
    Ce n'est pas parce qu'on utilise pas de "méthode Agile" documenté que l'on ne vas pas mettre en place test, CI et CD dans sont projet.

  4. #24
    Membre éclairé

    Homme Profil pro
    Ouvrier de l'informatique [ et quelquefois ingénieur logiciel ]
    Inscrit en
    Mars 2013
    Messages
    180
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Lot et Garonne (Aquitaine)

    Informations professionnelles :
    Activité : Ouvrier de l'informatique [ et quelquefois ingénieur logiciel ]
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2013
    Messages : 180
    Points : 755
    Points
    755
    Par défaut
    Citation Envoyé par palnap Voir le message
    85% de foirade? Je sais pas d'où il tire ces chiffres mais à vite de pif ça correspond à la proportion de structures qui ne comprennent pas Scrum et/ou qui l'implémentent mal ou partiellement. Organiser des dailies et livrer toutes les 3 semaines ne suffit pas a augmenter l'efficacité d'une équipe, il faut souvent revoir l'organisation (de la structure j'entends, pas uniquement de l'équipe de dev) ce que les entreprises sont rarement pretes a faire (trop de gens ont trop a perdre). Une fois les conditions nécessaires a la mise en place de Scrum (ou de toute autre méthode agile) réunies, il n'y a aucune raison que ça foire...
    merci je suis plutot d'accord avec ça ! les cllients ont ete bien satisfaits du boulot fourni par les equipes scrum au sein desquelles j'ai bossé les 4 dernieres annees, pourtant chaque fois des défis

    l'article "La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas", que je trouve provocateur, m'invite a chercher des reponses à des interrogations comme : seulement 15% de chefs de projets scrum masters et PO competents ? seulement 15% d'entreprises dont la culture et les pratiques permettent d'accueillir et utiliser à profit les atouts de l'agilité ? seulement 15% de clients ont des attentes réalistes au regard du prix payé ? etc.


  5. #25
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    Avril 2014
    Messages
    2 324
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 009
    Points
    2 009
    Billets dans le blog
    1
    Par défaut
    J'estime à 83,48% les chances de se planter de plein fouet dans les biais cognitif quand on fait des analyses qui ne se basent sur aucune données objectives et vérifiables.

  6. #26
    Membre actif
    Homme Profil pro
    Consultant
    Inscrit en
    Novembre 2013
    Messages
    34
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Novembre 2013
    Messages : 34
    Points : 278
    Points
    278
    Par défaut
    Pour ma part, j'ai toujours considéré Scrum comme une escroquerie intellectuelle.

    Si me souvenirs sont bons, une des premiers pré-requis qui est annoncé pour un projet organisé en scrum, c'est une équipe autonome et compétente.
    Hé bien je vais vous dévoiler un secret : réussir un projet avec une bonne équipe n'est pas une gageure incroyable (toutes choses étant égales par ailleurs, on est bien d'accord que si on vous demande d'envoyer une fusée sur la lune en 3 mois, et qu'au bout que 2 mois on vous dis, non finalement on veut explorer les fonds sous marins, une équipe de cador ne vous sauvera pas).
    Mais sur beaucoup de projet vous avez surtout des développeurs juniors, conséquence logique du manque de reconnaissance du métier de développeur en France, de la pression sur les prix exercée par les clients, et de la malhonnêteté de nombreuses ssii. Et quand vous laissez des personnes inexpérimentées en roue libre qui s'auto-organisent, le risque de plantage magistral n'est pas loin.


    Nul besoin de tout ce fatras pour mettre en oeuvre les bonnes pratiques :
    - cycle itératifs courts pour éviter l'effet tunnel
    - proximité du client avec les équipes de dev. pour des ajustements rapides en amont ou en aval du dev.
    - implication du client dans les phases de conception / recette
    - promouvoir la communication et le travail collaboratif


    On n'a pas attendu scrum, ni même le manifeste agile, pour comprendre et appliquer ça.
    Il y a 30 ans on faisait déjà du RAD, avec d'excellents résultats par ailleurs. J'ai géré au moins une dizaine de projets de taille importante (disons au moins 1000 j/h), avec des cycles itératifs courts, y compris au forfait, et on a (presque) toujours délivré dans les délais, le respect du planning et budget, à la satisfaction du client, et en ayant fait progresser les juniors au sein d'équipe mixtes. Sans faire d'agile au sens strict du terme.

    De ce que j'en vois depuis quelques années, ça occasionne surtout pas mal de dégâts et ça permet à toutes sortes de théoriciens fumeux de facturer à prix d'or des prestations inutiles voire contre-productives. En fait quand l'agile ne fonctionne pas, on fait appel à des gens dont le métier est justement de vendre de l'agilité : ils ne vont certes pas vous dire que la méthode retenue n'est pas adaptée à votre organisation ou à votre contexte projet. Non. Ils vont vous expliquer que vous faîtes mal, pas assez, qu'il faut faire évoluer l'organisation etc. Mais jamais il ne concluront que la méthode agile que vous appliquez sur votre projet n'est pas adaptée (à la maturité de votre équipe, à la culture de l'entreprise ...). En fait c'est le principe même de l'escroquerie, comme vous avez claqué plein de fric en consulting de coach agile et autres scrum master, vous voulez un retour sur investissement et vous remettez au pot, encore et encore : encore un petit effort et ça va fonctionner... jusqu'au moment où vous retrouvez vos esprits, virez tous les consultants inutiles, renforcez l'équipe par des personnels expérimenté et revoyez votre processus projet.

    L'esprit même de l'agile a été perverti par les SSII qui surfant sur l'effet de mode en collent partout, quel que soit la nature du projet et de l'entreprise, et facturent à prix d'or des glandus qui n'ont jamais piloté un projet, subitement transformés en experts de la gestion de projet après une formation de 3 jours aboutissant à une magnifique certification scrum master. Mais les SSII ne sont pas seules en cause, il y a probablement un problème culturel bien français, avec la séparation traditionnelle entre maitrise d'ouvrage (le seigneur du chateau qui manifeste son désir) et maîtrise d'oeuvre (les gueux et artisans qualifiés qui se démènent pour satisfaire le seigneur), qui perdure avec des notions bizarres comme les proxy-product-owner et autres variations.

    Pour finir sur une note positive, il ne faut pas jeter le bébé avec l'eau du bain. Scrum fonctionne bien sur certaines typologie de projet. Et j'ai connaissance dans mon entourage de projets ambitieux réussis en contexte Scrum (mais malheureusement de bien plus d'échec sanglants, m'enfin l'échec des projets n'est pas exceptionnel dans ce métier, avec ou sans scrum).

    Mais vouloir faire rentrer du scrum au chausse pied dans une organisation qui ne s'y prête pas, des représentants du métier qui ne jouent pas le jeu, dans un projet piloté par les coûts (ie : un forfait), avec une équipe de dev inexpérimentée sans encadrement technique adapté, c'est aller au casse pipe.

  7. #27
    Membre éclairé

    Homme Profil pro
    Ouvrier de l'informatique [ et quelquefois ingénieur logiciel ]
    Inscrit en
    Mars 2013
    Messages
    180
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Lot et Garonne (Aquitaine)

    Informations professionnelles :
    Activité : Ouvrier de l'informatique [ et quelquefois ingénieur logiciel ]
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2013
    Messages : 180
    Points : 755
    Points
    755
    Par défaut
    Citation Envoyé par damthemad Voir le message
    Mais vouloir faire rentrer du scrum au chausse pied dans une organisation qui ne s'y prête pas, des représentants du métier qui ne jouent pas le jeu, dans un projet piloté par les coûts (ie : un forfait), avec une équipe de dev inexpérimentée sans encadrement technique adapté, c'est aller au casse pipe.


    bonjour damthemad, je suis quasi entierement d'accord avec ton analyse et en particulier ta conclusion que je trouve pertinente (je n'ai que 20 ans de métier mais ça matche bien avec mon expérience)

    du coup j'adhere integralement a ton post hormis une seule chose que je ne comprends pas : ta premiere phrase (tu dis "Pour ma part, j'ai toujours considéré Scrum comme une escroquerie intellectuelle.")

    Scrum n'est pas un escroc, c'est juste un outil. L'agilité c'est pareil, c'est un ensemble de valeurs. Mieux : les valeurs auxquelles tu déclares être attaché (et moi aussi) appartiennent à celles que l'Agilité défend.
    Donc pour moi je crois qu'il est utile de bien faire la distinction entre l'Agilité et Scrum d'un coté, des "outils" qu'on peut utiliser si besoin, et d'un autre coté les personnes malhonnêtes ou simplement incompétentes à leurs postes (les escrocs des SSII ou les mauvais clients qui ne veulent pas comprendre les nécessités du métier, etc.) qui utilisent ou détournent les concepts à des fins peu reluisantes...

  8. #28
    Candidat au Club
    Homme Profil pro
    Directeur de projet
    Inscrit en
    Juillet 2020
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : Juillet 2020
    Messages : 1
    Points : 3
    Points
    3
    Par défaut
    Ya une grosse erreur dans tout ça... c'est que Scrum n'est pas une méthode.
    Si c'est pris comme une méthode, c'est évident que ça sera un échec dans la majorité des cas.
    Scrum est un framework / un cadre de travail, la différence est de taille par rapport à une méthode.
    Une méthode est une approche systématique pour atteindre un résultat ou un objectif spécifique. On est sur une approche scientifique, alors qu’en agilité et en Scrum on est sur approche empirique.

    Et justement vu que ce n'est pas une méthode, mais un cadre de travail, c'est universel.
    Il y a un cadre à respecter, après l'entreprise, l'organisation s'adapte dans ce cadre.

    Qu'est ce qui ne fonctionne pas ? Sur quelle base est basée cette affirmation ?

    La démarche Scrum, permet de délivrer plus de valeurs aux usagers finaux, plus rapidement. Ca n'assure pas de délivrer à moindre coût, ou un périmètre plus exhaustif etc ...
    J'ai vu de nombreux projets déclarer être une réussite, alors que le produit délivré était peu utilisé par les usagers, ou ne leur apportait pas satisfaction.
    Donc qu'est ce qui définit la réussite d'un développement de produit numérique pour vous?

  9. #29
    Membre averti

    Profil pro
    Inscrit en
    Mai 2002
    Messages
    640
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 640
    Points : 408
    Points
    408
    Par défaut
    Quelques constats et réflexions, pour compléter ce qui a été dit :

    Selon moi, une méthode agile comme Scrum n’a pas pour objectif d’améliorer la productivité d’une équipe. Le principal intérêt est de fournir un outil d’organisation, de pilotage et de priorisation qui permet d’éviter l’effet tunnel et donc les dérapages et les mauvaises surprises dans les dernières phases du projet. Elle ne constitue pas une méthode miracle pour réussir les projets.

    Scrum (ou une autre méthode agile) ne permet pas réduire les coûts d’un projet, au contraire. Le travail en itérations courtes avec des objectifs de court terme crée de la dette technique, ce qui on peut nécessiter un refactoring de plus en plus important qui s’ajoute à la charge du projet.

    Scrum ne permet pas d’être plus rapide. Avec le système d’itérations courtes (sprints), on a des livraisons plus fréquentes, ce qui permet de prendre en compte les retours et changements d’avis. Mais ce fonctionnement allonge les délais au lieu de les réduire.

    Bien souvent un projet est fortement contraint au niveau des dates, avec des délais difficilement tenables. Du coup, les sprint sont « optimisés » de manière irréaliste dès le début pour tenir une date de livraison finale. Il n’y a pas de place pour la prise en compte des retours du métier, les changements d’avis, le refactoring, les optimisations… On perd donc l’intérêt de l’agile. De plus si on travaille avec une documentation inexistante ou très réduite, on multiple les incompréhensions, les interprétations erronées, et le livrable a toutes les chances de ne pas correspondre au besoin, d’où insatisfaction du métier, décalage et surcoûts.

    Ensuite l’agile ne fonctionne que si tous les intervenants du projet (chef de projet, interlocuteur métier, fonctionnels/MOA/business analyst, développeurs, personnes en charge de l’infrastructure, du déploiement et de l’Exploitation…) travaillent réellement ensemble, idéalement dans un même bureau, pour faciliter les échanges. C'est rarement le cas.

    Il y a une idée fausse (qui ne fait d'ailleurs pas partie des 12 principes du manifeste agile) mais très répandue: dans un projet en mode agile il n’y a pas de spécifications précises. Celles-ci seraient remplacées par les récits utilisateurs (user stories). Or la user story n’est nullement un moyen de spécifier au développeur la fonctionnalité attendue. C’est avant tout un outil d’organisation et de gestion du projet*: le backlog produit est un outil de priorisation des fonctionnalités attendues. Si on travaille sans spécifications et sans documentation précise, on va perdre du temps en multipliant les échanges, et aboutir à des incompréhensions et des erreurs de conception, surtout si on travaille avec un prestataire.

    L'agile repose sur la capacité à définir les fonctionnalités du produit sous forme de récits utilisateurs précis, indépendants, cohérents, inter-changeables et de petite taille (correspondant à un développement pouvant être réalisé au cours d’un sprint). Or cela n’a rien d’évident.

    Les méthodes agiles fonctionnent très mal dans une organisation rigide (hiérarchique). Pour pouvoir fonctionner, elles doivent s'appuyer sur une organisation coopérative.

    Autre problème : le travail en agile avec un prestataire. Généralement la contractualisation n’est pas agile. Le prestatatire vend une organisation agile (projet est organisé en sprints, daily meeting, scrum master…) mais attend des spécifications détaillées pour démarrer les développements et refuse de prendre en compte les modifications.

    Enfin l’agile est lié à l’idée d’apprentissage et d’amélioration continue. Ce sont des aspects qui sont généralement oubliés dans les projets. En cas d’échec on est plutôt dans la recherche des coupables.

  10. #30
    Expert éminent sénior
    Avatar de Escapetiger
    Homme Profil pro
    Administrateur système Unix - Linux
    Inscrit en
    Juillet 2012
    Messages
    1 494
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Administrateur système Unix - Linux

    Informations forums :
    Inscription : Juillet 2012
    Messages : 1 494
    Points : 11 189
    Points
    11 189
    Par défaut
    Bonjour,

    Un billet de blog éloquent par rapport au thème du forum La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, selon Gene Bond, posté initialement et récemment par Derek Corgan ici dans la rubrique Emploi ci-après :
    Développeur, en entreprise, vous aussi vous êtes au bout du rouleau ?

    «
    Avant-propos
    Le texte qui suit est la version française d’un billet de blog à thèse publié en 2015 par le programmeur américain Michael O’Church.
    Je l’ai contacté pour le traduire et faire connaître ses arguments en France, où les méthodes Agile, et plus particulièrement Scrum, n’ont de cesse d’envahir les entreprises privées.

    L’agilité est sans nul doute une bonne chose, et l’Agile Manifesto n’est pas forcément déraisonnable. Si on la compare à l’imposture logique qu’est Waterfall, la méthode Agile s’avère notablement supérieure. Pourtant, Agile telle qu’elle est pratiquée dans les faits et dans la majorité des cas est profondément nocive ; et dans un premier temps, il ne me semble pas qu’une dichotomie Agile/Waterfall ait jamais été nécessaire à quelque projet que ce soit.

    Il existe une variante d’Agile, nommée Scrum, que j’ai vu détruire des entreprises, littéralement. Par « détruire », je ne veux pas dire «par la suite, la culture n’était plus si bonne que ça» ; je veux dire que l’action s’est effondrée de près de 90%, en moins de deux ans.
    »
    • Qu’est-ce qu’Agile ?
    • Transparence ultra-violente
    • Problèmes spécifiques à “Agile” et Scrum
      1. L’ingénierie business-driven (ou dirigée par les affaires)
      2. Juniorité terminale
      3. C’est bêtement, dramatiquement “court terme”
      4. Agile n’a aucun respect pour la cohérence professionnelle
      5. Le but est d’identifier les mauvais éléments, mais le taux de faux positifs est bien trop élevé
      6. Un changement de perception malheureux
      7. C’est vendu de façon malhonnête
    • Ce pourquoi Scrum fonctionne
    • Deux problèmes
    • Perspectives d’avenir
    Source: Pourquoi Agile et Scrum sont catastrophiques | by binnie | Medium

    [Edit au 7 mai 2021]
    Grâce à vous tous, je m'aperçois que nos chroniqueur.e.s ont passé entre-temps le sujet en une sur https://www.developpez.com/
    Développeur en entreprise, vous aussi vous êtes au bout du rouleau ? méthodes agiles mal appliquées ? management irresponsable ? Scrum une vaste blague ? Développeur en entreprise pour beaucoup serait très loin d'être un long fleuve tranquille, au point que certains ne recommandent pas cette profession. Projets mal définis qui finissent en usines à gaz, organisation déficiente, managers incompétents qui ne font que brasser du vent, réunions interminables et inutiles, méthodes mal appliquées, voire contre-productives, quelles sont les horreurs que doivent subir au quotidien les développeurs ?
    43 commentaires

  11. #31
    Expert éminent sénior
    Avatar de Escapetiger
    Homme Profil pro
    Administrateur système Unix - Linux
    Inscrit en
    Juillet 2012
    Messages
    1 494
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Administrateur système Unix - Linux

    Informations forums :
    Inscription : Juillet 2012
    Messages : 1 494
    Points : 11 189
    Points
    11 189
    Par défaut
    L'actualité va à la vitesse d'un cheval au galop, vous pouvez (re)trouvez cette information qui nous concerne tous et la commenter en cliquant sur «nnn commentaires», en une grâce à nos rédacteurs - rédactrices (désolé je me perds parfois avec l'écriture inclusive) sur les liens spécialisés ci-après (à la date du post):

    Développeur en entreprise, vous aussi vous êtes au bout du rouleau ? méthodes agiles mal appliquées ? management irresponsable ? Scrum une vaste blague ? Développeur en entreprise pour beaucoup serait très loin d'être un long fleuve tranquille, au point que certains ne recommandent pas cette profession. Projets mal définis qui finissent en usines à gaz, organisation déficiente, managers incompétents qui ne font que brasser du vent, réunions interminables et inutiles, méthodes mal appliquées voir contre productives, quelles sont les horreurs que doivent subir au quotidien les développeurs ?
    100 commentaires
    https://solutions-entreprise.developpez.com/
    https://emploi.developpez.com/

    In fine
    Accueil => Forum => Emploi et Etudes en Informatique => Emploi
    [Actualité] Développeur, en entreprise, vous aussi vous êtes au bout du rouleau ?

  12. #32
    Membre habitué
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    82
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : Octobre 2006
    Messages : 82
    Points : 178
    Points
    178
    Par défaut Pipotage
    La méthode Scrum, comme beaucoup de méthodes dites "agiles" n'est que du pipotage et du marketing pour les béotiens qui ont besoin d'être strictement encadrés sinon ils ne font que des bêtises.
    Il faut lire ou relire les standards de développement de l'ISO/IEC/IEEE : https://www.nbn.be/shop/fr/norme/nbn...207-2021_1833/

  13. #33
    Communiqués de presse

    Femme Profil pro
    Traductrice Technique
    Inscrit en
    Juin 2023
    Messages
    1 224
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France

    Informations professionnelles :
    Activité : Traductrice Technique

    Informations forums :
    Inscription : Juin 2023
    Messages : 1 224
    Points : 85 590
    Points
    85 590
    Par défaut La méthode agile Scrum serait un cancer, selon un enseignant en intelligence artificielle
    La méthode agile Scrum serait un cancer, selon un enseignant en intelligence artificielle.

    Scrum est un cancer. Santiago, un enseignant en intelligence artificielle, écrit des logiciels depuis 25 ans, et selon lui, rien ne rend une équipe logicielle inutile comme le fait Scrum. Voici ce qu'il rapporte :

    Quelques anecdotes :

    1. Ils ont essayé de me convaincre que le poker est un outil de planification, pas un jeu ;
    2. Si vous voulez être plus efficace, vous devez ajouter des processus, et non les supprimer. Ils nous ont fait assister aux "cérémonies", un nom fantaisiste pour un tas de réunions : stand-ups, groomings, planification, rétrospectives, et Scrum de Scrums. Nous avons passé plus de temps à parler qu'à agir ;
    3. Les ordinateurs portables sont interdits en réunion. Nous devions rester debout. Nous faisions circuler un ballon pour que tout le monde reste attentif ;
    4. Nous avons passé plus de temps à estimer les story points qu'à écrire des logiciels. Les story points mesurent la complexité, pas le temps, mais nous devions décider combien de story points correspondaient à un sprint ;
    5. J'ai dû utiliser la taille des t-shirts pour estimer les logiciels ;
    6. Nous avons mesuré le coût de livraison d'un story point, puis nous avons rédigé des contrats dans lesquels les clients payaient pour un lot de "500 story points" ;
    7. La direction a perdu la tête lorsqu'elle a découvert que les 500 story points d'un projet n'étaient pas les mêmes que les 500 story points d'un autre projet. Nous avons tenu de nombreuses réunions pour régler ce problème ;
    8. Imaginez que vous ayez un manager, un scrum master, un product owner et un tech lead. Vous deviez répondre à chacun d'entre eux et à aucun simultanément ;
    9. Nous avons payé des personnes qui nous ont dit si nous "brûlions des points" assez rapidement. Les story points n'étaient-ils pas une question de complexité plutôt que de temps ? Peu importe.


    Nom : 1.png
Affichages : 205940
Taille : 12,9 Ko

    Je crois en la méthode Agile, mais ce n'est pas le cas.

    Nous avons fait appel à des formateurs Scrum professionnels. Nous avons payé des membres de notre équipe pour qu'ils soient certifiés. Nous avons essayé Scrum de cette façon et de cette autre façon. Nous avons passé des années à le faire.

    Le résultat était toujours le même : cela ne fonctionnait pas.

    Scrum est un cancer qui va dévorer votre équipe de développement. Scrum n'est pas fait pour les développeurs. C'est un outil de plus pour que les managers aient l'impression de contrôler la situation.

    Mais les meilleurs de Scrum sont ceux qui vous regardent dans les yeux et vous disent : "Si cela ne fonctionne pas pour vous, c'est que vous vous y prenez mal. Scrum, c'est tout ce qui fonctionne pour votre équipe."

    Bien sûr que c'est le cas.


    Source : Santiago

    Et vous ?

    Trouvez-vous le témoignage de Santiago crédible ou pertinent ?
    Pensez-vous que le témoignage de Santiago reflète de mauvaises utilisations de Scrum ou que Scrum est bien un "Cancer" en tant que tel.
    Quel est votre avis sur Scrum ?

    Voir aussi :

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

    La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas, selon Gene Bond, directeur exécutif chez iiSM.ORG

    La méthode agile SCRUM est-elle une mauvaise méthode de gestion de projet ? Oui, répond un professionnel du secteur

  14. #34
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 482
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 482
    Points : 6 149
    Points
    6 149
    Par défaut
    Citation Envoyé par Santiago
    1. They tried to convince me that Poker is a planning tool, not a game.
    Le Guide Scrum ne mentionne pas le planning poker.

    Citation Envoyé par Santiago
    2. If you want to be more efficient, you must add process, not remove it. They had us attending the "ceremonies," a fancy name for a buttload of meetings: stand-ups, groomings, planning, retrospectives, and Scrum of Scrums. We spent more time talking than doing.
    Il y a pas mal de réunions de la fin d'un sprint au début du suivant. Le reste du temps, il y a une réunion de 15 minutes par jour.

    Citation Envoyé par Santiago
    3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
    Le Guide Scrum ne dit pas que la réunion soit se faire debout. Beaucoup de personnes appellent stand-up meeting le Daily Scrum, mais cela ne vient pas du Guide Scrum. Le ballon non plus.

    Citation Envoyé par Santiago
    4. We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.
    Le Guide Scrum ne dit pas d'utiliser des story points. Mais, en effet, le guide Scrum incite à faire pas mal de planification lors du Sprint planning, ce qui peut être du temps perdu. Extrait du Guide Scrum :
    « For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. »

    Citation Envoyé par Santiago
    5. I had to use t-shirt sizes to estimate software.
    Le Guide Scrum utilise les mots size et sizing pour les estimations, mais ne dit pas si les estimations sont en heures, en jours, en tailles de T-shirt, etc.

    Citation Envoyé par Santiago
    6. We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points."
    LOL.

    Citation Envoyé par Santiago
    7. Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.
    Des gens qui n'ont pas de compétences en gestion de projet de développement de logiciels se retrouvent à des postes de gestion de projet de développement de logiciels. Ce n'est pas nouveau. Mais, là, aucune méthode ne peut marcher.

    Citation Envoyé par Santiago
    8. Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously.
    En Scrum, dans une Scrum Team, il n'y a pas de hiérarchie, donc pas de tech lead. Extrait du Guide Scrum :
    « Within a Scrum Team, there are no sub-teams or hierarchies. »

    Citation Envoyé par Santiago
    9. We paid people who told us whether we were "burning down points" fast enough. Weren't story points about complexity instead of time? Never mind.
    Le Guide Scrum ne dit pas d'utiliser des story points.

    Citation Envoyé par Santiago
    But the best about Scrum are those who look you in the eye and tell you: "If it doesn't work for you, you are doing it wrong. Scrum is anything that works for your team."
    Vouloir mettre du Scrum partout serait une hérésie. Mais, de toute façon, personne ne fait du Scrum, même si beaucoup de gestionnaires prétendent en faire.

  15. #35
    Membre expert
    Homme Profil pro
    ingénieur qualité
    Inscrit en
    Mars 2015
    Messages
    1 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : ingénieur qualité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mars 2015
    Messages : 1 226
    Points : 3 729
    Points
    3 729
    Par défaut
    Rappel préliminaire : je ne suis pas développeur et ne travaille pas dans une entreprise ou le développement logiciel est le coeur de métier.

    Ca fait 6 mois/1 an qu'on me vend pas mal la "méthode agile", ce qui me laissais quelque peu dubitatif parce qu'on nous l'avais présentée peu de temps après le covid et le présentateur se présentait plus comme un gourou qui veut tout agiliser sans écouter nos demandes et notre contexte. Mais il s'avère que certaines équipes opérationnelles s'y sont mis et que ça semble bien fonctionner.
    Ce que je trouve rassurrant chez nous est que les équipes qui encadrent les lancements de projets agiles préfèrent faire peu de projet concluants que beaucoup de projet avec une "couche de peinture" agile. Certains projets agiles ont été lancés et la méthode a été abandonnée parce que inefficace (je ne sais pas pourquoi). Bref tout ça me rend oprimiste sur l'arrivée de l'agile chez nous.

    Il n'en reste pas moins que ça semble très dépendant des encadrants et/ou des formateurs. Parce que ça semble bien prendre mais la première présentation qu'on avait eu avait convaincu tout le monde de fuir la méthode comme la peste.

  16. #36
    Membre chevronné
    Homme Profil pro
    CTO
    Inscrit en
    Avril 2006
    Messages
    360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : CTO
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2006
    Messages : 360
    Points : 1 866
    Points
    1 866
    Par défaut
    Pour ma part, j'essaie d'adapter la méthode en fonction du contexte (entreprise, collaborateurs, nature du projet). Actuellement dans mon entreprise on va faire en fonction de la situation.
    Par exemple, Dans le cas d'une période où l'essentiel des tickets va être des bugs isolés, on va travailler en Kanban. Pas de planification, juste une priorisation des tickets faite par les PO et les devs piochent dedans. Daily meetings classiques et on livre régulièrement des releases. Ça s'arrête là

    Dans un cas où il y a plutôt des nouveaux développements, on fonctionne sur un sprint backlog préparé à l'avance par les PM et PO avec une priorisation au sein de celui-ci. Lors du premier jour du sprint, on va faire une estimation (en temps) et déjà une affectation à un développeur qui aura une capacité en temps déterminé (en fonction de son contrat, de ses congés sur la periode et de ses potentielles autres activités, typiquement un dev au 35h sans rien de particulier, ça va être 4h30 ou 5h par jour environ).
    Quand plus aucun développeur n'a de capacité, le sprint est considéré comme rempli et toutes les autres tâches non affectées sont reléguées dans le backlog.

    Chaque jour, on fait le daily meeting assez classiquement, ce qui permet de réajuster, de communiquer sur les difficultés ou au contraire d'aider les autres si l'un est plus en peine et à la fin du sprint, démonstration faite par un membre de l'équipe à l'équipe (devs, testeurs, po, PM, direction et toutes personnes intéressées) et échange rétrospectif après. Je trouve que dans mon contexte, cette méthode (pas forcément scrum) fonctionne assez bien.

  17. #37
    Membre éprouvé
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    Juin 2022
    Messages
    274
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Analyste d'exploitation

    Informations forums :
    Inscription : Juin 2022
    Messages : 274
    Points : 945
    Points
    945
    Par défaut
    J'ai pas de mal avec les méthodes mais j'ai beaucoup de mal avec les gens qui cherchent à les refourguer comme des charlatans revendent leurs remèdes anti-calvitie.

    Chaque problème son approche, et qu'on ne me fasse surtout pas croire cet immonde mensonge comme quoi la hiérarchie est mise de côté pour le Scrum. Sur le papier, peut-être. Concrètement, ca n'a jamais été le cas pour moi.

  18. #38
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 734
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 734
    Points : 18 753
    Points
    18 753
    Par défaut
    Citation Envoyé par Jade Emy Voir le message
    un tas de réunions : stand-ups, groomings, planification, rétrospectives, et Scrum de Scrums.
    C'est vrai que ça fait beaucoup de types de réunions différentes.

    Citation Envoyé par Jade Emy Voir le message
    Imaginez que vous ayez un manager, un scrum master, un product owner et un tech lead.
    C'est vrai que ça fait beaucoup de rôles.

    Citation Envoyé par totozor Voir le message
    Ca fait 6 mois/1 an qu'on me vend pas mal la "méthode agile"
    L'agilité c'est hyper important, rien que pour un truc :
    Méthode agile
    En ingénierie logicielle, les pratiques agiles mettent en avant la collaboration entre des équipes auto-organisées et pluridisciplinaires et leurs clients. Elles s'appuient sur l'utilisation d'un cadre méthodologique léger mais suffisant centré sur l'humain et la communication. Elles préconisent une planification adaptative, un développement évolutif, une livraison précoce et une amélioration continue, et elles encouragent des réponses flexibles au changement.
    Il y a forcément de l'agilité dans tous les projets, sinon ce serait n'importe quoi, il n'y aurait pas de dialogues entre le client et le développeur pendant tout le développement.
    Bon après la seule méthode qui n'est pas agile que je connaisse c'est le cycle en V, donc c'est pour ça que j'aime beaucoup l'agile.

    D'après moi, avoir des réunions régulières avec le client, livrer des versions intermédiaires afin d'avoir des retours des clients, c'est de l'agilité et c'est top.

    L'alternative à l'agilité ce serait de livrer le logiciel final, qui correspondrait exactement au cahier des charges, du coup le logiciel ne répondrait pas aux nouveaux besoins du client.
    Parce qu'entre le moment où le cahier des charges a été établi et le moment de la livraison des choses ont changées, en plus le client avait mal exprimé ses besoins, il a demandé des fonctions dont il n'a pas besoin et il n'a pas demandé des fonctions dont il a besoin.

    Avec l'agilité ont répond mieux aux besoins du client, parce qu'il est là pendant le développement.

  19. #39
    Membre habitué
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    82
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : Octobre 2006
    Messages : 82
    Points : 178
    Points
    178
    Par défaut D'accord avec Bond
    Je ne suis pas très bien placé pour discuter de la méthode agile Scrum car j'étais (je suis retraité) dans le domaine des systèmes complexes à logiciel prépondérant : avionique, spatial, systèmes militaires, énergie, centrales nucléaires, etc. où l'utilisation de ce genre de méthode est totalement exclue car inadéquate. Cependant j'ai eu de nombreuse occasions de discuter avec des développeurs de tous horizons en donnant des cours de langages de programmation (principalement C++ et Java mais aussi C, ADA, Lisp). L'immense majorité m'ont en effet affirmé que ce genre de méthode ne fonctionnait pas ou alors seulement pour de très petits projets (5 à 10 KLS) et un nombre restreint de développeurs.
    Ces méthodes agiles (et pas seulement Scrum) sont totalement inapplicables pour des projets comme les robots martiens ou le transport d'énergie (RTE) par exemple.
    Je pense qu'effectivement ces méthodes ne marchent pas dans au moins 85% des cas.
    Pour tous ceux qui voudraient s'instruire avec de vraies méthodes de développement logiciel, je conseille la lecture de https://www.nasa.gov/sites/default/f...handbook_0.pdf (gratuit) et les normes IEEE (dont je suis membre) telles que https://innovate.ieee.org/ieee-softw...ing-standards/ (payant)

  20. #40
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Janvier 2004
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 11
    Points : 17
    Points
    17
    Par défaut Retour sur scrum dans des structures de différentes tailles
    Ce n'est pas la faute de scrum mais la responsabilité d'un management incompétent (pléonasme). Celui-ci imagine s'en servir pour reprendre la main avec l'aide de "consultants" qui tiennent plus du gourou que de l'expert. De l'agilité tout est tordu. Exemples classiques : rajouter des tâches au sprint en cours sans en retirer, isoler complètement les devs du client et les obliger à passer par des intermédiaires dépassés etc... 😅

Discussions similaires

  1. Réponses: 49
    Dernier message: 08/06/2022, 22h33
  2. Méthode ondblclick qui ne marche pas oO
    Par kelaan dans le forum Général JavaScript
    Réponses: 18
    Dernier message: 18/02/2011, 12h30
  3. Présentation générale de la méthode Agile Scrum
    Par michel.di dans le forum Méthodes Agiles
    Réponses: 0
    Dernier message: 18/12/2009, 00h05
  4. [Scrum] étape de la méthode agile scrum
    Par wajdiisi2007 dans le forum Méthodes Agiles
    Réponses: 1
    Dernier message: 28/11/2008, 02h42
  5. Méthode getSize() qui ne marche pas
    Par mush_H dans le forum Agents de placement/Fenêtres
    Réponses: 15
    Dernier message: 20/03/2005, 01h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo