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

Méthodes Agiles Discussion :

Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries


Sujet :

Méthodes Agiles

  1. #41
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2007
    Messages
    186
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Janvier 2007
    Messages : 186
    Points : 478
    Points
    478
    Par défaut
    Parce que souvent il y a d'énormes différences entre l'idée du projet de base et le projet final.
    Alors qu'en cycle en V pure, on livre exactement ce qu'on a dit des années avant...
    C'est cool d'avoir des réunions régulière avec le client pour qu'il puisse dire "en fait je n'ai pas besoin de ça, mais maintenant j'ai besoin de ça".

    En Cycle en V il faut être extra fort, il faudrait comprendre le besoin du client mieux que le client lui même et anticiper les besoins du futur.
    100% d'accord avec ce que tu dis mais ça on le faisait déjà avant qu'on lui donne le nom de "méthode de travail agile", des vrais cycle en V et des développement en mode sous marin pendant x mois je n'ai jamais vu, à un moment ou à un autre le client toujours inquiet voudra voir son bébé en cours de réalisation et forcement il va changer des trucs et remettre en cause les specs. Heureusement que les développeurs eux ont toujours été flexibles, allez demander à un artisan carreleur de changer les dalles de votre futur salon parce que après réflexion cela ne vous plait pas.

  2. #42
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 676
    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 676
    Points : 18 642
    Points
    18 642
    Par défaut
    Citation Envoyé par Jitou Voir le message
    des vrais cycle en V et des développement en mode sous marin pendant x mois je n'ai jamais vu
    Oui, mais si on appliquait le cycle en V à la lettre il faudrait faire comme ça.
    C'est pour ça que je pense qu'au lieu de respecter scrupuleusement un protocole il vaut mieux comprendre l'essence du truc et faire sa propre gestion de projet.
    Parce que le Cycle en V pur et SCRUM pur, c'est pas top.

    Si vous parlez de "méthode de travail agile" et que vous êtes flexible, c'est qu'il y a un peu de gestion de projet agile.
    Selon comment on regarde : SCRUM c'est un peu plein de mini cycle en V itératifs.

    De toute façon ça change selon le projet, selon l'équipe, selon le besoin, etc.
    Il n'y a pas de méthode qui fonctionne dans tous les scénarios.
    Keith Flint 1969 - 2019

  3. #43
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 918
    Points
    2 918
    Par défaut
    Citation Envoyé par Jitou Voir le message
    Malheureusement l'agilité est devenue un "buzzword" et des managers sont prêt à tout pour prétendre faire de l'agilité pour bien se faire voir et pour ça il n'y a rien de plus simple que de mettre en place la partie la plus visible de certaines méthodes. Le plus souvent les post-it sur un mur dans une zone de passage car ça en jette, les autres collègues qui passent devant sont impressionnés, on donne l'impression que l'on a mise place une organisation quasi militaire et que l'on croule sous le travail et puis les stands up du matin c'est pas mal non plus car c'est aussi très visible, d'ailleurs cela suscite toujours la curiosité ces groupes de paroles improvisés au milieux des autres collègue debout autour d'un gourou

    Les méthodes agiles c'est surement bien si cela permet de répondre à certains problèmes d'organisation sur les projet mais je n'ai pas encore vu beaucoup de bénéfice sur les projets sur lesquels j'ai bossé jusqu'à présent. Si il y a quand même le Kanban implémenté sous forme logiciel, 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 mais ça on le vois pas si l'on ne fait pas parti de l'équipe projet
    Scoop(s) :

    - Il n'y a pas de chef de projet en agile. La notion de "visibilité sur son équipe" n'a pas de sens.

    - Les post-it sur les murs ou numériques ne font pas partie des méthodes agiles, c'est une pratique répandue mais connexe.

    - Kanban != agile

  4. #44
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 481
    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 481
    Points : 6 137
    Points
    6 137
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    - Il n'y a pas de chef de projet en agile. La notion de "visibilité sur son équipe" n'a pas de sens.
    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.
    À mon avis, un chef de projet qui donne les priorités dans les grandes lignes est compatible avec l'agilité.

  5. #45
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 918
    Points
    2 918
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    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.
    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.

    À mon avis, un chef de projet qui donne les priorités dans les grandes lignes est compatible avec l'agilité.
    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.

  6. #46
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    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.
    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.

  7. #47
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 918
    Points
    2 918
    Par défaut
    Citation Envoyé par Saverok Voir le message
    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 ).

    Schwaber et Sutherland (pour ne prendre que l'exemple des créateurs de Scrum) sont les mecs les plus intégrés dans l'orthodoxie capitaliste que je connaisse. Ils parlent de ROI à longueur de page et expliquent que leur méthode fait gagner des millions de dollars aux compagnies qui l'utilisent. Tout Scrum est tourné vers la création de valeur qui va permettre à un produit de prendre des parts de marché.

    Par ailleurs, tu sembles accorder à la seule méthode de management command-and-control le monopole de la conscience du temps et de l'argent. Je ne vois pas le rapport.

    Citation Envoyé par Saverok Voir le message
    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à.
    Le fait que tu ne précises même pas s'il s'agit de rendre des comptes et prendre des décisions au niveau technique, fonctionnel, organisationnel, financier, RH, administratif... montre bien que le schéma du chef de projet omnipotent a la vie dure.

    Et si on distribuait différemment les responsabilités ?

    Et si une personne responsable du produit se prenait les Scud relatifs au fonctionnel (retours utilisateurs, ROI...) et l'équipe de réalisation entière se prenait les Scuds relatifs ... à la réalisation ?

    Je ne vois pas ce qu'il y a de si ahurissant à cela

  8. #48
    Membre expérimenté
    Avatar de randriano
    Homme Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 219
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 219
    Points : 1 438
    Points
    1 438
    Par défaut
    Si je lis bien, il ne s'agit pas d'abandonner Agile mais abandonner les frameworks comme Scrum, XP, Kaban ou ... non??

    Si je cite les 12 principes issus du Manifeste:
    1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
    2. Accueillir positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage
    3. compétitif au client.
    4. Livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
    5. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
    6. Réaliser les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
    7. La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
    8. Les processus agiles encouragent un rythme de développement soutenable.
    9. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
    10. Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité.
    11. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
    12. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
    13. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.


    Et je prends le 7. Les processus agiles encouragent un rythme de développement soutenable

    L'Agilité devrait limiter au maximum le stress côté développeurs non???
    randriano.dvp.com
    Développeur. Product Owner [Agile]. Sites web, mobile apps, système d'information (SI).

  9. #49
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 065
    Points
    32 065
    Par défaut
    Citation Envoyé par Jitou Voir le message
    100% d'accord avec ce que tu dis mais ça on le faisait déjà avant qu'on lui donne le nom de "méthode de travail agile", des vrais cycle en V et des développement en mode sous marin pendant x mois je n'ai jamais vu, à un moment ou à un autre le client toujours inquiet voudra voir son bébé en cours de réalisation et forcement il va changer des trucs et remettre en cause les specs. (.../...)
    Moi j'ai vu. Des specs de deux ans d'âge, donc obsolètes(pour une fois qu'Accenture avait fait du bon boulot, le client a attendu que ça ne soit plus applicable tel quel...), et le grand chef coté client refuse toute modification dessus au prétexte que "c'est ce qui a été signé, c'est donc ce qui sera fait, et ça va marcher". Et ça n'a pas marché, évidemment, ça ne collait plus à l'existant. soit c'était conforme, mais ça ne marchait pas. Soit ça marchait, mais ce n'était pas conforme. un projet de 60 personnes, prévu sur 18 mois. 6 ans plus tard, ils ont tout mis à la poubelle et recommençé sur d'autres bases(saines? Aucune idée, je sais juste qu'ils sont repartis d'une feuille blanche, 8 ans après qu'Accenture aie fait ses specs).

    Effectivement, la plupart des clients sont plus sérieux que ça. Sorti un peu par hasard de cet enfer, je suis tombé chez un client pas folichon, mais quand je trouvait une erreur dans la specs, la réponse était "on va corriger la spec". Le Nirvana, en comparaison.

    Le truc, c'est que les projets qui finissent en tunnel sous-marin complètement à coté de la plaque, ce sont souvent les plus gros, les plus visibles. Parce que l’ego du décideur est en jeu. Le projet Louvois, le système d'armement du F35 sont des sujets de ce genre, et qui foirent justement parce que le décideur s'implique pour que ça marche...et exige un plan de marche suivi scrupuleusement à la lettre. Ce qui amène a des aberrations comme celle que j'ai vécu sur ce projet spécifié par Accenture. Alors que quand on laisse les gens bosser et corriger les erreurs au fur et à mesure qu'elles sont détectées, ça se passe bien mieux.

    Citation Envoyé par Luckyluke34 Voir le message
    - Il n'y a pas de chef de projet en agile. La notion de "visibilité sur son équipe" n'a pas de sens.(.../...)
    vrai, mais les chefs de projet n'en ont rien à foutre. Ils veulent des gens à fouetter, et le fouet à la mode s'appelle "agile", dans leur esprit autoritaire.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  10. #50
    Membre expérimenté
    Avatar de randriano
    Homme Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 219
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 219
    Points : 1 438
    Points
    1 438
    Par défaut
    Je suis fan de l'esprit Agile mais je n'aime pas du tout la représentation de la méthode incrémentale de l'Agile suivante:
    Nom : skate-bike-car.png
Affichages : 433
Taille : 200,5 Ko

    Cette image prête à confusion des gens leur faisant dire que je ne veux pas d'un skateboard en attendant une voiture. Cette illustration donne parfois raison au cycle V d'attendre jusqu'à la fin au lieu d'incrémentalement à chaque sprint

    Ou insistez-vous que c'est la bonne représentation??
    randriano.dvp.com
    Développeur. Product Owner [Agile]. Sites web, mobile apps, système d'information (SI).

  11. #51
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 676
    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 676
    Points : 18 642
    Points
    18 642
    Par défaut
    Citation Envoyé par randriano Voir le message
    je ne veux pas d'un skateboard en attendant une voiture
    Le truc c'est de dire au client "Regardez on a développé une fonction que vous avez demandez. Est-ce que ça répond toujours à vos besoins ?". C'est loin d'être fini, mais il y a un truc utile qui est déjà là.
    Avec l'agile on peut réorienté le projet avec l'évolution des besoins.
    Mettre un peu d'agile dans la gestion du projet ça permet de développer une solution qui répond vraiment aux besoins.

    Sans aucune agilité c'est hyper rigide. Tu livres ce qu'il y a dans le cahier des charges, donc il y a de grandes chances pour que ça tombe à côté des besoins du client...
    Keith Flint 1969 - 2019

  12. #52
    Membre à l'essai
    Homme Profil pro
    Utilisateur courant d'EXCEL
    Inscrit en
    Avril 2019
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Utilisateur courant d'EXCEL

    Informations forums :
    Inscription : Avril 2019
    Messages : 14
    Points : 17
    Points
    17
    Par défaut
    bonjour à toutes et à tous,

    Citation Envoyé par Ryu2000 Voir le message
    Le truc c'est de dire au client "Regardez on a développé une fonction que vous avez demandez. Est-ce que ça répond toujours à vos besoins ?". C'est loin d'être fini, mais il y a un truc utile qui est déjà là.
    Avec l'agile on peut réorienté le projet avec l'évolution des besoins.
    Mettre un peu d'agile dans la gestion du projet ça permet de développer une solution qui répond vraiment aux besoins.

    Sans aucune agilité c'est hyper rigide. Tu livres ce qu'il y a dans le cahier des charges, donc il y a de grandes chances pour que ça tombe à côté des besoins du client...
    Cette dernière contribution m'encourage à intervenir dans votre discussion.

    Mais force est de constater ... que je suis l'intrus ... je suis un client.

    En fait je représente plutôt un client, je ne suis pas le chef de projet client (il y en a 1 de désigné), je ne suis qu'un "chargé de projet", je vous laisse faire le distinguo.
    Le chef de projet du coté développeur, c'est chargé poliment de me remettre à ma place, mes demandes semblaient l'agacer.
    j'imagine qu'un chef de projet se doit de recevoir des "commentaires" (tickets) que d'un autre chef de projet.

    Je me suis permis d'ouvrir une discussion sur ce même forum.
    https://www.developpez.net/forums/d2...-informatique/
    Si vous avez du temps je veux bien un coup de clavier.

    merci de votre attention
    an1844

  13. #53
    Nouveau Candidat au Club
    Homme Profil pro
    Java
    Inscrit en
    Août 2018
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Congo-Kinshasa

    Informations professionnelles :
    Activité : Java

    Informations forums :
    Inscription : Août 2018
    Messages : 2
    Points : 1
    Points
    1
    Par défaut
    On ne change pas une methode qui marche

  14. #54
    Communiqués de presse

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

    Informations professionnelles :
    Activité : Traductrice Technique

    Informations forums :
    Inscription : Juin 2023
    Messages : 1 144
    Points : 80 104
    Points
    80 104
    Par défaut 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.

    Nom : 1.jpg
Affichages : 14080
Taille : 62,1 Ko

    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é :


    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.
    Source : Engprax

    Et vous ?

    Pensez-vous que cette étude est crédible ou pertinente ?
    Quel est votre avis sur le sujet ?

    Voir aussi :

    Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries, l'un des signataires du Manifeste Agile

    L'armée américaine annonce une nouvelle politique visant à favoriser l'adoption de pratiques de développement logiciel agiles

    La méthode Scrum est-elle une méthode agile efficace ou un cancer pour les développeurs ? Les propos d'un professionnel de l'informatique divisent la communauté
    Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  15. #55
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 676
    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 676
    Points : 18 642
    Points
    18 642
    Par défaut
    Citation Envoyé par Jade Emy Voir le message
    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.
    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" ?
    Keith Flint 1969 - 2019

  16. #56
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 481
    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 481
    Points : 6 137
    Points
    6 137
    Par défaut
    Dans cette publicité pour le livre Impact Engineering, je lis :

    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.
    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 ?
    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.

  17. #57
    Membre habitué
    Homme Profil pro
    Architecte réseau
    Inscrit en
    Février 2024
    Messages
    59
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Architecte réseau

    Informations forums :
    Inscription : Février 2024
    Messages : 59
    Points : 175
    Points
    175
    Par défaut
    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.

  18. #58
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2019
    Messages
    208
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2019
    Messages : 208
    Points : 1 011
    Points
    1 011
    Par défaut
    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.

  19. #59
    Expert confirmé
    Homme Profil pro
    Développeur
    Inscrit en
    Août 2003
    Messages
    1 303
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Août 2003
    Messages : 1 303
    Points : 4 194
    Points
    4 194
    Par défaut
    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

  20. #60
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 481
    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 481
    Points : 6 137
    Points
    6 137
    Par défaut
    Citation Envoyé par d_d_v Voir le message
    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.
    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.

    Citation Envoyé par d_d_v Voir le message
    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.
    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.

Discussions similaires

  1. Quels sont les langages de programmation les plus utilisés par les développeurs ?
    Par Michael Guilloux dans le forum Débats sur le développement - Le Best Of
    Réponses: 18
    Dernier message: 20/07/2018, 20h29
  2. Réponses: 55
    Dernier message: 08/09/2016, 17h43
  3. Quelles pratiques les développeurs devraient-ils éviter ?
    Par Stéphane le calme dans le forum Débats sur le développement - Le Best Of
    Réponses: 53
    Dernier message: 18/03/2015, 18h18
  4. Les développeurs PHP préfèrent les bureaux Windows aux bureaux Linux
    Par RideKick dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 42
    Dernier message: 25/02/2010, 02h15
  5. Réponses: 0
    Dernier message: 19/02/2010, 08h21

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