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

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    février 2017
    Messages
    896
    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 : 896
    Points : 30 149
    Points
    30 149
    Par défaut Charger les développeurs d'estimer les délais dans le détail est une perte de temps et d’argent
    Charger les développeurs d'estimer les délais dans le détail est une perte de temps et d’argent
    D’après un contributeur d’un institut en techniques de gestion des logiciels

    Dans une ère où le numérique occupe une place de choix dans les cultures du monde entier, les métiers du génie logiciel bénéficient d’une forte demande en applications de toutes sortes. Dans le processus de mise sur pied de ces dernières, une étape cruciale est à franchir : celle d’estimation des délais de réalisation des tâches qui impacte sur le respect du calendrier de livraison au client. Les travailleurs de la filière informatique sont pour la plupart d’accord sur un point au sujet de cet exercice : ses retombées (les estimations des délais) sont en général plus trompeuses qu’autre chose. Une publication parue sur une colonne d’un institut de gestion des logiciels tente son essai d’explication de cet état de choses…

    Ce qui ressort en premier de cette publication est que l’estimation des délais est faussée à la base en raison de la manière dont certaines équipes de développement la mènent. Le problème en toile de fond est celui de l’application de méthodes classiques de gestion des projets à un domaine (le développement de logiciels) auxquelles elles ne conviennent pas.

    « Le développement de logiciels implique la découverte en tout temps de nouvelles tâches dans l'environnement complexe et abstrait du code, ce qui fait que la durée des tâches de développement de logiciels finit par demeurer une inconnue. De plus, les techniques de gestion de projet sont conçues pour être appliquées à des tâches dont la durée est connue. Un exemple de tâches de durée connue est le pliage de textiles pour la livraison aux clients. Si vous travaillez sur un ensemble de tâches dont la durée est connue, ce serait une erreur de ne pas appliquer les techniques de gestion de projet pour les mener à bien de façon aussi efficace que possible. Maintenant, il existe un nombre limité de tâches en génie logiciel qui fonctionnent bien avec la gestion de projet. Prenons un ensemble de 100 rapports bien connus auxquels il faut appliquer quelques variations simples pour 10 clients. Ce travail peut être assez facilement planifié en supposant que vous ayez un ingénieur qui connaît très bien ces rapports et qui a déjà apporté des modifications similaires auparavant. Mais soyons réalistes, la plupart des logiciels sont bien plus compliqués que de petites adaptations de rapports. En outre, après le démarrage d'un projet typique en génie logiciel, la découverte constante de nouvelles tâches entraîne des extensions en terme de charge de travail pour l'équipe. Cela signifie que l'évaluation de la durée de nombreuses tâches en génie logiciel finit toujours par générer des interrogations. Ceci a au finish tendance à rendre de telles évaluations absurdes et mène à l'état actuel de l'industrie où les projets logiciels sont connus pour le non-respect des délais », lit-on.

    Non-respect des délais et tares liées : nouvelles planifications à profusion, accumulation de la dette technique, etc. Toutes choses qui suggèrent la conclusion selon laquelle requérir des estimations de délais dans le détail est une perte de temps et d’argent pour les entreprises.

    Nom : 3.png
