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

La taverne du Club : Humour et divers Discussion :

Est-ce que tous les développeurs français sont comme ça ?

  1. #1
    Inactif
    Homme Profil pro
    web+multimedia
    Inscrit en
    Décembre 2014
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : web+multimedia

    Informations forums :
    Inscription : Décembre 2014
    Messages : 6
    Points : 8
    Points
    8
    Par défaut Est-ce que tous les développeurs français sont comme ça ?
    Je sais pas si je suis un poissard qui est tombé sur les pires boîtes françaises, mais j'ai vraiment l'impression que le profil moyen du développeur français c'est ça:


    - Une définition de l'esprit d'équipe digne de taulards.
    C'est le plus fort qui décide ce qui l'arrange, c'est à dire qu'il en fout le moins possible, a la flemme de coordoner l'équipe, conséquence on est sûrs dès le départ que le programme va être d'office foutu n'importe comment et tout le monde se résigne à faire de la merde et abaisser sa motivation au niveau de celle du chef.

    - Une rétissence à communiquer
    Totalement rétissent aux méthodes AGIL, ça préfère coder tout seul comme un autiste devant l'écran en se contrefoutant de ce que fait le reste de l'équipe.
    Impossible d'accepter le binôme pilote/copilote, personne veut être copilote parce qu'il faut avouer être le moins fort des deux alors on perd des points de pouvoir sur l'autre.
    La flemme de rédiger de la doc pour les autres, cahiers des charges bâclés (voir réduits à un bordel de 50 mails) où il manque la moitié des infos, etapes de conception zappées on code direct n'importe comment car pressé d'en finir.
    Communication zéro, comme ça on est sûr que le programme sera un assemblage incohérent de trucs mal raccordés et va prendre un temps interminable à restructure de partout.

    - Braquage total contre la notion de qualité
    Un programme de qualité c'est plus long à faire que de la camelote alorsz c'est pas efficace donc pas rentable. Discours que j'ai entendu et réentendu...


    Bon ben si tous les dev français sont comme ça je comprends pourquoi on est nuls en informatique.

  2. #2
    Expert éminent sénior
    Avatar de Auteur
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    7 643
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 7 643
    Points : 11 131
    Points
    11 131
    Par défaut
    Tu travailles dans une SSII ?

  3. #3
    Membre éprouvé
    Inscrit en
    Mars 2006
    Messages
    848
    Détails du profil
    Informations personnelles :
    Âge : 40

    Informations forums :
    Inscription : Mars 2006
    Messages : 848
    Points : 1 078
    Points
    1 078
    Par défaut
    J'en suis à 4 boîtes dont 2 SSII.
    Aucune des équipes dans lesquelles je suis passée n'était parfaite, loin de là (et je ne le suis pas non plus...), mais à côté de ce que tu décris elles paraissent idylliques...
    Combien en as-tu côtoyées? As-tu essayer de prendre du recul pour juger?
    Si c'est bien le cas, je dirais que t'as vraiment pas eu de bol...

    Citation Envoyé par vangog Voir le message
    Totalement rétissent aux méthodes AGIL, ça préfère coder tout seul comme un autiste devant l'écran en se contrefoutant de ce que fait le reste de l'équipe.
    Je vois pas bien le rapport entre le deux.
    J'ai peut-être mal compris ce que tu as voulu dire, mais en lisant ça, ça me rappelle certains extrémistes des méthodes agiles que j'ai côtoyé.
    Malheureusement, ces personnes-là étaient tout sauf ouvertes d'esprit. Du coup, la communication était très difficile quelque soit la méthode effectivement appliquée. Je peut alors facilement concevoir que ces gens-là avaient une image très négative du travail en équipe...

    Ne prend pas mon commentaire pour une attaque personnelle, je n'ai pas lu d'autre post de toi, mais le seul que je lis me donne un peu cette impression. J'espère me tromper

  4. #4
    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 044
    Points
    32 044
    Par défaut
    Le discours sur la qualité ne vient généralement pas des développeurs, mais des financiers. Mais je l'ai déjà entendu. "Boarf, c'est du jetable, pas la peine de se faire suer". Résultat, ça aurait couté moins cher de faire "propre" dès le début - pour du jetable. Alors évidemment, pour du code de production...

    On trouve de tout, sur le marché du travail. J'ai appris à être tolérant. Moi-même, j'étais jeune et pétri de certitudes. Et parfois, il a fallu faire autrement. Et c'était une bonne chose.
    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.

  5. #5
    Inactif  
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    Mai 2013
    Messages
    2 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mai 2013
    Messages : 2 511
    Points : 10 335
    Points
    10 335
    Par défaut
    Pour le cahier des charges fonctionnel, dans un monde de bisounours (et suivant la taille de la boite), c'est le client qui le rédige, voir le chef de projet (avec le client), mais cela ne devrait pas être ton copain développeur assis à côté de toi (sauf dans une petite PME comme moi, ou tu ne fais que du dev interne, et où je rédige le cahier des charges avec les responsables / opérationnels métiers).

    Quant à la qualité, comme l'a dit el_slapper, ce n'est pas toujours du ressort du dev, et puis surtout, la plupart des devs font ce qu'ils peuvent avec les délais intenables vendus aux clients par des gens qui n'y connaissent rien, quand tu as 2 semaines, pour développer un truc qui en demanderait 3 voir 4, tu ne prends pas le temps de faire des fioritures...

    Concernant les problèmes de communication, vu que nous ne sommes que 2 chez nous, mon responsable et moi, je ne suis pas trop concerné donc je ne me prononcerais pas, n'ayant jamais travaillé en binôme, il fait son boulot dans son coin, et je code effectivement tout seul, on se fait juste des points réguliers pour savoir où est-ce qu'on en est.

  6. #6
    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
    [QUOTE=vangog]Je sais pas si je suis un poissard qui est tombé sur les pires boîtes françaises, mais j'ai vraiment l'impression que le profil moyen du développeur français c'est ça:

    - Une définition de l'esprit d'équipe digne de taulards.
    C'est le plus fort qui décide ce qui l'arrange, c'est à dire qu'il en fout le moins possible, a la flemme de coordoner l'équipe, conséquence on est sûrs dès le départ que le programme va être d'office foutu n'importe comment et tout le monde se résigne à faire de la merde et abaisser sa motivation au niveau de celle du chef.

    Citation Envoyé par vangog
    Totalement rétissent aux méthodes AGIL, ça préfère coder tout seul comme un autiste devant l'écran en se contrefoutant de ce que fait le reste de l'équipe.
    Impossible d'accepter le binôme pilote/copilote, personne veut être copilote parce qu'il faut avouer être le moins fort des deux alors on perd des points de pouvoir sur l'autre.
    La flemme de rédiger de la doc pour les autres, cahiers des charges bâclés (voir réduits à un bordel de 50 mails) où il manque la moitié des infos, etapes de conception zappées on code direct n'importe comment car pressé d'en finir.
    Communication zéro, comme ça on est sûr que le programme sera un assemblage incohérent de trucs mal raccordés et va prendre un temps interminable à restructure de partout.
    C'est bien connus, on serait pas développeurs si on était extravertis (ceux-là deviennent commerciaux \o/)
    Ceci dit j'ai déjà été sur le projet où il fallait rédiger des mails tout le lundi pour dire que le dev sera fait mardi matin et livré mardi soir, plutôt que de développer lundi matin et livrer lundi aprèm mais le client pas content ^^

    Citation Envoyé par vangog
    - Braquage total contre la notion de qualité
    Un programme de qualité c'est plus long à faire que de la camelote alorsz c'est pas efficace donc pas rentable. Discours que j'ai entendu et réentendu...
    C'est dû à l'effet tunnel. Tu penses avoir 6 mois pour faire le projet. Tu prends ton temps pour faire ton cahier des charges et merde le temps s'accélère. Finalement tu zappes les specs (on verra plus tard), les commentaires utiles (on n'a pas le temps pour ça), les tests unitaires se limitent à "ça compile = ça marche". Alors je te parle pas des consignes de merde données à l'équipe A pour une maintenance qui sera faite par B, qui va baisser les bras et fournir à C, qui va baisser les bras et faire le passage de connaissances à D... (moi j'étais dans l'équipe N)
    J'ai déjà bossé chez un client qui a mis en place une équipe qualité. Ouai elle nous a fait chier. Ouai elle nous a fait refaire nos devs jusqu'à qu'ils soient commentés, et pas validés si la spec n'était pas carré. On a délivré une doc fonctionnelle (oui l'AMOA nous l'avait déléguée) de 350 pages, derrière le projet en béton armé.

    Comme dit el_slapper : c'est du jetable, deux ans après c'était à la poubelle

    Citation Envoyé par Zirak Voir le message
    Pour le cahier des charges fonctionnel, dans un monde de bisounours (et suivant la taille de la boite), c'est le client qui le rédige, voir le chef de projet (avec le client), mais cela ne devrait pas être ton copain développeur assis à côté de toi (sauf dans une petite PME comme moi, ou tu ne fais que du dev interne, et où je rédige le cahier des charges avec les responsables / opérationnels métiers).
    Déjà vu en projet (véridique) :
    Dossier technique de conception, document de trois pages qui contient : une page de garde (titre avec le nom de la société), un sommaire, et un seul paragraphe à puce avec dedans : voir spécifications fonctionnelles détaillées.
    Spécifications fonctionnelles détaillées, document de trois pages qui contient : une page de garde (titre avec le nom de la société), un sommaire, et un seul paragraphe à puce avec dedans : voir définition techniques de besoins.
    Définition techniques de besoins, document de trois pages qui contient : une page de garde (titre avec le nom de la société), un sommaire, et un seul paragraphe à puce avec dedans : voir cahier des charges.
    Cahier des charges : un fichier excel incompréhensible. Pourtant je suis pas si con que ça. Mais j'ai eu l'impression de faire une bataille navale, genre tu piges P-5, il te dit rendez-vous en A-2, donc c'est logique que tu regardes BB-36.
    - 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

  7. #7
    Inactif  
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    Mai 2013
    Messages
    2 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mai 2013
    Messages : 2 511
    Points : 10 335
    Points
    10 335
    Par défaut
    Citation Envoyé par Glutinus Voir le message

    Déjà vu en projet (véridique) :
    Dossier technique de conception, document de trois pages qui contient : une page de garde (titre avec le nom de la société), un sommaire, et un seul paragraphe à puce avec dedans : voir spécifications fonctionnelles détaillées.
    Spécifications fonctionnelles détaillées, document de trois pages qui contient : une page de garde (titre avec le nom de la société), un sommaire, et un seul paragraphe à puce avec dedans : voir définition techniques de besoins.
    Définition techniques de besoins, document de trois pages qui contient : une page de garde (titre avec le nom de la société), un sommaire, et un seul paragraphe à puce avec dedans : voir cahier des charges.
    Cahier des charges : un fichier excel incompréhensible. Pourtant je suis pas si con que ça. Mais j'ai eu l'impression de faire une bataille navale, genre tu piges P-5, il te dit rendez-vous en A-2, donc c'est logique que tu regardes BB-36.
    Ne te plains pas, déjà ils font semblant de te faire des documents et un fichier Excel...

    Moi, 9.9 fois sur 10, le cahier des charges se résume à une demande orale en 5mn au téléphone, ou à une réunion de 30mn/1h et aux notes que je prend pendant celle-ci, cela ne fait que très peu de temps que j'arrive à pousser mon responsable, à leur faire faire un minimum de rédaction, pour avoir une base minimum (ce qui ne m'empêche pas d'avoir plusieurs contacts avec les opérationnels pour définir plus précisément les besoins).

  8. #8
    Invité
    Invité(e)
    Par défaut
    Salut vangog, juste pour te dire que je ne peux pas répondre à ton mp, vu que tu ne peux pas recevoir de messages.

    Bon, quand je développe en solo en général je ne fais pas de diagramme UML, car je n'en ai pas besoin, je prend juste une feuille de papier ou bien un logiciel si c'est vraiment trop compliqué à représenté sur une feuille, ça m'aide a développer les algorithmes vraiment plus complexe comme en 3D par exemple. :/

    Tu n'as sûrement pas eu de chance, car, à l'école, quand je faisais des projets en équipes (simulation de développement de projets pour des clients), on faisait :

    -Un cahier des charges.
    -On utilisait MS project pour savoir qui fait quoi, il y avait juste les coûts qu'on ne prenait pas en considération car, on était en école, mais je pouvais les imaginer suite au salaire d'un développeur, par contre, pour la vente ça, c'est toujours plus difficile car il faut prier pour que ça se vende et si ça se vent, que ça se vende ou prix fixé.
    -Une analyse complète du problème. Dessins des guis (à la main ou bien avec un logiciel) avec diagramme de cas d'utilisations (avec toutes les options possibles), diagrammes UML (qui code quel classe/fonctionnalité) ?, etc..., sans oublier bien sûr la documentation.
    -Ensuite chacun faisait son boulot et quelqu'un (en général c'était moi) faisait l’interaction entre les différents classes/fonctionnalité du programme pour la version finale.
    On faisait ensuite le point avec le client avec les quelques fonctionnalités développées dans la release intermédaire, corrigeait ce qui n'allait pas et ensuite, on développait la release intermédiare suivante.

    En école ça à toujours très bien marché comme ça pour autant que, chacun faisait bien son boulot, souvent on était en groupe de 2, ou de 3 mais souvent le 3ème profitait du travail des 2 autres. :/

    J'ai développé un projet en java comme ça avec une autre personne, motivée, j'ai eu de belle note, et le projet aurait pu bien se vendre si ça n'avait pas été un projet scolaire, m'enfin bref...

    Finalement je n'étais pas mécontent d'avoir dû refaire ce cours, la 1ère année je m'étais retrouvé seul pour le faire, et, on avait utilisé une autre méthode. (moins bonne du genre la même que celle que utilisée dans ta SSI)

    Donc dans une SSI ça devrait bien marché également avec cette méthode, sinon c'est voué à l'échec, ce n'est pas plus compliqué que ça.

    Bref moi si la SSI ne travaille pas comme ça je n'y reste pas.

    Mais le pire c'est lorsqu'on te met devant un code ou il n'y a pas de documentations, rien...

  9. #9
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 347
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 347
    Points : 20 347
    Points
    20 347
    Par défaut
    Citation Envoyé par vangog Voir le message
    - Une définition de l'esprit d'équipe digne de taulards.
    C'est le plus fort qui décide ce qui l'arrange, c'est à dire qu'il en fout le moins possible, a la flemme de coordoner l'équipe, conséquence on est sûrs dès le départ que le programme va être d'office foutu n'importe comment et tout le monde se résigne à faire de la merde et abaisser sa motivation au niveau de celle du chef.
    merci pour ce témoignage

    sans vouloir généraliser c'est un peu symptomatique de la mentalité française c.a.d. que tout repose sur les divisions internes et l'esprit conflictuel d'ailleurs ne dit-on pas "diviser c'est mieux régner.."
    Seulement il y a une majorité de gens en France qui n'ont pas compris que si les salariés d'une entreprise ne font pas "consensus" eh bien l'entreprise tourne en rond..

    Citation Envoyé par vangog Voir le message
    - Braquage total contre la notion de qualité
    Un programme de qualité c'est plus long à faire que de la camelote alorsz c'est pas efficace donc pas rentable. Discours que j'ai entendu et réentendu...
    je ne suis pas du tout étonné par cette remarque : étant donné que les entreprises qui font du service informatique sont rentables si les développements sont effectués le plus rapidement possible alors faut pas s'étonner que la qualité en prend un coup..
    Citation Envoyé par Glutinus Voir le message
    Déjà vu en projet (véridique) :[..]
    ehhh là c'est vraiment kafkaien...je ne pensais pas qu'il y avait tant de bureaucratie à ce point en entreprise..

  10. #10
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 626
    Points : 10 542
    Points
    10 542
    Par défaut
    Citation Envoyé par Lolilolight Voir le message
    Mais le pire c'est lorsqu'on te met devant un code ou il n'y a pas de documentations, rien...


    Tu arrives dans une boîte est tout "est rose" [même le P.Q.], tout est "propre et sent bon" [même les toilettes]

    Cette réflexion c'était avant


    ... avant d'écumer au moins 2 boîtes et lorsqu'on cire les bancs de la fac. avec le fond de son froc

    Maintenant, je n'ai plus d'espoir
    Mais je suis un guerrier [parce que j'aime mon métier mais pas les SC2Is/ ESNs] mais pas Simon McKay [<- pas un magicien]


    PS: Petite précision: Cela va faire 5 ans que je veux vraiment travailler dans une SC2I/ ESN mais je n'y arrive pas

  11. #11
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 277
    Points
    5 277
    Par défaut
    Pour apporter ma contribution au débat, et mon expérience après 8 ans passé en SSII, je dirais que la qualité d'un projet dépend de beaucoup de paramètres.

    Le gros avantage de la SSII (oui, car il y en a), c'est la possibilité de changer de projet, d'entreprise voire de métier (par métier j'entends dév, MOA, archi, CdP...) au gré des missions. Alors c'est vrai que ce gros avantage, c'est paradoxalement aussi le gros défaut.

    Mais pour revenir à la qualité des projets, je dirai que ça dépend. De mon expérience, ça varie très fortement d'une mission à l'autre. J'ai vu des projets catastrophiques sans aucune documentation sur lesquels sont passés 12 prestas (ou stagiaires) avant moi sans qu'aucun d'entre eux ne se rencontre, avec des demandes d'évolutions absurdes, qu'il faudra parfois défaire quand la MOA se rendra compte que les utilisateurs n'en veulent pas (il existe des MOA qui invente des évolutions sans demander leur avis aux utilisateurs... si si !).

    Et de l'autre côté, il existe des projets très propres où la documentation et la qualité sont prises en considération et dans lesquels des points d'avancement sont fait régulièrement avec de la communication au sein de l'équipe, de l'entraide, des moyens (un PC récent, une plateforme de recette à niveau, une usine logicielle...).

    Cela dit, et pour finir, je dirais qu'au gré des missions, ce n'est pas toujours la qualité du projet qui compte. L'ambiance au sein de l'équipe et de l'entreprise a aussi une grande part d'importance. J'ai connu des projets très médiocre avec une ambiance excellente et ça reste de très bons souvenirs (et à chaque fois c'est la médiocrité du projet qui a fait que l'équipe s'est davantage soudée et donc qui a amélioré l'ambiance).
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  12. #12
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 951
    Points
    32 951
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Barsy Voir le message
    la possibilité de changer de projet, d'entreprise voire de métier
    Encore faut-il que ton commercial/ou je ne sais quel bonhomme au-dessus, ou/et ton client l'accepte(nt)
    personnellement je me suis retrouvé bloqué dans une entreprise, sur un projet, 18 mois, quasiment sans suivi (faut dire que le commercial qui nous gérait a bien changé 5 fois en 18 mois, dont 3 fois sans qu'on soit au courant..), soit totalement abandonné et mon avis est qu'ils devaient se dire "tant qu'ils sont là, ils bossent et surtout rapportent, ça rale pas trop, on les laisse" (mourir/tranquille/seul dans leur coin)
    c'est pourtant pas faute d'avoir ralé régulièrement (~tous les mois après 8 mois), mais vu que les 3/4 des mails arrivaient dans la mauvaise boite mail (qui n'existait plus, ou du mec qui ne nous gérait plus) ...

    donc changer de projet, entreprise ou métier oui, mais uniquement si on te le demande; de ton propre chef, attends-toi à batailler (ou plus simple : à démissionner)
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  13. #13
    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 044
    Points
    32 044
    Par défaut
    Citation Envoyé par Glutinus Voir le message
    (.../...)C'est dû à l'effet tunnel. Tu penses avoir 6 mois pour faire le projet. Tu prends ton temps pour faire ton cahier des charges et merde le temps s'accélère. Finalement tu zappes les specs (on verra plus tard), les commentaires utiles (on n'a pas le temps pour ça), les tests unitaires se limitent à "ça compile = ça marche". Alors je te parle pas des consignes de merde données à l'équipe A pour une maintenance qui sera faite par B, qui va baisser les bras et fournir à C, qui va baisser les bras et faire le passage de connaissances à D... (moi j'étais dans l'équipe N)
    Franchement, à mon sens, il ne doit pas y avoir plus de 4 intervenants sur un projet :
    _le métier
    _le dev
    _le test
    _l'exploitation

    Et les 2 derniers doivent être présents du début à la fin du projet pour éviter la perte d'information à la transmission.

    Citation Envoyé par Glutinus Voir le message
    J'ai déjà bossé chez un client qui a mis en place une équipe qualité. Ouai elle nous a fait chier. Ouai elle nous a fait refaire nos devs jusqu'à qu'ils soient commentés, et pas validés si la spec n'était pas carré. On a délivré une doc fonctionnelle (oui l'AMOA nous l'avait déléguée) de 350 pages, derrière le projet en béton armé.

    Comme dit el_slapper : c'est du jetable, deux ans après c'était à la poubelle
    (.../...)
    2 ans? Mon jetable, c'était du one-shot.

    Mais peu importe : sans tout ça, votre projet n'aurait servi à rien. Là, au moins, pendant 2 ans, il a produit. Même pour du jetable, faire les choses "bien", c'est rentable. Parceque sinon on se perd en cours de route, et on a dépensé de l'argent pour un résultat zéro.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  14. #14
    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
    Citation Envoyé par Lolilolight Voir le message
    Bref moi si la SSI ne travaille pas comme ça je n'y reste pas.
    Accepter de bosser avec une SSII - et un client - c'est accepter de bosser avec ses dérives. A moins qu'on me demande de tuer, blesser quelqu'un, mouai c'est faisable. Après la plupart des SSII sont friandes qu'un simple développeur fasse le boulot du chef du projet, du concepteur, du team leader, de l'expert technique... s'il demande pas l'augmentation qui va avec.

    Citation Envoyé par Bousk Voir le message
    donc changer de projet, entreprise ou métier oui, mais uniquement si on te le demande; de ton propre chef, attends-toi à batailler (ou plus simple : à démissionner)
    Bwoah, pas compliqué.
    Un abandon de poste.
    Un drop de table en base.
    Bon, moi j'ai fait le râlage directement auprès du client, ça a pris un an, la SSII m'a même pas blamé. En même temps j'avais baissé les bras sur la fin et posté ma démission un matin de juin, deux heures après ma SSII m'a dit que je sortais de prison mission
    - 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

  15. #15
    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
    Les pires développeurs que j'ai rencontré sont ceux qui étaient formatés par les écoles d'ingé, qui ne savent pas s'adapter à d'autres outils et méthodes que celles apprises à l'école, et qui sont dans l'incapacité de trouver rapidement des solutions à une problématique. Bref, les connards prétentieux qui finissent chef de projet à 25 ans et qui te foirent tous les projets en te collant les merdes sur le dos. Quand on les mets en stress, ils perdent leurs moyens, ils sont à la limite du burn-out.

    Les meilleurs développeurs sont les vrais passionnées, qui touchent à tout et sont capables de mettre une techno adaptée et maîtrisée en face d'un besoin. Des mecs qui sont capables de maîtriser Python en un week-end, et te faire de l'Unity 3D juste pour le fun. Ce genre de mecs, il doit y en avoir 1000 en France, pas plus. Et c'est une espèce en voie de disparition qui partent au Québec tellement en France les équipes sentent trop la misère.
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

Discussions similaires

  1. Est-ce que la programmation en binôme convient à tous les développeurs ?
    Par Arsene Newman dans le forum Débats sur le développement - Le Best Of
    Réponses: 30
    Dernier message: 16/10/2014, 16h54
  2. [E-03] Vérifier que tous les caractères sont des chiffres
    Par neiluj26 dans le forum Macros et VBA Excel
    Réponses: 6
    Dernier message: 04/03/2009, 12h48
  3. Vérifier que tous les élements fils sont valables
    Par Grantoumaigr dans le forum PostgreSQL
    Réponses: 3
    Dernier message: 23/05/2008, 09h57
  4. Réponses: 2
    Dernier message: 31/08/2006, 12h20
  5. Réponses: 22
    Dernier message: 24/08/2005, 19h27

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