IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

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

Programmation : 7 choses que votre patron est censé savoir à propos du développement de logiciel


Sujet :

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

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

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    (.../...)

    Donc, amis développeurs, allez rencontrer vos utilisateurs, allez voir comment ils travaillent.

    Et puis, c'est plutôt sympa de voir utiliser notre réalisation en vrai
    C'est vrai même pour quelqu'un comme moi qui fais du test. Voir les médecins, infirmières et aides-soignantes se battre en vrai avec le logiciel que je teste tous les jours m'a permis de mieux comprendre ce qui était réellement important. En particulier, si on bouge un patient de lit, et que ça traine quelques secondes, assis à mon poste, je ne le remarque même pas(et je ne parle pas de mon automate de tests). Les infirmières que le devoir appellent, elles, ont un besoin critique de réactivité. Et ça fait partie de mon job que de signaler les faiblesses à ce niveau. Et je ne le savais pas tant que je n'ai pas passé une semaine sur place, pour un démarrage.
    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. #22
    Membre actif
    Homme Profil pro
    Développeur Concepteur WebMethods
    Inscrit en
    Février 2015
    Messages
    73
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur Concepteur WebMethods
    Secteur : Finance

    Informations forums :
    Inscription : Février 2015
    Messages : 73
    Points : 207
    Points
    207
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Petite anecdote pour illustrer: il est important d'aller voir ces utilisateurs.
    Haha, ne t'en fais pas, même si mes propos laissent croire que je développe sans contact avec l'utilisateur, c'est loin d'être le cas. Je reviens d'ailleurs du bureau de l'un d'entre eux pour lui résoudre un petit souci d'utilisation de l'outil qu'on lui a développé.

    Au-delà de ça, c'est bien sûr important de pouvoir communiquer avec eux, voire même de leur proposer des séances de "workshop" durant lesquelles on collecte leurs besoins et leurs propositions de correctifs et améliorations. C'est l'occasion d'échanger, d'expliquer pourquoi certains choix ont été faits, et d'avoir avant tout leur point de vue sur "Qu'est-ce qui permettrait à notre application d'être une réelle source de gains de temps et d'effort au quotidien ?". C'est ainsi que l'on fonctionne, et ça contente aussi bien les users que nous-mêmes côté développement, puisqu'on sait que ce que l'on fait correspondra concrètement à ce qui leur est nécessaire.

  3. #23
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par _skip Voir le message
    Je vais me faire l'avocat du diable parce que pour être moi-même développeur et chef d'équipe, le râbachage de généralités et de stéréotypes sur le développement chez les bloggers me gonfle un peu

    J'ai l'impression de relire encore et encore un énième concentré de lieux communs sur la profession. Le développeur, ce grand incompris qui se retrouve à assumer les décisions de supérieurs bornés et incompétents qui se croient à tort plus malins que lui. Ca tourne toujours autour de la même idée, les chefs c'est mal, la hiérarchie c'est mal, <mais insérer une recommandation agile ici> c'est bien... Généralement quand on voit ce genre de pavé, y'a une petite note en bas de page: "Ah et au fait pour savoir comment faut bosser oubliez pas notre super service de coaching Agile à seulement 250$ la demi journée".
    Je partage ton sentiment.

    Voici un article très divertissant que j'avais lu il y a quelques temps, qui tente d'expliquer le développement logiciel à des exécutifs à travers le point de vue de l'un d'entre eux au fil d'un projet qui déraille. Cela permettra peut-être à certains de se projeter...


    What is code ?

    For your entire working memory, some Internet thing has come along every two years and suddenly hundreds of thousands of dollars (inevitably millions) must be poured into amorphous projects with variable deadlines. Content management projects, customer relationship management integration projects, mobile apps, paperless office things, global enterprise resource planning initiatives—no matter how tightly you clutch the purse strings, software finds a way to pry open your fingers.

    Here we go again. On the other side of your (well-organized) desk sits this guy in his mid-30s with a computer in his lap. He’s wearing a taupe blazer. He’s come to discuss spending large sums to create intangible abstractions on a “website re-architecture project.” He needs money, support for his team, new hires, external resources. It’s preordained that you’ll give these things to him, because the CEO signed off on the initiative—and yet should it all go pear-shaped, you will be responsible. Coders are insanely expensive, and projects that start with uncomfortably large budgets have an ugly tendency to grow from there. You need to understand where the hours will go.

  4. #24
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Comment être crédible si on ne sait pas estimé son temps de réalisation ?
    Personnellement, ça me renvoie une image de quelqu'un qui ne maîtrise pas ce qu'il fait.

    Je préfère de très loin un développeur moyen mais qui sait me fixer une date de réalisation et la tenir (ou encore anticiper un retard et le remonter à temps) plutôt qu'un cador qui livre ses dev de manière erratique.
    Mais tu connais beaucoup de projets dont la date de livraison estimée n'a pas dérivé ? Pas moi.

    Selon certaines études, le dépassement de délai moyen pour les projets software était de 74% en 2012. Il y a des précédents absolument désastreux comme healthcare.gov ou ONP en France. Qu'est-ce qui est plus crédible et professionnel ? De donner une date dont on sait qu'elle a de fortes chances d'être complètement fantaisiste, ou de dire "je ne peux pas dire quand le gros problème sera résolu, mais je peux le découper en petits sous-problèmes qui deviendront estimables au fur et à mesure de la réalisation des précédents" ?

    Ce que dit l'auteur du post, c'est que c'est impossible d'estimer de manière fiable toute tâche de développement dépassant quelques heures. C'est inhérent à la nature de ce qu'on produit. On prend donc le problème par le mauvais bout en forçant les développeurs et chefs de projet à donner des estimations à échéance longue pour satisfaire le client. Un logiciel est un type de produit à part, incomparable à tout ce qu'on a connu jusque là. Il faut inventer de nouvelles façons de le vendre au client.

  5. #25
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    Ce que dit l'auteur du post, c'est que c'est impossible d'estimer de manière fiable toute tâche de développement dépassant quelques heures. C'est inhérent à la nature de ce qu'on produit. On prend donc le problème par le mauvais bout en forçant les développeurs et chefs de projet à donner des estimations à échéance longue pour satisfaire le client. Un logiciel est un type de produit à part, incomparable à tout ce qu'on a connu jusque là. Il faut inventer de nouvelles façons de le vendre au client.
    Oui, on travail sur des produits qui finalement ne seront jamais fini.
    On le livre à un moment donné au client, mais on sait que:
    • il reste quelques bugs
    • il manque quelques fonctionnalités
    • tels ou tels interfaces serait à refaire
    • il y a un peu de lenteur dans tels ou tels traitements
    • ...


    Contrairement à d'autre industrie, le produit que l'on livre n'est pas fini.
    Je dis pas qu'une voiture ou une machine à laver n'a pas de défauts, mais une fois livré, le produit répond correctement à un cahier des charges.
    Chez nous ce n'est pas le cas, parce qu'un cahier des charges d'un produit informatique est forcément incomplet et donc sans sens.

    Et donc, c'est logique que l'on puisse pas assurer une date de fin d'un produit jamais fini.
    Mais on continu de vouloir avoir a tout pris un cahier des charges précis dès le début et une estimation précise pour tous ce rassurer.
    Ben ça marche pas en informatique parce que nous ne sommes pas une industrie de production (avec une chaîne de fabrication) mais une industrie de conception (avec des cerveaux)

    Par contre, on peux annoncer : tel jours je vous livrerai.
    Mais on ne peux pas annoncer précisément quoi.

  6. #26
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par _skip Voir le message
    Ok c'est un coach et il vend des bouquins... A peine différent. Franchement j'aimerais bien que les gars de son genre, les baratineurs et autre consultants agiles laissent un peu les développeurs tranquilles et aillent casser les pieds au monde dans une autre industrie.
    Honnêtement, je trouve l'article plutôt dangereux pour son business et d'autant plus courageux de sa part. Un coach/consultant soucieux de ménager ses clients ne dirait pas "les analystes métier et chefs de projet ne branlent rien" dans un article ou shit et bullshit apparaissent tous les 3 mots.

    Citation Envoyé par _skip Voir le message
    Je passe les autres trucs du style, "les estimations c'est de la connerie (bullshit, c'est dans l'article)". C'est clair qu'on préférerait tous avoir des deadlines infinies et ne s'arrêter que quand on a atteint la perfection, seulement les estimations sont nécessaires pour chiffrer les coûts et organiser les ressources et font partie essentielle de la phase de marchandage avec le client.
    Le truc, c'est pour quel résultat au final ? J'ai l'impression que tout le monde fait comme si les projets de dev se terminaient merveilleusement bien avec un client satisfait, mais dans mon expérience c'est vrai dans, peut-être, 10% des cas et encore.

    Le dépassement de délai et de budget fait partie des fléaux qui ridiculisent la profession, renforcent la réputation d'escrocs finis des SSII s'il en était besoin, et exaspèrent les donneurs d'ordre, et ça arrive même (surtout ?) quand on a tout estimé au cordeau depuis le départ. Donc on continue avec les mêmes vieilles recettes, c'est à dire échouer et échouer encore dans nos tentatives de donner la juste estimation et au passage flouer le client, ou on essaie de trouver une autre approche ?

    Citation Envoyé par _skip Voir le message
    Il y a quasiment aucun projet qui peut se faire sans une estimation, ni construction d'immeuble, route, ligne de chemin de fer. Donc c'est pas de la connerie dont on choisit de se passer ou non, c'est un problème.
    La construction est une discipline vieille de dizaines de milliers d'années, les routes plusieurs milliers, les chemins de fer 170 ans. On est aux balbutiements du développement de logiciels, qui en plus a la particularité de manier de l'immatériel. Pourquoi s'acharner à vouloir appliquer des méthodes anciennes à une profession aussi radicalement différente ?

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

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    (.../...)
    Le truc, c'est pour quel résultat au final ? J'ai l'impression que tout le monde fait comme si les projets de dev se terminaient merveilleusement bien avec un client satisfait, mais dans mon expérience c'est vrai dans, peut-être, 10% des cas et encore.
    J'en ai eu bien plus que ça. Mais avec pas mal de casse quand même. J'ai quand même l'impression que plus un projet est gros, plus sa probabilité de plantage est importante. Tu as cité l'ONP, et je crois qu'on a là l'exemple typique d'un projet qui s'est écrasé sous son propre poids.

    Citation Envoyé par Luckyluke34 Voir le message
    Le dépassement de délai et de budget fait partie des fléaux qui ridiculisent la profession, renforcent la réputation d'escrocs finis des SSII s'il en était besoin, et exaspèrent les donneurs d'ordre, et ça arrive même (surtout ?) quand on a tout estimé au cordeau depuis le départ. Donc on continue avec les mêmes vieilles recettes, c'est à dire échouer et échouer encore dans nos tentatives de donner la juste estimation et au passage flouer le client, ou on essaie de trouver une autre approche ?
    Mais dans les pays sans SSII, c'est pareil. Des projets internes de grosses boites, Françaises ou étrangères, qui vont dans le décor, j'en ai vu quelques uns. Et aussi des cas ou le client final plantait la SSII par des exigences impossibles("il y a une erreur dans la spec? C'est pas possible, je l'ai validée, elle ne bougera plus d'un iota").

    Citation Envoyé par Luckyluke34 Voir le message
    La construction est une discipline vieille de dizaines de milliers d'années, les routes plusieurs milliers, les chemins de fer 170 ans. On est aux balbutiements du développement de logiciels, qui en plus a la particularité de manier de l'immatériel. Pourquoi s'acharner à vouloir appliquer des méthodes anciennes à une profession aussi radicalement différente ?
    ...et on a encore pas mal de surprises sur pas mal de chantiers. Pas de l'ampleur ou de la fréquence du logiciel, mais quand mê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.

  8. #28
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    Honnêtement, je trouve l'article plutôt dangereux pour son business et d'autant plus courageux de sa part. Un coach/consultant soucieux de ménager ses clients ne dirait pas "les analystes métier et chefs de projet ne branlent rien" dans un article ou shit et bullshit apparaissent tous les 3 mots.
    Franchement pourquoi pas? Dans beaucoup de pays du monde, les chefs de projets et les analystes métiers sont des employés comme les autres, en plus souvent des employés à plus haut salaire. Du coup un patron est tout content d'entendre qu'il peut se passer d'eux. En plus, ça assure un capital sympathie auprès des exécutants du stage, soit l'équipe de projet en leur disant "On sait ce que vous ressentez, vous avez pas besoin de ces gens qui vous cassent les couilles, émancipez-vous!*. Ceux qui sont visés sont les décideurs qui ont des soucis avec leurs projets informatiques et qui pourraient voir des solutions miracles au niveau de la simple organisation. Donc non il ne scie pas la branche sur laquelle il est assis, sa clientèle type ce sont pas les chefs de projets ou les entreprise où tout se passe bien, mais celles où il y a de l'eau dans le gaz et dont les patrons doutent et s'interrogent sur l'efficacité de leur service IT.

    Le truc, c'est pour quel résultat au final ? J'ai l'impression que tout le monde fait comme si les projets de dev se terminaient merveilleusement bien avec un client satisfait, mais dans mon expérience c'est vrai dans, peut-être, 10% des cas et encore.

    Le dépassement de délai et de budget fait partie des fléaux qui ridiculisent la profession, renforcent la réputation d'escrocs finis des SSII s'il en était besoin, et exaspèrent les donneurs d'ordre, et ça arrive même (surtout ?) quand on a tout estimé au cordeau depuis le départ. Donc on continue avec les mêmes vieilles recettes, c'est à dire échouer et échouer encore dans nos tentatives de donner la juste estimation et au passage flouer le client, ou on essaie de trouver une autre approche?

    La construction est une discipline vieille de dizaines de milliers d'années, les routes plusieurs milliers, les chemins de fer 170 ans. On est aux balbutiements du développement de logiciels, qui en plus a la particularité de manier de l'immatériel. Pourquoi s'acharner à vouloir appliquer des méthodes anciennes à une profession aussi radicalement différente ?
    Si tu te plantes sur le délai c'est une chose et ce n'est pas forcément synonyme d'échec, si tu te plantes sur la satisfaction tu as un autre problème bien plus grave. Les estimations sont un problème mais la solution n'est en aucun cas de répondre "Ca prend le temps que ça prend" et donc par extension "ça coûte le prix que ça coûte". Car ça c'est ne prendre aucun engagement ni sur l'aspect financier, ni sur les délais et donc virtuellement ne fournir aucune garantie de résultat. C'est pas acceptable dans le monde de l'industrie.

    Si tu as des travaux à faire faire chez toi, tu demandes un devis, tu demandes combien ça coûte.
    Tu te renseignes sur le prix, si le mec te répond "c'est 100 euros de l'heure", ta prochaine question c'est "ok vous pensez que ça vous prendra combien de temps", s'il dit qu'il peut pas trop savoir à vue de nez, tu l'invites à venir constater. Et là le type se rend sur place, constate ce qu'il y a à faire, il te donne un estimation du style : "c'est fini quand ce sera fini puis ça prend le temps que ça prendra" ta réponse logique c'est "Ok merci au revoir".
    C'est légitime, tu as besoin de savoir quel est ton budget ou du moins d'y mettre un ordre de grandeur, et niveau délai tu as peut être besoin de coordonner diverses entreprises qui ont elles aussi un agenda à tenir?

    C'est clair qu'il est difficile de dire, "c'est fini le vendredi 30 juin l'année prochaine", c'est rarement ce qu'on nous demande, à l'impossible nul n'est tenu. Mais définir un semblant de calendrier et donner un ordre de grandeur, on y est tenu. La marge d'erreur est grande mais il existe des solutions pour amortir les chocs, et je ne parle pas seulement de faire des points réguliers et de conserver une bonne communication. Commencer par une bonne analyse est déjà un début et les bloqueurs potentiels devraient apparaître pour la plupart, même s'il reste souvent des doutes. Pour cela il y a une arme sans faille, c'est la réalisation de POCs payantes, les clients sont généralement tout à fait disposés à les accepter, en principe ils savent qu'un projet comporte des risques, il est facile de leur faire comprendre que c'est aussi dans leur intérêt avant d'investir des sommes colossales dans le vide.

    Quand dans un projet de construction on a des doutes sur ce sur quoi on va tomber, on fait des études géologiques (payantes) et tout le monde trouve ça normal. Personne ne va dire "les délais et les dépassements nous font chier, on donne pas de délai comme ça on est sûr de les dépasser". C'est aussi ridicule que de dire "je casse le thermomètre puis il fera toujours 20 degrés".

  9. #29
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par _skip Voir le message
    Si tu as des travaux à faire faire chez toi, tu demandes un devis, tu demandes combien ça coûte.
    Tu te renseignes sur le prix, si le mec te répond "c'est 100 euros de l'heure", ta prochaine question c'est "ok vous pensez que ça vous prendra combien de temps", s'il dit qu'il peut pas trop savoir à vue de nez, tu l'invites à venir constater.
    On est en train de comparer des choux et des carottes. Ces travaux n'ont rien à voir avec la complexité d'un système applicatif même de taille moyenne. De plus, les variations du métier du client d'une application à l'autre sont énormes et complexes et les développeurs ne sont à la base pas des professionnels de ce domaine, ils doivent l'apprendre. Si le bâtiment est un métier, le logiciel est un méta-métier avec finalement peu de reproductibilité d'un projet applicatif à l'autre.

    De plus, deux grosses forces sont à l'oeuvre dans un projet de développement qui peuvent le faire déraper à tout moment : la complexité technique et le scope fonctionnel. En début de projet, l'équipe de développement peut se targuer de maîtriser la première à fond et le client ou le consultant en définition de besoins faire semblant d'avoir mis l'autre sous cloche mais on sait très bien qu'il n'en est rien, ces bestioles peuvent nous sauter à la tronche à tout moment et on n'y peut rien.

    Face à ça, l'idée n'est pas de baisser les bras et dire "ça sera fait quand ça sera fait" mais de découper en plus petites bêtes qu'on ne va ni estimer ni facturer intégralement tout de suite. On va partir sur une première prestation de durée et donc de coût fixe mais dont le scope sera effectivement peu connu à l'avance, pour découvrir le rythme auquel on peut aller, avant d'embrayer sur le reste. Deux principaux avantages : le client a la liberté de décider à n'importe quel moment de ne plus faire ou de faire différemment une feature X non entamée si des découvertes sont faites en chemin (et ça va forcément arriver), et l'équipe de développement va pouvoir affiner son calendrier de réalisation des futures fonctionnalités à mesure qu'elle avance en tenant compte de l'expérience acquise sur les features précédentes.

    Pour l'aspect technique, l'idée du POC ou des études géologiques que tu cites correspond exactement à cette approche, mais ça doit être répété pour chaque fonctionnalité dont la solution technique présente des risques et des inconnues, j'ai rarement vu un projet entier qui pouvait être estimé sur la base d'un seul POC.

  10. #30
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    Si le bâtiment est un métier, le logiciel est un méta-métier avec finalement peu de reproductibilité d'un projet applicatif à l'autre.
    Es-tu en train de prétendre que l'expérience d'un développeur n'a aucune valeur ?????


    Citation Envoyé par Luckyluke34 Voir le message
    Face à ça, l'idée n'est pas de baisser les bras et dire "ça sera fait quand ça sera fait" mais de découper en plus petites bêtes qu'on ne va ni estimer ni facturer intégralement tout de suite. On va partir sur une première prestation de durée et donc de coût fixe mais dont le scope sera effectivement peu connu à l'avance, pour découvrir le rythme auquel on peut aller, avant d'embrayer sur le reste. Deux principaux avantages : le client a la liberté de décider à n'importe quel moment de ne plus faire ou de faire différemment une feature X non entamée si des découvertes sont faites en chemin (et ça va forcément arriver), et l'équipe de développement va pouvoir affiner son calendrier de réalisation des futures fonctionnalités à mesure qu'elle avance en tenant compte de l'expérience acquise sur les features précédentes.
    Ce que tu décris, c'est la méthode Agile

  11. #31
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par _skip Voir le message
    Quand dans un projet de construction on a des doutes sur ce sur quoi on va tomber, on fait des études géologiques (payantes) et tout le monde trouve ça normal. Personne ne va dire "les délais et les dépassements nous font chier, on donne pas de délai comme ça on est sûr de les dépasser". C'est aussi ridicule que de dire "je casse le thermomètre puis il fera toujours 20 degrés".
    Tu as raison sur beaucoup de points, mais l'industrie logicielle est encore immature par rapport aux autres car toujours en pleine mutation et évolution. Nous n'en sommes encore qu'au moyen-âge du développement logiciel et chaque année amène de nouveaux problèmes et de nouvelles solutions techniques. La conséquence de ça c'est que tu n'as pas 5% ou 10% d'inconnues, mais 50%. Si tu veux vraiment prospecter toutes ces inconnues, il va te falloir dix ans et tes réponses seront obsolètes d'ici là.

    Les autres métiers évoluent bien sûr eux aussi, mais beaucoup plus lentement. Et au niveau de l'industrie logicielle dans son ensemble je pense préférable de continuer à évoluer très rapidement plutôt que de chercher à freiner cette évolution pour assurer une plus grande maturité. Même si ça se défend pour certains projets. Je m'inquiète d'ailleurs de cette tendance à vouloir stabiliser le développement logiciel : nous sommes loin d'avoir aujourd'hui des bases techniques satisfaisantes, il reste beaucoup à faire.

  12. #32
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    On est en train de comparer des choux et des carottes. Ces travaux n'ont rien à voir avec la complexité d'un système applicatif même de taille moyenne. De plus, les variations du métier du client d'une application à l'autre sont énormes et complexes et les développeurs ne sont à la base pas des professionnels de ce domaine, ils doivent l'apprendre. Si le bâtiment est un métier, le logiciel est un méta-métier avec finalement peu de reproductibilité d'un projet applicatif à l'autre.
    Tu as pas besoin de me convaincre, je sais exactement ce que je fais comme métier et ce que ça m'a valu comme heures non compensées .

    J'ai volontairement pas cité de corps de métier parce que justement je voulais pas qu'on me dise qu'un peintre il compte combien y'a de mètres carré puis il sait le temps qu'il lui faut, c'était pas le point.
    Je parlais en fait du besoin essentiel et incontournable qu'à le monde de pouvoir quantifier la charge de travail et la budgétiser et de pouvoir s'organiser en conséquence. J'essaie pas de convaincre les gens que c'est facile de faire des estimations, je dis juste qu'on est forcément obligé d'en faire. On peut dire que le monde est mal fait et que c'est pas normal qu on nous le demande, le fait est qu'on nous le demande et qu'on doit être capable de fournir au moins une partie de la réponse.

    Face à ça, l'idée n'est pas de baisser les bras et dire "ça sera fait quand ça sera fait" mais de découper en plus petites bêtes qu'on ne va ni estimer ni facturer intégralement tout de suite. On va partir sur une première prestation de durée et donc de coût fixe mais dont le scope sera effectivement peu connu à l'avance, pour découvrir le rythme auquel on peut aller, avant d'embrayer sur le reste. Deux principaux avantages : le client a la liberté de décider à n'importe quel moment de ne plus faire ou de faire différemment une feature X non entamée si des découvertes sont faites en chemin (et ça va forcément arriver), et l'équipe de développement va pouvoir affiner son calendrier de réalisation des futures fonctionnalités à mesure qu'elle avance en tenant compte de l'expérience acquise sur les features précédentes.

    Pour l'aspect technique, l'idée du POC ou des études géologiques que tu cites correspond exactement à cette approche, mais ça doit être répété pour chaque fonctionnalité dont la solution technique présente des risques et des inconnues, j'ai rarement vu un projet entier qui pouvait être estimé sur la base d'un seul POC.
    C'est ce que je dis depuis le début, il y a des solutions au niveau conduite de projet ou des airbags, pas forcément la panacée. Plus faciles à dire qu'à faire mais toutes nécessitent de bons efforts d'analyse. Croire qu'on va pouvoir bosser sans fournir d'estimation, et que sous prétexte qu'elles sont presques toujours fausses on va faire accepter à nos clients de nous éxonérer d'en faire, c'est pas réaliste.

  13. #33
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 653
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 653
    Points : 3 773
    Points
    3 773
    Par défaut
    Pas d'accord avec le passage sur les chefs de projet. Dans un projet il faut quelqu'un qui s'occupe de la gestion globale du projet et des "Affaires Etrangères" à l'équipe et c'est le rôle du CP. Le développeur "tête dans le guidon" de son code n'a pas forcément le temps pour regarder où l'équipe en est globalement dans le projet. De même le développeur n'a pas à avoir de lien direct avec l'extérieur en général. Dans le cadre d'une collaboration étroite sur une partie du projet, pourquoi pas avoir un tel lien, mais seulement dans le cadre de cette partie du projet. Pour le reste n'oubliez pas que le lien client-développeur n'est pas à sens unique. Oui c'est probablement bien en tant que dev de pouvoir avoir la réponse à sa question directement à la source en s'adressant directement au client. Mais cette relation c'est aussi le client qui peut solliciter directement le dev en cas de souci de son côté. Or je ne suis pas sûr que cette partie du lien là soit forcément bonne, surtout pour le dev qui serait constamment sollicité alors qu'il a surtout besoin de concentration.

    Bref le CP est nécessaire dans le sens où il permet aux devs de se concentrer sur ce qu'ils ont à faire en s'occupant de ces "entraves" là. Un bon CP libère le potentiel de ses devs et je ne suis pas sûr qu'on puisse se passer de cette personne là.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  14. #34
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    La question qui me viens alors: Qu'est ce qu'un chef de projet?

    Est-il un référent métier pour le produit que l'on développe?
    Est-il un expert informatique qui dirige techniquement le développement?

    J'ai l'impression, que la fonction CP est aussi différente qu'il y a de projet.

    Un CP qui est un référent pour le client, qui a une vision du produit, qui oriente les choix fonctionnels de l'application, .... est nécessaire pour un développement.
    Un CP qui me dit quoi codé et comment et qui passe sont temps à mettre un tableau d'avancement du projet (qui est constamment faux) je trouve ça du gaspillage de nos propres compétences.

  15. #35
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    La question qui me viens alors: Qu'est ce qu'un chef de projet?


    Est-il un référent métier pour le produit que l'on développe?
    Est-il un expert informatique qui dirige techniquement le développement?

    J'ai l'impression, que la fonction CP est aussi différente qu'il y a de projet.

    Un CP qui est un référent pour le client, qui a une vision du produit, qui oriente les choix fonctionnels de l'application, .... est nécessaire pour un développement.
    Un CP qui me dit quoi codé et comment et qui passe sont temps à mettre un tableau d'avancement du projet (qui est constamment faux) je trouve ça du gaspillage de nos propres compétences.
    Ta question est plaisante à lire
    On lit souvent des posts où les développeurs se plaignent de leurs CP "incompétents" mais sans jamais vraiment expliciter ce qu'ils attendent de leurs CP...

    Pour toi, qu'est un chef de projet ?
    A quoi sert il ?

    De mon point de vu, les développeurs, et tous les autres participants du projet, ne doivent pas avoir conscience de ce que fait le CP car justement, son rôle est de faire en sorte que chacun n'est à se préoccuper que de ce qu'il a à faire et que les décisions prises soient tenues et suivies d'effets.
    Bref, si un architecte mais en place des normes de dev, le CP veille à ce qu'elles soient suivies par les développeurs.
    De même, si un périmètre est défini : s'assurer qu'il est réalisé (ni plus, ni moins).
    Ou encore, s'il y a du retard (ce qui arrive presque tout le temps et n'a rien d'anormal), l'anticiper et prendre les mesures qui s'imposent : ça ne sert à rien de provisionner un env. de production trop longtemps à l'avance et pomper le budget du projet avec de la supervision de serveurs sur lesquels il n'y a rien d'installer, par exemple ou encore, ne pas mobiliser une équipe de recette métier alors que la livraison n'a pas pu se faire ou encore, ne pas mobiliser des utilisateurs pour une formation si les supports de formation et l'env. de formation ne sont pas dispo, etc, etc, etc.
    Un projet informatique, ce n'est rarement que du dev. Il y a beaucoup de choses qui se passent autour qu'il est nécessaire de coordonner.
    Un CP ne fait pas des plannings pour le plaisir c'est que derrière, il y a des actions à anticiper et/ou à coordonner sinon il y a des gens qui peuvent être mobilisés à se tourner les pouces ou de la production erronée (l’impression de prospectus avec une date fausse, par exemple).
    ==> l'anticipation est importante car on ne prévient pas la veille d'où les demandes de chiffrages qui paraissent si "absurdes" aux développeurs (cf. le billet de blog de ce topic).
    ==> sans parler des questions budgétaires et contractuelles où je partirai dans un roman.

    Ensuite, dans un petit projet, la fonction "pure" du CP occupe rarement un plein temps.
    Du coup, le CP peut cumuler d'autres fonctions comme l'architecture et la conception (pour CP technique) ou le suivi fonctionnel (AMOA pour un CP fonctionnel).

  16. #36
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Ta question est plaisante à lire
    Pas de quoi, j'aime bien posé des question gentillette comme cela, même si parfois ça semble enfoncer des portes ouvertes.
    Beaucoup ne se sont pas posé la question aussi simplement, je pense qu'elle est très importante à se poser.

    J'aime bien ta vision du CP, je la partage à plein de point de vu.
    Mais cela reste une vision cadré à une catégorie particulier de projet.

    Ayant travaillé chez des éditeurs de logiciel, je vois plus le CP utile comme un visionnaire de produit, quelqu'un qui donnera des priorités fonctionnels à ce que l'on voudra bientôt livrer.
    Donc, plutôt quelqu'un du métier, du fonctionnel voir du marketing.
    Et bien sur, pouvoir gérer en amont et en aval des impondérables: changement des besoins, changement de la livraison, manque de moyen matériel, manque de moyen humains (RH), ...

    Un CP technique, je ne comprend pas trop ce qu'il va m'apporter pour le bien de l'application.
    Après, j'ai toujours été dans des équipes moyennes ou petites (<20) où la vu globale du logiciel était possible pour les développeurs.
    Peut être que sur des gros projets, cela a un sens plus marqué.

    J'ai aussi vu des CPs MS-Project/diagramme de Gant qui passaient leur temps a mettre à jours un planning prévisionnelle pour du reporting.
    Ni technique, ni fonctionnel: Inutile, au possible.
    On aurait dit au managment "ça sera fini, quand ça sera fini", ils n'auraient pas du tout aimer, c'est sur.
    Mais là, ils sont content: ils ont en direct les courbes qui descendent, qui descendent ....
    Le résultats est le même, mais là, on a un type qui "gère" le projet (il fait des courbes fausses toutes la journée) donc tout va bien.

    Bon, je rapporte un cas extrême et heureusement tout les chefs de projets ne sont pas comme ça.

    Mais forcement, ma question reste bonne à se poser: C'est quoi un chef de projet?

  17. #37
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Mais forcement, ma question reste bonne à se poser: C'est quoi un chef de projet?
    C'est le responsable du projet, celui qui fait du projet une réalité.

    Pour l'exécutif (le point de vue à considérer), le chef de projet est une boîte noire qui va mettre au monde le projet. S'il faut engager du personnel, des consultants, louer un bâtiment, souscrire à des abonnements EDF, coordonner des sous-traitants, acheter des produits ou des services, c'est lui qui s'en occupera. Tout ce qui sera nécessaire à la réalisation du projet. Idéalement l'exécutif ne veut voir que le résultat (suivi de l'avancement compris).


    Les tâches distinctes qu'il peut être amené à occuper selon les cas :
    * L'architecte logiciel s'occupe de concevoir une architecture technique. C'est un "technicien".

    * Le directeur produit est un exécutif. Il apprend à connaître la clientèle, ses besoins, le positionnement stratégique du produit, la concurrence, le contexte commercial, et à décider en fonction de toute cela des évolutions futures du produit. Cela relève de la stratégie industrielle.

    * Le commercial ou chargé de clientèle fait l'interface avec le client ou le commanditaire. C'est un commercial avant tout, parfois épaulé d'un technicien qui peut être le chef de projet ou un membre de son équipe. Il est chargé de vendre le produit.

    * Le responsable qualité met au point des méthodologies, protocoles et outils pour assurer la qualité du produit. Il assure aussi un contrôle direct (revue de code & co) et peut superviser une équipe de testeurs de façon autonome.

    * Le chef d'équipe (manager) : dans les petits projets le chef de projet est presque toujours le chef d'équipe. Mais dans les grands projets on divise les individus en équipes distinctes avec autant de chefs d'équipe. Ces chefs d'équipes deviennent parfois de vrais petits chefs de projets pour les sous-projets du grand projet.

  18. #38
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    C'est le responsable du projet, celui qui fait du projet une réalité.

    Pour l'exécutif (le point de vue à considérer), le chef de projet est une boîte noire qui va mettre au monde le projet. S'il faut engager du personnel, des consultants, louer un bâtiment, souscrire à des abonnements EDF, coordonner des sous-traitants, acheter des produits ou des services, c'est lui qui s'en occupera. Tout ce qui sera nécessaire à la réalisation du projet. Idéalement l'exécutif ne veut voir que le résultat (suivi de l'avancement compris).


    Les tâches distinctes qu'il peut être amené à occuper selon les cas :
    * L'architecte logiciel s'occupe de concevoir une architecture technique. C'est un "technicien".

    * Le directeur produit est un exécutif. Il apprend à connaître la clientèle, ses besoins, le positionnement stratégique du produit, la concurrence, le contexte commercial, et à décider en fonction de toute cela des évolutions futures du produit. Cela relève de la stratégie industrielle.

    * Le commercial ou chargé de clientèle fait l'interface avec le client ou le commanditaire. C'est un commercial avant tout, parfois épaulé d'un technicien qui peut être le chef de projet ou un membre de son équipe. Il est chargé de vendre le produit.

    * Le responsable qualité met au point des méthodologies, protocoles et outils pour assurer la qualité du produit. Il assure aussi un contrôle direct (revue de code & co) et peut superviser une équipe de testeurs de façon autonome.

    * Le chef d'équipe (manager) : dans les petits projets le chef de projet est presque toujours le chef d'équipe. Mais dans les grands projets on divise les individus en équipes distinctes avec autant de chefs d'équipe. Ces chefs d'équipes deviennent parfois de vrais petits chefs de projets pour les sous-projets du grand projet.
    Merci DonQuiche de ta vision du chef de projet.

    C'est amusant, je bosse depuis 17 ans maintenant dans le monde de l'informatique et je n'ai pas identifié les mêmes types de Chef de Projet pour l'instant.
    Comme quoi, je pense toujours qu'il y a autant de type de CP que de projet.
    Bon, je pense que le fait que j'ai le plus souvent travaillé dans des équipes agiles doit jouer, c'est sur.

    Par contre, en te lisant, j'en viens à une autre question: C'est quoi un chef d'équipe ?
    C'est quoi la charge de travail et la responsabilité que tu vois dans un CE qui n'est pas celle du CP ?
    Pour un petit projet, c'est le CP qui le fait, mais pour un projet moyen, le CE fait quoi?

  19. #39
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    C'est amusant, je bosse depuis 17 ans maintenant dans le monde de l'informatique et je n'ai pas identifié les mêmes types de Chef de Projet pour l'instant.
    Comme quoi, je pense toujours qu'il y a autant de type de CP que de projet.
    Bon, je pense que le fait que j'ai le plus souvent travaillé dans des équipes agiles doit jouer, c'est sur.
    Le fonction du CP est très "brouillée" car sur les petits et moyens projets (la très grande majorité des projets), ce rôle occupe rarement un plein temps.
    Du coup, la personne qui a le titre de CP effectue aussi d'autres tâches...

    Dans le cas de l'Agile, il n'y a plus vraiment de CP car l'organisation du projet est plus "transverse"
    On parle plutôt de Product Owner et de Scrum Master (dans le cas du SCRUM), etc.

  20. #40
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    Mars 2012
    Messages
    1 969
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Mars 2012
    Messages : 1 969
    Points : 3 375
    Points
    3 375
    Par défaut
    Un patron avec un téléphone, un email et un tableur est un patron heureux.
    Si en plus il peut avoir un baton comme dans certains pays, là c'est le panard

    Va lui expliquer que t'as appris du Jquery, bootstrap, ajax pour l'application mais que tu as probablement 2 semaines de retard, là il va te regarder comme ça
    Si la réponse vous a aidé, pensez à cliquer sur +1

Discussions similaires

  1. Réponses: 47
    Dernier message: 29/05/2013, 19h55
  2. Est ce que ce syntaxe est juste ?( a propos des tableaux)
    Par lahdili.reda dans le forum Langage
    Réponses: 7
    Dernier message: 20/06/2012, 14h56
  3. Réponses: 11
    Dernier message: 15/02/2009, 17h11
  4. Exécuter un programme des que le poste est allumé
    Par edzodzinam dans le forum Autres Logiciels
    Réponses: 5
    Dernier message: 08/02/2006, 05h08
  5. [débutant]Est-ce que Direct X est programmable en C ?
    Par Bubonik software dans le forum DirectX
    Réponses: 12
    Dernier message: 12/12/2003, 11h45

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