Discussion :

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

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

[Auteur]

Tu travailles dans une SSII ?

[Deaf]

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

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

[el_slapper]

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.

[Zirak]

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.

[Glutinus]

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

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 ^^

- 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

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.

[Zirak]

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

[Invité]

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

[Mat.M]

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

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

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

[foetus]

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

[Barsy]

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

[Bousk]

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)

[el_slapper]

(.../...)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.

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.

[Glutinus]

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.

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

[zecreator]

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.