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. #81
    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 Jitou Voir le message
    ......plus personne n'écoute personne mais il faut le faire ... encore une fois ridicule et inefficace........ Ensuite les petits post-it sur le tableau encore une invention ridicule, on a l'impression qu'une panne d’électricité et survenu et que l'on se mets alors à gérer le projet à l'ancienne ... de toute manière les papiers plus personnes ne les lit maintenant ils ne servent plus qu'à donner bonne conscience au directeur de projet et à égayer le mur fades de papiers colorés....
    je ne suis pas dev , mais quand jai squatte quelques uns de ces meetings dans mon ancienne boite , cest limpression que jai eu ! apres cest peut etre parce que je pige pas tout donc je portes attention a dautres details.

    Citation Envoyé par Saverok Voir le message
    J'ai souvent eu ce retour
    Pour ce qui est des post it
    Il y a des outils super bien pour les dématérialiser (par exemple : https://kanbanize.com/ctrl_home est très bien et gratuit)
    Utiliser les vrais post it n'a de sens que pour la hiérarchie qui aime bien voir les grands tableaux dans les bureaux
    C'est juste une question d'image
    Ca leur donne l'impression qu'on travaille et ça fait bien quand il y a des visites des bureaux pour les clients "regardez, on fait de l'Agile, il y a plein de post it sur les tableaux et ils sont de toutes les couleurs" (histoire de faire hype)
    Encore une fois, si le scrum master est à l'aise dans son rôle, il sait faire le tampon entre sa hiérarchie et son équipe et se passer de tout cela
    Jai assiste aux premiers meeting en janvier , sauf que en septembre les post it etaient toujours les meme !
    "bye bye !" : Antonio Ferrara , 12 mars 2003 - check also my flight's diary and my flight's reports

  2. #82
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Je crois que nous sommes ici devant des perversions induites par le management moderne, tel que pratiqué par les grands groupes au nom de l'enrichissement permanent, et par les cabinets de conseil.

    Il fut un temps où j'étais développeur. Je consacrais 90% de mon temps de travail à développer, le reste à la machine à café ou pour le pause cloppe (à l'époque on pouvait fumer dans les bureaux). De temps en temps le directeur de la salle des marchés pour qui je bossais me demandait où j'en étais et je lui répondais. Quand j'avais besoin d'aide, je regardais si un collègue était la tête dans le guidon ou pas, et j'allais le voir si possible. Tout se passait bien, et mes dates de livraison étaient respectées.

    Mes remplaçants, 5 ans plus tard me racontaient qu'ils devaient faire des rétro plannings, des etudes et tout ça. Resultat, moins de 80% de leur temps alloués au développement. Et du coup ils étaient à la bourre et devaient justifier les retards.

    Maintenant quand je discute avec des développeurs, ils me disent qu'ils consacrent à peine 60% (dans le meilleur des cas) à leur travail : DEVELOPPER ! Le reste, c'est des stan-up meetings, des réunions, des centaines de mails par jour, des rapports d'activité, des enregistrement de temps passé sur les projets dans un soft de suivi d'activité, du reporting au chef, des présentations power point de 40 pages pour expliquer l'intéret d'un truc à un "top manager" qui de toutes façons ne verra au final que le prix à payer, des points d'équipe, des points clients, des points management, du suivi budgétaire, de al justification budgétaire... Résultat ils sont à la bourre, livent des trucs pas propres, plein de bugs, et doivent après tout justifier poru finalement se faire virer pour insuffisance professionnelle...

    Un autre exemple : au début de ma carrière je faisais du support (aussi ). Je passais mon temps à faire du support et tout allait bien, la mécanique tenait la route. Quand je regarde le temps réel de support que font maintenant les équipes support (je parle pas de la prise d'appel mais du support) je suis sidéré ! et encore plus quand un consultant KPMG (ou un autre) lui explique comment il doit maintenant faire son boulot suivant la sacro-sainte bible du management moderne, écrit par des brillants penseurs qui n'ont jamais fait de support de leur vie.

    Je pense que l'informatique, qui est en passe de devenir aussi primordiale pour l'homme que l'air qu'il respire souffre de trois maux :
    • la démocratisation qui fait que tout le monde s'auto bombarde "informaticien" sans en avoir ni les règles ni les bases ni la formation parce que "en troisième année d'ingénieur option informatique financière, j'ai fait un site web avec du java"
    • le management moderne qui veut sans arrêt expliquer à tout le monde comment faire une chose qu'il ne sait pas faire lui même.
    • cette manie insupportable de vouloir prendre des ingénieurs là où on a besoin de programmeurs, et qui nous fait des générations d'ingénieurs désabusés et des programmeurs au chômage...

    Autant dire qu'il y a peu d'espoir que ça s'améliore...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  3. #83
    Membre régulier
    Profil pro
    Inscrit en
    Août 2013
    Messages
    40
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Août 2013
    Messages : 40
    Points : 70
    Points
    70
    Par défaut
    L'agilité marche bien dans certains cas, mais pas partout. Cette méthode n'est pas faite pour tout le monde, elle demande à des "pisseurs de code" qui ont l'habitude d'être très bien gérés une certaine adaptation.

    De plus c'est un système ou on "casse la hiérarchie". J'aime bien inverser visuellement le système hiérarchique dans l'agilité, le chef se trouve tout en bas, les "codeurs" tout en haut. Le but du chef est d'être au service des autres.

    D’expérience il faut environ "une année" pour qu'un profil non agile expérimenté s'adapte à une méthodologie agile: "je n'ai pas assez d'informations, je peux pas travailler sans un projet bien défini.". Quelqu'un qui sort des école s'adaptera en quelques jours.

    Pour terminer, l'agilité est une très bonne chose si on fait un projet pour la première fois, qu'on ne sait pas exactement ou on va. Qu'on doit s'adapter, qu'il y a beaucoup d'inconnus, de recherche. Le daily meeting, retrospective sont des choses qui forcent des gens qui sont souvent un peu dans leur monde à communiquer, et c'est une excellente chose. Les développeurs sont souvent des gens moins ouverts que des commerciaux, alors il faut les aider à partager des informations, à discuter ensemble.

    Si on fait un projet pour la 10ème fois, une méthode de gestion de projet très structurée (ex: Waterfall), un management de proximité, est mieux. Car on sait exactement ou on va, on connais les problèmes, on a souvent déjà une base précédente pour gérer un projet.

  4. #84
    Inactif  

    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    Avril 2005
    Messages
    5 879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance EURL / Business Intelligence ETL
    Secteur : Finance

    Informations forums :
    Inscription : Avril 2005
    Messages : 5 879
    Points : 26 145
    Points
    26 145
    Billets dans le blog
    3
    Par défaut
    Je vais un peu faire mon suisse mais :

    Cycle en V : c'est beau sur le papier, mais ça dérive énormément, notamment parce qu'à cause de l'effet tunnel qui fait que les spécifications prennent leurs temps, sont pas carrés, et au final un truc analysable correctement en début du projet coûte après 100 jh en fin de projet. En plus ça isole les développeurs qui demandent souvent qu'à mieux comprendre ce qu'ils font et intervenir sur le projet (sont jamais contents, les développeurs !)

    Méthode(s) Agile(s) : c'est beau sur le papier, mais ça dérive énormément, on profite justement de l'absence de documentation pour faire tout et n'importe quoi et se déclarer agile. Souple. Flexible. En plus, ça force les développeurs qui demandent qu'à bosser dans leur coin et faire leur expertise technique (sont jamais contents, les développeurs !)

    Citation Envoyé par arkhamon Voir le message
    Je crois que nous sommes ici devant des perversions induites par le management moderne, tel que pratiqué par les grands groupes au nom de l'enrichissement permanent, et par les cabinets de conseil.

    Il fut un temps où j'étais développeur. Je consacrais 90% de mon temps de travail à développer, le reste à la machine à café ou pour le pause cloppe (à l'époque on pouvait fumer dans les bureaux). De temps en temps le directeur de la salle des marchés pour qui je bossais me demandait où j'en étais et je lui répondais. Quand j'avais besoin d'aide, je regardais si un collègue était la tête dans le guidon ou pas, et j'allais le voir si possible. Tout se passait bien, et mes dates de livraison étaient respectées.

    Mes remplaçants, 5 ans plus tard me racontaient qu'ils devaient faire des rétro plannings, des etudes et tout ça. Resultat, moins de 80% de leur temps alloués au développement. Et du coup ils étaient à la bourre et devaient justifier les retards.

    Maintenant quand je discute avec des développeurs, ils me disent qu'ils consacrent à peine 60% (dans le meilleur des cas) à leur travail : DEVELOPPER ! Le reste, c'est des stan-up meetings, des réunions, des centaines de mails par jour, des rapports d'activité, des enregistrement de temps passé sur les projets dans un soft de suivi d'activité, du reporting au chef, des présentations power point de 40 pages pour expliquer l'intéret d'un truc à un "top manager" qui de toutes façons ne verra au final que le prix à payer, des points d'équipe, des points clients, des points management, du suivi budgétaire, de al justification budgétaire... Résultat ils sont à la bourre, livent des trucs pas propres, plein de bugs, et doivent après tout justifier poru finalement se faire virer pour insuffisance professionnelle...

    Un autre exemple : au début de ma carrière je faisais du support (aussi ). Je passais mon temps à faire du support et tout allait bien, la mécanique tenait la route. Quand je regarde le temps réel de support que font maintenant les équipes support (je parle pas de la prise d'appel mais du support) je suis sidéré ! et encore plus quand un consultant KPMG (ou un autre) lui explique comment il doit maintenant faire son boulot suivant la sacro-sainte bible du management moderne, écrit par des brillants penseurs qui n'ont jamais fait de support de leur vie.

    Je pense que l'informatique, qui est en passe de devenir aussi primordiale pour l'homme que l'air qu'il respire souffre de trois maux :
    • la démocratisation qui fait que tout le monde s'auto bombarde "informaticien" sans en avoir ni les règles ni les bases ni la formation parce que "en troisième année d'ingénieur option informatique financière, j'ai fait un site web avec du java"
    • le management moderne qui veut sans arrêt expliquer à tout le monde comment faire une chose qu'il ne sait pas faire lui même.
    • cette manie insupportable de vouloir prendre des ingénieurs là où on a besoin de programmeurs, et qui nous fait des générations d'ingénieurs désabusés et des programmeurs au chômage...

    Autant dire qu'il y a peu d'espoir que ça s'améliore...
    Là encore, je vais faire mon suisse, mais un minimum d'implication du développeur est nécessaire. Le problème c'est comme tu dis, le faire venir dans des réunions où il a juste à valider et finalement lui prendre 120 minutes de sa journée si ce n'est plus. Ceci dit je reconnais des missions dans lesquelles ton point était :

    * une mission où il fallait redoubler d'arguments et de rhétorique pour dire non au "directeur des développements" (ça implique quoi ce poste ???) qui veut absolument faire passer un truc impossible, ou du moins infaisable dans les délais / budgets impartis, et qui va jusqu'à éteindre ton poste, te confisquer ta souris jusqu'à ce que tu dises oui, tout en usant de la menace / la pommade / faire l'idiot / être idiot. Et après se plaindre que tu n'as pas bosser pour d'autres => voir "l'expert en réunion" je vous laisse googler.

    * une autre mission où le but était de faire du ping-pong pour prouver qu'on traite bien les mails. Tu as raté la réponse d'un mail d'un quart d'heure ? Pas biiiiieeen.

    Bref, le service informatique idéal, à l'image de la société idéale, comme on le voit dans la pub pour les prud'hommes en 1996 (je vous laisse googler) c'est pas demain qu'on la verra...
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  5. #85
    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
    @arkhamon
    Je ne partage pas du tout ton pessimisme
    Le fait qu'il y ait des mauvais managers ne justifie en rien de faire des généralités défaitistes de la sorte
    Il y a des mauvais éléments dans tous les jobs et l'informatique s'est incroyablement développée ces 20 denières années
    Autrement dit, il y a beaucoup plus d'informaticiens qu'avant, et donc de managers aussi, et proportionnellement, plus de mauvais managers aussi (idem pour les informaticiens, par ailleurs. Pas de jaloux)
    Il ne faut pas faire d'une minorité visible une généralité.

    Citation Envoyé par arkhamon Voir le message
    Je pense que l'informatique, qui est en passe de devenir aussi primordiale pour l'homme que l'air qu'il respire souffre de trois maux :
    • la démocratisation qui fait que tout le monde s'auto bombarde "informaticien" sans en avoir ni les règles ni les bases ni la formation parce que "en troisième année d'ingénieur option informatique financière, j'ai fait un site web avec du java"
    Les métiers de l'informatique se sont énormément développés.
    Il est parfaitement possible d'exercer un métier de l'informatique sans jamais écrire une seule ligne de code (SEO, graphiste, web analyste, community manager, etc.).
    Je trouve très arrogant de croire que la seule façon de faire de l'info est décrire du code.
    Un admin réseau n'a rien à voir avec un développeur Java et il n'est pas moins informaticien pour autant.

    Ensuite, je trouve extrêmement bien que l'informatique se démocratise et ne soit plus réservée à une "caste" de privilégiés et souvent "d"incompris"
    Au contraire, je trouve très bien que les gens s’intéressent enfin à ce que l'on fait
    Et oui, on doit rendre des comptes comme tout le monde.
    C'est fini le temps des développeurs sur leur tour d'ivoire
    Il est temps de s'ouvrir au monde et savoir communiquer
    Et c'est à nous, informaticiens, de nous adapter aux autres et d'apprendre à vulgariser notre façon de communiquer.

    Citation Envoyé par arkhamon Voir le message
    • le management moderne qui veut sans arrêt expliquer à tout le monde comment faire une chose qu'il ne sait pas faire lui même.
    Ca, c'est du mauvais management.
    Un manager n'est pas là pour te dire comment faire ton job mais au contraire, t'aider à mieux le faire et te fournissant tout l'environnement approprié.
    Par contre, comme tu le dis, l'informatique est devenu ultra important et il fauit rendre des comptes.
    Donc, oui, en échange, il faut donner de la visibilité sur ce que l'on fait.
    Rendre des comptes régulièrement (tous les 2 jours à 1x/semaine) à ton manager en lui disant "voilà ce que j'ai fait depuis la dernière fois, ce je suis en train de faire, ce qu'il me reste à faire et combien de temps cela me prendra" ou encore "voilà quelles difficultés j'ai rencontrés et comment je les ai résolus et comment faire pour que cela ne se reproduise plus pour moi et mes camarades", je trouve ça très bien
    Ca sort le développeur du guidon justement
    Ca l'aide à prendre du recul sur son travail
    De même, c'est fini le temps des développeurs seuls dans leur coin
    Aujourd'hui, les projets sont de tailles et on travaille en équipe et ça implique de communiquer et de faire des points de synchro.

    Citation Envoyé par arkhamon Voir le message
    • cette manie insupportable de vouloir prendre des ingénieurs là où on a besoin de programmeurs, et qui nous fait des générations d'ingénieurs désabusés et des programmeurs au chômage...
    Là, pour le coup, je suis d'accord
    Par contre, c'est typiquement franco-français et les choses changent
    Certes, doucement, mais ça évolue dans le bon sens.

  6. #86
    Candidat au Club
    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    Janvier 2014
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Distribution

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1
    Points : 3
    Points
    3
    Par défaut Agile ou ne pas être
    Pour ma part, un bon projet géré avec des méthodes classiques, nous a laissé deux ans et demi sans voir une ligne de code, ni même un bout de programme qui fonctionne et nous a coûté 1,3 M €.
    Ou comment emmener le client le plus loin possible afin qu'il ne puisse faire machine arrière et soit obligé de casquer 2 fois le prix en 2 fois plus de temps, bravo IBM !

  7. #87
    Membre habitué
    Profil pro
    Travail non informatique
    Inscrit en
    Décembre 2010
    Messages
    102
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Travail non informatique

    Informations forums :
    Inscription : Décembre 2010
    Messages : 102
    Points : 179
    Points
    179
    Par défaut Faute !
    "au point ou"

  8. #88
    Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Septembre 2010
    Messages
    67
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Canada

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

    Informations forums :
    Inscription : Septembre 2010
    Messages : 67
    Points : 61
    Points
    61
    Par défaut
    Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ? OUI

    Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?
    POUR CAR AGILE C'EST UN CANCER

    Agile freine-t-il l’écriture du code ?
    IL PERD BEAUCOUPS DE TEMPS
    Bassel EL-BIZRI

  9. #89
    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
    Citation Envoyé par napi15 Voir le message
    Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ? OUI

    Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?
    POUR CAR AGILE C'EST UN CANCER

    Agile freine-t-il l’écriture du code ?
    IL PERD BEAUCOUPS DE TEMPS
    Je suppose que tu as cette opinion suite à un retour d’expérience malheureux.
    Tu peux un peu détailler ?

    Tu travaillais sur un gros projet ou un petit?
    Quel organisation agile aviez vous ? (Scrum, Kanban, autre..)
    As tu eu une meilleur expérience sur un projet gérer en waterfall (en V) ?

  10. #90
    Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Septembre 2010
    Messages
    67
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Canada

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

    Informations forums :
    Inscription : Septembre 2010
    Messages : 67
    Points : 61
    Points
    61
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Je suppose que tu as cette opinion suite à un retour d’expérience malheureux.
    Tu peux un peu détailler ?

    Tu travaillais sur un gros projet ou un petit?
    Quel organisation agile aviez vous ? (Scrum, Kanban, autre..)
    As tu eu une meilleur expérience sur un projet gérer en waterfall (en V) ?

    Oui Oui , j'ai fait un stage dans une grande entreprise en génie logicielle . Je peux te dire que Le scrum n'etait qu'un outil depressive.

    Voici les mauvaises expérience vécu et pourquoi JE DETESTE cette methode :

    1) on m'a chialer sur plusieurs reprise car j'ai travaillé sur des tasks hors du scoop du sprint ( c'est des tasks super facile a résoudre et les utilisateurs ont apprécier la rapidité d’exécution de leur demandes ) MAIS ca ne respect pas la méthode agile donc....on me taper le derrière mais ....c'est pas sa ce que un développeur est senser de faire ? (satisfaire le demande des utilisateurs dans le moindre délai et coup possible ) c'est ce que m'a appris toujours a l’école

    2) le scrum master a trop pris des décisions concernant le code ( alors qu'il est seulement senser de s'occuper du coup et du temps ) LE CODage c'est le travail du DEVELOPPEUR

    3) BEAUCOUPS de délai a finir les taches car il dépendant d'autre tasks (encore une fois il était interdit de travailler sur les autres task -> car la méthodologie agile l’autorise pas )
    4) On travailler sur la maintenance de plusieurs projet (2-3) dont un qui est assez sophistiquée et on était une équipe de 4 développeur expérimenté et un stagiaire qui est moi . Et je pense qu'on est assez mature pour juger et prendre des décisions par nous mêmes sans avoir un cauchemar qui s’appelle scrum a nous guider

    en conclusion , Agile , scrum et bla bla bla c'est un enfer pour un développeur . Par contre , c'est un bon outil pour la gestion de projet , je répète bien GESTION DE PROJET et non Développer un projet , c'est un bijoux pour les gestionnaires les project manager etc ( excellent pour gérer l'argent et le temps et la date de livraison des projets) ... mais pour un développeur c'est un cauchemar
    Bassel EL-BIZRI

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

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par napi15 Voir le message
    (.../...)la méthodologie agile l’autorise pas(.../...)
    Voilà.

    Ca, c'est de la connerie. C'est ce que t'ont dit tes chefs, mais c'est de la connerie. Mais c'est pareil en waterfall, hein, sauf qu'en waterfall c'est assumé. En waterfall, j'ai fait une tâche non planifiée, et j'ai eu une enguelade de 20 minutes(et en fait, ils étaient très contents, mais ils n'avaient pas le droit de le dire). Le principe de l'agile, c'est justement de faire ce qu'il faut faire, quand il faut le faire, même si ça n'est pas prévu.

    Ce genre d'imbécile est juste imperméable à ce genre de principe, et est tout perdu dès qu'on sort du planning. Agile ou pas, ça ne changera jamais. Tu est tombé sur des imbéciles, pas sur des agiles.
    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.

  12. #92
    Membre actif Avatar de Tr0n33
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Novembre 2014
    Messages
    69
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Service public

    Informations forums :
    Inscription : Novembre 2014
    Messages : 69
    Points : 220
    Points
    220
    Par défaut
    Outch.

    En conclusion, de mon point de vue, tu n'as pas utilisé du Scrum mais un ensemble de processus régulé par l'entreprise.

    on m'a chialer sur plusieurs reprise car j'ai travaillé sur des tasks hors du scoop du sprint ( c'est des tasks super facile a résoudre et les utilisateurs ont apprécier la rapidité d’exécution de leur demandes )
    Et heureusement qu'on t'a rappelé à l'ordre. Imagine que contractuellement ta task soit disant très simple, plante sur la mise en production et décale des éléments d'un sprint. Tu prends la responsabilité de payer les pénalités ? Être développeur ne veut pas dire ne faire que du développement mais aussi être au courant des tenants et aboutissants de son travail. Un développeur, développe oui, mais il développe ce qu'on lui demande. Les développeurs qui décident dans leur coin, c'est ce qu'il y a de pires dans un projet.

    le scrum master a trop pris des décisions concernant le code ( alors qu'il est seulement senser de s'occuper du coup et du temps ) LE CODage c'est le travail du DEVELOPPEUR
    Ce n'est donc pas la méthode Scrum qui a été appliqué dans ton cas car si le scrum master avait fait son travail, c'est à dire si la méthode avait été respectée, tu n'aurais pas râlé sur ce point. Tu râles sur un élément qui n'a rien à voir avec Scrum mais avec un individu qui dévie la méthode. Donc ce n'est pas la méthode qui est critiquable mais le processus de l'entreprise dans laquelle tu as travaillé. La nuance est de taille.

    3) BEAUCOUPS de délai a finir les taches car il dépendant d'autre tasks (encore une fois il était interdit de travailler sur les autres task -> car la méthodologie agile l’autorise pas )
    La méthodologie Agile ne restreint rien du tout ! Da fuk ! La règle numéro 1 de toutes les méthodes agiles c'est de dire qu'on fait les choses quand on en a besoin et qu'on est capable de les adapter au fur et à mesure du développement. Elle fait primer l'humain au processus. Encore une fois, ce n'est pas la méthode agile qui restreint mais le processus de gestion de projet dans ton entreprise. La nuance est colossale.

    4) On travailler sur la maintenance de plusieurs projet (2-3) dont un qui est assez sophistiquée et on était une équipe de 4 développeur expérimenté et un stagiaire qui est moi . Et je pense qu'on est assez mature pour juger et prendre des décisions par nous mêmes sans avoir un cauchemar qui s’appelle scrum a nous guider
    Justement la méthode Scrum considère que les développeurs et les utilisateurs sont au centre du système. Tu n'as juste appliqué dans l'entreprise que les bouts de Scrum qui plaisait à la direction tout en gardant les superbes processus classiques d'entreprise en France. J'appelle ça de la soupe pseudo agile à laquelle on appose une marque. Ca n'a rien à voir avec les méthodes agiles justement.

    en conclusion , Agile , scrum et bla bla bla c'est un enfer pour un développeur . Par contre , c'est un bon outil pour la gestion de projet , je répète bien GESTION DE PROJET et non Développer un projet , c'est un bijoux pour les gestionnaires les project manager etc ( excellent pour gérer l'argent et le temps et la date de livraison des projets) ... mais pour un développeur c'est un cauchemar
    Un enfer ? Un bijou pour les gestionnaires ? C'est justement le gros problème en France : de réussir à imposer au management la "vraie" méthode Scrum. Le centre de la méthode agile c'est justement "l'agilité" contrairement à la rigueur de la gestion. C'est tout le contraire. Le coeur c'est le client, le développement et l'interfaçage entre les deux. Déjà quand je lis que tu le pratiques dans le cadre d'une TMA, je bondis. Mais je bondis très haut car c'est encore des chefs qui ont brandi la méthode comme la croix dans une église. Ils n'ont rien compris à son fonctionnement, s'empare de certains bouts qui justifient leur gestion de projet et oublie la première de toutes les règles (elle est écrite dans l'article).

    C'est fou comme on peut confondre la méthode et les processus d'entreprise.

    D'ailleurs le métier du développement ça n'est pas juste développer ou prendre des décisions sur le code. J'ose espérer que le génie logiciel c'est un peu plus que ça justement.
    "Dans une hiérarchie, tout employé a tendance à s'élever à son niveau maximum d'incompétence" - Principe de Peter
    "Il n’y a pas de langage informatique dans lequel vous ne puissiez pas écrire de mauvais programmes" - Dérivation de Murphy
    Un scientifique doit douter de tout et connaître l'échec : http://fr.wikipedia.org/wiki/Corr%C3%A9lation_illusoire

    Tr0n

  13. #93
    Membre expert
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Octobre 2013
    Messages
    1 563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2013
    Messages : 1 563
    Points : 3 404
    Points
    3 404
    Par défaut
    En ajout à ce qui a pu être dit :
    Citation Envoyé par napi15 Voir le message
    (encore une fois il était interdit de travailler sur les autres task -> car la méthodologie agile l’autorise pas )
    Il me semble qu'on ne parle pas de tâches, mais de fonctionnalités en Scrum et dans les méthodes agiles en générales. Si ces fonctionnalités ont bien été identifiées, hormis quelques exceptions, les dépendances sont inexistantes.

    Citation Envoyé par napi15 Voir le message
    Et je pense qu'on est assez mature pour juger et prendre des décisions par nous mêmes sans avoir un cauchemar qui s’appelle scrum a nous guider
    Tout dépend du niveau des décisions... Le fonctionnel c'est pour le client, le technique c'est pour l'entreprise ou le team leader. Si chacun fais sou bouiboui dans son coin on fonce droit au mur

    Citation Envoyé par napi15 Voir le message
    c'est un bijoux pour les gestionnaires les project manager etc ( excellent pour gérer l'argent et le temps et la date de livraison des projets) ... mais pour un développeur c'est un cauchemar
    Je pense que, au contraire, la tâche est plus compliquée pour le gestionnaire de projet, ou "Scrum Master", qui doit faire un effort supplémentaire tout au long du projet pour faire appliquer la méthode. Grossièrement le développeur n'a qu'a prendre son post-it sur le Scrum Board, développer sa fonctionnalité et faire part de ces difficultés/remarques/propositions/etc.. durant les réunions...

  14. #94
    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
    Citation Envoyé par napi15 Voir le message
    1) on m'a chialer sur plusieurs reprise car j'ai travaillé sur des tasks hors du scoop du sprint ( c'est des tasks super facile a résoudre et les utilisateurs ont apprécier la rapidité d’exécution de leur demandes ) MAIS ca ne respect pas la méthode agile donc....on me taper le derrière mais ....c'est pas sa ce que un développeur est senser de faire ? (satisfaire le demande des utilisateurs dans le moindre délai et coup possible ) c'est ce que m'a appris toujours a l’école
    Citation Envoyé par Tr0n33
    Et heureusement qu'on t'a rappelé à l'ordre. Imagine que contractuellement ta task soit disant très simple, plante sur la mise en production et décale des éléments d'un sprint. Tu prends la responsabilité de payer les pénalités ? Être développeur ne veut pas dire ne faire que du développement mais aussi être au courant des tenants et aboutissants de son travail. Un développeur, développe oui, mais il développe ce qu'on lui demande. Les développeurs qui décident dans leur coin, c'est ce qu'il y a de pires dans un projet.
    L'autre cas où on ne doit pas faire de fonctionnalité (pour pas dire tache, vu qu'il y avait une valeur client d'après toi), c'est que tu ne sais pas forcement les négociations commerciales qu'avaient ta boite avec des clients.
    De ne pas vouloir prendre une fonctionnalité "facile" dans le backlog trop tôt peux aussi faire partie d'une stratégie de ton Product Owner pour des futures ventes par exemple.
    En poussant ta jolie amélioration dans la livraison courant, tu peux avoir enclenché un dilemme du PO: livrer quant même la version du sprint (mais perdre une renégociation de contrat) ou ne pas livrer (et se retrouver en faute avec un client).
    => Bon, l'agilité impose de la transparence et dans ces cas là il est bon aussi que le PO soit claire sur ce type de démarche de sa part.

    Scrum, avec son principe de contrat de sprint, impact aussi toute la chaîne de commercialisation d'un logiciel.
    Donc, si tu voulais faire cette fonctionnalité dans le sprint, il fallait la demander à ta réunion de "Sprint planing" pour qu'elle soit ajouté dans le "Sprint backlog"
    A ce moment là, la fonctionnalité fait partie du sprint et même le PO peux l'annoncer au client.
    Même si la conséquence n'est pas aussi importante, le PO avait peut-être annoncer au client que la fonctionnalité en question serait dans 2 itérations et là il passe pour une buse qui ne sait pas ce que les développeurs font.
    Et pour un commercial, se faire prendre pour un incompétent par un client c'est trèèèèèès désagréable.

    Et puis, même si cette fonctionnalité était facile à réalise (développement + tests + doc + validation fonctionnelles + .... enfin respectant votre Definition of Done) il aurait été mieux que tu aides tes collègues sur les autres fonctionnalités, quitte à être en Pair Programming et en apprendre un peu plus sur d'autre partie du logiciel.

    Dans ton retour d’expérience, il me semble qu'il y a 2 soucis qui se sont téléscopés:
    • Comme le dit Tr0n33, l'entreprise n'est pas réellement Agile, mais très dirigiste dans ses procédure en saupoudrant de concepts vaguement Scrum
    • Toi même, tu me sembles un peu un "chien fou", très indépendant, qui a du mal à accepter des règles d'entreprises.
      Tu es jeunes, on l'a été aussi, mais essaye d'être plus humble dans ton travail.
      Croire que "on est assez mature pour juger et prendre des décisions par nous même" dans ta position est une erreur, on a rarement la vision global d'un produit informatique sur lequel on travail.

  15. #95
    Membre expert

    Homme Profil pro
    Consultant
    Inscrit en
    Janvier 2006
    Messages
    1 376
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 376
    Points : 3 583
    Points
    3 583
    Par défaut
    Je ne connais pas les concepts Agile et ne les pratiques pas. Mais si "développer dans un environnement Agile" veut dire "passer sa vie en réunion en se tirer la nouille en se demandant Pourquoi ? Comment ? Qui ? Quand ?", ben merci mais non merci. Je suis développeur, je code... Si j'avais envie de passer mes journées en réunion à rien foutre, je serai Chef de projet !
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  16. #96
    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
    Citation Envoyé par zecreator Voir le message
    Je ne connais pas les concepts Agile et ne les pratiques pas. Mais si "développer dans un environnement Agile" veut dire "passer sa vie en réunion en se tirer la nouille en se demandant Pourquoi ? Comment ? Qui ? Quand ?", ben merci mais non merci. Je suis développeur, je code... Si j'avais envie de passer mes journées en réunion à rien foutre, je serai Chef de projet !
    On ne passe pas sa vie en réunion en Agile.
    Par exemple, en Scrum, pour des itérations de 4 semaines, tu auras seulement:
    - 8 heures de Sprint Planing
    - 1/4 heures de Daily meeting chaque jours
    - 4 heures de Sprint review
    - 3 heures de Retrospective
    => total = 19h30 de réunion par mois.

    Et sinon, combien de temps passe tu en réunion pour ton projet actuellement ?
    Fait le compte, ça va très vite.

    Autre question: tu code, d'accord, mais quoi et pourquoi?

  17. #97
    Membre expert

    Homme Profil pro
    Consultant
    Inscrit en
    Janvier 2006
    Messages
    1 376
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 376
    Points : 3 583
    Points
    3 583
    Par défaut
    Bien évidemment les réunions sont utiles. En règle générale il y a :
    - une réunion de cadrage avec le client (afin de déterminer ses besoins et son environnement technique) = de 2 à 3 heures
    - une réunion à chaque livraison de version afin de déterminer les corrections à apporter = 30 min max X par le nombre de livraison (3 à 4)
    - une réunion de livraison finale (avec Champagne, binouze et petits fours) = de 1h à toute la nuit

    Il y a aussi des réunions avec le client pour valider les contenus, le storyboard... Mais les développeurs n'ont pas besoin d'être présents.
    En tout, sur un projet de 2 mois je dois passer 5h en réunion grand max.

    Par exemple, nous venons de livrer 2 gros projets avec des délais très serrés. A livrer au même moment pour 2 clients différents. Pas question de passer 20h par mois et par projet en réunion. Pendant que je suis en train de taper la discute sur la beauté de mon code, y a personne derrière mon PC pour programmer à ma place. Et les 20h de réunion où j'ai pas codé, j'ai pas envie de les rattraper le soir après le bureau ou le week-end pour rester dans les délais.
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  18. #98
    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
    @zecreator
    Si la seule chose qui t'intéresse c'est le développement et rien d'autre, tu n'as pas le profil pour travailler sur un projet Agile.
    Je ne porte aucun jugement
    Tu as parfaitement le droit d'être focalisé sur l'implémentation.

    Pour travailler en mode Agile, on a besoin de profils plus transverses, limite DevOps
    Les développeurs ne font jamais que du dev dans un projet Agile
    Il font également la conception technique et fonctionnelle, de la qualité, etc.
    Bref, c'est beaucoup d'échange en direct avec le client qui implique de savoir s'adapter à son interlocuteur et comprendre son besoin pour le traduire techniquement.
    L'organisation n'est absolument pas pyramidale où chaque rôle est cloisonné à une fonction.

  19. #99
    Membre expert

    Homme Profil pro
    Consultant
    Inscrit en
    Janvier 2006
    Messages
    1 376
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 376
    Points : 3 583
    Points
    3 583
    Par défaut
    Citation Envoyé par Saverok Voir le message
    @zecreator
    Si la seule chose qui t'intéresse c'est le développement et rien d'autre, tu n'as pas le profil pour travailler sur un projet Agile.
    Je ne porte aucun jugement
    Tu as parfaitement le droit d'être focalisé sur l'implémentation.

    Pour travailler en mode Agile, on a besoin de profils plus transverses, limite DevOps
    Les développeurs ne font jamais que du dev dans un projet Agile
    Il font également la conception technique et fonctionnelle, de la qualité, etc.
    Bref, c'est beaucoup d'échange en direct avec le client qui implique de savoir s'adapter à son interlocuteur et comprendre son besoin pour le traduire techniquement.
    L'organisation n'est absolument pas pyramidale où chaque rôle est cloisonné à une fonction.
    Comment un développeur peut faire de la gestion de projet sans avoir la formation qui va avec ? Faut que l'on m'explique comment on arrive à vendre ça au client...
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  20. #100
    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 zecreator Voir le message
    Comment un développeur peut faire de la gestion de projet sans avoir la formation qui va avec ? Faut que l'on m'explique comment on arrive à vendre ça au client...
    Le DevOps n'est pas de la gestion de projet.

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