Discussion :

[mamadoudou]

Pas fatiguant.. physiquement, ok. Mais ça ne t'arrive jamais d'être rincée le soir ?

non très rarement.
Franchement je ne pense pas que se soit un métier fatiguant, au contraire meme plus un algo est complexe plus cela stimule mon cerveau et me donne du plaisir pour travailler.
Bon c'est sur que si je devais développer des IHM ou des pages web, des taches que je trouve rébarbative & inintéressante oui je pense que je serais content de finir ma journée, mais des gens doivent je pense aimer coder des IHM ou des pages, ils en faut pour tous gout.

Je trouve que travailler en open space c'est clairement tuant pour les nerfs. Et je perds beaucoup en capacité de travail...
Pour le choix de mon prochain travail, ca sera l'un de mes critères déterminants

Dans ma boite, nous sommes dans des mini open space (des open space de 15max) c'est 1 open space / équipe et je trouve que c'est bien plus efficace comme méthode travail que chacun enfermé dans son bureau.
Il est idiot d'etre dans un grand open space a coté du comptable ou du service marketing, mais il est pertinent d’être dans des open space centré sur ton métier (etre avec les gens de ton équipe)

si tu veux comparer, il faut le faire par rapport aux métiers qui demandent le même niveau d'étude.
Comparer le salaire d'un ingénieur bac+5 avec celui d'un médecin bac+12 n'a aucun sens de même que la comparaison avec celui d'un métier ouvrier nécessitant bac-2 (aucun jugement vis à vis des ouvriers, les 3/4 de ma famille l'est à commencer par mes parents)

En province, un ingénieur chimiste (bac+5) démarre en sortie d'école entre 36 et 40k€ brut annuel

Pour tes 31k€, c'est sur Paris ou en province ?

Je pensais que mon message était clair : sortie d'un master en info, donc bac +5 et en province, donc oui je bosse en province
visiblement c'est le meme salaire qu'il y'a 10ans, cela n'a pas évolué.

Moi je vois dans l'info des avantages, déja tu peut faire de la veille techno dans ta boite, combien de gens ici vont sur ce site au lieu de bosser la journée ? beaucoup.
Ensuite le grand avantage c'est de travailler sur des projets de manière incrémentale (méthode agile notamment) je trouve que c'est bien mieux que de travailler sur un projet avec toute les specs écrite a l'avance (comme dans la fabrication d'un avion)
cela permet de discuter avec le client, de le comprendre...etc. c'est bien plus humain que de suivre un cahier des charges sans se poser de question comme un zombie.
et enfin avec l'info on peut mettre son travail en pause, je opeut dans ma boite partir en vacannce quand je veut nottament, ou repôrter une features au sprint suivant, c'est pas comme une maison, en info on peut construire d'abord le toi et ensuite les fondations et assemblé le tous sans probleme.

[foetus]

Je ne pense pas que se soit un métier fatiguant, au contraire meme plus un algo est complexe plus cela stimule mon cerveau et me donne du plaisir pour travailler.

LOL je voudrais bien voir la tronche de tes algos.

développer des IHM ou des pages web, des taches que je trouve rébarbative & inintéressante

Tu te trompes : tu touches au graphisme, à l'ergonomie, à l'animation, à l'interaction.

sortie d'un master en info, donc bac +5

Non master+2, parce que master+1 (anciennement maîtrise) c'est bac+4

combien de gens ici vont sur ce site au lieu de bosser la journée ? beaucoup.

Et alors , lorsque tu vas sur Internet pour travailler, vérifier les nouveaux messages ne prend que 30 secondes.
Moi, par exemple, je ne fume pas et je ne bois [presque] pas de café (... je suis chiant oui ) et je peux rester à mon poste 5 heures durant sans souci.

Ensuite le grand avantage c'est de travailler sur des projets de manière incrémentale (méthode agile notamment) je trouve que c'est bien mieux que de travailler sur un projet avec toute les specs écrite a l'avance

jusqu'au jour on te demande une évolution qui pouvait être prévue, mais pas prise en compte parce que pas de cahier de charges : localisations, changement de sgbd, intégration de la sécurité, ...

en info on peut construire d'abord le toi et ensuite les fondations et assemblé le tous sans probleme.

J'ai ri

