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
    900
    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 : 900
    Points : 30 258
    Points
    30 258
    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 : 17825
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
    14
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : mai 2005
    Messages : 14
    Points : 37
    Points
    37
    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 : 621
    Points
    621
    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
    345
    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 : 345
    Points : 1 088
    Points
    1 088
    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
    79
    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 : 79
    Points : 681
    Points
    681
    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
    200
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : mai 2019
    Messages : 200
    Points : 577
    Points
    577
    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 264
    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 264
    Points : 2 255
    Points
    2 255
    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
    89
    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 : 89
    Points : 342
    Points
    342
    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 ...

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

    Informations professionnelles :
    Activité : chercheur

    Informations forums :
    Inscription : avril 2004
    Messages : 817
    Points : 1 354
    Points
    1 354
    Par défaut
    " découvrir ce dont le client a vraiment besoin "...
    Ce qui s'énonce clairement se conçoit bien ( Le hautbois)

  10. #10
    FMJ
    FMJ est déconnecté
    Membre actif
    Profil pro
    tutu
    Inscrit en
    octobre 2003
    Messages
    342
    Détails du profil
    Informations personnelles :
    Localisation : France, Aveyron (Midi Pyrénées)

    Informations professionnelles :
    Activité : tutu

    Informations forums :
    Inscription : octobre 2003
    Messages : 342
    Points : 257
    Points
    257
    Par défaut
    Bref, vive les prestations au temps passé !!!!!

  11. #11
    Membre extrêmement actif Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    octobre 2007
    Messages
    1 264
    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 264
    Points : 2 255
    Points
    2 255
    Par défaut
    Citation Envoyé par Chuck 3.50 Voir le message
    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 ...
    Attention, la méthode à Gilles ne corrige pas les problèmes d'incompétence ou de laxisme des chefs d'équipe, de projet, des développeurs, pas plus qu'elle ne supprime les obligations contractuelles de livrer son client en temps et en heure. Mais cette obligation étant rarement remplie, autant passer au poker planning pour cerner et corriger les points faibles de la phase d'estimation. Et avec l'expérience, la conversion des points de charge en temps est de plus en plus précise.

    Que propose-t'on, que les développeurs s'engagent sur l'honneur et le sang à livrer en temps et en heure ? avec des pénalités financières en cas d'erreur ?
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  12. #12
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Cyber sécurité
    Inscrit en
    mai 2004
    Messages
    9 746
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Cyber sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 9 746
    Points : 26 360
    Points
    26 360
    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.
    Je ne vois pas l'intérêt de passer par des points. Assez rapidement, on se retrouve avec des correspondances du genre "20 points, c'est 2 semaine", donc pourquoi ne pas dire directement 2 semaines ?

    Attention, ceci n'est pas un troll, mais bien une vraie question. Pour moi, si tu es capable d'estimer en points, tu es capable d'estimer en heures ou en jours.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  13. #13
    Membre extrêmement actif Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    octobre 2007
    Messages
    1 264
    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 264
    Points : 2 255
    Points
    2 255
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Je ne vois pas l'intérêt de passer par des points. Assez rapidement, on se retrouve avec des correspondances du genre "20 points, c'est 2 semaine", donc pourquoi ne pas dire directement 2 semaines ?

    Attention, ceci n'est pas un troll, mais bien une vraie question. Pour moi, si tu es capable d'estimer en points, tu es capable d'estimer en heures ou en jours.
    C'est une bonne question, parce demander un temps est imprécis justement d'où l'usage du planning poker, alors qu'une estimation en temps est relative. L'intervenant Jean-Pierre y répond en détail dans sa vidéo. Charge ensuite au responsable de faire la conversion corrigé de son propre factoromètre, qui varie au court du temps. Si 20 points valent 1 mois a un moment T, ils peuvent valoir 2 semaines a T+4.

    A l'inverse, une équipe de développeurs capable de chiffrer correctement ses temps de développement n'a sans doute pas besoin de ce outil, soit parce qu'elle est meilleure, soit parce qu'elle connait le projet sur le bout des doigts.
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  14. #14
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 049
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 049
    Points : 4 490
    Points
    4 490
    Par défaut
    Pour que des développeurs puissent estimer la durée des tâches de manière assez fiable, je vois au moins trois conditions à remplir.

    La première, c'est de définir précisément les fonctionnalités à implémenter et pas juste une idée générale. Si on ne sait pas quelles tâches effectuer, on ne peut pas les estimer. Le corolaire, c'est que l'estimation ne peut pas être précise si elle doit inclure de nouvelles fonctionnalités surprises ajoutées entre l'estimation et la livraison, voire de nouvelles tâches surprises qui ne sont pas liées au dev. Le plus simple est que l'estimation ne porte que sur ce qui a été prévu et que, si les exigences changent, on refait l'estimation et on décale le délai (s'il n'y avait pas assez de marge dans le délai).

    La deuxième, c'est de bien connaître l'existant. Des fois, la fonctionnalité à ajouter est très claire, mais on ne connaît pas à l'avance tous les changements que cela implique de faire dans l'existant. Il faut donc des développeurs qui connaissent bien l'existant. Pour cela, il faut que l'entreprise se débrouille pour que le turnover soit faible, ce qui implique d'augmenter régulièrement les salaires des développeurs sur place.

    La troisième, c'est de ne pas avoir un existant de merde. En effet, plus la dette technique est élevée, plus on perd du temps, mais aussi plus le temps perdu est imprévisible.
    • Si le code est mal architecturé et mal écrit, on a souvent des imprévus quand on veut le changer.
    • Si le code a trop de bogues car n'est pas couvert par des tests unitaires, un bogue existant risque de pourrir les tests manuels en faisant croire que le problème vient des dernières modifs alors que c'est un bogue historique. Ou alors, ce qui arrive plus fréquemment, c'est que le développement en cours sera interrompu car un client a remonté un bogue urgent.
    • Si le code a une mauvaise gestion d'erreurs et que le programme a des mauvaises données en entrée, un client va interrompre le développement pour enquêter sur le problème, ce qui risquera d'être long car le message d'erreur n'indique pas clairement que le problème vient des données en entrée.


    Si une boîte n'a pas fait ce qu'il fallait pour que ces conditions soient réunies, il ne faudra pas s'attendre à des estimations précises.

  15. #15
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 319
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 319
    Points : 17 906
    Points
    17 906
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Si une boîte n'a pas fait ce qu'il fallait pour que ces conditions soient réunies, il ne faudra pas s'attendre à des estimations précises.
    Il manque un point essentiel, c'est la saisie du consommé. Une estimation n'est pas un engagement c'est une hypothèse. C'est en comparant les estimations avec le consommé (la réalité) que l'on peut voir si les estimations sont pertinentes ou non et donc si on peut s'y fier pour planifier. Ce n'est qu'au terme de plusieurs sprints avec une équipe stable que les deux devraient commencer à se rapprocher et c'est à ce moment que l'on peut tirer parti des estimations.

    Si on ne fait pas cet exercice (qui est chiant car il faut être minutieux et rigoureux) l'ensemble ne sert à rien du tout.

    Et si on fait cet exercice et qu'il fonctionne, on se rend compte que convertir les points en temps devient ipso facto inutile puisqu'on sait rien qu'avec les points ce qu'on va réussir à réaliser ou non.

    Penser en points permet de penser complexité au lieu de temps et c'est bien utile lorsqu'on ne sait pas trop le temps que ça va prendre.

    De toutes manières l'aboutissement de SCRUM pour moi c'est KANBAN pour aboutir in fine à du continuous delivery voire du continuous deployment (le Saint Graal). C'est là qu'on réduit au maximum le lead time et donc le TTM.

    De ce point de vue SCRUM n'est qu'une phase d’entraînement pour améliorer sa vitesse de delivery (lead time si on part du commit mergé, TTM si on part de l'expression du besoin par le métier).

    Je précise que je n'ai pas vu la vidéo mais que j'en ai déjà vu plusieurs de cet auteur.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 068
    Points : 28 086
    Points
    28 086
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Pour que des développeurs puissent estimer la durée des tâches de manière assez fiable, je vois au moins trois conditions à remplir.(.../...)
    Si une boîte n'a pas fait ce qu'il fallait pour que ces conditions soient réunies, il ne faudra pas s'attendre à des estimations précises.
    +1

    J'ai vu un gars qui était capable de dire, après 30 secondes de réflexion, "ton projet, il va coûter 420 jours". Avec une marge d'erreur mesurée ne dépassant pas 5%. Mais oui, l'existant était archiconnu de toute l'équipe, maintenable et maîtrisable (Il y avait des redondances, mais elles étaient connues et maîtrisées). Après, j'ai foutu la merde dans ses calculs en faisant(sur les ordres d'un autre chef de l'équipe) une refonte qui faisait sauter une bonne partie des redondances(mesuré après coup : plus d'un temps plein de maintenance d'économisé). Mais sur une appli fixe et connue, oui, on peut être précis sur des specs précises et qui ne vont pas changer en cours de projet.
    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.

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