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

ALM Discussion :

Un développeur estime qu’Agile est un « loup déguisé en agneau », le Waterfall 2.0


Sujet :

ALM

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    juillet 2013
    Messages
    2 584
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 584
    Points : 79 032
    Points
    79 032
    Billets dans le blog
    2
    Par défaut Un développeur estime qu’Agile est un « loup déguisé en agneau », le Waterfall 2.0
    Un développeur estime qu’Agile est un « loup déguisé en agneau », le Waterfall 2.0
    Qu’en pensez-vous ?

    Agile a été applaudi dans la communauté des développeurs avec ses promesses garantissant un processus de développement conduit par les ingénieurs plutôt que par l’entreprise. Mais quelques années plus tard, Agile fait de moins en moins l’unanimité au sein des développeurs. Le concept semble avoir manqué le but initialement annoncé au vu des témoignages d’un nombre croissant de développeurs y compris des célèbres.

    En janvier dernier, Erik Meijer, un développeur 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 ouvertement fustigé Agile lors d’un événement. Pour ce dernier, « Agile est un cancer que nous devons éliminer de l’industrie ».

    En mai dernier, Andy Hunt, l’un des 17 co-auteurs du Manifeste Agile en 2001, a rejoint les rangs de ceux qui pensent que la pratique d’Agile n’a pas atteint ses promesses. Il s’est indigné de la manière dont le concept Agile s’est détourné du droit chemin et a donc proposé une nouvelle méthode pour corriger cela. Bref ! Il y a de quoi se demander si Agile, dans la pratique, permet de corriger les problèmes connus dans les méthodes traditionnelles dites en cascade (Waterfall).

    D’après le développeur Amir Yasin, cofondateur et CTO de June (société US spécialisée dans le recrutement des professionnels seniors de l’IT), Agile ne résout pas du tout les problèmes du modèle Waterfall. Pour lui, Agile n’est rien d’autre le Waterfall 2.0, la nouvelle version du modèle de développement en cascade, et peut s’avérer encore pire que les méthodes traditionnelles. « Agile est devenu tout ce que le modèle Waterfall était pour les développeurs, et pire. C’est un loup déguisé en agneau », a écrit Yasin dans un billet de blog.

    Agile a fait des promesses impressionnantes, comme un développement conduit par les ingénieurs, afin que les décisions importantes ne soient pas prises sans les développeurs. Mais selon le CTO de June, dans la réalité, Agile et Waterfall partagent la même idée du développement conduit par l’entreprise. Les décisions techniques sont pilotées par la direction et imposées aux développeurs. « Le résultat final est le même Waterfall. Seul le nom a changé », explique-t-il. Il ajoute encore qu’Agile est plus toxique que les méthodes en cascade, car il rend le développeur beaucoup plus responsable du résultat sans lui donner l’autorité qui va avec sa responsabilité.

    « Agile est un marteau » et « vous êtes le clou », poursuit Amir Yasin en s’adressant aux développeurs. Il pense qu’Agile n’est seulement profitable qu’aux sociétés de conseil, qui doivent faire un prototype rapide pour un client qui ne sait pas vraiment ce qu’il veut, et qui facturent sur une base temporelle. Ces dernières sont ainsi prêtes à accepter n’importe quelle idée avec laquelle vient le client, étant donné que cela signifie un délai plus long, donc plus de revenus.

    Il s’insurge aussi contre le fait que les sociétés de conseil « Agile » se cachent derrière ce concept pour vendre du Waterfall dans un nouvel emballage sans être pointées du doigt en cas d’échec. Si le projet s’est bien passé, tant mieux. Mais si « votre projet a échoué ; ce n’est pas Agile, c’est vous. Vous l’avez juste mal appliqué, et vous auriez gagné en le faisant bien », explique Yasin, pour décrire la réalité.

    Agile semble en effet beaucoup plus facile en théorie. A cet effet, Amir Yasin estime qu’Agile n’est pas agile. Il pense donc que vous deviendrez plus agiles en commençant par vous débarrasser de tout ce qui vous lie à ce concept considéré comme une alternative au modèle Waterfall. C’est-à-dire votre scrum master, votre coach Agile ou encore la société de conseil qui essaie de vous rendre plus Agile.

    Il suggère que les équipes de développement suivent leur propre voie avec des méthodes qui font participer tout le monde, mais qui n’accordent pas la priorité au délai dans les discussions. Il insiste sur le fait que tout le monde doit participer, et si des personnes doivent être exclues, il faut exclure les gestionnaires. Il suggère également de livrer le logiciel seulement quand il est prêt, ni avant, ni après. Le coût de livraison du mauvais produit est beaucoup plus élevé que le coût de prolongement des délais pour livrer le bon produit, rappelle-t-il.

    Source : Medium

    Et vous ?

    Qu’en pensez-vous ?

    Forum ALM
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    3 147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 3 147
    Points : 9 376
    Points
    9 376
    Par défaut
    Je ne serai pas autant catégorique, cela dépend de comment on applique les méthodes Agile.
    Si seuls les développeurs sont impliqués dans l'Agile en effet ce n'est pas la bonne chose à faire (et c'est malheureusement majoritairement appliqué ainsi).

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  3. #3
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    août 2007
    Messages
    272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 272
    Points : 526
    Points
    526
    Par défaut
    Il pense donc que vous deviendrez plus agiles en commençant par vous débarrasser de tout ce qui vous lie à ce concept considéré comme une alternative au modèle Waterfall. C’est-à-dire votre scrum master, votre coach Agile ou encore la société de conseil qui essaie de vous rendre plus Agile.

    Il suggère que les équipes de développement suivent leur propre voie avec des méthodes qui font participer tout le monde, mais qui n’accordent pas la priorité au délai dans les discussions. Il insiste sur le fait que tout le monde doit participer, et si des personnes doivent être exclues, il faut exclure les gestionnaires.
    Oh que oui ! La programmation est l'affaire ... des programmeurs. Combien de projets échouent à cause de gestionnaires qui n'y connaissent rien et nous mettent des bâtons dans les roues ?
    Par contre, ce n'est pas Agile qu'il faut remettre en cause : quelque soit la méthode choisie, les mêmes personnes produiront les mêmes problèmes. Ce que soulève Amir Yasin est très juste, mais il se trompe de cible : ce sont les compétences des participants au projet à remettre en cause, pas la méthodologie.

    De part mon expérience, je peux affirmer qu'une bonne équipe arrivera à un bon résultat quelque soit la méthode choisie, et une équipe de bras cassés ira toujours dans le mur même avec la meilleure méthode au monde.
    Personnellement, je préfère Agile, mais je ne cracherai pas sur le Waterfall qui a aussi connaît de gros succès.

  4. #4
    Membre émérite

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 427
    Points
    2 427
    Par défaut
    En fait, je suis plutôt d'accord, malheureusement. Dans la pratique, l'agilité ne sert à rien si c'est toujours la direction ou le marketing qui font les plannings.

  5. #5
    Membre émérite

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 427
    Points
    2 427
    Par défaut
    Citation Envoyé par Bono_BX Voir le message
    Oh que oui ! La programmation est l'affaire ... des programmeurs. Combien de projets échouent à cause de gestionnaires qui n'y connaissent rien et nous mettent des bâtons dans les roues ?
    Par contre, ce n'est pas Agile qu'il faut remettre en cause : quelque soit la méthode choisie, les mêmes personnes produiront les mêmes problèmes. Ce que soulève Amir Yasin est très juste, mais il se trompe de cible : ce sont les compétences des participants au projet à remettre en cause, pas la méthodologie.

    De part mon expérience, je peux affirmer qu'une bonne équipe arrivera à un bon résultat quelque soit la méthode choisie, et une équipe de bras cassés ira toujours dans le mur même avec la meilleure méthode au monde.
    Personnellement, je préfère Agile, mais je ne cracherai pas sur le Waterfall qui a aussi connaît de gros succès.
    Je ne pense pas que ça soit les compétences dont il parle, mais bien les intentions. Tant qu'on continuera à imposer les délais aux équipes techniques, l'agilité sera plus nuisible qu'utile, et malheureusement, ça n'est pas près de changer.

  6. #6
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    août 2007
    Messages
    272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 272
    Points : 526
    Points
    526
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Je ne pense pas que ça soit les compétences dont il parle, mais bien les intentions. Tant qu'on continuera à imposer les délais aux équipes techniques, l'agilité sera plus nuisible qu'utile, et malheureusement, ça n'est pas près de changer.
    Mais justement, imposer des délais aux équipes techniques, ça n'a rien à voir avec l'Agile, ça se fait aussi en Watrefall, avec les mêmes conséquences. Si tu penses aux itérations de 2 - 3 semaines (j'extrapole sur ce que tu dis ), les users stories doivent être suffisamment concises pour rentrer dans une itération, sinon on les redécoupe ; il n'y a donc pas vraiment de délais imposé.

  7. #7
    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 938
    Points
    7 938
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Il suggère également de livrer le logiciel seulement quand il est prêt, ni avant, ni après. Le coût de livraison du mauvais produit est beaucoup plus élevé que le coût de prolongement des délais pour livrer le bon produit, rappelle-t-il.
    L'effet tunnel est désastreux, comment peux-tu en arriver à le justifier ?

    Oui, les livraisons intermédiaires ont un coût mais c'est un coût nécessaire.
    Il est important de pouvoir montrer que le projet avance et d'identifier le plus tôt possible les mauvais choix lors des spec.
    Combien de fois on écrit quelque chose en théorie génial et qui s'avère désastreux une fois en pratique ?
    Cela est aussi vrai pour la technique que pour les AMOA.

    Citation Envoyé par Traroth2 Voir le message
    Tant qu'on continuera à imposer les délais aux équipes techniques, l'agilité sera plus nuisible qu'utile, et malheureusement, ça n'est pas près de changer.
    Le hic c'est que c'est un peu une obligation.
    Dire au client "ça sera livré quand ça sera terminé" n'est tout simplement pas possible.
    Un projet informatique est rarement seul.
    Derrière, il peut y avoir des tas de choses à coordonner : une campagne marketing, de la formation, etc.
    Sans parler du budget...

  8. #8
    Membre confirmé
    Profil pro
    Developpeur
    Inscrit en
    septembre 2013
    Messages
    230
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Developpeur

    Informations forums :
    Inscription : septembre 2013
    Messages : 230
    Points : 543
    Points
    543
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Il s’est indigné de la manière dont le concept Agile s’est détourné du droit chemin
    Je n'ai pas lu l'article d'origine, mais ne vaudrait-il pas mieux dire "dont le concept Agile a été détourné du droit chemin" ?

  9. #9
    Membre averti
    Inscrit en
    novembre 2006
    Messages
    121
    Détails du profil
    Informations forums :
    Inscription : novembre 2006
    Messages : 121
    Points : 327
    Points
    327
    Par défaut
    Ce que les SSII soi-disant "agiles" ne comprennent pas (et ne veulent pas comprendre) c'est que l'agilité ne se limite pas à l'équipe de développement. Toute la structure doit devenir agile elle aussi et répondre aux besoins de l'équipe de dev. Tant que les commerciaux et autres directeurs de projets continueront à s'interposer entre les devs et les clients (imposer des dead lines, des fonctionnalités inutiles mais couteuses, ou rien que faire l'intermédiaire entre les 2), ça ne pourra pas marcher !

    Il faut aussi accepter de payer plus cher une équipe agile car elle a plus de responsabilités, et il faut des développeurs aguerris (pas des stagiaires ou des débutants facturés comme des experts) car le maillon le plus faible de la chaine peut mettre en péril l'équipe.

    Donc +1 avec ce qui a été dit plus haut, le problème ce n'est pas la méthodologie mais les équipes, et j'ajouterai la rigidité des entreprises elles-mêmes...
    Développeur / Formateur
    Tutoriels AngularJS / Node.js sur ma chaîne Youtube : http://www.youtube.com/user/DevDuFutur

  10. #10
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    2 223
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 2 223
    Points : 7 591
    Points
    7 591
    Billets dans le blog
    3
    Par défaut
    En un mot, pareil.

    Avec un peu plus de détails, je plussoie au fait qu'une méthode, au même titre qu'un outil, n'est ni bonne ni mauvaise. C'est ceux qui les appliquent qui font les bons ou les mauvais choix, ceux qui en font la pub qui donnent les bons ou les mauvais tuyaux, etc. C'est facile de mettre les échecs des uns et des autres sur le dos d'une méthode, mais n'est-ce pas la plus grande preuve d'irresponsabilité ?

    On a tenté d'appliquer telle méthode et ça a foiré. Bon. Maintenant, il y a ceux qui vont chercher ce qui a foiré et tenter de le corriger (changer de méthode, l'appliquer autrement, changer des membres de l'équipe, l'organiser autrement, etc.), et ceux qui vont passer leur temps à se plaindre et à chercher des coupables (et si toute l'équipe est comme ça, ce sera forcément la méthode la coupable, ce qui est stupide car on ne peut pas lui faire "payer", or c'est bien là le but de la responsabilité).
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  11. #11
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Agile a fait des promesses impressionnantes, comme un développement conduit par les ingénieurs, afin que les décisions importantes ne soient pas prises sans les développeurs. Mais selon le CTO de June, dans la réalité, Agile et Waterfall partagent la même idée du développement conduit par l’entreprise. Les décisions techniques sont pilotées par la direction et imposées aux développeurs. « Le résultat final est le même Waterfall. Seul le nom a changé », explique-t-il. Il ajoute encore qu’Agile est plus toxique que les méthodes en cascade, car il rend le développeur beaucoup plus responsable du résultat sans lui donner l’autorité qui va avec sa responsabilité.
    Citation Envoyé par Agile Manigesto - Principe N°11
    Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
    En effet, si les décisions techniques sont pilotées par la direction, on corrompe ce principe de l'Agilité.
    L'auto-organisation est un élément très important dans l'agilité.

    Comment peut on alors dire "Agile, ça marche pas, c'est trop nul", si on ne respecte déjà pas l'ensemble de ses règles.
    Comme si un parachutiste disait que son parachute ne marche pas alors qu'il n'a pas tiré sur la poignée: logique, on s'écrase

    Et on peux pas dire que les 'règles' soient nombreuses et compliquées à comprendre : 12 principes à respecter.
    Un équipe qui a vraiment compris le sens de l'agilité, mettra Scrum (ou autre méthode parfaite pour commencer) au placard et fera pleinement de l’amélioration continu de ses pratiques avec pour seule guide ces 12 principes.

    Par contre, là où je suis plutôt d'accord, c'est que l'Agilité deviens tellement un effet de mode, que forcement on retrouve dans plein d'entreprise de très mauvaise mise en place et de mauvais consultant 'expert' catch-agile, ....
    Mais voyez qui on retrouve sur les conférences agiles de France: la question de la légitimité des experts que l'on ne voit jamais se pose.

  12. #12
    Membre émérite

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 427
    Points
    2 427
    Par défaut
    Citation Envoyé par Bono_BX Voir le message
    Mais justement, imposer des délais aux équipes techniques, ça n'a rien à voir avec l'Agile, ça se fait aussi en Watrefall, avec les mêmes conséquences. Si tu penses aux itérations de 2 - 3 semaines (j'extrapole sur ce que tu dis ), les users stories doivent être suffisamment concises pour rentrer dans une itération, sinon on les redécoupe ; il n'y a donc pas vraiment de délais imposé.
    C'est exactement ce que dit l'article. Le problème est que l'agile ne peut pas avoir d'effet positif dans ces circonstances.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 747
    Points : 31 634
    Points
    31 634
    Par défaut
    Ben oui. C'est toujours pareil : l'équipe qui a gagné la coupe du monde jouait en 4.2.3.1, donc plein d'équipes amateurs se sont mises à jouer en 4.2.3.1. Avec des résultats moins impressionnants. Est-ce surprenant?

    Enfin, les crétins qui lisent le petit manuel et ensuite se proclament empereur du monde et emmènent leur organisation à sa perte, c'est vieux comme le monde.

    Après, éviter leurs travers ne suffit pas à garantir le succès d'un projet. Avoir des gens compétents et humbles ne suffit pas toujours à assurer le succès d'un projet. Avoir un sponsor réaliste qui ne demande pas de refaire Amazon, en mieux, en 4 jours(mon père a reçu une offre de ce genre, et les 4 jours étaient payés 999€), c'est bien, mais ça ne suffit pas toujours à réussir le projet.

    Notre putain de métier est difficile. Ce n'est pas le seul. On peut aligner des superstars du football et ne pas gagner la ligue des champions pendant des décennies. Comme bien d'autres, notre métier est difficile. Certaines théories peuvent être des outils utiles pour se planter moins souvent. Mais ça ne sont jamais que des outils. Dès lors qu'ils sont élevés au rang de religion, ils deviennent toxiques. Ça n'a rien de spécifique à l'agile.

    Ma conclusion, c'est que les équipe compétentes, elles, sont plus fortes avec agile que sans. Les autres seront toujours des catastrophes, et ça c'est vrai depuis que le monde est monde.
    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.

  14. #14
    Membre émérite

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 427
    Points
    2 427
    Par défaut
    Citation Envoyé par Saverok Voir le message

    Le hic c'est que c'est un peu une obligation.
    Dire au client "ça sera livré quand ça sera terminé" n'est tout simplement pas possible.
    Un projet informatique est rarement seul.
    Derrière, il peut y avoir des tas de choses à coordonner : une campagne marketing, de la formation, etc.
    Sans parler du budget...
    Je ne saurais désapprouver plus. Quand des non-techniciens décident des délais d'un projet technique, c'est tout simplement de la pensée magique : je veux que ça soit faisable dans ce délai, donc c'est faisable dans ce délai. Les faits sont têtus : ça ne fonctionne pas. La preuve ? Les innombrables projets qui vont dans le mur.

    Si la direction générale a besoin d'un délai, il faut que ça soit l'équipe technique qui le définisse, à partir d'un planning, au lieu d'essayer de faire tenir un "rétro-planning" (une aberration inutile) dans un délai défini au doigt mouillé par un peigne-cul du marketing qui n'y connait rien.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 747
    Points : 31 634
    Points
    31 634
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Je ne saurais désapprouver plus. Quand des non-techniciens décident des délais d'un projet technique, c'est tout simplement de la pensée magique : je veux que ça soit faisable dans ce délai, donc c'est faisable dans ce délai. Les faits sont têtus : ça ne fonctionne pas. La preuve ? Les innombrables projets qui vont dans le mur.

    Si la direction générale a besoin d'un délai, il faut que ça soit l'équipe technique qui le définisse, à partir d'un planning, au lieu d'essayer de faire tenir un "rétro-planning" (une aberration inutile) dans un délai défini au doigt mouillé par un peigne-cul du marketing qui n'y connait rien.
    Ben, quand tu as un projet d'ordre réglementaire(notre quotidien, dans le médical, sur la partie comptable), c'est inévitable. Si le jour J on est pas prêt, on a plus qu'à mettre la clef sous la porte. Et le délai est imposé par des gens dans des bureaux du ministère, encore plus loin de moi que ta personne du marketing.

    Et sinon, pour du fonctionnel, on peut choisir une date, et accepter de perdre des fonctionnalités en cours de route. Ça peut être parfaitement rationnel de dire que le 1 Janvier, la nouvelle version doit être prête, avec toutes les évolutions réglementaires pour 2016... et on essayera d'y mettre un maximum de vraies évolution aussi, mais ça, ça dépendra de ce qui est possible. Nous, en tous cas, on marche comme ça, et on a des fonctionnalités qui trainent dans les cartons depuis des années, que les clients réclament, mais avec nos faibles moyens et l'épée de Damoclès du réglementaire, ça doit attendre. C'est triste, mais nos concurrents ont les mêmes soucis.
    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.

  16. #16
    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 938
    Points
    7 938
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Je ne saurais désapprouver plus. Quand des non-techniciens décident des délais d'un projet technique, c'est tout simplement de la pensée magique : je veux que ça soit faisable dans ce délai, donc c'est faisable dans ce délai. Les faits sont têtus : ça ne fonctionne pas. La preuve ? Les innombrables projets qui vont dans le mur.

    Si la direction générale a besoin d'un délai, il faut que ça soit l'équipe technique qui le définisse, à partir d'un planning, au lieu d'essayer de faire tenir un "rétro-planning" (une aberration inutile) dans un délai défini au doigt mouillé par un peigne-cul du marketing qui n'y connait rien.
    La définition d'un planning se fait dans un échange entre le marketing et la technique.
    Il y a un besoin business que le projet soit délivré à telle date.
    La technique doit être en mesure de dire au marketing, pour telle date, je suis en mesure de délivrer tel périmètre sous telles conditions (jalons de spec, équipes, etc).
    Et y a échange jusqu'au compromis mutuellement acceptable.

    La technique seule ne peut pas définir un planning.
    De même, je suis de ton avis, que le marketing ne peut pas le faire seul non plus.

  17. #17
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    août 2007
    Messages
    272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 272
    Points : 526
    Points
    526
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    C'est exactement ce que dit l'article. Le problème est que l'agile ne peut pas avoir d'effet positif dans ces circonstances.
    ????? Peux-tu creuser, STP ? Si ta phrase se rapporte aux délais imposé, OK, si c'est aux user stories redéfinies, là je ne comprends pas.

    Citation Envoyé par Saverok Voir le message
    La définition d'un planning se fait dans un échange entre le marketing et la technique.
    Il y a un besoin business que le projet soit délivré à telle date.
    La technique doit être en mesure de dire au marketing, pour telle date, je suis en mesure de délivrer tel périmètre sous telles conditions (jalons de spec, équipes, etc).
    Et y a échange jusqu'au compromis mutuellement acceptable.

    La technique seule ne peut pas définir un planning.
    De même, je suis de ton avis, que le marketing ne peut pas le faire seul non plus.
    Je suis tout à fait d'accord. Petit retour d'expérience qui s'est bien passé : pour faire face à des délais très court, nous étions arrivé à un compromis avec les équipes de production sur le fait qu'ils auraient bien les fonctionnalités demandées à temps, mais au lieu d'avoir une interface ce seraient de bonnes vieilles lignes de commande, et au lieu d'un beau reporting, un vieux csv tout basique.
    Et ça a marché, nous avons pu leur implémenter "le sucre" plus tard, et tout le monde était content (happy ending).

  18. #18
    Membre à l'essai
    Homme Profil pro
    Responsable sécurité
    Inscrit en
    octobre 2015
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : Responsable sécurité

    Informations forums :
    Inscription : octobre 2015
    Messages : 3
    Points : 10
    Points
    10
    Par défaut
    J'en pense que tout ceci sont des effets de modes et que chaque développeur qui gère sa carrière et sa notoriété sur Twitter ou son blog se doit de faire parler de lui tout les x temps.

    Prôner l'agilité était déjà un effet de mode à l'époque. C'était très vendeur. Relativiser sur l'agilité est devenu à la mode aujourd'hui.

    Des articles qui remettent en cause les systèmes en place on en voit tout le temps en IT. C'est un des principes même de l'IT... comme il s'agit d’ingénierie, pas de science, n'importe qui peut remettre en cause tout ce qui a été mit en place par d'autres a tout moment et autant sur des sujets très techniques que sur des sujets divers tel que la méthodologies. Il est facile de dire, après coup, que tel technique n'est pas bonne. C'est comme ça qu'on fait parler de soit et qu'on crée de nouvelles modes. Et quand ça marche, que son idée fait le buzz et bien c'est aussi sa carrière qui fait le buzz.

    Or ce n'est pas comme ça qu'il faut le voir. Toutes techniques, méthodologies peut toujours être remise en cause en fonction du contexte. Si aujourd'hui certain blogueur remettent en cause l'agilité c'est parce que effectivement dans certaines sociétés, équipes elle est mal utilisée. Bref on peut aujourd'hui s'amuser a remettre en cause les fondements même du développement si on veut s'amuser.

  19. #19
    Expert confirmé

    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    septembre 2006
    Messages
    3 580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : septembre 2006
    Messages : 3 580
    Points : 5 194
    Points
    5 194
    Par défaut
    Bonjour

    Moi, je me demande pourquoi dans l'informatique on veut "toujours" donner la méthode de travail utilisée par l'équipe.

    quand je fais venir un artisan, des artisans chez moi pour intervenir, je ne leur demande pas si ils sont agiles, ou waterfall, ou merise, ou autre...

    Je veux juste que le travail soit bien fait dans des couts raisonnables par rapport à l'intervention à réaliser.

    Je ne comprends pas pourquoi ce besoin de toujours tout formaliser, toujours avec une méthode ou autre...

    Ne peut-on simplement se baser et se concentrer sur la réalisation logicielle plutôt que d'introduire des méthodes qui, peuvent fonctionner, mais au final, la meilleure
    organisation et la plus facilement acceptée, c'est celle que tout le monde choisie.

    Perso (ok, je suis peut-etre un peu rebel et metalleuh...), ça me saoule de devoir faire autre chose que de la conception et du développement (test, etc..) quand je dois
    livrer un logiciel...

    Mon expérience n'est pas absolue, donc, difficile de dire que ce qui marche / a marché pour moi doit marcher pour tous les autres... mais je me souviens simplement
    que sur des projets de 10 développeurs, une réunion de 1h par semaine pour valider l'avancement était largement suffisant... ensuite, le CP passait de temps en temps
    voir chaque développeur pour "affiner" les choses, mais pas besoin d'une lourdeur d'un process bien "théorisé"...

    Au final, on se rend compte que plus on met d'ordre (organisation, etc...) et plus ça gonfle les vrais développeurs qui sont, pour moi, avant tout des créateurs, des artistes...
    The Monz, Toulouse
    Expertise dans la logistique et le développement pour
    plateforme .Net (Windows, Windows CE, Android)

  20. #20
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    3 147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 3 147
    Points : 9 376
    Points
    9 376
    Par défaut
    Citation Envoyé par theMonz31 Voir le message
    Bonjour

    Moi, je me demande pourquoi dans l'informatique on veut "toujours" donner la méthode de travail utilisée par l'équipe.

    quand je fais venir un artisan, des artisans chez moi pour intervenir, je ne leur demande pas si ils sont agiles, ou waterfall, ou merise, ou autre...

    Je veux juste que le travail soit bien fait dans des couts raisonnables par rapport à l'intervention à réaliser.

    Je ne comprends pas pourquoi ce besoin de toujours tout formaliser, toujours avec une méthode ou autre...

    Ne peut-on simplement se baser et se concentrer sur la réalisation logicielle plutôt que d'introduire des méthodes qui, peuvent fonctionner, mais au final, la meilleure
    organisation et la plus facilement acceptée, c'est celle que tout le monde choisie.

    Perso (ok, je suis peut-etre un peu rebel et metalleuh...), ça me saoule de devoir faire autre chose que de la conception et du développement (test, etc..) quand je dois
    livrer un logiciel...

    Mon expérience n'est pas absolue, donc, difficile de dire que ce qui marche / a marché pour moi doit marcher pour tous les autres... mais je me souviens simplement
    que sur des projets de 10 développeurs, une réunion de 1h par semaine pour valider l'avancement était largement suffisant... ensuite, le CP passait de temps en temps
    voir chaque développeur pour "affiner" les choses, mais pas besoin d'une lourdeur d'un process bien "théorisé"...

    Au final, on se rend compte que plus on met d'ordre (organisation, etc...) et plus ça gonfle les vrais développeurs qui sont, pour moi, avant tout des créateurs, des artistes...
    Si l'artisan est tout seul il n'y a pas de problème de méthode, juste de tenu de planning.
    Si il s'inscrit dans des plus gros travaux c'est le maitre d'oeuvre qui utilise une certaine méthode pour que tout le monde se marche pas dessus.
    Bref dans tout métier tu as des méthodes, plus ou moins connues du client.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

Discussions similaires

  1. Un développeur estime que nous vivons dans l’âge des logiciels ratés
    Par Michael Guilloux dans le forum Débats sur le développement - Le Best Of
    Réponses: 111
    Dernier message: 07/12/2015, 13h32
  2. Un développeur estime que le développeur full stack est une chimère
    Par Olivier Famien dans le forum Actualités
    Réponses: 63
    Dernier message: 16/11/2015, 11h58
  3. Un développeur estime que Ruby on Rails est dépassé
    Par Olivier Famien dans le forum Ruby on Rails
    Réponses: 56
    Dernier message: 13/10/2015, 19h40

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