Certaines tâches sont bloquantes comme un système de bassins ("pools") ou la mise en place du sgdb (<- ou à moins d'arriver à faire une [très] grosse abstraction dès le départ)

[yolle]

je suis développeuse (ingénieure développement logiciel)
j'ai finis mon master l'année dernière et j'ai été embauché en juillet 2017 en province comme ingénieure développement logiciel java pour 31000€

Aviez vous ce salaire quand vous aviez commencé il y'a 10ans/20ans ?

Perso j'estime que 31000 c'est bien payé pour un métier pas fatiguant (je suis assise toute la journée dans un bureau climatisé), quand on le compare a d'autres métiers comme celui de mon copain (ouvrier btp)

Embauché en juillet 2017 ? attends quelques années (pas beaucoup, 2 ou 3) et tu vas rapidement déchanter .....

[Coeur De Roses]

non très rarement.
Franchement je ne pense pas que se soit un métier fatiguant, au contraire meme plus un algo est complexe plus cela stimule mon cerveau et me donne du plaisir pour travailler.
Bon c'est sur que si je devais développer des IHM ou des pages web, des taches que je trouve rébarbative & inintéressante oui je pense que je serais content de finir ma journée, mais des gens doivent je pense aimer coder des IHM ou des pages, ils en faut pour tous gout.

Dans ma boite, nous sommes dans des mini open space (des open space de 15max) c'est 1 open space / équipe et je trouve que c'est bien plus efficace comme méthode travail que chacun enfermé dans son bureau.
Il est idiot d'etre dans un grand open space a coté du comptable ou du service marketing, mais il est pertinent d’être dans des open space centré sur ton métier (etre avec les gens de ton équipe)


Je pensais que mon message était clair : sortie d'un master en info, donc bac +5 et en province, donc oui je bosse en province
visiblement c'est le meme salaire qu'il y'a 10ans, cela n'a pas évolué.

Moi je vois dans l'info des avantages, déja tu peut faire de la veille techno dans ta boite, combien de gens ici vont sur ce site au lieu de bosser la journée ? beaucoup.
Ensuite le grand avantage c'est de travailler sur des projets de manière incrémentale (méthode agile notamment) je trouve que c'est bien mieux que de travailler sur un projet avec toute les specs écrite a l'avance (comme dans la fabrication d'un avion)
cela permet de discuter avec le client, de le comprendre...etc. c'est bien plus humain que de suivre un cahier des charges sans se poser de question comme un zombie.
et enfin avec l'info on peut mettre son travail en pause, je opeut dans ma boite partir en vacannce quand je veut nottament, ou repôrter une features au sprint suivant, c'est pas comme une maison, en info on peut construire d'abord le toi et ensuite les fondations et assemblé le tous sans probleme.

Bonjour mamadoudou, plutôt fun comme nom.
N'écoute pas certaines personnes sur ce forum te décourager ou se moquer de toi. Garde ta bonne humeur et ton enthousiame. Si certains développeurs pêtent des câbles sur leur travail c'est leur problème, pas le tiens, tout le monde n'aborde pas les choses de la même manière en environnement professionnel. Sois forte, intelligente et enthousiaste comme tu l'est maintenant, bon courage.

[Zefling]

non très rarement.
Franchement je ne pense pas que se soit un métier fatiguant, au contraire meme plus un algo est complexe plus cela stimule mon cerveau et me donne du plaisir pour travailler.

