Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Quelles habitudes faut-il avoir pour parvenir à concevoir d'excellents logiciels ?

Votants
148. Vous ne pouvez pas participer à ce sondage.
  • Impliquer les utilisateurs

    123 83,11%
  • Mettre au point d’élégantes abstractions

    22 14,86%
  • Focaliser sur l’essentiel

    76 51,35%
  • Simuler de façon continue

    19 12,84%
  • S’inspirer de l’existant

    26 17,57%
  • Proposer des modèles alternatifs de l’espace problème

    8 5,41%
  • Voir les erreurs comme des opportunités

    41 27,70%
  • Bien prendre en compte les limites

    66 44,59%
  • Autres (à préciser)

    4 2,70%
Sondage à choix multiple
Débats sur le développement - Le Best Of Discussion :

Quelles sont les habitudes à avoir pour parvenir à mettre sur pied d’excellents logiciels ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    février 2017
    Messages
    805
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 805
    Points : 27 711
    Points
    27 711
    Par défaut Quelles sont les habitudes à avoir pour parvenir à mettre sur pied d’excellents logiciels ?
    Quelles sont les habitudes à avoir pour parvenir à mettre sur pied d’excellents logiciels ?
    Voici une liste inspirée du livre « 66 façons dont les experts pensent »

    De façon indépendante du domaine dans lequel on œuvre, combiner expérience et capacités innées permet de se démarquer de ses pairs. Dans la filière de la programmation informatique, c’est la même réalité. En fait, il s’agit des deux ingrédients à mettre ensemble pour aboutir à ce que l’on peut appeler le « programmeur expert. » Il y a seulement que faire mention de l’expérience et des capacités innées ne permet pas de savoir comment ce dernier aborde les diverses tâches qui sont les siennes au quotidien ; en d’autres termes, quelles sont les habitudes sur lesquelles il s’appuie pour une meilleure conception de logiciels. Dans un article paru il y a peu, deux auteurs proposent une liste inspirée de leur livre intitulé « 66 façons dont les experts pensent. »

    Nom : 0.png
Affichages : 14875
Taille : 136,5 Ko

    1. Impliquer les utilisateurs

    Les experts connaissent très bien les utilisateurs. Ils impliquent délibérément les utilisateurs dans le processus de conception, les étudient, leur parlent, les invitent à tester des conceptions intermédiaires et leur demandent même de jouer un rôle actif dans l'équipe de conception.

    Pourtant, les experts ne prennent pas tout ce que les utilisateurs disent pour argent comptant. Ils se rendent compte des limites potentielles, car la pensée des utilisateurs est souvent colorée par les expériences actuelles. Les experts regardent au-delà de ce que les utilisateurs demandent, vers ce dont ils ont réellement besoin.

    2. Mettre au point d’élégantes abstractions

    Alors que tous les développeurs créent des abstractions, les experts les conçoivent. Une bonne abstraction met en évidence ce qui est important, à la fois dans ce qu'elle fait et comment elle le fait. À travers une seule lentille, il communique le problème qu'il résout et la mécanique de sa solution.

    Les experts ne se contentent pas de n'importe quelle abstraction, ils cherchent délibérément des abstractions élégantes à travers lesquelles des structures complexes peuvent être introduites, comprises et référencées de façon efficace.

    3. Focaliser sur l’essentiel

    Chaque problème de conception tourne autour d'un ensemble de considérations essentielles qui doivent être comprises et injectées dans la solution pour qu'elle puisse résoudre le problème avec succès. Cette essence peut être perturbatrice : les changements dans le noyau modifient de façon radicale les décisions périphériques qui doivent être prises. Les experts concentrent d'abord leurs efforts sur l'essence et retardent les efforts de conception à la périphérie.

    4. Simuler de façon continue

    Les experts imaginent comment un design fonctionnera en simulant des aspects du logiciel envisagé et comment ses différentes parties supportent une variété de scénarios. Lorsqu'ils travaillent avec d'autres personnes, les experts passent régulièrement en revue un design en donnant, à haute voix, des détails sur son fonctionnement étape par étape. Lorsqu'ils sont seuls, ils simulent de façon mentale, en testant le design de façon répétée.

    Nom : 4.png
