Affichage des résultats du sondage: Quelles sont les tâches que vous estimez les plus difficiles pour un développeur ?

Votants
152. Vous ne pouvez pas participer à ce sondage.
  • Rédiger un cahier de charges

    29 19,08%
  • Recenser et documenter les fonctionnalités

    19 12,50%
  • Concevoir une solution

    5 3,29%
  • Ecrire les tests

    21 13,82%
  • Rédiger la documentation

    29 19,08%
  • Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord

    32 21,05%
  • Travailler avec le code de quelqu'un d'autre

    69 45,39%
  • Traiter avec d’autres personnes

    17 11,18%
  • Estimer le temps nécessaire pour effectuer des tâches

    108 71,05%
  • Expliquer ce qu'on fait (ou ne fait pas)

    25 16,45%
  • Nommer correctement les choses

    31 20,39%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 4 sur 4 PremièrePremière 1234
  1. #61
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    4 787
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 787
    Points : 20 276
    Points
    20 276

    Par défaut

    Citation Envoyé par Jitou Voir le message
    OK pour la doc technique (je ne parle pas de la doc d'architecture) sauf qu'en 15 ans de projets je n'ai jamais eu à le faire ni jamais vu le faire ... après ce que l'on fait en pratique c'est que l'on commente correctement son code, ce qui sera plus utile pour un développeur après qui reprendra le code pour sa maintenance.
    ça m'est arrivé plusieurs fois qu'on me l'exige. je trouve l'exercice intéressant, ça oblige à justifier les choix qu'on a fait, et parfois on se rend compte qu'on a pas forcément choisi le meilleur chemin. Après, oui, un code auto-documenté est plus utile.
    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.

  2. #62
    Expert éminent sénior
    Avatar de Glutinus
    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    avril 2005
    Messages
    4 064
    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 : 4 064
    Points : 17 953
    Points
    17 953
    Billets dans le blog
    3

    Par défaut

    J'ai hésité entre Estimer le temps de travail et Expliquer les choses.
    Mais expliquer, je pense que c'est très possible, à terme. Bon bien sûr, quand on a une quiche devant soi qui comprend pas comment fonctionne une souris, que faire A1+A2 c'est compliqué mais qui se permet de dire que rajouter un bouton dans le formulaire qui devrait calculer le taux d'indexation de Bougrain-Dubourg par rapport aux données de Wall Street qui viendront après-demain, ça prend pas deux minutes hein.
    Il est évident que faire fonction, une requête, une page, qui semble simple parce qu'on l'a fait 100 fois, mais modulo le contexte donné et des fois des choses dont on n'est pas au courant, c'est ultra-difficile.

    Je pense que le pire qui me soit arrivé au niveau chiffrage d'un projet, c'était la méconnaissance de mon client. Effectivement, je n'avais pas pris en compte le fait que... je devais fournir un cahier de recette et des données à l'équipe d'homologation !
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!

  3. #63
    Expert éminent sénior
    Avatar de Glutinus
    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    avril 2005
    Messages
    4 064
    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 : 4 064
    Points : 17 953
    Points
    17 953
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    ça m'est arrivé plusieurs fois qu'on me l'exige. je trouve l'exercice intéressant, ça oblige à justifier les choix qu'on a fait, et parfois on se rend compte qu'on a pas forcément choisi le meilleur chemin. Après, oui, un code auto-documenté est plus utile.
    J'aime beaucoup rédiger et expliquer ce que j'ai fait.
    Mais mes clients ne voient pas toujours la chose comme ça ^^
    Il en vient cependant que je donne le minimum à savoir le dossier d'exploitation (je travaille en BI et il y a beaucoup de batchs, il faut donc que j'explique quoi faire quand tel endroit plante, qu'est-ce qui se passe à cet endroit si on écrit un fichier ou dans une table...).
    Et évidemment, expliquer à tel endroit pourquoi j'ai fait cette pirouette bizarre, ça évitera à mon successeur ou à mon moi du futur dans deux ans pourquoi casser cette brique fera effondrer l'édifice.

    Je travaille sur des ETL, j'ai dû faire le suivi de production d'un projet horrible où il y a eu un turn-over de malade... l'ETL que j'utilise est graphique, en un coup d'oeil on comprend le cheminement d'idée voir le cheminement fonctionnel. Mais chez le client ça a été fait à l'arrache, ou par des gens qui ne savaient pas l'utiliser, et il y avait une grosse requête de 4000 lignes à analyser, et bien sûr zéro commentaire ni documentation technique (mais il y avait une jolie documentation fonctionnelle et le modèle de données était plus que correct).
    Et bizarrement, l'ano que j'ai corrigée le plus vite était celle où le code était fait correctement, et surtout commenté dans chacune des briques implémentées, avec les raisons où se trouve les pièges... alors que je me faisais engueuler que je passais des jours entiers sur d'autres tout en me disant "mais en plus c'est simple, y a qu'une seule brique "
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 787
    Points : 20 276
    Points
    20 276

    Par défaut

    Citation Envoyé par Glutinus Voir le message
    (.../...)
    Je pense que le pire qui me soit arrivé au niveau chiffrage d'un projet, c'était la méconnaissance de mon client. Effectivement, je n'avais pas pris en compte le fait que... je devais fournir un cahier de recette et des données à l'équipe d'homologation !
    %*£$¤#!!!!!!

    C'est le boulot des homologateurs!!!!!! C'est moooooooon boulot, pas le tien!!!!!!!! Arrrrrrrrrgh!!!
    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. #65
    Expert éminent sénior
    Avatar de Glutinus
    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    avril 2005
    Messages
    4 064
    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 : 4 064
    Points : 17 953
    Points
    17 953
    Billets dans le blog
    3

    Par défaut

    C'est ce que j'ai essayé d'expliquer à l'équipe d'homologation...
    J'étais sur le cul quand ils m'ont dit ça, ils y croyaient dur comme faire.

    J'ai remonté ça à mon N+1 qui a remonté à mon N+2 qui discuté ferme avec le chef des homologateurs, puis comme en fait ils sont super potes depuis des années, en ont déduit que c'était ma faute et que je devais fournir ces données.

    Donc bien sûr j'ai fourni mes données de dev parce que je ne me base que sur ça, ça a posé la recette haut la main, et quand ça a planté en prod on m'a accusé de tous les maux...
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 787
    Points : 20 276
    Points
    20 276

    Par défaut

    Citation Envoyé par Glutinus Voir le message
    C'est ce que j'ai essayé d'expliquer à l'équipe d'homologation...
    J'étais sur le cul quand ils m'ont dit ça, ils y croyaient dur comme faire.

    J'ai remonté ça à mon N+1 qui a remonté à mon N+2 qui discuté ferme avec le chef des homologateurs, puis comme en fait ils sont super potes depuis des années, en ont déduit que c'était ma faute et que je devais fournir ces données.

    Donc bien sûr j'ai fourni mes données de dev parce que je ne me base que sur ça, ça a posé la recette haut la main, et quand ça a planté en prod on m'a accusé de tous les maux...
    *****ceci est une insulte autocensurée par son auteur*****. C'est quoi, leur valeur ajoutée? Suivre le cas-test comme des drones??? Merde, on a la chance de vivre dans un pays ou un testeur est quasiment aussi bien payé qu'un programmeur(à juste titre à mon sens, enfin pour les vrais), et ces mecs-là font ça?????? Ca ne leur est pas venu à l'idée que tu serais juge et partie? Que l'idée d'avoir une homologation, c'est justement d'avoir un autre regard sur l'appli? Que si ils ne sont pas plus utiles que ça, ils ne méritent pas leur paye(et risquent, à terme, de la perdre?)



    Enfin, fournir des données, à la rigueur, suivant l'appli, ça peut se comprendre. Si ce sont des testeurs purs et qu'ils ont besoin d'un référentiel(base ou autre) peuplé, ils peuvent avoir besoin de l'aide des progs. Mais le cahier de tests..... Notre valeur ajoutée, ce qui justifie notre salaire, ils te l'ont refourgué. Ah les sagouins. Et un programmeur qui demande au testeur de lui programmer l'appli, c'est quoi? Parceque c'eqst du même niveau.
    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.

  7. #67
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

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

    Informations forums :
    Inscription : avril 2007
    Messages : 25 262
    Points : 48 320
    Points
    48 320

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    C'est le boulot des homologateurs!!!!!! C'est moooooooon boulot, pas le tien!!!!!!!! Arrrrrrrrrgh!!!
    Scusez ma naiveté, mais vu que les Francais ont tendance à avoir des tonnes de postes différents dans l'IT, c'est un peu étranger pour moi. C'est quoi un homologateur? C'est un testeur?
    David Delbecq Java developer chez HMS Industrial Networks AB.     LinkedIn | Google+

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 787
    Points : 20 276
    Points
    20 276

    Par défaut

    Citation Envoyé par tchize_ Voir le message
    Scusez ma naiveté, mais vu que les Francais ont tendance à avoir des tonnes de postes différents dans l'IT, c'est un peu étranger pour moi. C'est quoi un homologateur? C'est un testeur?
    Un testeur capable d'écrire son propre cahier de tests en partant des specs. Après, on trouve, en effet, différentes appellations : testeur, recetteur, homologateur, validateur, tout ça c'est pareil : on passe après les programmeurs(de préférence juste après en essayant de faire un retour aussi rapide que possible) et on chasse le bug avec vice et sadisme.
    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.

  9. #69
    Membre expérimenté
    Avatar de mumen
    Homme Profil pro
    Développement à façon multisecteur.
    Inscrit en
    mars 2004
    Messages
    547
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France

    Informations professionnelles :
    Activité : Développement à façon multisecteur.

    Informations forums :
    Inscription : mars 2004
    Messages : 547
    Points : 1 334
    Points
    1 334

    Par défaut

    1. Nommer correctement les choses.
    2. Nommer correctement les choses.
    3. Nommer correctement les choses.

    Je plaisante à peine, selon moi, la tâche dont découlent toutes les autres, c'est de nommer tout, les entités, les procédures, les modules, les requêtes, etc. Il faut être capable de revenir sur un nommage - capable veut dire : comprendre les conséquences et avoir les outils. Quand on nomme mal, on se dit "ceci veut dire cela qui n'a pas vraiment de nom pour moi, je m'en rappellerai", mais cela ne marche jamais, on oublie et on galère à retrouver, on désagrège de la puissance de travail pour le vrai travail du jour. Le travail d'analyse en clientèle est parfois une torture pour l'esprit (du client, oups), mais en programmation, comme partout ailleurs, en science, en philosophie, etc., le nommage correct est la fondation, le socle de toute construction.

    Je comprends donc très bien les 50% du camembert à ce sujet.

    Nakedata : La démo.

    ·

Discussions similaires

  1. Réponses: 42
    Dernier message: 07/08/2009, 22h11
  2. Réponses: 16
    Dernier message: 19/05/2005, 17h20

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