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 :

« Agile est un cancer », pour Erik Meijer


Sujet :

ALM

  1. #21
    Membre régulier
    Inscrit en
    Mars 2006
    Messages
    121
    Détails du profil
    Informations forums :
    Inscription : Mars 2006
    Messages : 121
    Points : 110
    Points
    110
    Par défaut
    Citation Envoyé par LSMetag Voir le message
    Evidemment, mais normalement ça ne doit pas être le cas.

    A part si tu es un vrai hargneux dans la vie, je ne pense pas qu'avoir la possibilité de demander aux clients des précisions sur ce qu'ils veulent ou les inviter à se poser des questions sur certains aspect n'est en décalage avec le rôle d'analyste programmeur. Pour les personnes moins à l'aise, elles peuvent tout d'abord en faire part à leur chef de projet ("SCRUM Master" pour les puristes) qui passe le coup de fil, en ta présence.
    Je suis d'accord avec toutes les interventions dans cette discussion, entre autres la tienne

    Juste pour clarifier, dans ma dernière phrase, ce que j'assimilais à un acteur est le principe Agile lui même, pas un développeur qui évolue dans un cadre agile. c'est totalement différent.

  2. #22
    Membre à l'essai
    Inscrit en
    Juin 2004
    Messages
    20
    Détails du profil
    Informations personnelles :
    Âge : 40

    Informations forums :
    Inscription : Juin 2004
    Messages : 20
    Points : 16
    Points
    16
    Par défaut Scrum OK - TDD bof
    J'ai expérimenté Scrum en tant que développeur, scrum master et product owner.
    Je trouve que la méthode est valorisante pour le développeur (implication, challenge, livrable en mode start-up), et offre une vraie visibilité à chaque acteur du projet.

    Pour les TDD (qui n'ont rien à voir avec Scrum...), je dois confesser un bilan plus que mitigé.
    Ayons l'honnêteté de reconnaître que l'approche TDD est très coûteuse :
    - Il faut du temps pour écrire les tests (Les devs sont deux fois plus lents)
    - Il faut du temps pour ré-écrire les tests quand le code change (ce qui arrive souvent dans les 6 premiers mois du projet)
    - Même avec un bon taux de couverture, le test reste attaché à une ligne de code, donc lié à l'implémentation, et ne prévient pas un défaut de conception.

  3. #23
    Membre actif Avatar de zaza576
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2013
    Messages
    175
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Août 2013
    Messages : 175
    Points : 275
    Points
    275
    Par défaut
    Citation Envoyé par CyberDenix Voir le message
    Pour les TDD (qui n'ont rien à voir avec Scrum...), je dois confesser un bilan plus que mitigé.
    Ayons l'honnêteté de reconnaître que l'approche TDD est très coûteuse :
    - Il faut du temps pour écrire les tests (Les devs sont deux fois plus lents)
    - Il faut du temps pour ré-écrire les tests quand le code change (ce qui arrive souvent dans les 6 premiers mois du projet)
    - Même avec un bon taux de couverture, le test reste attaché à une ligne de code, donc lié à l'implémentation, et ne prévient pas un défaut de conception.
    Quels seraient les impacts sur un même projet si les tests étaient réalisés à la fin d'un cycle en V plutôt qu'en TDD ?
    C'est bien mitigé mais cela fait des dizaines d'années que dans 2 projets informatiques sur 3, on néglige la véritable et juste valeur des tests dans la réalisation de projet informatique. Par conséquent, les MOE et MOA se mordent la queue en se demandant comment inclure ce temps de travail qu'à l'époque ils négligeaient pour livrer plus rapidement des projets !

    La course contre le temps vous a rattrapé.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    function googleIsYourF*ck*ngFriend(String url, String maQuestion){
        goTo(url);
        reponse = find(maQuestion);
        if(isAcceptable(reponse)){
            clickOn(By.xpath("//button[@id='resolvedButton']"));
        }
        sendMessage("Merci");
    }
    
    googleIsYourF*ck*ingFriend("http://www.google.fr", "ma question");

  4. #24
    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
    Même avec un bon taux de couverture, le test reste attaché à une ligne de code, donc lié à l'implémentation, et ne prévient pas un défaut de conception.
    Pas tout à fait d'accord : si tu utilises des mocks, tes tests peuvent être réellement fait avant ton code, et donc promouvoir une architecture correcte. D'expérience, j'ai déjà eu à écrire des tests unitaires sur du code existant, et l'impossibilité de mocker des objets, donc d'écrire des tests décorrélés de l'environnement, a révélé de graves erreurs de conception. Et à l'inverse, l'écriture préalable des tests a permis d'établir une architecture correcte, et donc de gagner beaucoup de temps par la suite, grâce à la fiabilité du code écrit.
    Par contre, cela nécessite de l'expérience et de la pratique, et cela prend effectivement du temps, donc a un coût.

  5. #25
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

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

    Informations forums :
    Inscription : Juillet 2009
    Messages : 1 030
    Points : 4 203
    Points
    4 203
    Par défaut
    Citation Envoyé par Bono_BX Voir le message
    Pas tout à fait d'accord : si tu utilises des mocks, tes tests peuvent être réellement fait avant ton code, et donc promouvoir une architecture correcte. D'expérience, j'ai déjà eu à écrire des tests unitaires sur du code existant, et l'impossibilité de mocker des objets, donc d'écrire des tests décorrélés de l'environnement, a révélé de graves erreurs de conception. Et à l'inverse, l'écriture préalable des tests a permis d'établir une architecture correcte, et donc de gagner beaucoup de temps par la suite, grâce à la fiabilité du code écrit.
    Par contre, cela nécessite de l'expérience et de la pratique, et cela prend effectivement du temps, donc a un coût.
    C'est clair que si tu mets en place dès le début un module de tests automatisés, mis à jour à chaque évolution, ça va vite, et ça évite les régressions ou effets de bord.
    Mais bon, les décideurs ne voient qu'à court terme, pour contenter leurs actionnaires...

  6. #26
    Modérateur
    Avatar de kolodz
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2008
    Messages
    2 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Avril 2008
    Messages : 2 211
    Points : 8 316
    Points
    8 316
    Billets dans le blog
    52
    Par défaut
    @Hinault Romaric : Voici la vidéo d'origine : http://reaktor.fi/blog/erik-meijer-s...-eating-world/



    Remarque :
    Au-delà de ces remarques, Meijer s’insurge également par rapport au fait que le terme « Agile » a été détourné et est désormais dénué de tout sens. Il a fini sa présentation en citant Dave Thomas, l’un des signataires du manifeste agile : « Le mot ‘Agile’ a été détourné au point ou il est devenu vide de sens. Et ce qui passe pour une communauté agile est devenu une arène pour les consultants et les entreprises qui veulent vendre leurs produits et services »
    Qui finit par :
    Donc, je pense qu'il est temps de mettre à la retraite le mot "Agile"
    Il est dommage de cité les propos des 10 premières minutes d'une présentation de 45 minutes. En particulier quand ceux-ci sont destiné à faire réagir l’audience...

    Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ?
    Il est vrai que beaucoup d'entreprise utilise le mot "Agile" sans même avoir lu une définition. Et applique la nouvelle méthodologie en vogue. Pour eux, cela change juste le nombre de réunion. C'est d'ailleurs ce que l'explique dans l'un de mes billets : [Agile]Le daily meeting et la dérive du "flicage à la journée".
    Donc, si vous voulez mon avis allez lire le billet !

    Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?
    Il fait une critique globale de la structuration de l'entreprise qui ne prends pas en compte les "feedback" de l'environnement. D'ailleurs, Agile n'est pas le sujet principal de sa présentation. Si il y a un thème récurant, c'est "subtle controle". Où le cas de l'Agile n'est que le dernier exemple en date.
    Le propos et ses arguments sont juste. Il n'y a pas de doute. Cependant, l'organisation en couche n'est peut-être pas la seule alternative au défaut qu'il observe et critique dans l'organisation actuel.

    Deux des phrases qu'il cite me semble importante à relever dans le discours général.
    When 9 peoples agrees,it's the tenth man's responsability is to disagree no matter how imporbable the idea.
    L'idée étant que si nous somme tous convaincu d'être dans le vrai. Un jour ou l'autre, on va très probablement aller dans le mur. Aujourd'hui, tout le monde est pro "Agile", il joue donc le rôle de la 10ième personne.

    Context, not Control
    Dire ce qui doit être fait. Ce n'est pas au manager de dire comment.

    La critique du TDD :
    Il critique le TDD par rapport au Chaos Money. Ce qui n'est pas faut si tu es suffisamment confiant pour pousser ton code en production directement et débrancher un serveur pour voir ce qui se passe. Les tests...
    Cependant, l'idée dernier le TDD est aussi de réfléchir à ce qu'on veux comme résultat, indépendamment de l'implémentation. Et cette phase de réflexion

    Agile freine-t-il l’écriture du code ?
    Il est pour un système hiérarchique en couche, ou chaque partie fait son job et ne s'occupe pas de ce que fait la couche du dessus. Comme les hiérarchie religieuse et militaire. Ce qui me semble être un bon point se sa faveur. Si on s'occupait moins de faire des repporting pour les M+42, on ferai plus de chose à notre niveau. Mais encore une fois l'Agile, n'est pas sa cible principale.

    Il me semble que serait plus important de relevé les 3 points de sa conclusions/ouvertures d’horizon:

    • Il y a trop d'amateur dans notre travail. Pourquoi y-a-t-il des livres "Apprendre Java en 24 heures" ? Croirait-on un livre "Apprendre la chirurgie en 24 heures" ?
    • On(Développeur) devrait s'améliorer en communication. (Prendre des douches tout ça...)
    • On(Développeur) devrait avoir plus de valeur pour notre travail et nos outils de travail, ne pas se plaindre que la licence est à 60€, que c'est trop cher. (Un couteau de chef cuisinier étant à 300€...). Car on dévalue notre propre travail.


    Cordialement,
    Patrick Kololdziejczyk.

    PS : Il critique le "ribbon" Office et je suis à 100% avec lui.

    Note : Certains poste avant même d'avoir le temps de se faire un avis sur le sujet, car la présentation/conférence de cette personnes fait 45 minutes. Pas sûr que toutes les personnes soit allez voir la source, donc.
    Donc le premier qui me cite pour faire une critique sur le sujet : Merci de regarder l'ensemble de la vidéo. Et ajoute le mot "banane" dans ton message. (c'est mon check)

    Citation Envoyé par fiftytwo Voir le message
    Est ce que cette methologie est devenue un autre bvuzzword parmi tant dautres dans l' ÍT ? comme ''Big data'' ou ''cloud'' ou ''virtualisation''
    ...

    Ais je tort ?
    Tu n'as pas trot. Mais, ce que je constate, c'est qu'on est de plus en plus à réagir sur le Buzz et non sur le fond.

    Le cas que présente @sebbod comme étant en opposition avec l'avis de Erik Meijer est en réalité en accord avec ce qu'il dit !

    PS²: Réponse simpliste qui est deux fois plus longue que le poste initial...

    Citation Envoyé par Haseo86 Voir le message
    Si sa passion c'est de pisser du code H24, grand bien lui fasse, mais je ne crois pas que ce soit de cette façon qu'on obtienne de bons logiciels.
    La méthode Agile comme n'importe quelle autre a ses défauts, mais je ne comprends pas qu'on puisse reprocher aux développeurs de passer du temps à réfléchir sur leur code et à en discuter. Ca me parait bien mieux que de foncer tête baissée et d'avoir un codeur qui reste dans sa bulle.
    Dommage que tu n'ai pas regardé ou lu ce qu'il explique, car ce n'est pas ce qu'il dit.


    Citation Envoyé par LSMetag Voir le message
    Erik Meijer, c'est le genre de personnes qui pour moi sont un cancer pour une entreprise.

    J'ai vu ce que ça donnait les cycles en V. Plus jamais. A chaque fois, j'y ai vu un manque de respect pour l'utilisateur final des solutions. Car c'est un cadre qui n'est pas dedans qui va décider à sa place.
    ...
    L'agilité est là aussi pour se corriger ou corriger rapidement le tir. Et je ne parle pas que pour les développeurs mais aussi pour les demandeurs, qui parfois aussi se plantent. Et elle n'empêche pas de faire de bonnes spécifications. Elle permet de les modifier rapidement c'est tout. Et après, on vérifie tout et donne (si elle n'y est pas déjà) une cohérence à tout ça.
    Encore une fois, pas ce qu'il dit. D'ailleurs, il est pour la mise en production direct et donc pour les "hotfix". (On ne peux pas corrigé le tire plus rapidement...) C'est pour cela qu'il cite une personne qui dit qu'on ne devrait plus utiliser le mot "Agile". Car pour beaucoup trop, cela ne représente pas, ce que c'est sensé représenter.


    Citation Envoyé par Saverok Voir le message
    Erik Meijer ne critique pas vraiment l'Agile, mais plutôt la façon dont il est mis en place dans la plupart des entreprises et je partage, sur cet aspect, plutôt son avis.
    ...
    16ième message pour voir une personne qui est allée voir la source et se faire son propre avis sur ce qu'il dit !
    Si une réponse vous a été utile pensez à
    Si vous avez eu la réponse à votre question, marquez votre discussion
    Pensez aux FAQs et aux tutoriels et cours.

  7. #27
    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 LSMetag Voir le message
    C'est clair que si tu mets en place dès le début un module de tests automatisés, mis à jour à chaque évolution, ça va vite, et ça évite les régressions ou effets de bord.
    Mais bon, les décideurs ne voient qu'à court terme, pour contenter leurs actionnaires...
    Pas évident de sortir l'argent en anticipant tjrs sur le long terme
    Les clients, et les actionnaires, voient l'instant T et à cet instant, il est possible de réduire le coût du projet de X%
    Tant pis si dans 6 mois, il faudra sortir une rallonge, ça passera sur le budget suivant...

    Une entreprise raisonne beaucoup par trimestre ou année fiscal
    Le coût des projets doit s'inscrire sur cette période

  8. #28
    Membre émérite
    Avatar de fiftytwo
    Homme Profil pro
    DevOps
    Inscrit en
    Novembre 2009
    Messages
    713
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Pologne

    Informations professionnelles :
    Activité : DevOps

    Informations forums :
    Inscription : Novembre 2009
    Messages : 713
    Points : 2 662
    Points
    2 662
    Par défaut
    Citation Envoyé par Bono_BX Voir le message
    Ha non, il faut comparer ce qui est comparable, et ne pas déformer ce que j'ai dis (en plus, je suis un ancien pianiste ).
    jai compris ton propos , je voulais juste dire qu un outil , aussi fantastique soit il , si tu le met entre les mains dun idiot il ne feras pas grand chose de bon

    Citation Envoyé par Bono_BX Voir le message
    Ton analogie est toutefois intéressante : sais-tu que Debussy aimait jouer sur des pianos de différentes qualités, parfois assez délabrés ou non accordés, car cela faisait parti de leurs histoires et leurs donnait un son différent ?
    Tu parles a un mec qui , quand sa mere la emmene au conservatoire , en lui demandant de quel instrument il voudrait apprendre a jouer , a repondu ...... ''je veux etre dj'' !
    "bye bye !" : Antonio Ferrara , 12 mars 2003 - check also my flight's diary and my flight's reports

  9. #29
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

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

    Informations forums :
    Inscription : Juillet 2009
    Messages : 1 030
    Points : 4 203
    Points
    4 203
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Pas évident de sortir l'argent en anticipant tjrs sur le long terme
    Les clients, et les actionnaires, voient l'instant T et à cet instant, il est possible de réduire le coût du projet de X%
    Tant pis si dans 6 mois, il faudra sortir une rallonge, ça passera sur le budget suivant...

    Une entreprise raisonne beaucoup par trimestre ou année fiscal
    Le coût des projets doit s'inscrire sur cette période
    Et oui je sais. Mais je déteste ça. Car au final c'est jamais fait... Non seulement ils payent ensuite doublement (ou triplement) la rallonge (sans parler des utilisateurs finaux, les vraies victimes), mais nous aussi développeurs on la paye (on nous met la pression, des astreintes,...)
    Ben oui, ils fonctionnent comme ça, même sur des applications critiques ayant un impact fort sur des millions de gens !!!

  10. #30
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 690
    Points : 20 211
    Points
    20 211
    Par défaut
    Pour moi le TDD est un réel plus pour éviter les régressions. Je pense que c'est arriver à tout le monde au moins une fois de corriger un bug et finalement par effet de bord d'en créer un autre sans même sans rendre compte.
    Et c'est à ce moment là que les tests unitaires prennent tout leur intérêts.

    Après ça implique que le code soit correctement couvert , autant dire que c'est compliqué quand le but est souvent de travailler vite pour faire le plus de marge possible.

    Perso je pratique ni agile (en tout cas pas selon les "règles") ni le tdd et c'est pas si pire
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  11. #31
    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 grunk Voir le message
    Perso je pratique ni agile (en tout cas pas selon les "règles") ni le tdd et c'est pas si pire
    L'Agile n'améliore pas la qualité des dev
    A vrai dire, ça peut parfois être pire si la proportion de développeurs confirmées n'est pas assez importante dans l'équipe car les travers des jeunes développeurs peuvent facilement être amplifiés par ce type de méthode.
    L'Agile, à mon sens, améliore la satisfaction client
    On code moins de fonctionnalité mais on code des fonctionnalités plus utilisées et mieux utilisées et rien que ça, ça change tout

  12. #32
    Inactif  
    Profil pro
    Inscrit en
    Août 2008
    Messages
    238
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 238
    Points : 620
    Points
    620
    Par défaut
    Je ne suis pas étonné que l'on revienne de toutes ces méthodes "miraculeuses".

    Quand on sait de quoi est fait le manifeste Agile,

    "Les individus et leurs interactions priment sur les processus et les outils.
    Du logiciel qui fonctionne prime sur une documentation exhaustive.
    La collaboration avec les clients plutôt que la négociation contractuelle.
    L’adaptation au changement prime sur le respect des plannings.
    "

    on a tout compris.

    Ces préceptes sont applicables à n'importe quelle industrie.
    Pourtant, ils ne sont pas appliqués depuis la révolution industrielle.
    Ces adeptes ont-ils une explication ? Moi j'en ai quelques unes ...

  13. #33
    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 195
    Points
    5 195
    Par défaut
    Bah c'est un peu toujours le même débat...

    Est-ce que TA méthode est mieux que la mienne... etc..; qui a la plus longue... et s'en sert le mieux ? !!!

    Franchement, moi, les méthodologies, ça le gonfle... mon métier, c'est de faire du logiciel... pas d'appliquer des méthodes en pensant que celà va me
    rendre plus efficace... ma méthode est surement partagé par plein de développeur...

    Pourquoi veux t-on utiliser des méthodes ?

    pour se rassurer en se disant que cette méthode ayant fait ses preuves, on se garantit un meilleur taux de réussite ? Oui, bien sur.. sauf qu'une méthode étant
    appliqué par des humains, le résultat sera toujours différent...

    Développer un logiciel, ce n'est pas fabriquer une Ford T à la chaine...

    On a envoyé des hommes sur la lune sans Agile... ou d'autres méthodes... donc, oui, chaque méthode a surement permis de réussir des choses... mais de croire
    qu'une méthode aurait sauvé un projet, j'ai plus de mal à y croire... donc, de la qualifier de cancer, c'est un peu facile et rapide...


    Un projet marche parce que les gens sont impliqués, motivés, à leur place et bien managés...

    et si une méthode quelconque peut aider, elle ne rattrapera pas un manque d'implication, de motivation et un mauvais management.
    The Monz, Toulouse
    Expertise dans la logistique et le développement pour
    plateforme .Net (Windows, Windows CE, Android)

  14. #34
    Membre du Club
    Homme Profil pro
    Ingenieur BI
    Inscrit en
    Avril 2013
    Messages
    61
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Maroc

    Informations professionnelles :
    Activité : Ingenieur BI
    Secteur : Finance

    Informations forums :
    Inscription : Avril 2013
    Messages : 61
    Points : 64
    Points
    64
    Par défaut
    je rejoins ce qu a dit Erik , la méthode agile actuelle est loin de l'application de l'agilité dans une entreprise , elle est devenue un moyen de contrôle de l'activité et des collaborateur plus qu'un moyen de suivi de la qualité des développements effectuer pour mener à bien la mise en œuvre du produit!!

  15. #35
    Membre confirmé

    Homme Profil pro
    Mâle reproducteur chez Amazon
    Inscrit en
    Mars 2006
    Messages
    207
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Mâle reproducteur chez Amazon

    Informations forums :
    Inscription : Mars 2006
    Messages : 207
    Points : 490
    Points
    490
    Par défaut
    Citation Envoyé par Haseo86 Voir le message
    Si sa passion c'est de pisser du code H24, grand bien lui fasse, mais je ne crois pas que ce soit de cette façon qu'on obtienne de bons logiciels.
    La méthode Agile comme n'importe quelle autre a ses défauts, mais je ne comprends pas qu'on puisse reprocher aux développeurs de passer du temps à réfléchir sur leur code et à en discuter. Ca me parait bien mieux que de foncer tête baissée et d'avoir un codeur qui reste dans sa bulle.

    Maintenant je le rejoins un peu sur les TDD, je ne comprends pas cette méthode de travail.
    Tout à fait d'accord. Dans les années 80, un dev pouvait se lancer dans le guidon dans son code. Ca marchait. Mais bon, il n'y avait pas autant de code, pas autant de personnes sur le projet (en général, il était seul). Mais ça, c'était just like old times. Comme lorsqu'on se fait un petit script. Pas besoin de SCRUM, ni de rien d'autre. Just code.
    Mais quand on est sur un gros projet de 100 personnes, vous imaginez si tout le monde part dans tous les sens? Ce serait un sacré bor... Et je donne peu de chance au projet. J'ai même connu une boîte qui a coulé à cause de ça.
    Pour vivre heureux, vivons cachés. Proverbe alien.

  16. #36
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

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

    Informations forums :
    Inscription : Juillet 2009
    Messages : 1 030
    Points : 4 203
    Points
    4 203
    Par défaut
    Citation Envoyé par theMonz31 Voir le message
    Bah c'est un peu toujours le même débat...

    Est-ce que TA méthode est mieux que la mienne... etc..; qui a la plus longue... et s'en sert le mieux ? !!!

    Franchement, moi, les méthodologies, ça le gonfle... mon métier, c'est de faire du logiciel... pas d'appliquer des méthodes en pensant que celà va me
    rendre plus efficace... ma méthode est surement partagé par plein de développeur...

    Pourquoi veux t-on utiliser des méthodes ?

    pour se rassurer en se disant que cette méthode ayant fait ses preuves, on se garantit un meilleur taux de réussite ? Oui, bien sur.. sauf qu'une méthode étant
    appliqué par des humains, le résultat sera toujours différent...

    Développer un logiciel, ce n'est pas fabriquer une Ford T à la chaine...

    On a envoyé des hommes sur la lune sans Agile... ou d'autres méthodes... donc, oui, chaque méthode a surement permis de réussir des choses... mais de croire
    qu'une méthode aurait sauvé un projet, j'ai plus de mal à y croire... donc, de la qualifier de cancer, c'est un peu facile et rapide...


    Un projet marche parce que les gens sont impliqués, motivés, à leur place et bien managés...

    et si une méthode quelconque peut aider, elle ne rattrapera pas un manque d'implication, de motivation et un mauvais management.
    En fait je ne cherche pas non plus à appliquer une méthode particulière. J'applique juste MA méthode. Recueillir les besoins auprès du demandeur, écrire une spec technique et fonctionnelle, la faire valider pour un plus haut gradé que moi si le projet est important, développer tout en demandant des précisions ou en prenant en compte les remarques des demandeurs, tout en anticipants d'éventuels besoins, tester, exposer et rédiger une documentation. Et il s'est révélé que c'était une version personnelle de l'Agile. Par contre, ce qui est sûr, c'est que je HAIS le cycle en V !

  17. #37
    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 theMonz31 Voir le message
    Pourquoi veux t-on utiliser des méthodes ?

    pour se rassurer en se disant que cette méthode ayant fait ses preuves, on se garantit un meilleur taux de réussite ? Oui, bien sur.. sauf qu'une méthode étant
    appliqué par des humains, le résultat sera toujours différent...

    Développer un logiciel, ce n'est pas fabriquer une Ford T à la chaine...

    On a envoyé des hommes sur la lune sans Agile... ou d'autres méthodes... donc, oui, chaque méthode a surement permis de réussir des choses... mais de croire
    qu'une méthode aurait sauvé un projet, j'ai plus de mal à y croire... donc, de la qualifier de cancer, c'est un peu facile et rapide...


    Un projet marche parce que les gens sont impliqués, motivés, à leur place et bien managés...

    et si une méthode quelconque peut aider, elle ne rattrapera pas un manque d'implication, de motivation et un mauvais management.
    Comment coordonnes-tu une équipe ? Surtout lorsqu'elle a une taille importante ?
    Comment suis-tu un planning ?
    Comment suis-tu un périmètre ?
    Comment suis-tu l'avancement du projet ?
    Comment suis-tu le budget ?
    Comment manages-tu une équipe ?
    Comment coordonnes-tu plusieurs équipes alors qu'elles interviennent à des phases différentes du projet ?
    ...
    Tout cela se fait par une méthode.
    Une méthode qui doit être partagées par tous les acteurs du projet.
    C'est la seule façon de faire.

    Ensuite, chaque corps de métier à ses méthodes spécifiques (BTP, Industrie, Informatique, Hôtellerie, etc.)

    Je peux comprendre que les lourdeurs administratives qui accompagnent la plupart des méthodologies puissent être contraignantes pour les développeurs (et il en est de même pour les CP, faut pas croire que c'est e pieds de faire des Excel toute la journée) mais cela est indispensable à la bonne marche d'un projet.
    Sans cela, tout le monde ferai ce qu'il voudrait quand il le voudrait et ça serait le bordel avec une fuite du budget et une qualité désastreuse.

    On peut se permettre de se passer de méthodologie lorsque l'on est seul ou très peu nombreux (moins de 5) car le bon sens et l'expérience permettent de s'en sortir (et encore, les analyses sociologiques montrent qu'une organisation implicite se met tout de même en place ce qui est une forme de méthodo).

    Bref, tout ça pour dire que l'application d'une méthodologie est indispensable à la bonne marche d'un projet.
    Après, ces débats sur "quelle est la meilleure" sont stupides.
    Chaque méthodo a ses défauts et ses qualités et tous l'art de la gestion de projet et de savoir choisir quelle méthode choisir en fonction du projet et de ses acteurs (et parfois même en fonction des domaines du projet car la méthodes principale n'y est pas forcément pertinente : par exemple, l'Agile n'apporte absolument rien lors des spécifications et développements des flux)

  18. #38
    Membre expérimenté
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2003
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

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

    Informations forums :
    Inscription : Septembre 2003
    Messages : 1 047
    Points : 1 640
    Points
    1 640
    Par défaut
    Juste une précision : La méthode agile n'existe pas, il existe par contre des méthodes agiles (Scrum, XP, Crystal, DSDM, …).

    Pour répondre au sujet, je conseille la lecture de ces livres :
    • Succeeding with Agile: Software Development Using Scrum (de Mike Cohn, dont je conseille la lecture des bouquins et du blog)
    • The Software Craftsman de Sandro Mancuso
    • TDD by example de Kent Beck


    Dans notre métier, il ne faut pas oublier que la formation est primordiale est qu'elle est avant tout de notre ressort.
    En premier lieu, utilisez un moteur de recherche.
    En second lieu, postez sur le forum adéquat !

  19. #39
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    Août 2011
    Messages
    342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Août 2011
    Messages : 342
    Points : 1 091
    Points
    1 091
    Par défaut
    Citation Envoyé par Patriarch24 Voir le message
    Juste une précision : La méthode agile n'existe pas, il existe par contre des méthodes agiles (Scrum, XP, Crystal, DSDM, …).

    Pour répondre au sujet, je conseille la lecture de ces livres :
    • Succeeding with Agile: Software Development Using Scrum (de Mike Cohn, dont je conseille la lecture des bouquins et du blog)
    • The Software Craftsman de Sandro Mancuso
    • TDD by example de Kent Beck


    Dans notre métier, il ne faut pas oublier que la formation est primordiale est qu'elle est avant tout de notre ressort.
    Y'aurait beaucoup à dire sur ta dernière phrase... La formation professionnelle du ressort de l'employé, ce sont les patrons qui vont être contents

  20. #40
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Citation Envoyé par Hinault Romaric Voir le message

    Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ?

    Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?
    C'est exactement ce qu'il dit, il y a eu trop de cabinet de consulting qui ont vu là un filon pour vendre du service dans une industrie grandissante. Ca a donné un important matraquage sur les bienfaits des méthodes agiles, qui peuvent tout à fait être intéressants. Et aussi le sentiment qu'il existait des formules magiques à appliquer à la lettre pour réussir n'importe quel projet dans n'importe quel environnement. Gangsoleil l'a très bien dit au début du topic, il y a tout un existant à prendre en compte.

    Perso nous avons essayé dans ma boîte d'en retirer les grandes lignes, notamment l'implication du client final. Mais ce dernier point est resté très difficile à appliquer, d'autant plus encore qu'un développement "trop" agile est parfois bien difficile quand il s'agit de gérer un budget et un planning.

Discussions similaires

  1. « Agile est un cancer », pour Erik Meijer
    Par Hinault Romaric dans le forum Actualités
    Réponses: 84
    Dernier message: 27/01/2015, 11h47
  2. Le JPanel est trop reduit pour mon interface !
    Par LeNeutrino dans le forum JBuilder
    Réponses: 4
    Dernier message: 25/07/2005, 19h58
  3. [Info] Eclipse est-il gratuit pour développer une application ?
    Par kaishef dans le forum Eclipse Platform
    Réponses: 2
    Dernier message: 12/04/2005, 12h04
  4. apprentissage du C est-il necessaire pour C++ ?
    Par Anonymous dans le forum C
    Réponses: 6
    Dernier message: 02/05/2002, 13h56

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