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 3 sur 4 PremièrePremière 1234 DernièreDernière
  1. #41
    Membre confirmé

    Homme Profil pro
    Étudiant
    Inscrit en
    août 2014
    Messages
    257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : Burkina Faso

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : août 2014
    Messages : 257
    Points : 520
    Points
    520

    Par défaut

    Qu'entendez vous par :
    nommer correctement les choses ?
    Je ne pense en aucun cas que cela soit un problème. Chacun nomme ses variables,
    ses méthodes, ses classes, ses tables, ses ... selon son inspiration. A ce que je sache il n'ya
    pas non de norme de nommage ! Alors où se trouve le problème ?
    A mon avis, le dure quand on est developpeur c'est pouvoir se faire comprendre par un client
    qui ignore tout du developpement. !
    Aujourd'hui apprenant, demain appreneur.
    Faites preuve d'indulgence envers moi!

  2. #42
    Membre confirmé

    Homme Profil pro
    Consultant en architecture
    Inscrit en
    décembre 2013
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant en architecture
    Secteur : Conseil

    Informations forums :
    Inscription : décembre 2013
    Messages : 79
    Points : 567
    Points
    567
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par dk Voir le message
    Résultats intéressants. Ce qui me frappe c'est le point "concevoir une solution" : 0.92% / 2% Il n'y que des archi qui ont répondu au questionnaire ou quoi ?
    Au taf je réalise beaucoup de revue de code / conception, s'il y a un problème récurrent, c'est bien la conception, et effectivement ensuite le nommage, ce qui est lié parce que les devs ne saisissent pas toujours très bien ce qu'ils implémentent, ni comment ils l'implémentent. Vive l'auto évaluation en somme
    Je me suis dit exactement la même chose, même si ça augmenté pour atteindre 5%. (A voté )

    Je ne comprends absolument pas comment on peut avoir du mal à nommer les choses, mais ne pas avoir de mal à concevoir une solution.. La première étape pour concevoir une bonne solution, c'est de bien formuler son problème, avec le bon mot sur la bonne notion.

    Pour reprendre une célèbre citation de ce cher Boileau :
    Citation Envoyé par Boileau
    Ce qui se conçoit bien s’énonce clairement

  3. #43
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 839
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 839
    Points : 5 805
    Points
    5 805
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par GeoffreyOnRails Voir le message
    Je ne comprends absolument pas comment on peut avoir du mal à nommer les choses, mais ne pas avoir de mal à concevoir une solution.. La première étape pour concevoir une bonne solution, c'est de bien formuler son problème, avec le bon mot sur la bonne notion.
    C'est peut-être là toute la subtilité : si tu cherches juste une solution (et non forcément une solution qui passe certains critères de qualité), rien ne t'empêche d'en faire une à l'intuition, sans vraiment chercher d'explication. Après quoi, quand tu revois le code pour le nettoyer un peu, tu te rends comptes que c'est pas super clair et qu'il est difficile de mettre en terme sur les concepts que tu as utilisé. Mais ça marche quand même.

    Dans le domaine de l'expertise, je ferai le parallèle avec le fait que les experts ont souvent de la difficulté à expliciter leurs pensées, en particulier parce qu'ils ont automatisé leurs comportements. Notamment, quelqu'un ayant de la bouteille te trouveras rapidement des (bonnes) solutions, mais si tu lui demandes d'expliquer pourquoi ou comment ça marche, ce n'est qu'à ce moment là qu'il cherchera effectivement les règles sur lesquelles sa solution se base, pas avant (car la solution lui paraît juste évidente). Autrement dit, si la majorité des répondants sont des gens qui ont déjà une expérience bien ancrée, il me semble logique de voir une tendance "facilité de conception + difficulté de nommage" (la réciproque par contre n'est pas vraie {^_^}).
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 620
    Points : 19 047
    Points
    19 047

    Par défaut

    Citation Envoyé par Matthieu Vergne Voir le message
    C'est peut-être là toute la subtilité : si tu cherches juste une solution (et non forcément une solution qui passe certains critères de qualité), rien ne t'empêche d'en faire une à l'intuition, sans vraiment chercher d'explication. Après quoi, quand tu revois le code pour le nettoyer un peu, tu te rends comptes que c'est pas super clair et qu'il est difficile de mettre en terme sur les concepts que tu as utilisé. Mais ça marche quand même.

    Dans le domaine de l'expertise, je ferai le parallèle avec le fait que les experts ont souvent de la difficulté à expliciter leurs pensées, en particulier parce qu'ils ont automatisé leurs comportements. Notamment, quelqu'un ayant de la bouteille te trouveras rapidement des (bonnes) solutions, mais si tu lui demandes d'expliquer pourquoi ou comment ça marche, ce n'est qu'à ce moment là qu'il cherchera effectivement les règles sur lesquelles sa solution se base, pas avant (car la solution lui paraît juste évidente). Autrement dit, si la majorité des répondants sont des gens qui ont déjà une expérience bien ancrée, il me semble logique de voir une tendance "facilité de conception + difficulté de nommage" (la réciproque par contre n'est pas vraie {^_^}).

    +1

    Dans les domaines ou je suis bon(je ne me vante pas, tout le monde en a, et il y a plein de domaines, y compris professionnels, ou j'en suis loin), la solution me vient souvent naturellement à l'esprit. Avant même que les autres n'aient compris le problème.
    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. #45
    Membre confirmé Avatar de Cincinnatus
    Homme Profil pro
    Développeur Java
    Inscrit en
    mars 2007
    Messages
    200
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Service public

    Informations forums :
    Inscription : mars 2007
    Messages : 200
    Points : 571
    Points
    571

    Par défaut

    Citation Envoyé par Mat.M Voir le message
    bonjour les tâches les plus difficiles essentiellement pour un développeur c'est de

    comprendre précisément le métier du client dans le service informatique
    si vous travaillez dans la banque il faut comprendre un minimum les métiers de la banque.

    pouvoir conceptualiser , aller dans l'abstraction...avoir une vision globale d'un projet...

    de ce qui est indiqué précédemment analyser un problème complexe et le décomposer en problèmes simples donc découper en modules.
    reprendre le code de quelqu'un d'autre surtout s'il y a des tonnes de copier-coller avec du code redondant et aucun refactoring.

    ce qui quelque part rejoint les avis précédents.
    Etant donné que "ce qui se conçoit aisément s'énonce clairement" effectivement nommer ce que l'on fait peut être difficile je ne suis pas étonné par les résultats du graphique


    des projets que l'on est pas capable d'expliquer j'ai déjà participé à ce genre de projets..
    à la base le projet est mal défini, n'a pas de fonctionnalités pertinentes et c'est pour satisfaire les ambitions d'un DSI
    Pour moi les éléments que tu listes font partie du boulot de développeur, en ce qui me concerne j'aime bien certains (conceptualiser, découper en modules...) et il vaut mieux comprendre le métier du client (ça peut être plus ou moins difficile selon ce métier et sa propre expérience). Il ne s'agirait donc pas (pour moi) de tâches difficiles mais importantes.

    Quant à reprendre du code pourri, malheureusement ça existe. Le mieux étant de réécrire et virer ce code.

  6. #46
    Membre confirmé Avatar de Cincinnatus
    Homme Profil pro
    Développeur Java
    Inscrit en
    mars 2007
    Messages
    200
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Service public

    Informations forums :
    Inscription : mars 2007
    Messages : 200
    Points : 571
    Points
    571

    Par défaut

    • Rédiger un cahier des charges
    • Estimer le temps nécessaire pour effectuer des tâches
    • Expliquer ce qu'on fait (ou ne fait pas)

    Il arrive que les fonctionnalités demandées soient vagues ; alors le temps nécesssaire ne peut pas être estimé au début de façon fiable. Après tout, les méthodes agiles ont été créées suite à ce constat.
    Expliquer ce que l'on fait à quelqu'un qui n'est pas de la partie est assez compliqué aussi (la compréhension du message dépend de l'émetteur mais aussi du destinataire, qui a peut-être des idées préconçues). Pire : expliquer les développements actuels à quelqu'un qui a fait du développement (pas à temps complet) il y a un certain temps et qui n'a pas suivi les évolutions (évolution hiérarchique) mais croit connaître .

  7. #47
    Membre actif
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2013
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : février 2013
    Messages : 179
    Points : 261
    Points
    261

    Par défaut

    Pour ma part, deux taches se valent en terme de difficulté : estimer une tache et le nommage

    Quand on rentre dans une nouvelle entreprise, on nous demande d'estimer notre charge, or il y a plusieurs paramètres que l'on ne connaît pas à ce moment la.
    Pour moi, une bonne estimation du travail demandé est 100 % due à l'expérience, acquise lors de ses précédents projets. Il est donc nécessaire de rencontrer le problème avant d'estimer le temps de résolution. Et dans notre métier, c'est loin d'être facile d'estimer les taches puisque la technologie change sans arrêt, donc les problèmes aussi.

    Le deuxième point est le nommage, l'informatique est là pour aider d'autre corps de métier. Donc les noms ne veulent pas forcement signifier la même chose d'un corps de métier à l'autre. De mon point de vue, une bonne règle de nommage à deux contraintes :
    - le nom doit être compréhensible par les développeurs (ceux qui font l'application et ceux qui peuvent reprendre l'application)
    - être compréhensible pour le corps de métier ou l'application sera déployé.
    Or si, je vous donne des noms est-ce que tout le monde le comprendra de la même manière ? (Exemple : "ressource", "niveau",...)


    Le reste des taches a chaqu'un son lot de difficulté, mais pour certaine, elle sont hors catégorie, puisqu'elle en font un métier a part entière.
    Les tests est un métier a part entier.
    La réalisation du cahier des charges est le boulot d'un chef de projet.
    ...

    Je dis ça, mais, la plupart du temps les métiers sont mélangés ^^, comme moi qui fait l'analyse avec le client jusqu’à la formation des utilisateurs pour l'outil en question.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 620
    Points : 19 047
    Points
    19 047

    Par défaut

    Citation Envoyé par Cincinnatus Voir le message
    (.../...)
    Quant à reprendre du code pourri, malheureusement ça existe. Le mieux étant de réécrire et virer ce code.
    souvent, le budget n'est pas en face. Ça nécessite des tests automatiques de partout, et tout le monde ne les a pas. Quand on m'a demandé de le faire, j'ai du d'abord faire tous les tests automatiques avant d'arriver à quelque 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.

  9. #49
    Membre habitué
    Inscrit en
    novembre 2008
    Messages
    114
    Détails du profil
    Informations forums :
    Inscription : novembre 2008
    Messages : 114
    Points : 135
    Points
    135

    Par défaut Mon inquiétude

    Bonjour,

    Je découvre en n° 2 : Travailler avec le code de quelqu'un d'autre - 16.56%

    Je trouve cela très dommage.
    -> OK, faire du code au quotidien c'est une activité solitaire : le développeur seul face à son écran.
    L'une des mauvaises conséquence, c'est que le développeur se referme sur lui-même.

    Et la je retrouve un travers de beaucoup de développeur : dans la vrai vie, il faut intéragir avec des vrais gens, avec leurs défauts et leur histoire. Et c'est important que ce ne soit pas une source de stress.

    Le code d'autre personne, ce n'est pas un mal, mais un bien.

    Cordialement
    Emmanuel

  10. #50
    Membre actif
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2013
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : février 2013
    Messages : 179
    Points : 261
    Points
    261

    Par défaut

    Citation Envoyé par emmanuel_dumas Voir le message
    Je découvre en n° 2 : Travailler avec le code de quelqu'un d'autre - 16.56%

    Je trouve cela très dommage.
    Dans l'ensemble je suis d'accord, travailler avec le code de quelqu'un d'autre peut être un bien.

    l'avantage de travailler avec le code de quelqu'un d'autre, c'est d'apprendre de nouvelle façon de faire. (et je ne dis pas ça parce que je débute)
    Après il faut que le développeur ne soit pas quelqu'un qui s’obstine, qui ne voit que de la ..... si ce n'est pas lui qui l'a fait, mais une sorte d'apprentissage
    qui va lui permettre d'apprendre si cette solution est performante ou non.

    Après cela inclus aussi que le code que l'on reprend soit minimum de qualité.
    Par exemple le type de code qui ne devrait jamais exister, lors d'une de mes premières expérience j'ai repris une application en VB5,
    qui a été développée par une 15ene de stagiaires de façon successif, et ça c'est une horreur, et même si tous les stagiaires sont extrêmement bon, avec la meilleur volonté du monde le code restera "SALE". D’ailleurs la solution qui a été retenue étais de virer ce logiciel pour prendre une solution pro-logiciel toute faite ^^

  11. #51
    Membre à l'essai
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2014
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : septembre 2014
    Messages : 12
    Points : 21
    Points
    21

    Par défaut Faire travailler le donneur d'ordres sur le cdc

    Bonjour, pour moi, sur de petits projets n'impliquant pas de nombreux intervenants, le plus dur est de faire comprendre au client que le gros du travail est l'audit du besoin, l'analyse, et la formulation du CDC.
    C'est d'autant plus difficile que :

    1/ le client doit participer à ce travail
    2/ idéalement il doit aussi le payer car c'est une tache indispensable
    3/ il a l'impression de payer du vent, car ce qui l'interesse est d'avoir vite un livrable, et il ne voit pas l'interet d'un bon cdc.

    Comment lui faire comprendre cela ?

  12. #52
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 839
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 839
    Points : 5 805
    Points
    5 805
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par loutox Voir le message
    Comment lui faire comprendre cela ?
    [semi-troll]
    Soit tu es très pédagogue (i.e. tu le convainc), soit tu es patient (i.e. tu fais comme il veut et tu lui dis à la fin "je vous l'avais bien dit"), soit tu te focalises sur les bénéfices que tu pourras tirer du projet (i.e. tu trouves un meilleur client).
    [/semi-troll]

    Si tu veux le convaincre, il vaut mieux qu'il soit prêt à changer d'avis (sinon tu peux toujours courir) et parler le même langage que lui. Tu peux tenter de trouver des études ou des rapports relatifs à son domaine qui montrent que ce qu'il croît est une erreur. Une erreur typique, donc pas de quoi avoir honte, mais une erreur quand même.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  13. #53
    Membre expérimenté
    Avatar de Dendrite
    Femme Profil pro
    Développeur informatique
    Inscrit en
    juin 2008
    Messages
    955
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 51
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : juin 2008
    Messages : 955
    Points : 1 349
    Points
    1 349

    Par défaut

    Les questions sont pour le moins limitées.
    Il y a 2 choses qui me semblent difficiles au travail, et qui ne sont pas mentionnées ici :

    1) Suivre le rythme des demandes d'évolution (une blague à mon boulot, c'est de dire "Le changement, c'est tout le temps !"
    2) Etre toujours à la page de la veille technologique...

    Et j'ai voté (mais ce serait en 3 et 4) reprendre le code d'un autre (quand on le trouve mauvais en tout cas), et développer un module quand on n'est pas d'accord.

    A part ça, ce métier est MERVEILLEUX, je ne m'y ennuie jamais et j'ai l'impression d'être moins bête chaque jour. Il n'y a pas beaucoup de métier qui procure cette délicieuse sensation.
    It's easier to be friends with lots of people online than one person in person!

  14. #54
    Membre averti
    Avatar de didier.cabale
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    août 2004
    Messages
    122
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information
    Secteur : Conseil

    Informations forums :
    Inscription : août 2004
    Messages : 122
    Points : 330
    Points
    330

    Par défaut

    En ce qui vous concerne en tant que développeurs, quelles sont parmi les tâches citées ci-dessus, celles que vous estimez les plus difficiles dans votre métier ?
    1. Concevoir une solution: même si ce n'est pas le point qui est dans 100% des cas le plus difficile, c'est *le point crucial*. De la solution envisagée dépendra toute la chaine des problématiques dépendantes: simplicité de mise en œuvre des tests, facilité de maintenance (modification du code, débogage), etc ..
    Ce point nécessite à la fois une très bonne connaissance du Framework, des librairies potentielles et du métier en question.
    Si vous travaillez sur un gros projet, avec une maintenance active, les *économies résultant de ce point peuvent être considérables*.
    2. Travailler avec le code de quelqu'un d'autre : ça, c'est la *bouteille à l'encre* du développement informatique. Si le code précédemment réalisé est mal découpé, pléthorique et /ou inutilement complexe, vous *vivrez l'enfer*, sans pour autant pouvoir modifier structurellement l'existant, sous peine de créer une kyrielle d'effets indésirables, bugs, ..

  15. #55
    Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2015
    Messages
    17
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 20
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juillet 2015
    Messages : 17
    Points : 41
    Points
    41

    Par défaut

    Estimer le temps nécessaire

  16. #56
    Membre chevronné Avatar de psychadelic
    Profil pro
    Inscrit en
    mai 2010
    Messages
    910
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2010
    Messages : 910
    Points : 2 139
    Points
    2 139

    Par défaut

    Citation Envoyé par tp1024 Voir le message
    Je pense qu'il manque un choix:
    * Obtenir toutes les informations utiles pour concevoir la solutions technique et/ou réaliser le chiffrage.
    De mon expérience, le pb ne concerne pas le client, mais les relais entre le client et l'équipe technique.
    Citation Envoyé par nirgal76 Voir le message
    La chose la plus difficile que j'ai à faire pratiquement tous les jours, c'est savoir précisément ce qu'il faut faire. LA demande client se résume bien souvent à "j'voudrais un machin qui fait des trucs...combien de temps il te faut ?"...c'est lassant
    C'est pour ça que j'ai répondu : " Traiter avec d’autres personnes ".

    Parce que pour rédiger un bon cahier des charges on est obligé d'interviewer des gens qui souvent ne savent même pas ce que peut être un raisonnement cartésien; voire qui croient toujours que la terre plate (si, si, c'est du vécu).

    Et tout le reste en découle :
    - Recenser et documenter les fonctionnalités devient une chasse aux œuf de Paques
    - Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord complétement inutile(s)

    Quand à estimer le temps, c'est souvent une question piège, mais avec l'expérience (non pas du métier ou de moi même) mais des sournoiseries des "dirigeants" je sais quoi répondre, et par une autre question :

    Vous voulez quoi ?
    Le temps de réalisation avec ou sans la documentation ? , avec ou sans les tests et les retours utilisateurs ? avec ou sans relecture du code et de ses commentaires par un autre dev ?

    Ps on a souvent essayé de me la faire, et ça me fait tout sauf rire : 15 jours hommes c'est pas 2 semaines, mais 3 semaines, sinon faut payer en heures sup et salaire au double pendant les week-end.

    Quand à relire le code d'un autre, ça dépends surtout de la qualité d'écriture du premier codeur, parfois c'est un plaisir, mais c'est rare...
    «La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode

  17. #57
    Membre actif Avatar de polkduran
    Profil pro
    Consultant informatique
    Inscrit en
    décembre 2009
    Messages
    153
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : décembre 2009
    Messages : 153
    Points : 275
    Points
    275

    Par défaut

    Travailler avec des personnes incompétentes

  18. #58
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 148
    Points : 357
    Points
    357

    Par défaut

    Estimer le temps est de toute manière compliqué pour un développeur ou pour quiconque, architecte ou chef de projet y compris. Aucune estimation n'est fiable dans 95% des projet et pourtant il faut le faire à minima lors de la proposition initiale.

    Ensuite écrire les tests ou rédiger la documentation, un développeur ne devrait pas avoir à le faire, car pour plus de pertinence et d'efficacité ce devrait être une personne étrangère au dev et surtout non technique qui devrait s'en charger. Selon le principe de celui qui code ne test pas lui même (tests fonctionnels et pas unitaires ici).

    Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord ne devrait jamais être un pb, en tant que développeur on ne décide pas ce que veut le client par contre on a normalement la latitude de décider de la meilleure implémentation technique du moins en accord avec l'architecte technique.

    Travailler avec le code de quelqu'un d'autre ne doit pas non plus poser de difficultés si les règles de nommage, l'architecture des packages, les API utilisées sont respectés et les patterns de conception utilisés à bon escient.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 620
    Points : 19 047
    Points
    19 047

    Par défaut

    Citation Envoyé par Jitou Voir le message
    (.../...)Ensuite écrire les tests ou rédiger la documentation, un développeur ne devrait pas avoir à le faire, car pour plus de pertinence et d'efficacité ce devrait être une personne étrangère au dev et surtout non technique qui devrait s'en charger. Selon le principe de celui qui code ne test pas lui même (tests fonctionnels et pas unitaires ici). (.../...)
    D'accord, à un détail près : quelle doc? Parceque la doc technique qui explique comment sont codés les éléments, je ne vois pas qui d'autre que le développeur peut s'y coller.
    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.

  20. #60
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 148
    Points : 357
    Points
    357

    Par défaut

    D'accord, à un détail près : quelle doc? Parceque la doc technique qui explique comment sont codés les éléments, je ne vois pas qui d'autre que le développeur peut s'y coller.
    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.

Discussions similaires

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

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