+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 7 12345 ... DernièreDernière
  1. #1
    Responsable .NET

    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2007
    Messages
    4 524
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 4 524
    Points : 250 797
    Points
    250 797
    Billets dans le blog
    65

    Par défaut « Agile est un cancer », pour Erik Meijer

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


    Erik Meijer, un développeur célèbre de l’écosystème .NET, qui s’est notamment fait remarquer par la création de LINQ et ses travaux sur le langage C#, Visual Basic, Volta et le framework Reactive Extensions (Rx), a fait des déclarations acerbes contre Agile, lors d’un événement.

    Les méthodes agiles sont de plus en plus adoptées par les équipes de développeurs. Elles se positionnent comme une meilleure alternative au cycle de développement en cascade, qui ne répond plus aux exigences des organisations qui évoluent rapidement. Elles sont donc considérées comme une recette pour accélérer le processus de développement, tout en réduisant le taux de bogues dans les applications.

    Les méthodes agiles sont unies par le Manifeste agile qui doit son succès à la description de 4 valeurs essentielles, facilement compréhensibles pour les développeurs, à savoir :


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


    Cependant, l’agilité ne fait pas l’unanimité auprès des développeurs. Lors d’une conférence en Finlande, Erik Meijer a eu des propos très durs envers Agile. « Agile est un cancer que nous devons éliminer de l’industrie », a déclaré celui-ci.

    Meijer critique surtout le fait que l’application de l’agilité dans des projets fait « beaucoup plus parler sur le code, que d’écrire le code ». Erik Meijer s’en prend particulièrement à la méthode Scrum, qui entraine des « interruptions inutiles ».

    Selon celui-ci, les « Scrum Meeting » sont des interruptions ennuyeuses, au mieux des mécanismes de contrôle subtil utilisés par les gestionnaires pour conduire une équipe, en donnant l’illusion d’un leadership partagé. « Nous devons cesser Scrum et Agile. Nous sommes des développeurs. Nous devons écrire du code », a affirmé Meijer.


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

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

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

    Sur ce point, il a été rejoint par un autre conférencier. Nic Ferrier architecte dans une entreprise de développement qui utilise Agile, a affirmé qu’Agile est en partie victime de son succès. Selon lui, lorsque les méthodes agiles ont conduit aux premiers bons résultats, les entreprises ont commencé à développer des outils qui prennent en charge ces méthodes. Dès lors, elles ont commencé à véhiculer l’idée qu’Agile est un outil que l’on peut acheter.

    Un avis d’ Erik Meijer, certes tranché, mais qui reflète la frustration d’un passionné du code, qui souhaite par-dessus tout consacrer son temps à sa passion : écrire du code.


    Source


    Et vous ?

    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 ?

    Agile freine-t-il l’écriture du code ?
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

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

    Informations professionnelles :
    Activité : Developpeur

    Informations forums :
    Inscription : septembre 2013
    Messages : 213
    Points : 506
    Points
    506

    Par défaut

    Je comprends sa réaction. Je me demande aussi s'il existe des études qui relèvent les méthodes agiles utilisées en entreprise et qui mesurent le taux de satisfaction client après la réalisation du produit ? Histoire de comparer ce qui se dit Agile, ce qui l'est en pratique et les résultats derrière.

  3. #3
    Membre chevronné
    Avatar de fiftytwo
    Homme Profil pro
    Consultant ITSM
    Inscrit en
    novembre 2009
    Messages
    608
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Pologne

    Informations professionnelles :
    Activité : Consultant ITSM

    Informations forums :
    Inscription : novembre 2009
    Messages : 608
    Points : 2 225
    Points
    2 225

    Par défaut

    Ce sujet tombe bien car je me demande de plus en plus quelque chose a propos d' Agile.

    Est ce que cette methologie est devenue un autre bvuzzword parmi tant dautres dans l' ÍT ? comme ''Big data'' ou ''cloud'' ou ''virtualisation''

    Je ne parle pas de ses bons / mauvais cotes , mais plus du fait que beaucoup de boites disent adopter et suivre ces methologies , mais en fait , connaissant la culture de certaines entreprises , je vois deja ce que cela donne avec les frameworks comme ITIL , Prince 2 ou Cobit dans la realite ou les bouquins , certaines boitent appliquent de maniere efficace tandis que dautres , en manque de perormances , recuperent un truc dont un font une grosse blague qui y ressemble vaguement , avec plein de gens pour se donner des titres pompeux alors quils ne font pas 1/3 du travail qui devrait etre fait.

    Je me dis que beaucoup dequipes ne font que suivre ce que le manager a decide et qui souvent seloigne dagile et le travail final nen est pas plus qualitatif.

    Car


    Ais je tort ?
    "bye bye !" : Antonio Ferrara , 12 mars 2003 - check also my flight's diary and my flight's reports

  4. #4
    Membre actif Avatar de zaza576
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2013
    Messages
    156
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    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 : 156
    Points : 257
    Points
    257

    Par défaut

    Il faut voir aussi de quelle manière les scrum masters de ces Mossieurs de "Microfault" gère l'Agile dans leur société.

    D'une société à une autre, tout est différent. Partant des mêmes méthodes, méthodologies, outils, logiciels, ..., nous aurons deux résultats différents pour deux entreprises identiques. Savez-vous pourquoi ? Le facteur "humain" est ce qui fait varier le plus les choses.

    Je considère qu'il est important de faire un minimum de réunion pour suivre l'évolution au jour le jour des tâches, user story, projets, produits...
    Oui, il s'agit d'un leadership partagé dans l'équipe. Mais un leadership responsable qui suit son projet comme l'évolution et l'éducation de ses enfants. De manière responsable, engagée, avec amour et investissement.

    Il faut arrêter de critiquer les méthodologies parce que les résultats ne sont pas là. Je trouve cela idiot de dire "on fait un produit" et seulement en phase de préproduction "on le teste ?!". Non ! Pour ma part, le TDD intervient pour réduire drastiquement les coûts liés à la correction de bugs.
    Doit-on prévenir le mal en l'anticipant dès le départ, ou en l'ignorant jusqu'au dernier moment ?

    Cela ne m'étonne pas que des échecs internationaux comme Vista et 8.1 on vu le jour s'ils ne testent qu'à la toute fin. S'ils avaient employé Agile de manière responsable et adaptée (d'où le nom Agile), ils auraient eu toute la souplesse de voir arriver que Vista était un Windows 98 de 7 Go lourd, moche et buggé ou même que l'interface Métro était un changement trop bouleversant pour une communauté de consommateurs habitué au bon vieux desktop.

    Touche ironique pour terminer : "Laissons le soin aux consommateurs de tester notre application pour que les bugs remontent à nous ...". Oui, et la marmotte, elle met le chocolat dans le papier d'alu. Voilà pourquoi cela fait bien longtemps que je ne paie plus de licence pour des produits de ce genre. C'est fou que des entreprises se gangrenent par la flemmardise de corriger leurs bugs. Un commentaire de consommateur coûte-t'il moins cher qu'un fix anticipé pour un bug découvert en production et qui coûterait 1 M€ ?
    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");

  5. #5
    Membre chevronné

    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 063
    Points
    2 063

    Par défaut

    Les méthodes agiles, pratiquées sérieusement et honnêtement, ça peut sans doute donner des bons résultats. Cela dit, je ne saurais être vraiment affirmatif : dans toutes les boites que j'ai pu voir où on prétendait faire de l'agile, ce n'était qu'un prétexte pour ne pas faire de specs, pour permettre à la maitrise d'ouvrage de changer constamment d'avis ("embrasser le changement", ok, mais en principe, c'est que le besoin a réellement changé, pas simplement que le client n'est pas foutu de savoir ce qu'il veut !), ne pas documenter le code, coder à l'arrache (KISS mal compris), etc.

    Le problème de fond, c'est que les principes agiles mal compris permettent de justifier énormément de mauvaises pratiques ancestrales du monde informatique. Et ils ne s'en privent pas !

  6. #6
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2008
    Messages
    433
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : FrancesƆ

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 433
    Points : 1 305
    Points
    1 305

    Par défaut

    A chaque méthode ses défauts.

    Personnellement j'ai rencontré plus de soucis avec les méthodes non Agiles en industrie, ou on ne corrigeait pas les bugs/lenteur non bloquant simples avant des mois.

    Cela donnait des utilisateurs mécontent.

    en gros ces histoires sont souvent liée au process ( Parfois une application non critique utilise les mêmes process de dev qu'une application vitale).

    Il ne faut pas qu'un process lourd nuise à la qualité et la réactivité d'un SI.

    De plus limiter le turn-over permet d'avoir des développeurs qui connaissent mieux leur contexte métier et l'entreprise, cela limite drastiquement les impacts, mais c'est sur en embauchant plus 70% de dev "jetables" c'est pas facile...


    De plus Microsoft qui sort une beta de Visual Studio toute les 3 semaines doit surement utiliser beaucoup les méthodes agiles, et VS est plutôt bon.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 812
    Points : 20 423
    Points
    20 423

    Par défaut

    Le problème, c'est que "Agile" est une manière de penser, pas une méthode.

    Les gens qui n'ont pas cette manière de penser et qui appliquent la méthode, fatalement, ont de mauvais résultats.

    Un autre cas peut être destructeur : certains dans la structure sont agiles, tandis que d'autres sont restés à l'ancienne méthode. Résultat, tout le monde doit se plier à l'agile sans être prêt, et on casse tous les projets(vécu).
    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.

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

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 232
    Points : 479
    Points
    479

    Par défaut

    Ce sujet tombe bien car je me demande de plus en plus quelque chose a propos d' Agile.

    Est ce que cette methologie est devenue un autre bvuzzword parmi tant dautres dans l' ÍT ? comme ''Big data'' ou ''cloud'' ou ''virtualisation''
    Tu as malheureusement parfaitement raison. L'Agile est devenu un argument de vente, aussi bien en BTC qu'en BTB. Les SSII vendant des services Agile ne se compte plus, et j'ai pu voir en interne un chef d'équipe (particulièrement mauvais) faire passer l'échec de son projet sur le dos de la méthode de développement et ... TADA ! On passe en Agile et vous allez voir ce que vous allez voir ! (le projet fut bien évidemment un échec complet)

    Mon avis personnel sur l'Agile est que cette méthode est une amélioration, une grosse amélioration, mais qu'une amélioration : si l'on a une équipe de bras cassés ou de personnes non formées ou peu impliquées, le projet sera un échec quelque soit la méthode employée.

    @zaza576 : ton post est très intéressant, je me permets d'y répondre point par point.

    Il faut voir aussi de quelle manière les scrum masters de ces Mossieurs de "Microfault" gère l'Agile dans leur société.
    A priori, je dirais par mal vu qu'ils doivent utiliser TFS qui est un excellent produit !

    D'une société à une autre, tout est différent. Partant des mêmes méthodes, méthodologies, outils, logiciels, ..., nous aurons deux résultats différents pour deux entreprises identiques. Savez-vous pourquoi ? Le facteur "humain" est ce qui fait varier le plus les choses.

    Je considère qu'il est important de faire un minimum de réunion pour suivre l'évolution au jour le jour des tâches, user story, projets, produits...
    Oui, il s'agit d'un leadership partagé dans l'équipe. Mais un leadership responsable qui suit son projet comme l'évolution et l'éducation de ses enfants. De manière responsable, engagée, avec amour et investissement.
    100% d'accord !

    Il faut arrêter de critiquer les méthodologies parce que les résultats ne sont pas là. Je trouve cela idiot de dire "on fait un produit" et seulement en phase de préproduction "on le teste ?!". Non ! Pour ma part, le TDD intervient pour réduire drastiquement les coûts liés à la correction de bugs.
    Doit-on prévenir le mal en l'anticipant dès le départ, ou en l'ignorant jusqu'au dernier moment ?
    Encore une fois, 100% d'accord. Le seul bémol, c'est qu'il faut faire comprendre ça à des gestionnaires / comptables / chefs de projet non techniques (genre parachuté / j'ai-vu-de-la-lumière-je-suis-rentré). Et là, c'est dans les faits quasi-impossible

    Cela ne m'étonne pas que des échecs internationaux comme Vista et 8.1 on vu le jour s'ils ne testent qu'à la toute fin. S'ils avaient employé Agile de manière responsable et adaptée (d'où le nom Agile), ils auraient eu toute la souplesse de voir arriver que Vista était un Windows 98 de 7 Go lourd, moche et buggé ou même que l'interface Métro était un changement trop bouleversant pour une communauté de consommateurs habitué au bon vieux desktop.
    Autant je suis d'accord pour Vista, autant tu exagères pour 8.1 et Metro. Là, c'est plus une mauvaise orientation commerciale qui croyait trop au tout tactile (trop en avance sur son temps ?). De plus, Windows Phone 8.1 est une vraie réussite.

    Pour ton dernier paragraphe, voir mon commentaire précédent sur les gestionnaires !

  9. #9
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2006
    Messages
    55
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : février 2006
    Messages : 55
    Points : 150
    Points
    150

    Par défaut La méthodes à Gilles est à tout le monde ;-)

    Cette méthode aide énormément et je trouve que l'on devrait l'adopter à partir du moment où l'on fait du développement en équipe (plus de 1 développeur).

    -J'ai un PO qui rédige des US parfaite (Mais au début ça n'était pas le cas, nous avons corriger le tir pour obtenir du PO ce que nous avions besoins pour développer c'est ça aussi la méthode AGILE, ce remettre en question)

    -J'ai un SM qui sait ce faire oublier mais qui est là quand on a une question. On est un peu tous SM (Scrum Master je précise parce que je lis dans tes penses gros dégoutant) finalement dans l'équipe

    -Le daily scrum du matin c'est bien mangés en ;-) franchement discuter tous les matins 2 minutes/personne des problèmes de la veille et des choses à faire dans la journée, je trouve qu'on gagne en clarté, en efficacité et sa force la cohésion d'équipe et l’entraide car si y'en a un qui galère sur un truc les autres sont force de proposition pour l'aider à trouver des solutions ou on peut aussi faire du "Pair programming" ce qui une fois de temps en temps ne fait pas de mal et permet de débloquer certaine situation ou/et aussi de former une nouvelle personne.

    Bref j'ai développé pendant 10 ans tout seul et j'aimais ça.
    Et maintenant ça fait 3 ans que je suis dans l'équipe à Gilles ;-)
    Etant plutôt solitaire de nature je préfère développer en solo mais la vie ne nous laisse pas toujours le choix et finalement j'ai appris à aimer la méthode AGILE.

    Donc merci à lui

  10. #10
    Membre éclairé
    Ingénieur de recherche
    Inscrit en
    novembre 2008
    Messages
    225
    Détails du profil
    Informations professionnelles :
    Activité : Ingénieur de recherche

    Informations forums :
    Inscription : novembre 2008
    Messages : 225
    Points : 807
    Points
    807

    Par défaut

    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.

  11. #11
    Membre expert

    Homme Profil pro
    Ingénieur Etudes et Développements Junior
    Inscrit en
    juillet 2009
    Messages
    965
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Etudes et Développements Junior
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 965
    Points : 3 844
    Points
    3 844

    Par défaut

    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.

    Au moins, dans l'agile, dès qu'on voit un bug, on le corrige. Dès qu'on a une question ou une remarque, on appelle la personne concernée, plutôt que de passer par 3 intermédiaires pour qu'au final la question se perde.

    Le matin, on prend 5/10 minutes pour discuter avec le chef de projet pour indiquer où l'on en est, ce qu'on a fait, et parler de l'ordre du jour. Autrement c'est quoi ? Des chiffres dans un logiciel de BugTracking, des indicateurs abstraits ?

    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.

    Evidemment comme dit plus haut, "Agile" ne fait pas tout. Il faut que le personnel ait le concept "agile" dans la peau, qu'il soit impliqué dans ses projets, qu'il s'entende,... On peut se planter tout autant en "Agile" qu'autrement si l'équipe, et surtout son Chef, est mauvaise.

    Bref, je m'arrête là, mais tout ce que j'ai fait en agile et forfaitaire a toujours beaucoup mieux fonctionné que les fameux trucs contractuel et figés. Je me suis d'ailleurs fait virer à cause d'une grosse baisse de charge due à des contractuels qui avaient mal anticipé la charge et les demandes...
    Si on avait été en agile, on aurait au moins pu continuer à corriger des bugs, ajouter des fonctionnalités souhaitées par les utilisateurs au lieu d'attendre les ordres venant d'en haut (et qui ne sont pas venus...)

    Peut-être qu'avec une méthode agile appliquée de façon efficace, on aurait pu éviter le bug de l'an 2000. Je suis sûr qu'il a dû être signalé dans plusieurs entreprises, dont les décideurs n'ont pas tenu compte...

  12. #12
    Modérateur
    Avatar de gangsoleil
    Profil pro
    R&D en systemes informatiques bas niveau Unix/Linux
    Inscrit en
    mai 2004
    Messages
    9 315
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : R&D en systemes informatiques bas niveau Unix/Linux

    Informations forums :
    Inscription : mai 2004
    Messages : 9 315
    Points : 26 753
    Points
    26 753

    Par défaut

    Citation Envoyé par sebbod Voir le message
    Bref j'ai développé pendant 10 ans tout seul et j'aimais ça.
    Et maintenant ça fait 3 ans que je suis dans l'équipe à Gilles ;-)
    Donc si je comprends bien, en terme de méthodologie de développement en équipe, tu ne connais que Agile, tu n'as jamais vraiment pratiqué d'autre méthode de développement ? Si c'est le cas, tu peux effectivement donner ton retour d'expérience sur Agile, mais tu ne peux pas dire que c'est mieux, ou moins bien, qu'autre chose.

    Pour ma part, j'ai connu une équipe avec un vrai bon chef, technique, qui a construit son équipe en choisissant les membres, et qui arrivait à vraiment en tirer parti, sans avoir besoin d'Agile.
    Et j'ai aussi connu des équipes avec méthodologie mal ou pas appliquées, et dans ce cas ça vire toujours au n'importe quoi.

    Mais à l'inverse de toi, je n'ai pas encore fait d'Agile, mais ça ne saurait tarder, donc je verrai bien ce que ça va donner. En tout cas, il est certain que c'est un argument commercial -- et si en plus l'entreprise du Big Data dans le cloud, tu as le tiercé gagnant dans l'ordre, et les commerciaux sont aux anges.
    Modérateur "C", "Informatique Générale & Hardware" et "Unix"
    Les règles du forum

  13. #13
    Membre régulier
    Inscrit en
    mars 2006
    Messages
    121
    Détails du profil
    Informations forums :
    Inscription : mars 2006
    Messages : 121
    Points : 107
    Points
    107

    Par défaut

    Je comprends plus ou moins les frustrations du mec.

    Je pense que cette situation est similaire à celle où, on est entrain d'utiliser un outil/framework de dév, et que lorsqu'on rencontre des problèmes avec, on commence à le critiquer.

    Parfois c'est pas l'outil qui fait défaut, mais notre façon d'intégrer et utiliser le truc qui nous fait souffrir.

    Dans le cas de Agile, effectivement je pense qu'on lui attribut des descriptifs, des rôles, des responsabilités, des capacités et des pouvoirs qu'elle n'est/n'a/ pas/jamais.

    Pour moi Agile n'est pas une méthodologie, n'est pas un standard, n'est pas un outil. Agile c'est un esprit/attitude/framework organisationnel, propre à chaque projet, et à chaque entreprise. par nature elle n'est pas standarisable car pas toujours forcément liée à des indicateurs ou données mesurables. C'est propre au contexte.

    Un acteur peut paraitre ridicule si on lui demande de jouer un rôle qui n'est pas le sien. C'est le cas de Agile.

  14. #14
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2006
    Messages
    55
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : février 2006
    Messages : 55
    Points : 150
    Points
    150

    Par défaut

    Citation Envoyé par gangsoleil Voir le message
    Donc si je comprends bien, en terme de méthodologie de développement en équipe, tu ne connais que Agile, tu n'as jamais vraiment pratiqué d'autre méthode de développement ? Si c'est le cas, tu peux effectivement donner ton retour d'expérience sur Agile, mais tu ne peux pas dire que c'est mieux, ou moins bien, qu'autre chose.
    c'est effectivement le cas c'est pour cela que je ne fait qu'un retour d'expérience.

    mais j'essaye d'appliquer la méthode AGILE à la maison pour parler au moins une fois par jour de ce qui va et de ce qui ne va pas avec ma compagne ce qui me fait 2 expériences avec la même méthode

  15. #15
    Membre expert

    Homme Profil pro
    Ingénieur Etudes et Développements Junior
    Inscrit en
    juillet 2009
    Messages
    965
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Etudes et Développements Junior
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 965
    Points : 3 844
    Points
    3 844

    Par défaut

    Citation Envoyé par santana2006 Voir le message
    Un acteur peut paraitre ridicule si on lui demande de jouer un rôle qui n'est pas le sien. C'est le cas de Agile.
    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.

    Quand on est "Ingénieur Etude et Developpement" à BAC + 5, je trouve très réducteur d'être réduit à l'état d'ouvrier qui pisse du code H24 comme dit précédemment. Et ça me plaît beaucoup de discuter avec les utilisateurs en live, pour m'adapter à leurs besoin, les satisfaire, ou leur faire part d'un besoin qu'ils n'ont pas anticipé.

    On travaille sur un forfait. C'est à dire qu'on a des délais malgré tout !

    Si on est passionné par son travail, tout le monde est gagnant. Le client paye une somme pour avoir le meilleur possible par rapport à sa demande, le "développeur" se sent plus concerné car il peut participer et moins frustré parce qu'il a le droit de corriger des bugs avant la prochaine version qui sera dans 2 ans, ou signaler des pb de specs.

  16. #16
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    1 754
    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 : 1 754
    Points : 7 010
    Points
    7 010

    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 ?
    Oui, c'est devenu un terme marketing galvaudé.
    Par contre, ce n'est pas l'Agile qu'il faut critiqué pour cela, c'est les entreprises.
    Sur ce coup Erik Meijer se trompe de cible.

    Citation Envoyé par Hinault Romaric Voir le message
    Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?
    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.
    Par contre, je suis en total désaccord avec son expression "écrire du code"
    Le job d'un développeur est bien plus que cela
    Je dirai plutôt que je job d'un développeur est de concevoir et développer des fonctionnalités
    Cela est bien plus large que se limiter à la phase de réalisation (l'écriture du code)
    Les phases d'analyse et de conception sont ultra importantes et ne doivent pas être négligées

    De plus, je ne partage pas du tout son point de vue sur les réunions d'équipe
    Je trouve que c'est un point essentiel et il est important qu'une équipe se parle et se coordonne d'autant plus que ça peut créer une ambiance conviviale qui est bien plus agréable pour travailler.

    Citation Envoyé par Hinault Romaric Voir le message
    Agile freine-t-il l’écriture du code ?
    Pas du tout
    On écrit aussi vite que par les autres méthodes
    Par contre, on écrit moins car on se pose plus la question du quoi et pourquoi
    Je ne trouve pas que ce soit mal car on développe l'essentiel, le réellement utile

    Partir bille en tête pour développer des dizaines et des dizaines de fonctionnalités pour qu'au final, seule une poignet sera utilisée, c'est déprimant et c'est du temps perdu pour rien
    Autant concentrer les efforts sur le réellement utile pour l'utilisateur final.

  17. #17
    Modérateur
    Avatar de gangsoleil
    Profil pro
    R&D en systemes informatiques bas niveau Unix/Linux
    Inscrit en
    mai 2004
    Messages
    9 315
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : R&D en systemes informatiques bas niveau Unix/Linux

    Informations forums :
    Inscription : mai 2004
    Messages : 9 315
    Points : 26 753
    Points
    26 753

    Par défaut

    Citation Envoyé par santana2006 Voir le message
    Pour moi Agile n'est pas une méthodologie, n'est pas un standard, n'est pas un outil. Agile c'est un esprit/attitude/framework organisationnel, propre à chaque projet, et à chaque entreprise. par nature elle n'est pas standarisable car pas toujours forcément liée à des indicateurs ou données mesurables. C'est propre au contexte.
    Le problème aujourd'hui, c'est que beaucoup d'entreprises veulent appliquer une méthode Agile comme on exécute une recette de gateau : on reproduit point par point ce qui a été fait à côté, avec un coach Agile bien sur, et hop, ça fait des chocapics (ou de la choucroute si on préfère).

    Je ne vois que peu d'entreprises qui cherchent à voir quelle méthode appliquer (Scrum, XP, autre, peu importe), quelles sont leurs limites, pourquoi elles iront bien ou non, comment les équipes vont réagir, est-ce que ça s'applique à eux, ...

    Prends une équipe dans laquelle il y a beaucoup de caractères forts et indépendants, et essaye d'imposer XP avec le codage à deux : il y a de fortes chances pour que ça passe mal, chacun voulant tirer la couverture à soi. De même, les réunions de 10 minutes le matin lorsque tu as des gens qui arrivent à 7h et d'autre à 10h, ce n'est pas forcément super productif...

    Or c'est bien ce qui se passe dans la plupart des entreprises que j'ai vu.
    Modérateur "C", "Informatique Générale & Hardware" et "Unix"
    Les règles du forum

  18. #18
    Membre chevronné
    Avatar de fiftytwo
    Homme Profil pro
    Consultant ITSM
    Inscrit en
    novembre 2009
    Messages
    608
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Pologne

    Informations professionnelles :
    Activité : Consultant ITSM

    Informations forums :
    Inscription : novembre 2009
    Messages : 608
    Points : 2 225
    Points
    2 225

    Par défaut

    Citation Envoyé par sebbod Voir le message
    mais j'essaye d'appliquer la méthode AGILE à la maison pour parler au moins une fois par jour de ce qui va et de ce qui ne va pas avec ma compagne ce qui me fait 2 expériences avec la même méthode
    Et quand tu as oublie de faire la vaisselle , vider les poubelles ou sortir le chien tu fais un sprint ??

    Citation Envoyé par Bono_BX Voir le message
    chefs de projet non techniques (genre parachuté / j'ai-vu-de-la-lumière-je-suis-rentré). Et là, c'est dans les faits quasi-impossible
    La ou je suis jpasse jen ai vu plein des comme ca , manager , TL , ou CDP ( un mec qui en 6 ans de carriere change 4 fois de boites , passe un pseudo MBA et devient manager , un autre qui etait admin windows senior ya meme pas un an et est devenu manager dune quarantaine de personnes , un mec qui etait second dans un resto qui est reparti faire ses etudes et est devenu SDM , un mec du helpdesk qui en deux ans est devenu team leader et qui est passe manager car le manager sest fait vire etc ....... )

    Mon prefere , cest mon ancienne TL , qui ne connaissait rien a exchange , je crois quelle bossait dans un kindergarden avant dentrer a ibm , elle a occupe un poste de quality analyst pendant un an avant detre mute au poste de team leader . Quand je lui ai demande en quoi consistait son poste de quality analyst , elle m'a repondu '' ben j'analysait la qualite " -> parachutage et copinage font bon menage chez bigblue

    Du coup je me marre quand je vois les profils requis pour certains postes , et meme si je ne cale pas a 100% je tente quand meme car generalement ce poste sera surement file a un/une touriste , alors autant me le donner : quelqu un de motive sera a ce poste , ca me feras avancer ma carriere et au moins jaurais un challenge intellectuel .

    Mon objectif pour les prochaines annees : apprendre a vendre du vent et faire de la politique

    Citation Envoyé par Bono_BX Voir le message
    Mon avis personnel sur l'Agile est que cette méthode est une amélioration, une grosse amélioration, mais qu'une amélioration : si l'on a une équipe de bras cassés ou de personnes non formées ou peu impliquées, le projet sera un échec quelque soit la méthode employée.:
    Ok , donc pour agile , cest pareil que de donner un piano Steinway a Kristina Hu (alias the UnsungHeroine) , Beethoven , David Guetta ou un Chimpanze , cela restera toujours un piano , avec lequels ils feront de la merde , du bruit ou un chef doeuvre
    "bye bye !" : Antonio Ferrara , 12 mars 2003 - check also my flight's diary and my flight's reports

  19. #19
    Membre actif Avatar de zaza576
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2013
    Messages
    156
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    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 : 156
    Points : 257
    Points
    257

    Par défaut

    Citation Envoyé par Bono_BX Voir le message
    Mon avis personnel sur l'Agile est que cette méthode est une amélioration, une grosse amélioration, mais qu'une amélioration : si l'on a une équipe de bras cassés ou de personnes non formées ou peu impliquées, le projet sera un échec quelque soit la méthode employée.
    Je suis entièrement de ton avis pour cela. Une méthodologie ne reste qu'une extension de soi-même pour accomplir une tâche et réussir un objectif. Comme un katana n'est que l'extension du bras d'un samouraï, et un outil pour en faire son métier.

    Citation Envoyé par Bono_BX Voir le message
    Encore une fois, 100% d'accord. Le seul bémol, c'est qu'il faut faire comprendre ça à des gestionnaires / comptables / chefs de projet non techniques (genre parachuté / j'ai-vu-de-la-lumière-je-suis-rentré). Et là, c'est dans les faits quasi-impossible
    Je te rejoins sur l'aspect commercial / financier / non technique / manageurial. Toutefois, des entreprises ont su surmonter ce point avec la "communication", compétence qui reste la seule richesse interne réelle sur laquelle toutes les teams / départements / services devraient compter. Quand un technicien A dit à un non-technicien B, je vous suggère d'utiliser le produit X car le produit Y coûte cher, est buggé, ne répond pas au besoin, B devrait aussi écouter A plutôt que de se baser que sur les déclarations d'autres non-techniciens. En quelques mots : confiance, écoute et communication. D'où l'utilité des réunions. Et pas seulement des réunions de MOE ou de MOA, mais aussi mêlant les deux afin d'avoir un avis le plus vaste possible. L'objectif étant de réduire les risques de faire dériver le projet de A à Z.

    Citation Envoyé par Bono_BX Voir le message
    Autant je suis d'accord pour Vista, autant tu exagères pour 8.1 et Metro. Là, c'est plus une mauvaise orientation commerciale qui croyait trop au tout tactile (trop en avance sur son temps ?). De plus, Windows Phone 8.1 est une vraie réussite. Pour ton dernier paragraphe, voir mon commentaire précédent sur les gestionnaires !
    Ok, j'ai été un peu vache sur W8.1 sachant que s'était innovant mais totalement bête de proposer cette idée à un public trop fermé sur leurs anciennes habitudes de l'OS Windows. Encore une fois, un problème de communication de leur part qui leur a coûté un bras ?!

    Les consommateurs, trop ancrés dans leurs habitudes, ne sont que peu enclins à accepter le changement technologique quand il s'annonce majeur / révolutionnaire ... (Preuve avec AngularJS v2, Windows 8.1 et son interface Metro, le framework Symfony v2 non rétrocompatible, ...).

    Une souris et un clavier... tu leur retire cela, tu perds tes clients. Pourquoi ? Car la courbe d'apprentissage générationnelle d'un produit doit être progressive et s'intercaler avec les autres courbes d'apprentissages d'autres équipements / produits / logiciels / matériaux ...

    Donne une kalash' à un enfant de 5 ans et il t'en fera un petit train ...
    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");

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

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 232
    Points : 479
    Points
    479

    Par défaut

    Ok , donc pour agile , cest pareil que de donner un piano Steinway a Kristina Hu (alias the UnsungHeroine) , Beethoven , David Guetta ou un Chimpanze , cela restera toujours un piano
    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 ).
    La méthodologie ne fait ni l'application, ni le développeur ; exemple, le mien actuellement : je suis obligé de travailler (pour des raisons comptables et de choix du client ) sur un site PHP, alors que je ne connais pas ce langage ; je fais ce que je peux, mais je n'ai pas les connaissances nécessaires pour faire du bon travail (par exemple du code bien optimisé, je ne peux faire que du code très basique). Et là, agile ou cycle en V, la méthode ne m'apportera pas les connaissances. Je gonfle mes chiffrages afin d'inclure le temps d'auto-formation, mais c'est tout.
    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 ?

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