Affichages : 5158
Taille : 184,0 Ko


    5. S’inspirer de l’existant

    De la même manière que les architectes se promènent dans les villes pour examiner et s'inspirer des bâtiments existants, les experts en logiciels examinent les détails de la conception d'autres logiciels. Ils le font souvent en réponse à un défi particulier auquel ils sont confrontés, mais il leur arrive de passer du temps à regarder autour d'eux simplement pour enrichir leur répertoire de solutions à utiliser à l'avenir.

    6. Proposer des modèles alternatifs de l’espace problème


    Les experts prennent souvent du recul par rapport au problème énoncé et l'envisagent de manière plus large, en cherchant d'autres moyens de cerner le problème. Ils peuvent changer de direction en concevant à nouveau l'espace du problème ou en abordant un problème différent dans le même espace. Ils choisissent de façon intentionnelle des objectifs quelque peu différents du problème de conception d'origine, car cela leur permet de comprendre où se situe le vrai problème ou comment surmonter les principaux obstacles.

    7. Voir les erreurs comme des opportunités

    Le processus de conception implique régulièrement des erreurs : des choses qui vont mal, des malentendus, des obstacles, des mauvais virages, des problèmes qui font surface. Plutôt que de craindre l' erreur, les experts la considèrent comme une opportunité. Ils l'acceptent comme une partie inhérente du processus et prennent le temps d'explorer à la fois l'échec et le contexte qui l'entoure. Comprendre ce qui s'est passé révèle souvent un aperçu du problème ou de la solution

    8. Bien prendre en compte les limites

    Bien qu'il soit naturel de se concentrer sur ce qu'un design doit accomplir, les experts passent aussi du temps à réfléchir à ce qu'un design n'est pas destiné à faire. En articulant et en considérant les limites, ils découvrent où ils sont sur et sous-dimensionnés.

    Marian Petre et Andre Van Hoek proposent là un sous-ensemble des habitudes (8 sur 66 au sein de leur livre) à avoir pour parvenir à concevoir d’excellents logiciels. Sur le plan du fond, il faut dire qu’il est assez sommaire, ce qui pourrait laisser place à diverses interprétations. Par exemple, sans plus d’éclaircissements, le troisième point peut laisser penser qu’ils suggèrent de s’arrimer à une approche de développement ascendante dans laquelle on écrit les fonctionnalités de base avant même de penser à l’interface. En fait, cet état de choses est même de nature à suggérer des éléments additifs à cette liste : la précision ; l’on pourrait faire la proposition d’extension de liste « l’expert doit s’exprimer avec précision », mais sans plus pour rester sur le fil conducteur des auteurs. En fait, le sujet interpelle et mobilise l’attention d’intervenants de la filière. De façon générale, c’est le volet expérience sur lequel les développements portent puisqu’y faire référence c’est aussi passer en revue des habitudes et principes qu’un tiers met en application au travail pour atteindre ses objectifs. Jacob Kaplan-Moss – l’un des principaux contributeurs Django – a d’ailleurs formulé un avis allant dans ce sens il y a quelques années en soulignant que « la programmation n’est pas une passion ni un talent, ce n’est qu’un ensemble de compétences que tout le monde peut apprendre. » Autrement dit, la capacité à mettre sur pied d’excellents logiciels s’acquiert en passant par l’acquisition de certaines habitudes et principes.


    Source : MIT PRESS

    Et vous ?

    Que pensez-vous de cette liste ? Vous satisfait-elle sur le plan du fond ?

    Quels sont les éléments qu’on pourrait y ajouter ou qui devraient ne pas y paraître ?

    Quelles sont les habitudes sur lesquelles vous vous appuyez au quotidien pour parvenir à concevoir d'excellents logiciels ?

    Voir aussi :

    Qu'est-ce qui fait un bon programmeur ? Un senior liste cinq caractéristiques d'un bon programmeur

    Faut-il éliminer le mythe du programmeur génie ? Selon un sénior, « la plupart des gens sont moyens » et cela n'est pas grave

    Le talent et la passion suffisent-ils pour faire un bon développeur ? Les créateurs de Django, PHP et Rails n'étaient pas des passionnés du code

    Tout le monde ne peut pas devenir développeur, il faut d'abord disposer de certains prérequis
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éprouvé
    Avatar de Garvelienn
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2016
    Messages
    232
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

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

    Informations forums :
    Inscription : septembre 2016
    Messages : 232
    Points : 945
    Points
    945
    Par défaut
    Autre :
    Mettre à l'écart les commerciaux/marketeux de la décision et des choix en les remplaçant par les utilisateurs finaux. Ce qui rejoint le premier point de l'article
    «Le management, tel qu’on l’apprend dans les écoles et tel qu’on l’applique ensuite, sous prétexte de «motivation du personnel», organise exactement le contraire, à savoir la démotivation organisée.» - Bernard Stiegler

  3. #3
    Membre régulier
    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    janvier 2006
    Messages
    104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2006
    Messages : 104
    Points : 100
    Points
    100
    Par défaut Architecture et stratégie
    faudra prendre le temps de bien réfléchir la stratégie business et l'architecture.

  4. #4
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 859
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 859
    Points : 8 297
    Points
    8 297
    Par défaut
    1. Impliquer les utilisateurs

    Les experts connaissent très bien les utilisateurs. Ils impliquent délibérément les utilisateurs dans le processus de conception, les étudient, leur parlent, les invitent à tester des conceptions intermédiaires et leur demandent même de jouer un rôle actif dans l'équipe de conception.

    Pourtant, les experts ne prennent pas tout ce que les utilisateurs disent pour argent comptant. Ils se rendent compte des limites potentielles, car la pensée des utilisateurs est souvent colorée par les expériences actuelles. Les experts regardent au-delà de ce que les utilisateurs demandent, vers ce dont ils ont réellement besoin.
    Je ne vois pas le rapport avec de l'expertise technique en informatique...
    C'est de l'expertise de commercial dont on parle ici (faut bien que son métier serve à quelque chose ).
    Impliquer le client, savoir exactement ce qu'il veut, tout ceci pour ne pas le décevoir et être certain de vendre au mieux le produit.
    Certes l'expert en informatique sera impliqué dans le processus mais il n'en est pas responsable.

    De toute façon dans 80% des cas ce n'est pas l'expert en informatique qui voit le client donc...

    Sur le plan du fond, il faut dire qu’il est assez sommaire
    Je dirai même que c'est juste de la logique.
    Or la logique c'est un peu la base de notre métier.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  5. #5
    Membre émérite
    Homme Profil pro
    Responsable informatique
    Inscrit en
    juin 2004
    Messages
    563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Responsable informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 563
    Points : 2 562
    Points
    2 562
    Par défaut
    Citation Envoyé par transgohan Voir le message
    Je ne vois pas le rapport avec de l'expertise technique en informatique...
    C'est de l'expertise de commercial dont on parle ici (faut bien que son métier serve à quelque chose ).
    Tout dépend de ce que tu vends : du logiciel sur étagère, du développement personnalisé (basé sur un soft existant) ou du développement à façon. C'est pas pareil !

    Citation Envoyé par transgohan Voir le message
    Impliquer le client, savoir exactement ce qu'il veut, tout ceci pour ne pas le décevoir et être certain de vendre au mieux le produit.
    Certes l'expert en informatique sera impliqué dans le processus mais il n'en est pas responsable.
    Si : "l'expert informatique" est responsable de ce qu'il livre auprès du client (enfin c'est comme ça chez nous)

    Citation Envoyé par transgohan Voir le message
    De toute façon dans 80% des cas ce n'est pas l'expert en informatique qui voit le client donc...
    C'est bien le problème dans certaines boites, les commerciaux chiffrent et vendent sans avoir pris l'avis des développeurs du coup à l'arrivée ça ne colle pas...
    Pour les gros projets chez nous on envoi toujours un développeur et parfois même une deuxième personne du BE avec le commercial pour avoir toutes les billes pour le chiffrage et encore ça nous arrive de nous tromper...

    Citation Envoyé par transgohan Voir le message
    Je dirai même que c'est juste de la logique.
    Or la logique c'est un peu la base de notre métier.
    La logique de certains est parfois bien déroutante...

  6. #6
    Membre expérimenté
    Profil pro
    chercheur
    Inscrit en
    avril 2004
    Messages
    798
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : chercheur

    Informations forums :
    Inscription : avril 2004
    Messages : 798
    Points : 1 306
    Points
    1 306
    Par défaut
    C'est quoi, un logiciel "excellent" ?
    Deux réponses extrêmes :
    Un logiciel qui fait le boulot sans problème
    Un logiciel qui oblige le client à dépenser une fortune en maintenance, formation, etc.
    (heureusement pour le premier cas, il y a les maj de Windows)
    Ce qui s'énonce clairement se conçoit bien ( Le hautbois)

  7. #7
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 859
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 859
    Points : 8 297
    Points
    8 297
    Par défaut
    Citation Envoyé par sergio_is_back Voir le message
    Si : "l'expert informatique" est responsable de ce qu'il livre auprès du client (enfin c'est comme ça chez nous)
    J'en comprends qu'il est responsable en cas de cahier des charges que le client ne reconnait plus une fois signé non ?

    Car sinon, c'est de la logique, on est bien d'accord qu'on est responsable en cas d'écart avec le cahier des charges sur la livraison.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  8. #8
    Membre émérite
    Homme Profil pro
    Responsable informatique
    Inscrit en
    juin 2004
    Messages
    563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Responsable informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 563
    Points : 2 562
    Points
    2 562
    Par défaut
    Citation Envoyé par transgohan Voir le message
    J'en comprends qu'il est responsable en cas de cahier des charges que le client ne reconnait plus une fois signé non ?
    Le cahier des charges est parfois réduit à sa plus simple expression. Normalement c'est le rapport de spécifications logicielles qui fait foi (l'analyse si tu préfère) et qui traduit le besoin exprimé dans le cahier des charges en briques logicielles. Mais il arrive (et très souvent) que le client lise les spécifications en travers et donne son aval alors qu'il n'a pas compris. Que l'analyste ne soit pas à l'aise avec les termes métiers (le jargon spécifique : un plombier n'utilise pas les même termes qu'un avionneur) du client et passe à travers certains détails importants, bref il y a rarement totale adéquation entre :

    - Le CDC d'origine (qui peut être partiellement changé en cours de route)
    - Les spécs (qui évoluent au cours du projet parfois)
    - Le livrable (qui peut être en décalage, car le(s) développeur(s) interprète(nt) aussi des fois avec sa(leur) propre compréhension)

    C'est surtout vrai sur les gros projet (plusieurs mois)
    Tout ton rôle est alors de ménager tous les acteurs et de faire converger le livrable et le besoin réel des utilisateurs même si parfois ça ne respecte pas pile poil le CDC du client.

    Citation Envoyé par transgohan Voir le message
    Car sinon, c'est de la logique, on est bien d'accord qu'on est responsable en cas d'écart avec le cahier des charges sur la livraison.
    Chez nous on ne fait que du soft sur mesure (des moutons à cinq voir six pattes) et c'est rare qu'il y ait un CDC parfaitement précis au début. Bien souvent celui rédige le CDC ne connais que vaguement le problème (ou le process) c'est souvent un administratif loin des utilisateurs, quand ce n'est pas un consultant extérieur qui n'a jamais mis les pieds dans l'atelier par exemple... Alors les écarts on connais bien...

    Cela rejoint le premier point évoqué dans la dépêche : Il faut être proche des utilisateurs finaux et les impliquer (tenir compte de leur façon de travailler, tenir compte des habitudes de l'entreprise, des termes métier, etc...) sans cependant tout prendre comme argent comptant. Certaines entreprises en ont conscience et font participer leurs salariés aux réunions préalables et demandent à ce que l'on tienne compte des remarques mais d'autres ne jugent pas que c'est nécessaire mais j'aime mieux la première façon de travailler, on est plus impliqué et c'est plus facile de sortir quelque chose de viable et d'efficace même si parfois on s'éloigne peu ou prou du CDC original. Le tout c'est d'être capable de simplifier les choses et de concilier les différents éléments pour rester dans le clous en terme de temps de développement (et de coût).

    Si nécessaire le commercial peut aussi avoir un rôle important dans cette phase : rassurer le client sur un écart particulier (c'était mieux de faire comme ça plutôt que comme c'était prévu pour une raison précise), rassurer les utilisateurs, négocier des points de développement non prévus (en acceptant certains demandes, en proposant des avenants à sa proposition d'origine, etc...), bref dans les cas compliqués il reste aussi un facilitateur

  9. #9
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 859
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 859
    Points : 8 297
    Points
    8 297
    Par défaut
    On est d'accord que le cahier des charges incomplet est un évènement récurrent dans notre profession.
    Mais je reste sur mon idée désolé... Je ne veut pas être responsable des lacunes des autres métiers...
    Être expert dans son domaine ce n'est pas savoir combler les défauts des autres domaines.
    Ou alors on me propose l'augmentation qui va bien et là j'y réfléchirai.

    Donc pour moi le point 1 est toujours hors contour.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  10. #10
    Membre émérite
    Homme Profil pro
    Responsable informatique
    Inscrit en
    juin 2004
    Messages
    563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Responsable informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 563
    Points : 2 562
    Points
    2 562
    Par défaut
    Citation Envoyé par transgohan Voir le message
    On est d'accord que le cahier des charges incomplet est un évènement récurrent dans notre profession.
    Mais je reste sur mon idée désolé... Je ne veut pas être responsable des lacunes des autres métiers...
    Être expert dans son domaine ce n'est pas savoir combler les défauts des autres domaines.
    Ou alors on me propose l'augmentation qui va bien et là j'y réfléchirai.

    Donc pour moi le point 1 est toujours hors contour.
    Tout dépend de la boite dans laquelle tu bosses... C'est pas l'esprit chez nous, tout le monde est responsabilisé à son niveau... Et les salaires sont plus que corrects... (Pour une PME j'entends)

  11. #11
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 859
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 859
    Points : 8 297
    Points
    8 297
    Par défaut
    Citation Envoyé par sergio_is_back Voir le message
    tout le monde est responsabilisé à son niveau...
    J'ai un peu l'impression d'écrire noir sur fond noir, je n'ai jamais écrit l'inverse...
    J'ai dit que je ne veux pas être responsable du travail des autres, c'est différent.

    Bien évidemment que je suis responsable de mon propre livrable.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  12. #12
    Membre actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 79
    Points : 220
    Points
    220
    Par défaut
    WTF ?

    Que pensez-vous de cette liste ? Vous satisfait-elle sur le plan du fond ?
    Belle liste avec 8 éléments.
    Les énoncés sont en parfaite accord avec leurs descriptions.

    Quels sont les éléments qu’on pourrait y ajouter ou qui devraient ne pas y paraître ?
    Tous et aucuns à la fois.
    Personne n'as la formule magique pour "mettre sur pied d’excellents logiciels", peut importe ce que ça peut bien signifier.
    Sortir une liste et annoncé que ce sont les éléments qui garantiraient "d'excellents logiciels", juste .

    Quelles sont les habitudes sur lesquelles vous vous appuyez au quotidien pour parvenir à concevoir d'excellents logiciels ?
    Pour "concevoir d'excellents logiciels" je ne saurait dire, mais des "logiciels" qui donne satisfaction au client, là on peut discuter.

    Je dirais que pour mener à bien mes projet j'ai 2 règles que je respecte scrupuleusement et qui ne mon jamais trahit :
    1. Si le client ne peut exprimer ses propre besoins, alors c'est au-revoir M./Mme.
      Même si la personne est sympathique et de bonne fois, je n'est jamais vue un projet donner totale satisfaction à un client, si ce dernier était incapable d'exprimer ses besoins, ne serait ce que durant la phase d'avant projet.
      A l'inverse, j'ai vue plein de projets échoué et donc de client mécontent, parce que le livrable ne répondait pas à leur besoins (ou n'était jamais terminé, ...etc) à cause de cette "incertitude" dans les spec.
    2. Si les demandes client dépasse mes capacités, ne pas hésiter à le rediriger vers un collègue.
      Que ce soit, en temps à accorder au projet ou bien en terme technique, il ne faut jamais ce surestimer.
      J'ai vu quantité de projet échouer parce-que les responsables sous-estimé le travail à accomplir ou à l'inverse surestimer leurs capacités et celle de leurs équipes.

    Avec ces 2 règles, c'est déjà un bon point de départ pour entrevoir un début de projet convenable.

    Vous noterez toutefois, qu'il n'existe, à ma connaissance, aucune façon de garantir quoique ce soit sur un projet logiciel.
    Des personnes infiniment plus qualifiées que je ne le suis ont bien essayer de trouver des méthodes pour ça, mais rien de ferme et définitif n'as encore émergé à ce jour.
    Des outils pour facilité la gestion de la durée de vie d'un projet existe bien, ainsi que des bonnes pratiques en fonction du domaine, mais encore une fois, rien de garantie.

    P.S. : J'ai toujours considéré le développement logiciel plus comme un art, que comme une science exacte (coucou à toi facteur humain)

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 867
    Points : 26 781
    Points
    26 781
    Par défaut
    Citation Envoyé par defZero Voir le message
    Si les demandes client dépasse mes capacités, ne pas hésiter à le rediriger vers un collègue.
    ça, c'est vraiment important. J'ai vu les dégâts du syndrome du héros, 2-3 fois. J'ai moi-même commis l'erreur une fois.

    pas deux.

    Citation Envoyé par defZero Voir le message
    P.S. : J'ai toujours considéré le développement logiciel plus comme un art, que comme une science exacte (coucou à toi facteur humain)
    à minima de la R&D : https://www.developerdotstar.com/mag...sign_main.html - avec tous les aspects aléatoires qui en découlent.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  14. #14
    Membre actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 79
    Points : 220
    Points
    220
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    J'ai vu les dégâts du syndrome du héros, 2-3 fois. J'ai moi-même commis l'erreur une fois. pas deux.
    .
    @el_slapper +1 (Merci pour le lien, ça semble intéressant)

    C'est l'expérience qui parle, tout simplement.
    En fait ce que décrit ces 8 points, peut ce résumé (en ne si limitant pas) à l' "Expérience".

    [Petite apartée]
    C'est aussi une des raisons pour laquelle, je suis toujours dubitatif quand je vois un Ingénieur Junior postuler à un poste de "Chef de Projet" ou de "Product Manager".

    Je n'en fait pas une généralité, mais plus d'une fois j'ai vécu cette situation et à chaque fois, à la fameuse question "Pourquoi Chef de Projet ?" ils m'ont tous répondu (sans exception, mais ce n'est que mon expérience perso) que c'était parce-qu’ils avaient un diplôme d'Ingénieur (pas forcement en Info d'ailleurs) et qu'ils ne voulaient pas coder.

    Pas la peine de vous dire que les projets en question n'ont jamais était mes plus agréables moments Pro.
    Je code depuis bien plus de 10 ans et je ne me voit pas être Chef de Projet (en équipe de plus de 5 personnes, j’entends), tout simplement parce-que ce n'est pas le même métier.
    Bien que je sois convaincu qu'il existe des Ingé Junior tout à fait apte à ce poste, je n'en est juste pas rencontré personnellement et à ce jour.
    Par contre je leur concède qu'en générale, ils renvoient une bonne image aux clients.
    Le gros point négatif étant que "leurs" équipes ne peuvent pas réellement compter sur eux en cas de besoin, là ou justement un "bon" Chef de Projet sera apporté des solutions.
    Il ne s'agit pas toujours de solutions technique, je n'attend pas forcement d'un Chef de Projet qu'il soit un artiste du code, mais plutôt qu'il sache gérer les difficultés qui pourraient ce présenter sur son/ses projets et ça je pense requière pas mal d’expérience et de spécialisation.
    Enfin, j'ai connu pas mal de Chef de Projet très compétent, mais leur point commun n'était pas le diplôme mais bien l’expérience.
    [/Petite apartée]

  15. #15
    Membre éprouvé

    Homme Profil pro
    Écrivain public, Économiste et Programmeur Free Pascal
    Inscrit en
    août 2005
    Messages
    285
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Écrivain public, Économiste et Programmeur Free Pascal
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2005
    Messages : 285
    Points : 1 075
    Points
    1 075
    Billets dans le blog
    40
    Par défaut
    Connaître un métier industriel et utiliser Rust, Julia, ou Lazarus pour réaliser cela grâce à Software Heritage et Delphi Super Page.

  16. #16
    Membre expert
    Avatar de GLDavid
    Homme Profil pro
    LIMS manager, bio/chemoinformatique
    Inscrit en
    janvier 2003
    Messages
    2 731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : LIMS manager, bio/chemoinformatique
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : janvier 2003
    Messages : 2 731
    Points : 3 776
    Points
    3 776
    Par défaut
    Citation Envoyé par defZero Voir le message
    J'ai toujours considéré le développement logiciel plus comme un art, que comme une science exacte (coucou à toi facteur humain)
    Bonjour

    Content de voir quelqu'un qui se rapproche de ma vision. Je me souviens que l'on m'avait ri au nez sur ce forum il y a quelques années quand j'avais posté une telle phrase. Evidemment, la programmation, c'est des sciences exactes, je ne dis pas le contraire, mais vous devez être "inspiré par le sujet", croyez-moi, ça se ressent la motivation du programmeur sur le résultat obtenu.
    Pour en revenir au sujet, je trouve que les propositions citées sont trop centrées sur le programmeur. De mon point de vue, qu'appelle t'on un 'excellent logiciel'? Et bien, c'est un logiciel qui satisfait:
    1. aux utilisateurs, car il est simple d'utilisation et répond parfaitement à leurs attentes.
    2. requiert un minimum de support, hors mise à jour pour ajout de fonctionnalités pourvu que cela satisfasse toujours à la 1ère condition
    3. reste facile à la lecture du source code et demande des outils d'ingénierie logiciel accessibles mais évitant le déploiement d'une usine à gaz

    Ouais, ça fait un peu "Small is Beautiful" mais je reste persuadé qu'un logiciel simple est garant de son succès de de son adaptation par les utilisateurs pourvu qu'il remplisse bien ses fonctions.

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  17. #17
    Membre actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 79
    Points : 220
    Points
    220
    Par défaut
    @GLDavid, +1.

    Citation Envoyé par GLDavid Voir le message
    ... Evidemment, la programmation, c'est des sciences exactes, je ne dis pas le contraire, ...
    Ah, pas si évident que ça, en fait.
    Si c'était totalement vrai, tout programme compilant ne pourrait jamais planter.
    Ma compréhension du sujet est que la programmation est basé sur des concepts scientifiquement validé, mais qu'en pratique elle s'assimile plus à un art, tellement le nombre de variation est élevé à notre échelle (comme la peinture et la musique par exemple).
    Ne pas oublier que la science s'applique à définir notre monde, alors que la programmation ce borne à coder des limites (le programme) sur un sous ensemble déjà très restreint (l'ordinateur).

    Mais sinon, je comprend et suis tout à fait d'accord avec le reste.

  18. #18
    Membre régulier
    Avatar de VBurel
    Profil pro
    Développeur Indépendant
    Inscrit en
    août 2004
    Messages
    64
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Indépendant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2004
    Messages : 64
    Points : 99
    Points
    99
    Billets dans le blog
    1
    Par défaut le programmer 3 fois:
    Une fois pour comprendre les problématiques, une fois pour les résoudre et une dernière fois pour satisfaire les besoins utilisateurs. C’est ce qu’on appelle dans l’industrie, le prototype, le pré-produit et le produit.

    Je rappelle aussi qu'un logiciel est une sorte de roman (exécuté par une machine) et à ce titre est soumis aux droits de la propriété intellectuelle... Et la science est un moyen de se planter de manière rationnelle.

  19. #19
    Membre du Club
    Homme Profil pro
    Directeur technique
    Inscrit en
    septembre 2016
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Hautes Pyrénées (Midi Pyrénées)

    Informations professionnelles :
    Activité : Directeur technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2016
    Messages : 11
    Points : 52
    Points
    52
    Par défaut La Qualité
    Cet ouvrage est bienvenu. Il vise la Qualité logicielle. Il y a une dérive techno qui fait que la technologie est devenu son propre but. En tant que "vieux de la vieille"
    je suis frappé à quel point la conception est un sujet absent de nos formations d'ingénieur et à quel point le niveau de réflexion tourne autour de zéro pour ce qui concerne la qualité du logiciel en tant que produit.
    Le devops, les tests unitaires, cela n'a en fait pas grand chose à voir avec la qualité, ce sont des outils qui permettent de rendre compte du travail effectué. Si un illuminé a décidé que la voiture aurait des roues carrées, les tests unitaires rendront compte du fait que les roues sont carrées.
    La conception informatique, contrairement à d"autres domaines techniques n'est arrivée à aucune doctrine ni consensus. Chacun fait "ce qui lui plait" et ce qui me plait correspond à mes habitudes de faire et ma logique propre. Ce livre comble un vide effectivement.
    On peut se faire la même réflexion sur l'architecture. Regardez les fiches de poste correspondant à Architecte et vous verrez que cela correspond grosso merdo à une fiche de poste de dev expérimenté. En pratique l'Architecte dans une équipe est celui qui a autorité pour imposer ses vues. Pas vraiment satisfaisant.

  20. #20
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 267
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 267
    Points : 27 945
    Points
    27 945
    Par défaut Le quoi et le comment
    Salut,
    Citation Envoyé par quote
    On est d'accord que le cahier des charges incomplet est un évènement récurrent dans notre profession.
    Mais je reste sur mon idée désolé... Je ne veut pas être responsable des lacunes des autres métiers...
    Être expert dans son domaine ce n'est pas savoir combler les défauts des autres domaines.
    Ou alors on me propose l'augmentation qui va bien et là j'y réfléchirai.
    Tu sembles oublier qu'une application, c'est un mélange de quoi et de comment.

    Le "quoi" correspond à un besoin auquel on veut / espère répondre car, si le programme ne répond à aucun besoin, il est inutile, et ne sera donc pas utilisé.

    Cela peut commencer par une phrase lachée à un ami aussi simple que
    Tiens, ce serait pas mal si on avait un programme qui ... (complète à ta guise).
    Mais il faut se dire que si tu n'as pas une description correcte du quoi, tu peux faire absolument tout et n'importe quoi; et tu ne sais donc rien faire d'utile.

    Or, le meilleur candidat pour décrire le besoin me semble décidément être... la personne qui est confrontée au besoin en question.

    On ne peut -- bien sur -- pas te tenir pour responsable si la personne à qui l'on demande de décrire le besoin n'en a elle-même pas une vision d'ensemble, si elle "oublie" de décrire une procédure qui ne doit être appliquée que tous les dix ans, ou si elle ne comprend pas elle même correctement le besoin qui devra être rempli.

    Mais n'est ce pas, en partie, ton rôle en tant qu'expert, d'orienter sa réflexion de manière à lui permettre d'exprimer correctement ce "quoi", si possible en t'assurant que tous les aspects seront décrits et qu'ils le seront correctement

    Une fois que l'on a le "quoi" (ou, "suffisamment de quoi" que pour commencer à travailler, selon la méthode Agile), il est temps de se poser la question du "comment". Il se subdivise en deux aspects bien distincts: un aspect "ergonomique" (comprend : comment l'utilisateur devra utiliser l'application pour obtenir un résultat bien précis) et un aspect purement technique (dont je parlerai un peu plus loin).

    L'ergonomie de l'application est essentielle et met une fois encore l'utilisateur au centre du problème, car:
    • si elle ne correspond pas aux habitudes de l'utilisateur, il utilisera mal son application, et n'obtiendra pas forcément (ou du moins pas "facilement") le résultat escompté
    • si une fonctionnalité de l'application est soumises à des manipulations trop complexes(*) de la part de l'utilisateur, elle risque d'être errore prone ou (trop) peu / mal utilisée.

    (*) par exemple, en nécessitant une combinaison de touches difficile à obtenir, en obligeant l'utilisateur à passer par un grand nombre de fiches pour y accéder ou en l'obligeant à introduire plusieurs fois la même information.

    L'un dans l'autre, seul l'utilisateur final n'est sans doute en mesure de dire si l'ergonomie correspond à "ses habitudes" et à ses besoins.

    Dans le même temps, vient la partie "exclusivement technique" du comment : les structures de données et les algorithmes à mettre en place, la manière dont les informations sont sauvegardées pour "une utilisation ultérieure", la manière dont tout cela (et ce que j'aurais oublié de citer) cohabite et interagit.

    Tout cela est du seul ressort du développeur / de l'équipe de développement, et le "client" ne devrait -- a mon sens --pas autorisé à y mettre son grain de sel.

    Citation Envoyé par defZero
    ... Evidemment, la programmation, c'est des sciences exactes, je ne dis pas le contraire, ...
    Ah, pas si évident que ça, en fait.
    Si c'était totalement vrai, tout programme compilant ne pourrait jamais planter.
    C'est, justement, parce que la programmation est une science exacte qu'un programme compilant risque de planter...

    Le plantage (les résultats aberrants) sont, en quelques sortes, le symptôme suprême que le développeur a "foiré quelque chose" dans sa logique ou dans sa conception. Si la programmation n'était pas une science exacte, ces "foirades" n'auraient qu'un impact très limité sur l'ensemble .
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

Discussions similaires

  1. Quelles sont les solutions existantes pour uploader une visite virtuelle vers Google map
    Par Marketingalternative dans le forum Interfaces Graphiques en Java
    Réponses: 0
    Dernier message: 13/02/2018, 11h25
  2. Réponses: 12
    Dernier message: 14/04/2009, 08h56
  3. Réponses: 7
    Dernier message: 23/03/2009, 22h38
  4. Réponses: 17
    Dernier message: 04/07/2008, 11h20
  5. Quelles sont les compétences à avoir pour devenir un bon graphiste ?
    Par sidahmed dans le forum Webdesign & Ergonomie
    Réponses: 6
    Dernier message: 05/10/2007, 10h31

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