Récemment j'ai passé 2 journée à faire une p*t**n d’installation sous Mac (résultat ça marche pas, en même temps je n'ai aucune formation Mac). Je peux te dire que j'en pouvais plus, c'était lessivant : chercher sur Google, lire de la doc, essayer un truc qui ne marche pas, faire un truc recherche, lire de la doc, essayer un autre truc qui ne marche pas, etc. (Fait ça 8 h dans la journée, tu verras c'est passionnant)
Quand je bosse sur des trucs intéressants, ça passe, je ne vois même pas le temps passer, mais quand c'est sur des trucs chiant à mourir, c'est autre chose. Franchement j'ai eu l'impression de faire une semaine en deux jours. Il ne fallait surtout pas de parler de Mac.

jusqu'au jour on te demande une évolution qui pouvait être prévue, mais pas prise en compte parce que pas de cahier de charges : localisations, changement de sgbd, intégration de la sécurité, ...

Tu résumes bien ma vie.

Par contre, en ce moment c'est plutôt, on a lancé un projet puis on fait la R&D 2 ans après pour faire un truc qui aurait dû fait dès le début. Forcement, sur un projet qui a 2 ans, les contraintes sont devenus colossales.

Visiblement, il y en a qui vivent dans le monde des Bisounours.

[yento]

Embauché en septembre 2017 à Lyon en sortant d'école d'ingé à 35k sans négociation de ma part.
Je suis surpris des salaires parisiens que je vois sur ce topic. Ca me semble très bas.

T'as eu la chance d'avoir la bonne ecole ET la bonne entreprise. La norme est plus proche de 30k pour le reste du monde.

[Mat.M]

L'être humain est un éternel insatisfait donc rien de surprenant.

ça c'est vite dit...il faut être conscient des réalités.
Admettons que tu touches 1000euros aujourd'hui le 04 août 2018, avec l'inflation, tes 1000euros ne vaudront plus que 800 euros dans des 10 ans ( avec 2% annuels )...d'où une grosse perte en pouvoir d'achat.
De toute façon dans la vie tout finit par coûter (je ne vais pas utiliser des arguments populos ) : l'essence pour ta voiture, les contraventions que tu prends si tu est mal garé ,l'électricité...etc

[Jamatronic]

Ah la la ! Le développeur français !

* Il est BAC + 5. Si possible "ingénieur".
* Mais il est payé comme un BAC + 3
* Et il réalise quotidiennement des tâches de niveau BAC - 3 (se servir d'APIs et autres SGBDr pour faire du CRUD, par exemple).

Et il râle parce qu'il n'est payé "que" comme un BAC + 3.

Je hais les golios qui se plaignent alors qu'ils n'ont rien d'autre à faire que se lever le matin pour être heureux.

[koyosama]

je suis développeuse (ingénieure développement logiciel)
j'ai finis mon master l'année dernière et j'ai été embauché en juillet 2017 en province comme ingénieure développement logiciel java pour 31000€

Aviez vous ce salaire quand vous aviez commencé il y'a 10ans/20ans ?

Perso j'estime que 31000 c'est bien payé pour un métier pas fatiguant (je suis assise toute la journée dans un bureau climatisé), quand on le compare a d'autres métiers comme celui de mon copain (ouvrier btp)

Deja c'est 31000 tu t'es fait un peu arnaque, je gagnais plus a ma sortie. Ensuite, je sais pas comment tu travaiiles, surquoi tu travailles et a qule rythme tu travailles.
Je travaille sur des données qui peut impacter la moitie d'un continent. Je fais 8 heures par jour et a la fin de la journée, j'ai plus de force mental pour continuer.

Les autres jobs sont peut-etre okay ou pas mieux renumerés. C'est un réalité, j'ai fait ces jobs là aussi. Mais un métier de dévéloppeur demande beaucoup de mantra quand tu fais des choses compliqués. Ou alors on fait pas du tout le même métier. Concevoir, debugger, détruire, réfactorer, TESTER, écrire de la docs... tu dois avoir de la discipline, de l'imagination, de la créativité, une vision du futur de tes multiples projet, tu dois demander, chercher, comprendre, décider, dialoguer (avec finesse à la bonne personne). C'est impossible que tu ne sois fatiguer mentalement. La prise descision doit rapide, efficace et durable, c'est le plus gros challenge avec des moyens quasi de zero.

J'ai fait les jobs alimentaires comme tout le monde, je travaillais 10 heures le soir (5h mat et 5 matin) pour 40 heures parsemaine en temps normal et 55h pendant les periodes de fetes et je codais 4h la journée et j'avais ce rythme pendant presque deux ans avant d'avoir mon poste en informatique, c'est rien. Etant un penseur, reveur, tu as le bore-out seulement, mais tu as juste physiquement, ça s'est facile entretenir. Mais c'est pas aussi épuisant mentalement. Au bout d'un moment mon corps s'habituait. Crois-moi c'est pas dure, c'est juste accepter l'ennui.

Moi les descisions que je prends impacte le futur, presque tout le temps tu as l'impression de jouer a Game of Throne alors que tu veux juste le bien du projet et l'informatique n'est pas considere par les gens d'en haut. Tu es encore jeune, tu vas découvrir le monde comme tout le monde.

[kedare]

Embauché en septembre 2017 à Lyon en sortant d'école d'ingé à 35k sans négociation de ma part.
Je suis surpris des salaires parisiens que je vois sur ce topic. Ca me semble très bas.

Je confirme... Quand je vois les salaires ici, je me dit que c'est pas si mal ce que j'ai... Commencé en 2014 à Paris pour 32k (avec un BTS seulement, j'étais accepté en école d'ingénieur mais le programme me paraissait bien chiant vu que en gros j'avais déjà travaillé en production sur quasiment tout les sujets des 3 années donc je n'ai pas accepté et signé commencé à bosser, et j'apprends bien mieux par moi même ou en entreprise qu'en école), et aujourd'hui à Barcelone pour plus de 50k (Après j'ai un ensemble de compétences assez complexes a trouver donc ça doit sûrement jouer aussi).
Je dirait que le plus important pour avoir un bon salaire c'est de vraiment bien négocier (si l'entreprise veux vous embaucher elle vous donnera le salaire que vous voulez ou au moins le maximum qu'ils sont autorisés à vous payer par les RH) et surtout fuir les SSII comme la peste.
Après l'Espagne a aussi l'avantage de pas avoir cette mentalité des diplômes comme en France, pas de grille de salaire non plus,net environnement beaucoup plus dynamique qu'en France (à Barcelone en tout cas).

[mamadoudou]

Bonjour mamadoudou, plutôt fun comme nom.
N'écoute pas certaines personnes sur ce forum te décourager ou se moquer de toi. Garde ta bonne humeur et ton enthousiame. Si certains développeurs pêtent des câbles sur leur travail c'est leur problème, pas le tiens, tout le monde n'aborde pas les choses de la même manière en environnement professionnel. Sois forte, intelligente et enthousiaste comme tu l'est maintenant, bon courage.

merci
je pense en effet au vue des réponses a mon commentaires que beaucoup ici sont mal orienté.

Ils se disent "fatigué" la fin de la journée, mais quel métier ne l'est pas ?
Moi aussi je bosse 8h/jours et c'est peu, oui 36h/semaines c'est le minimum pour un cadre !

et enfin la remaruqe qui me fait sursauté :

Récemment j'ai passé 2 journée à faire une p*t**n d’installation sous Mac (résultat ça marche pas, en même temps je n'ai aucune formation Mac). Je peux te dire que j'en pouvais plus, c'était lessivant : chercher sur Google, lire de la doc, essayer un truc qui ne marche pas, faire un truc recherche, lire de la doc, essayer un autre truc qui ne marche pas, etc. (Fait ça 8 h dans la journée, tu verras c'est passionnant)

cette semaine j'ai passé 4 jours pour faire fonctionner un cluster hadoop et faire de l'analytics sur 34To de données.
Oui c'est frustrant que sa ne marche pas... mais c'est le métier, moi j'aime bien ces difficultés, si tous était facile le métier serait chiant.

Je ne répondrais pas au message de foetus qui n'est que de la provocation voir meme je le trouve insultant. Je répondrais de ced torchon juste a une phrase :

jusqu'au jour on te demande une évolution qui pouvait être prévue, mais pas prise en compte parce que pas de cahier de charges : localisations, changement de sgbd, intégration de la sécurité, ...

C'est justement ce qui m'arrive chaque jours !
Je ne sais pas ce que le projet deviendra demain, je dois répondre aux besoins de clients qui évolue chaque semaine en fonction des solutions que je leurs apporte.
J'ai par exemple migré de Hbase vers Cassandra il y'a peu.

Le waterfall c'est fini depuis 20 ans en informatique, le principe meme des méthodes agiles c'est de travailler de manière incrémentale. Si tu ne le sais pas sache de par mon expérience qu'un projet informatique originel ne ressemble jamais au projet finale



ceux qui n'aiment pas la difficulté notamment l'installation/configuration des outils ou bien qui croient que l'informatique c'est la réalisation de projet 100% définis dans le cahier des charges, je pense qu'ils sont mal orienté car l'informatique ce n'est absolument pas cela.
Vous devriez vous convertir pour etre ingénieur en aéronautique ou bien travailler dans le social.

[foetus]

le principe meme des méthodes agiles c'est de travailler de manière incrémentale. Si tu ne le sais pas sache de par mon expérience qu'un projet informatique originel ne ressemble jamais au projet finale

Perdu mais je ne t'en veux pas parce que tu n'as que 1-2 ans d'expérience en pseudo MOA (parce que ta boite a trouvé une dév-MOA-administrateur voire plus )

Le but des méthodes agiles, c'est, en gros, on s'est rendu compte que certains projets ne nécessitaient pas 1 an, 2 ans ou plus de développement (avec le fameux "effet de tunnel") et qu'on pouvait "faire un projet" plus rapidement (*), et donc potentiellement s'adapter plus rapidement aux demandes/ changements du client.
Et cela passe par des méthodes de développement qui garantissent un logiciel toujours robuste en adoptant les pratiques dites "agiles" : revue de pair, pair programming, tests unitaires, itérations courtes, refactoring, ...
L'incrémental est important parce qu'il permet de ne pas planter le projet trop longtemps en cas d'imprévu : une tâche qui nécessite soit plus de temps soit terminée plus tôt, une erreur de conception, un changement de budget, ...
Pour moi, l'incrémental ne veut pas dire "prendre en compte toutes les demandes du client'.

Je te signale que les méthodes cycle en V et RAD sont aussi incrémentales


*, Édit : comme le signale dad3zero , c'est du moins d'avoir des versions fonctionnelles mais pas forcément complètes le plus rapidement.

ceux qui n'aiment pas la difficulté notamment l'installation/configuration des outils ou bien qui croient que l'informatique c'est la réalisation de projet 100% définis dans le cahier des charges, je pense qu'ils sont mal orienté car l'informatique ce n'est absolument pas cela.
Vous devriez vous convertir pour etre ingénieur en aéronautique ou bien travailler dans le social.

Cela dépend de la société. Dans certaines tu ne peux même pas installer un notepad++ et chaque connexion est logguée.

Donc bon, ton cas n'est ni rare, ni unique ni normal ni spécifique

[dad3zero]

Moi les descisions que je prends impacte le futur

Whaw, c'est bô
J'imagine la pression, la responsabilité, le risque… Dire que jusqu'ici j'avais de l'admiration pour les jobs comme aide-soignante, pompier, militaire en opex… Mais là, en une phrase, on se rend compte de tout le poids qu'un dev porte sur ses épaules…

[dad3zero]

Le waterfall c'est fini depuis 20 ans en informatique, le principe meme des méthodes agiles c'est de travailler de manière incrémentale. Si tu ne le sais pas sache de par mon expérience qu'un projet informatique originel ne ressemble jamais au projet finale

Heu…*"votre expérience", à ce que je lis plus haut est de… 1 an ? Allez, 3 si je compte les stages ? Je prends la mienne qui de 20 ans, 22 avec les stages, laquelle dois-je considérer comme plus significative ?

Lorsque vous êtes sur des projets qui à l'état final n'ont rien à voir avec l'initial (j'insiste sur le "rien"), je n'ose même pas qualifier ça d'un projet… Dans de nombreux domaines, le projet informatique est une partie du produit, il s'inscrit dans un produit final. J'ignore le sous entendu du "Le waterfall c'est fini depuis 20 ans en informatique", mais dans le cas que vous écrivez, l'explosion des couts que l'on pouvait avoir avec un effet tunnel (qui n'a rien à voir avec Waterfall en soi) est identique…

Sinon, le principe des méthodes Agiles, c'est avant tout de vendre du consulting et du coaching.

ceux […] qui croient que l'informatique c'est la réalisation de projet 100% définis dans le cahier des charges, je pense qu'ils sont mal orienté car l'informatique ce n'est absolument pas cela.
Vous devriez vous convertir pour etre ingénieur en aéronautique ou bien travailler dans le social.

Ou alors d'essayer d'inciter ses collègues à de la rigueur et à la production de qualité. En effet, tant que ça manquera dans le dev, les projets iront dans tous les sens…

Le but des méthodes agiles, c'est, en gros, on s'est rendu compte que certains projets ne nécessitaient pas 1-2 ans de développement (avec le fameux "effet de tunnel") et qu'on pouvait "faire un projet" plus rapidement, et donc potentiellement s'adapter plus rapidement aux demandes/ changements du client.

"Plus rapidement" ? Quand je lis de la part de coachs Scrum Master que la méthode Scrum, considérée comme la méthode Agile du moment, a besoin entre 3 et 7 itération pour commencer à permettre d'évaluer la vélocité, soit avec des sprints en moyenne de 2 semaines, entre 6 et 14 semaines soit 1,5 mois et 3,5 mois, c'est surtout une pratique pour les projets très longs…
Et pour avoir eu des projets dans l'évènementiel avec des délais très courts et des exigences changeantes, on n'a pas le temps pour tous les rituels de l'Agilité…

Et cela passe par des méthodes de développement qui garantissent un logiciel toujours robuste : revue de pair, pair programming, tests unitaires, itérations courtes, refactoring

Question : quelle est le rapport entre la partie gauche et droite de vos deux points ?

[foetus]

Et pour avoir eu des projets dans l'évènementiel avec des délais très courts et des exigences changeantes, on n'a pas le temps pour tous les rituels de l'Agilité…

Il y a déjà l'Extrem Programming (XP) pour cela ... mais il y a de [grosses] contraintes

Mais en France, lorsque les gens (*) connaissent cette méthode, dans leur cerveau c'est direct : "Travail de m$rd$ fait à l'arrache comme un gros goret"
Et d'ailleurs ce n'est pas vraiment une méthode, mais un ensemble de pratiques, d'où sa difficulté pour l'appliquer.

Et d'ailleurs, c'est peut-être pour cela que l'XP n'est pas aimé : cette méthode est essentiellement axée sur le développement avec un peu gestion.
Là, où SCRUM n'est quasi que de la gestion. En France, on kiffe la gestion, la gestion


* : et surtout les recruteurs qui eux s'y connaissent

Question : quelle est le rapport entre la partie gauche et droite de vos deux points ?

À droite, c'est l'ensemble des pratiques dites "agiles" que l'on adopte pour avoir un logiciel robuste

[mamadoudou]

Perdu mais je ne t'en veux pas parce que tu n'as que 1-2 ans d'expérience en pseudo MOA (parce que ta boite a trouvé une dév-MOA-administrateur voire plus )

Le but des méthodes agiles, c'est, en gros, on s'est rendu compte que certains projets ne nécessitaient pas 1 an, 2 ans ou plus de développement (avec le fameux "effet de tunnel") et qu'on pouvait "faire un projet" plus rapidement (*), et donc potentiellement s'adapter plus rapidement aux demandes/ changements du client.
Et cela passe par des méthodes de développement qui garantissent un logiciel toujours robuste en adoptant les pratiques dites "agiles" : revue de pair, pair programming, tests unitaires, itérations courtes, refactoring, ...

Si tu veut du robuste il faut surtout mettre en place du test driven development.

Sinon ce que vous dite n'est pas faux mais non, les méthodes agiles ont surtout été mis en place parce que l'informatique c'est pas une science exacte, contrairement a la fabrication d'un avion ou d'un bâtiment, tu ne sais pas a l'avance ce que le client veut concrètement.

d'ou l'interet des méthodes agiles, qui fonctionne en partant du postulat que le client ne sais pas ce qu'il veut et donc que le projet final ressemble peu a ce qu'il a imaginé au départ sur la forme j'entand pas dans le fond.
Le client veut par exemple un logiciel de monitoring, il aura un logiciel de monitoring, mais ce qui vas changer c'est la qt de données de traité, les solutions pour stocker des données (sgbd), une fonctionnalité d'analyse prédictive (ia)...etc.
au départ mon client voulais juste voir ces données sur un graphique et au final 2ans plus tard il a eu un gros logiciel d'analyse prédictivie (c'est ce qu'il a voulue avec le temps son besoin a changé)

https://agiliste.fr/introduction-methodes-agiles/

Une approche dite "traditionnelle" attend généralement du client une expression détaillée et validée du besoin en entrée de réalisation, laissant peu de place au changement. La réalisation dure le temps qu'il faut et le rendez vous est repris avec le client pour la recette. Cet effet tunnel peut être très néfaste et conflictuel, on constate souvent un déphasage entre le besoin initial et l'application réalisée. On se rapporte alors aux spécifications validées et au contrat. Certains projets se terminent dans la douleur (surtout dans le cadre d'un contrat au forfait classique) au risque de compromettre la relation client. De plus il n'est pas rare que certaines fonctionnalités demandées se révèlent finalement inutiles à l'usage alors que d'autres, découvertes en cours de route, auraient pu donner plus de valeur au produit.

[Invité]

tu ne sais pas a l'avance ce que le client veut concrètement.[/url]

je dirais plutôt que c'est le client qui ne sait pas à l'avance ce qu'il veut vraiment.

Sinon il y a aussi la méthode de développement la R.A.C.H.E. ( https://www.la-rache.com/ ) couramment employée mais rarement nommée clairement.

[Glutinus]

je dirais plutôt que c'est le client qui ne sait pas à l'avance ce qu'il veut vraiment.

Sinon il y a aussi la méthode de développement la R.A.C.H.E. ( https://www.la-rache.com/ ) couramment employée mais rarement nommée clairement.

Bien joué 7gy, exactement les deux points que j'allais évoqué
Sinon, que dire... ne soyez pas difficile envers mamadoudou. Moi aussi j'ai pensé pareil quand j'ai commencé à bosser. 8h45-18h30, et le plus fatigant c'est les transports. Aujourd'hui, je dois faire 9h37 - 18h02 (à la grosse louche), et je vais au boulot à pied, mais je marche beaucoup. Et je peste sur le salaire, car quand tu vois le gusse qui gesticule dans le bureau à côté et qui est payé / facturé plus par rapport à toi, tu t'aperçois que si ton travail ne vaut pas autant, ton brassage de vent devrait valoir plus.

La mode aujourd'hui : les DBO (grosso modo, les gourous de la RGPD), parfois des pantins de SSII en reformation, qui ne savent pas faire la différence entre une anonymisation et une pseudonimisation, mais qui derrière ont le double de ta factu.

[dad3zero]

Et d'ailleurs ce n'est pas vraiment une méthode, mais un ensemble de pratiques, d'où sa difficulté pour l'appliquer.

C'est ce que j'ai toujours trouvé intéressant dans ces pratiques : elles sont apparues car les informaticiens sont incapables de suivre des process et en conséquence, on propose des pratiques qui s'affranchissent des process par des process…

À droite, c'est l'ensemble des pratiques dites "agiles" que l'on adopte pour avoir un logiciel robuste

Je connais la phrase d'accroche de toutes les plaquettes des consultants Agilistes, mais dans l'état, si je remplace tout ce qui est à droite par "apero, piscine, babyfoot", j'ai une phrase tout aussi cool avec les mêmes conséquences de cause à effet…

[dad3zero]

Si tu veut du robuste il faut surtout mettre en place du test driven development.

Ouh, je crois que je vais aller me faire des pop-corns…

En quoi le TDD permet la robustesse ? En fait, il faudrait avant définir "robustesse"…

les méthodes agiles ont surtout été mis en place parce que l'informatique c'est pas une science exacte

L'informatique n'est pas une science exacte… Il faudrait peut-être revoir la définition de science exacte et science molle. Oh, après tout…

contrairement a la fabrication d'un avion ou d'un bâtiment, tu ne sais pas a l'avance ce que le client veut concrètement.

Ok, en effet, donc si l'informatique relève des sciences humaines c'est du fait qu'elle nécessite l'expression d'un besoin… Comme le bâtiment et l'aéronautique en fait…

Bon, ben en fait, c'est surtout pour compenser la gestion chaotique de projets…

d'ou l'interet des méthodes agiles, qui fonctionne en partant du postulat que le client ne sais pas ce qu'il veut

Oh c'est bien come postulat ça…*en fait, c'est en partant de ce postulat que l'informaticien ne lit jamais les specs pour arriver à la conclusion que le client ne sait pas ce qu'il vaut alors que c'est avant tout qu'il n'a rien compris à son besoin…

(c'est ce qu'il a voulue avec le temps son besoin a changé)

Alors question : c'est son besoin qui a changé ou sa demande ? Parce qu'avant de faire un projet de prédiction, perso, je lance un projet de collecte de données. Si on arrive à quelque chose, on fait évoluer. C'est la base de l'outillage.

P.S. Dans votre citation, un truc comme ça

La réalisation dure le temps qu'il faut et le rendez vous est repris avec le client pour la recette

est spécifique à l'informatique. Vous citez le BTP, mais le BTP a des réunions de chantier régulières (pour ne pas dire toutes les semaines). Le projet est corrigé au fur et à mesure de son avancement même si il faut démolir un mur car pas droit. Si cela tient dans le budget évidemment. Il n'y a pas besoin d'agilité pour ne pas avoir d'effet tunnel…