Affichages : 6283
Taille : 211,2 Ko

    Pourtant, il faut bien pouvoir définir une fourchette dans laquelle le projet sera livré au client, ce qui passe d’une manière ou d’une autre par l’exercice des estimations. À ce propos, la publication suggère de ne pas trop en faire sur le papier, mais de s’inspirer des méthodes Agile : l’action.

    « C'est dans ce contexte qu'est apparu Agile, ce qui est un bon signe de reconnaissance de l'idée que non seulement les estimations sont inexactes, mais que l'équipe était lancée sur la mauvaise piste, car les exigences étaient erronées. C'est pourquoi Agile dit d'arrêter de se concentrer autant sur la paperasserie et de faire des démonstrations tôt et souvent au client pour que l'équipe puisse découvrir ce dont le client a vraiment besoin et lui donner un bon coup de pouce ! », suggère la publication aux chefs de projets. Elle va plus loin en indiquant de s’appuyer sur des historiques de gestion de projets bouclés pour sortir les prévisions les plus précises possible pour les projets en cours ou à venir.


    À l’intention des chefs de projet, c’est peut-être le lieu de rappeler quelques règles (formulées par un architecte logiciel il y a quelques années) à respecter pour une estimation logicielle optimale :

    Première règle : ne pas allouer un temps énorme à estimer les délais

    Le temps passé à faire des estimations peut être valorisé autrement, sur d’autres tâches du projet. Il peut par exemple être ajouté au temps de développement. Malheureusement, c’est bien le contraire qui prévaut sur le terrain dans la plupart des cas et entraîne un manque de productivité des équipes de développement. Dans les chiffres, les équipes de développement perdent environ 2 à 4 heures à cause des estimations sur une semaine de 40 heures impliquant une perte en productivité entre 5 à 10 %.

    Deuxième règle : les estimations sont non transférables

    Ce qu’il faut comprendre par là est qu’une estimation faite par un individu n’est pas forcément valable pour un autre pour la simple raison que les personnes ne sont pas les mêmes, n’ont pas les mêmes capacités ni les mêmes compétences face à un problème donné. C’est encore moins valable quand l’estimation a été faite par une personne qui n’est pas du même domaine ou qui n’a pas les mêmes intérêts. C’est le cas par exemple quand c’est un commercial, dont le souci est de vendre un produit qui n’est pas encore sorti d’usine, mais qui fait croire au client que le produit en question peut être livré dans un délai assez court, qui fait l’estimation. C’est moins grave quand il s’agit d’une estimation faite par une personne du même domaine, avec un niveau d’expérience similaire. L’erreur à ne surtout pas commettre est de faire les estimations pour une équipe en considérant le temps que mettrait le plus rapide de l’équipe pour exécuter une tâche donnée.

    Troisième règle : il faut savoir qu’une estimation est par défaut erronée

    Les estimations ne doivent pas être considérées comme étant des promesses, mais plutôt comme des suppositions dépendant de l’évolution de l’activité et des risques d’erreurs. Il vient donc que personne ne devrait être surpris lorsque des estimations se révèlent fausses, mais il faut plutôt l’être quand elles sont exactes. C’est d’ailleurs la raison pour laquelle le mot estimation est utilisé et non le mot exactitude. En sus, il faut s’attendre à des précisions plus proches de la réalité quand il s’agit d’une petite tâche, mais aussi pour des projets individuels ou des projets en cours d’achèvement. En effet, pour ces derniers, on apprend de ses erreurs pour améliorer les estimations futures pour qu’elles soient les plus précises possible.

    Quatrième règle : les estimations sont temporaires

    Les estimations sont périssables avec une durée de vie relativement courte. Un développeur peut faire une estimation d’une semaine pour « coder » une fonctionnalité de son application avant le début du projet. Trois mois après le démarrage du projet, il peut arriver que certaines spécifications en relation avec la fonctionnalité en question aient changé. D’une semaine, la fonctionnalité peut se retrouver avec une nouvelle estimation d’une heure ou d’un mois. Ou alors, il peut arriver que la fonctionnalité soit tout simplement abandonnée pour une raison ou une autre. C’est pour prévoir des cas pareils que certaines équipes recommandent une révision de l’ensemble des estimations de façon périodique. Cependant, cela peut exacerber les membres de l’équipe qui ont encore en tête la première règle. Pour trouver le juste milieu entre les règles « une » et « trois », le conseil est de retarder les estimations le plus possible en vue d’y inclure tous les facteurs déterminants. Mais pour ceux qui souhaitent une estimation avec 100 % de précision, ils peuvent aussi attendre la fin du travail pour donner une estimation.

    Cinquième règle : faire une estimation de ses dépenses

    Une estimation qui vaut la peine d’être faite est bien celle du budget des dépenses. En effet, l’architecte logiciel affirme qu’aucune équipe de développement ne prendrait la décision de réaliser un nouveau logiciel sans avoir fait au préalable une estimation de ses dépenses. Si les lois précédentes sont valables, cela ne signifie pas faire fi de toute estimation. Pour mieux réussir cette estimation, toute l’équipe doit y participer, du gestionnaire du projet au développeur en passant par le commercial.

    Source : iiSM

    Et vous ?

    Qu’en pensez-vous ?
    En tant que développeur, l’estimation des délais fait-elle partie de votre quotidien ? Comment se passe cet exercice au sein de votre entreprise ?
    Les équipes de développement sont-elles condamnées à ne jamais respecter les délais de livraison des projets quelles que soient les méthodes employées ?

    Voir aussi :

    Des retards dans les délais de livraison d'un projet ? Oui, mais à qui la faute ? Une étude en recherche la cause
    Pourquoi nous trompons-nous toujours dans l'estimation des délais ? Les sprints de courtes durées sont la solution, affirme un sénior
    Programmation : 7 choses que votre patron est censé savoir à propos du développement de logiciel, selon un blogueur
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Nouveau membre du Club
    Profil pro
    Inscrit en
    mai 2005
    Messages
    9
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : mai 2005
    Messages : 9
    Points : 28
    Points
    28
    Par défaut
    Estimer les délais est une vrai plaie. Dans mon ancienne équipe les DEV avaient peur de donner des estimations, car ils se faisaient brimer par le management en cas de dépassement .

    Nous avions fini par établir une notion de forfait fixe: Trois jours par user story (point barre). Si les dev estimaient que ce n'était pas suffisant, alors on la redécoupait....

    Au final on arrivait plus près de la réalité via se système, qu'en perdant du temps à calculer la durée des tâches à la demi journée près.

  3. #3
    Membre confirmé Avatar de MagnusMoi
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2013
    Messages
    115
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : février 2013
    Messages : 115
    Points : 616
    Points
    616
    Par défaut Méthode Agile
    Si la méthode agile est apparue et que les estimations de temps sont fausses c'est à cause de 2 facteurs :
    1. La recherche de l'argent rapide
    2. La nation des pisseurs de code


    Parce que les sociétés et leur commerciaux sont prêtes à signer n'importe quoi pourvu qu'elles signent avant les autres. Donc on s'en fiche de savoir en détail ce que veulent les clients.
    Ensuite pas mal de développeur veulent juste taper du code sans prendre le temps de le penser, test de nouvelle tech sans prendre de recul, et que se poser 2 semaines ou plus pour faire : Cahier d'analyse de la demande, concevoir le modèle de donnée les CU les Workflows, le principe générale des interfaces et l'architecture ... "C'est trop fatiguant"

    Et donc on se retrouve dans des situations absurdes comme aujourd'hui, où les projets sont bâcles, non documentées (on utilise Agile parce que leur utilisateurs pensent à tord que cela les libère des doc), refait tous les 5 ans les app de zéro, remplis de copier coller et j'en passe. L'important étant de livrer on patchera après (WWE 2K20 I SEE YOU ! ), parfois comme pour le dernier God Of War certaines applications n'ont même pas certain fonctionnalité cruciales pensées ou implémentées 3 mois avant la sortie ( pas de menu pour GoW d'où l'arbre monde). Et je ne parle pas de mon expérience pro (projet flash, windev et java I SEE YOU TOO !!! ).

    Pour résumé le problème avec une image
    L'informatique aujourd'hui ... c'est un commercial qui vend une maison à un particulier, sans plan, sans terrain, qui demande à un maçon et un architecte de donner une estimation vis-à-vis de leur dernière construction (même si c'était un centre commercial), et de commencer la construction sans plus tarder.
    Ensuite, utilisant la méthode agile, à chaque revu de sprint on demande au client si veut une pièce en plus ou arranger les choses et à la fin du projet :
    On se rend compte que les pièces ne se collent pas, certaines sont clonées, que le terrain est en fait un ensemble de parcelle non contiguës, qu'il manque la moitié du toit et que l'autre partie est directement sur la dalle et que ... en dépit du fait que le client soit passablement satisfait du cagibi, il faut tout casser pour mettre l'eau et l’électricité

    La conception logicielle et les outils associés comme modelio n'ont pas été inventé pour les chiens en fait, si le temps et la qualité étaient le main focus, il y aurait moins de problème. Dans les industries plus "physique" exigent plus de rigueur (et encore) sans doute parce que l'on a pas l'impression que se rouler sur un clavier suffit pour sortir un produit.

    Désolé pour la noirceur de mon post mais c'est pas très rose en ce moment dans ma vie
    True Story Bro

  4. #4
    Membre éprouvé
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2016
    Messages
    342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2016
    Messages : 342
    Points : 1 075
    Points
    1 075
    Par défaut
    Citation Envoyé par Patrick Ruiz Voir le message
    En tant que développeur, l’estimation des délais fait-elle partie de votre quotidien ? Comment se passe cet exercice au sein de votre entreprise ?
    L'estimation des delais à son importance. Si un dev estime qui doit mettre une semaine pour faire une tâche mais qu'il y passe un mois, il faut tenter de comprendre pourquoi et corriger le tir pour la prochaine fois.
    De même que si ont estime un temps à une semaine et qu'on y passe un jour, c'est bien de comprendre comment on à pu réduire le temps de dev, savoir si ça peut s'appliquer ailleurs, ect...

    De mon coter, même si on ne me demande pas toujours d'estimation j'en fait toujours une au préalable pour moi. Le but étant de capter là ou j'ai le plus de mal et de voir ce qui peut être fait pour m'améliorer.

    Citation Envoyé par Patrick Ruiz Voir le message
    Les équipes de développement sont-elles condamnées à ne jamais respecter les délais de livraison des projets quelles que soient les méthodes employées ?
    Tout dépend qui fait les estimations. Là ou je bosse on refait tout un ERP. Y'a 1 ans les commerciaux nous ont annoncer avec un grand sourire et une joie non contenue qu'il avait lancer un mailling général à nos clients qui annoncer la sortir de la nouvelle version pour juin 2020.
    Étonnamment toute l'équipe de dev c'est mise à rire, sauf l'architecte logiciel et le chef de projet qui eux avait bien compris que c'était pas une blague... Et faut être honnête on finira pas avant fin 2020/début 2021. Depuis les commerciaux tente de minimiser l'impacte de leur annonce sur les clients. S'quand même dommage parce que d'habitude nos commerciaux viennent d'abord nous voir pour demander en combien de temps on peut faire les devs avant d'annoncer au client au chiffrage.

    'fin bref tout ça pour dire que tant que les dev ce verrons imposer des temps de dev par d'autre, ils ne pourrons que difficilement respecter les délais. Sinon, un dev avec un peu d'expérience qui fait ses propres estimation devrait être généralement dans les délais, avec parfois un peut d'avance, parfois un peut de retard.

  5. #5
    Membre éclairé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    décembre 2008
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2008
    Messages : 78
    Points : 671
    Points
    671
    Par défaut
    Pour pouvoir faire une estimation, il faut savoir qui va réaliser: un débutant sorti de l'école risque d'être moins rapide qu'un développeur expérimenté qui a déjà l'expérience de ce type de sujet... Fut un temps, les chefs de projets qui étaient des développeurs confirmés ayant une bonne connaissance fonctionnelle des sujets faisaient les estimations... Maintenant ceux-ci ont été remplacé par des gens sortit d'école de management ou de commerce: ils n'ont ni la connaissance des technologies ni du fonctionnel... Mais ils peuvent être catapulté chef de projet direct à la sortie de l'école et sont donc moins coûteux... Lorsque les actionnaires et les dirigeants cesseront de penser à leurs primes, le monde s'en portera mieux...

  6. #6
    Membre confirmé
    Homme Profil pro
    Développeur Java
    Inscrit en
    mai 2019
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : mai 2019
    Messages : 187
    Points : 513
    Points
    513
    Par défaut
    Citation Envoyé par pboulanger Voir le message
    Pour pouvoir faire une estimation, il faut savoir qui va réaliser: un débutant sorti de l'école risque d'être moins rapide qu'un développeur expérimenté qui a déjà l'expérience de ce type de sujet... Fut un temps, les chefs de projets qui étaient des développeurs confirmés ayant une bonne connaissance fonctionnelle des sujets faisaient les estimations... Maintenant ceux-ci ont été remplacé par des gens sortit d'école de management ou de commerce: ils n'ont ni la connaissance des technologies ni du fonctionnel... Mais ils peuvent être catapulté chef de projet direct à la sortie de l'école et sont donc moins coûteux... Lorsque les actionnaires et les dirigeants cesseront de penser à leurs primes, le monde s'en portera mieux...
    J'ai tendance à dire que parfois en sortie d'école les devs sont justement plus rapides, parce-qu’ils font un peu du quick and dirty sans penser que cela peut leur retomber dessus "on verra demain", je jette pas la pierre j'étais dans ce cas !

  7. #7
    Membre extrêmement actif Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    octobre 2007
    Messages
    1 261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 261
    Points : 2 250
    Points
    2 250
    Par défaut
    La seule méthode d'estimation des délais qui fonctionne est celle du poker planning. Lorsque chaque développeur estime les tâches en amont, et les chiffre en réunion en points avec un jeu de carte. Ceux ayant émis les estimations les plus extrèmes doivent discuter rapidement de leur estimation, peuvent ainsi lever les lièvres, confronter leur connaissance du code source, les seniors peuvent éclairer les juniors etc.

    Ainsi Jean-Claude apprendra enfin a quoi sert réellement WidketAbstractFactoryManager, Gonzague qui pensait devoir toute une fonctionnalité top-down peut alors apprendre qu'elle existe déjà sous une forme tierce à modifier, une catastrophe sera évitée et l'esprit d'équipe sera renforcé. En outre, les développeurs jouent ensembles symboliquement et sont dans l'échange, et même le chef d'équipe participe.

    Charge au chef d'équipe, à l'animateur, de transformer ces évaluation de temps en heures.

    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  8. #8
    Membre averti
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2012
    Messages
    86
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2012
    Messages : 86
    Points : 331
    Points
    331
    Par défaut
    Citation Envoyé par ddoumeche Voir le message
    La seule méthode d'estimation des délais qui fonctionne est celle du poker planning. Lorsque chaque développeur estime les tâches en amont, et les chiffre en réunion en points avec un jeu de carte. Ceux ayant émis les estimations les plus extrèmes doivent discuter rapidement de leur estimation, peuvent ainsi lever les lièvres, confronter leur connaissance du code source, les seniors peuvent éclairer les juniors etc.

    Ainsi Jean-Claude apprendra enfin a quoi sert réellement WidketAbstractFactoryManager, Gonzague qui pensait devoir toute une fonctionnalité top-down peut alors apprendre qu'elle existe déjà sous une forme tierce à modifier, une catastrophe sera évitée et l'esprit d'équipe sera renforcé. En outre, les développeurs jouent ensembles symboliquement et sont dans l'échange, et même le chef d'équipe participe.

    Charge au chef d'équipe, à l'animateur, de transformer ces évaluation de temps en heures.


    Salut, on travail de cette manière c'est très efficace en effet, mais je trouve que le soucis/dérive de la méthode agile c'est qu'on dit que l'estimation c'est qu'une estimation, mais on dit aussi qu'un sprint est un contrat, du coup une estimation par son nom est forcément fausse et du coup le contrat forcément non rempli ...

Discussions similaires

  1. Réponses: 25
    Dernier message: 13/03/2019, 12h35
  2. Charger les données dans la table de faits
    Par mo9rissat dans le forum Pentaho
    Réponses: 1
    Dernier message: 22/05/2014, 13h14
  3. Réponses: 1
    Dernier message: 06/12/2011, 22h08
  4. Réponses: 7
    Dernier message: 05/03/2009, 16h46
  5. [JS] Remplacer les mots dans le code d'une page.
    Par sansamis dans le forum Général JavaScript
    Réponses: 9
    Dernier message: 07/01/2007, 20h06

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