La Planification Par les Faits

From The Joel on Software Translation Project

Jump to: navigation, search

Article original publié le vendredi 26 octobre 2007 : Evidence Based Scheduling

De la collection Joel on Software

Traduction : Thierry Machicoane


Les développeurs logiciels ne se délectent pas vraiment de faire des plannings. Généralement, ils essaient de s'en passer. "Ca sera terminé quand ce sera fini !" disent-ils, espérant que leur déclaration courageuse et drôle réduira leur chef à un fou rire, et qu'il oubliera le planning dans la jovialité qui s'en suivra.

La majorité des plannings sont de timides tentatives. Ils sont stockés sur un partage réseau quelque part puis totalement oubliés. Lorsque leurs équipes livrent, avec deux ans de retard, le mec bizarre, qui a l'armoire à dossiers dans son bureau, apporte le vieux planning au post-mortem, et tout le monde s'esclaffe. "Hé, regardez ! Nous avions prévu deux semaines pour tout ré-écrire en Ruby !".

Hilarant ! A condition d'être encore dans le business.

Vous souhaitez passer votre temps sur les choses qui vous en donne le plus pour votre argent. Et vous ne pouvez savoir combien cela vous en coûtera sans savoir combien de temps cela va prendre. Lorsque vous avez tranché entre les fonctionnalités "trombone animé" et "plus de fonctions financières", vous avez réellement besoin de savoir combien de temps cela durera.

Pourquoi les développeurs ne font-ils pas de plannings ? Deux raisons. Un : c'est enquiquinant. Deux : personne ne croit que le planning est réaliste. Pourquoi s'embêter à travailler de la sorte sur un planning qui ne sera pas juste ?

Toutes ces dernières années à Fog Creek nous avons développé un système tellement simple que même nos développeurs les plus grincheux sont disposés à l'utiliser. Et autant que nous puissions le dire, il produit des plannings extrêmement fiables. Ce système est appelé la Planification Par les Faits, ou PPF (EBS en Anglais pour Evidence-Based Scheduling). Vous collectez les faits, principalement à partir des archives des feuilles d'heures, que vous ré-insérez dans vos plannings. Ce que vous obtenez n'est pas qu'une date de livraison : vous avez une courbe de confiance, représentant la probabilité de livraison en fonction de la date. Cela ressemble à cela :

20071026-1.png

Plus la courbe est raide, plus grande est votre confiance de livrer dans les temps.

Voici maintenant comment il faut procéder.

Contents

Décomposez

Lorsque je vois un planning mesuré en jours, ou même en semaines, je sais que cela ne va pas marcher. Vous devez décomposer votre planning en tâches élémentaires très petites qui peuvent se mesurer en heures. Rien de plus long que 16 heures.

Cela vous impose de vraiment comprendre ce que vous aurez à faire. Ecrire la méthode foo. Créer cette boîte de dialogue. Analyser le fichier Fizzbott. Les tâches de développement élémentaires sont faciles à estimer, parce que vous avez déjà écrit des méthodes, créé des boites de dialogue et analysé des fichiers auparavant.

Si vous êtes négligeant, et considérez des grosses tâches de développement de trois semaines (ie, "Implémenter l'éditeur photo en Ajax"), alors vous n'avez pas pensé à ce que vous allez faire. En détail. Etape par étape. Et lorsque vous n'avez pas pensé à ce que vous allez faire, vous ne savez pas combien de temps cela prendra.

Définir un maximum de 16 heures vous force à concevoir (NDT au sens conceptuel du terme et non design) cette sacrée fonctionnalité. Si vous avez une fonctionnalité floue de trois semaines appelée "éditeur photo Ajax" sans une conception détaillée, je suis désolé d'être celui qui vous le révèle mais vous êtes officiellement voué à l'échec. Vous n'avez jamais pensé aux étapes nécessaires et vous êtes sûr d'en oublier beaucoup d'entre-elles.

Suivez le temps passé

Il est difficile d'obtenir des estimations individuelles totalement justes. Comment intégrez-vous les interruptions, les bogues impondérables, les réunions d'avancement et les journées semestrielles d'Offrande Windows où vous devez ré-installer tout votre système depuis le début ? Flute, même sans tout ça, comment pouvez-vous dire exactement combien de temps prendra l'implémentation d'une fonction donnée ?

Vous ne le pouvez pas, vraiment.

Alors, gardez les feuilles d'heures. Conservez la trace du temps passé à travailler sur chaque activité. Alors vous pourrez y revenir et voir combien de temps cela a duré comparativement à l'estimation initiale. Pour chaque développeur, vous collecterez les données suivantes :

20071026-2.png

Chaque point de la coube représente une tâche terminée, avec les temps de réalisation estimés et réels pour chaque tâche. Lorsque vous divisez l'estimation par le réel, vous obtenez la vélocité : à quelle vitesse la tâche a été réalisée par rapport à son estimation. Au fil du temps et pour chaque développeur, vous collecterez un historique des vélocités.

  • L'estimateur parfait mythique, qui n'existe que dans votre imagination, donne toujours des estimations exactes. Ainsi, son historique de vélocité est {1, 1, 1, 1, ...}
  • Un mauvais estimateur typique a toujours des vélocités éparpillées sur le graphique, par exemple {0.1, 0.5, 1.7, 0.2, 1.2, 0.9, 13.0}
  • La plupart des estimateurs ont la mauvaise échelle mais leurs estimations relatives sont correctes. Tout dure plus longtemps que prévu, parce que l'estimation n'intègre pas la correction des bogues, les réunions, les pauses café, et ce chef dingue qui vous interrompt tout le temps. Cet estimateur courant a des vélocités très homogènes, mais inférieures à 1.0. Par exemple, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}

A mesure que les estimateurs acquièrent de l'expérience, leurs compétences en estimation s'améliorent. Supprimez donc les vélocités de plus de, disons, six mois.

Si vous avez un nouvel estimateur dans votre équipe, qui n'a pas encore d'historique, supposez le pire : mettez-lui un historique factice avec une large plage de vélocités, jusqu'à ce qu'il ait terminé une demi-douzaine de tâches réelles.

Simulez l'avenir

Plutôt que d'ajouter simplement les estimations pour obtenir uniquement une date de livraison, ce qui semble correct mais vous donne un résultat totalement faux, vous allez utiliser la méthode de Monte Carlo pour simuler de nombreux futurs possibles. Dans une simulation de Monte Carlo, vous pouvez créer 100 scénarii possibles de futur. Chacun de ces futurs possibles possède une probabilité de se réaliser de 1%, et vous pouvez ainsi faire un graphique de la probabilité de livrer à une date donnée.

Lors du calcul de chaque futur pour un développeur donné, vous allez diviser chaque estimation de tâche par une vélocité choisie au hasard dans l'historique des vélocités du développeur en question, qui avaient été collectées à l'étape 2. Voici un exemple de futur :

20071026-3.png

Faites cela 100 fois. Chaque total a une probabilité de 1%, et maintenant vous pouvez déterminer la probabilité de livrer à une date donnée.

Maintenant, observez ce qui se passe :

  • Dans le cas de l'estimateur parfait mythique, toutes les vélocités valent 1. Diviser par une vélocité de 1 n'a pas d'effet. Donc tous les scénarii de la simulation donnent la même date de livraison, et cette date de livraison a une probabilité de 100%. Comme dans les contes de fées !
  • Les vélocités du mauvais estimateur sont éparpillées sur le graphique. 0.1 et 13.0 ont aussi probables. Chaque scénario de la simulation va donner un résultat fort différent des autres, parce que lorsque vous divisez par une vélocité choisie au hasard, vous obtenez un nombre très différent à chaque fois. La courbe de probabilité sera très plate, montrant une chance de livrer demain équivalente à celle de livrer dans un futur lointain. Au passage, c'est aussi une information utile à retenir : cela vous montre que nous ne devriez pas avoir confiance dans les dates de livraison estimées.
  • L'estimateur courant a beaucoup de vélocités proches les unes des autres, par exemple {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}. Lorsque vous divisez par ces vélocités vous augmentez la durée des activités, de la sorte qu'en une itération, une tâche de 8 heures pourrait durer 13 heures. Dans une autre itération, cela pourrait prendre 15 heures. Cela compense l'optimisme perpétuel des estimateurs. Et cela le compense précisément, sur la base exacte de l'optimisme réel, prouvé et historique de ce développeur. Et comme toutes les vélocités historiques sont assez proches, autour de 0.6, lorsque vous calculez chaque scénario de la simulation, vous obtenez des nombres assez similaires, et donc vous avez finalement une plage assez étroite de dates de livraison possibles.

Pour chaque scénario de la simulation de Monte Carlo, vous devez bien entendu convertir les données horaires en données calendaires, ce qui signifie que vous devez tenir compte de l'agenda de chaque développeur, en prenant en compte ses absences, congés, etc. Et vous devez donc regarder, pour chaque scénario, quel développeur finira le dernier car cela correspond à la date de fin de toute l'équipe. Ces calculs sont laborieux, mais heureusement, c'est le genre de truc pour lesquels les ordinateurs sont bons.

Trouble Obsessionel Compulsif non requis

Que faire concernant le chef qui vous interrompt tout le temps avec ses interminables histoires de sorties de pêche ? Ou les réunions commerciales auxquelles vous êtes obligé d'assister bien que vous n'ayez aucun raison d'y être ? Les pauses café ? Passer une demi-journée à aider un nouveau à installer son environnement ?

Lorsque Brett et moi avons développé cette technique chez Fog Creek, nous nous préoccupions beaucoup des choses qui prennent un temps effectif mais qui ne peuvent pas être prévues d'avance. Parfois, cela représente plus de temps que d'écrire du code. Devriez-vous avoir des estimations pour cela aussi; et l'intégrer dans les feuilles d'heures ?

20071026-4.png

Eh bien, oui, vous pouvez, si vous voulez. Et la Planification Par les Faits marchera.

Mais vous n'avez pas besoin.

Il ressort que la PPF fonctionne si bien que tout ce que vous avez à faire consiste à laisser la pendule tourner pendant n'importe quelle tâche lorsque celle-ci est interrompue. Aussi déconcertant que cela paraisse, la PPF produit les meilleurs résultats lorsque vous procédez de la sorte.

Laissez-moi vous donner un court exemple. Pour rendre celui-ci aussi simple que possible, je vais imaginer un programmeur très prévisible, Jean, dont tout le travail consiste à écrire ces fonctions get et set que les langages de programmations inférieurs nécessitent. C'est ce qu'il fait toute la journée :

  private int width;
  public int getWidth  () { return width; }
  public void setWidth (int _width} { width = _width; }

Je sais, je sais ... c'est un exemple délibérément ballot, mais vous savez que vous avez rencontré quelqu'un comme cela.

Bref. Chaque fonction lui prend 2 heures. Ses estimations ressemblent donc à cela :

{2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, ... }

Maintenant, ce pauvre garçon a un chef qui l'interrompt tout le temps avec une conversation de deux heures sur la pêche au marlin. Evidemment, Jean pourrait avoir une activité dans son agenda appelée "Conversation pénible sur le marlin", et mettre cela dans sa feuille d'heures, mais cela pourrait s'avérer politiquement risqué. A la place, Jean laisse juste la pendule tourner. Donc, son activité réelle ressemble à cela :

{2, 2, 2, 2, 4, 2, 2, 2, 2, 4, 2, ... }

Et ses vélocités sont :

{1, 1, 1, 1, 0.5, 1, 1, 1, 1, 0.5, 1, ...}

Maintenant réfléchissez à ce qui se passe. Dans la simulation de Monte Carlo, la probabilité que chaque estimation soit divisée par 0.5 est exactement la même que la probabilité que le chef de Jean l'interrompe durant une fonction donnée. Donc, la PPF donne un planning juste !

En fait, la PPF a bien plus de chances d'intégrer l'impact des interruptions que même le développeur le plus obsédé des feuilles d'heures. Ce qui est exactement pourquoi cela fonctionne si bien. Voici comment je l'explique aux gens. Lorsque un développeur est interrompu, il peut soit :

  1. Faire toute une scène pour devoir tenir compte de l'interruption dans sa feuille d'heure et ses estimations, et ce afin que le management puisse constater à quel point il perd son temps avec des discussions sur la pêche, ou
  2. Faire toute une scène pour refuser d'en tenir compte dans sa feuille d'heure, laissant juste la fonctionnalité sur laquelle il travaillait prendre du retard, parce qu'il refuse de pervertir son estimation qui était parfaitement juste avec cette conversation stupide sur l'expédition des poissons à laquelle il n'avait même pas été convié,

... et dans les deux cas, la PPF donne les mêmes résultats exacts, quel que soit le type de développeur passif ou agressif en présence.

Gérez vos projets activement

Une fois que cela est en place, vous pouvez gérer vos projets activement afin de livrer dans les temps. Par exemple, si vous classez les fonctionnalités en fonction de leurs priorités, il est aisé de voir de combien la suppression des fonctionnalités peu prioritaires réduirait le planning.

20071026-5.png

Vous pouvez aussi regarder la répartition des dates de livraison possibles pour chaque développeur :

20071026-6.png

Certains développeurs (comme Milton sur ce graphique) peuvent poser des problèmes car leurs dates de livraisons sont très incertaines : ils ont besoin d'apprendre à faire de meilleures estimations. D'autres développeurs (comme Jane) ont des dates de livraison très précises qui sont juste trop tard : ils ont besoin d'être soulagés d'une partie de leur travail. D'autres développeurs (moi ! hé hé !) ne sont pas sur le chemin critique du tout, et peuvent être laissés tranquilles.

L'augmentation du périmètre fonctionnel

Si vous avez initialement tout décomposé correctement dans le détail, alors la PPF marche très bien. Pour être honnête cependant, vous pouvez avoir des fonctionnalités que vous n'aviez pas prévues. Vous avez de nouvelles idées, vos commerciaux vendent des fonctions que vous n'avez pas, et quelqu'un de la Direction déboule avec une nouvelle idée cool pour faire faire au GPS de votre voiturette de golf les électro-cardiogrammes des golfeurs sur leur parcours. Tout cela induit des retards qui ne pouvaient pas être prévus lors de la planification initiale.

Idéalement, vous avez paquet de tampons pour cela. En fait, prévoyez des tampons dans votre planning initial pour :

  1. Les nouvelles idées
  2. Contrer la concurrence
  3. L'intégration
  4. La mise au point
  5. Les tests d'utilisation (et l'incorporation des résultats)
  6. Les beta-tests

Ainsi maintenant, lorsque de nouvelles fonctionnalités surviennent, vous pouvez prendre un morceau du tampon correspondant et l'utiliser pour le nouveau besoin.

Qu'arrive-t-il si vous ajoutez encore de nouvelles fonctionnalités au delà de la capacité du tampon ? Alors, maintenant, les dates de livraison obtenues par la PPF commencent à glisser. Vous devriez prendre une photo de la distribution de la confiance de vos dates de livraison chaque nuit, afin de pouvoir la suivre dans le temps :

20071026-7.png

L'axe des abcisses représente le moment où le calcul avait été fait. L'axe des ordonnées représente les dates de livraison. Il y a trois courbes ici : celle du haut représente les dates probables à 95%, celle du milieu les dates probables à 50%, et celle du bas les dates probables à 5%. Ainsi, plus les courbes sont proches les unes des autres, et plus la plage des dates de livraison possibles est étroite.

Si vous voyez des dates de livraison de plus en plus tard (courbes qui montent), alors vous avez des problèmes. Si vous prenez plus d'un jour de retard par jour, vous ajoutez du travail plus vite que vous ne le faites, et vous n'aurez alors jamais terminé. Vous pouvez aussi regarder et voir si la distribution de la confiance des dates de livraison se resserre (les courbes convergent alors), ce qui devrait être le cas si vous convergez réellement vers une date.

Pendant qu'on y est

Voici d'autres choses que j'ai apprises au fil des années sur les plannings.


1) Seul le programmeur réalisant un travail peut en faire l'estimation. Tout système dans lequel le management établit le planning et l'impose aux programmeurs est voué à l'échec. Seul le programmeur qui va implémenter une fonctionnalité pour définir les étapes qui seront nécessaire pour implémenter la fonction en question.

2) Corriger les bogues à mesure que vous les trouvez, et reportez le temps correspondant dans la tâche initiale. Vous ne pouvez prévoir la correction d'un bogue donné à l'avance, parce que vous ne savez pas quels bogues vous allez avoir. Lorsque des bogues sont découverts dans un nouveau code, reportez le temps dans la tâche initiale que vous avez mal implémentée. Cela aidera la PPF à prévoir le temps que cela prend d'avoir du code totalement débogué, et pas simplement du code fonctionnel.

3) Ne laissez pas les managers harceler les developpeurs jusqu'à ce qu'ils raccourcissent leurs estimations. Beaucoup de managers débutants imaginent qu'ils peuvent « motiver » leurs programmeurs à travailler plus vite en leur donnant des plannings « bien tendus » (incroyablement courts). Je pense que ce type de motivation est stupide. Lorsque je suis en retard, je me sens en échec, déprimé et non motivé. Dans le cas contraire, je suis enjoué et productif. Le planning n'est pas le bon candidat pour pratiquer des jeux psychologiques.

Pourquoi les managers essaient-ils cela ?

Lorsque le projet commence, les managers techniques entrent en action, rencontrent les ingénieurs d'affaire, et reviennent avec une liste de fonctionnalités dont ils pensent qu'elles nécessiteront trois mois, mais qui en prendrait en réalité douze. Lorsque vous pensez à écrire du code sans penser à toutes les étapes que vous avez à entreprendre, il semble toujours que cela prendra un temps n, alors qu'en réalité cela prendra probablement un temps supérieur à 4n. Lorsque vous faites un vrai planning, vous intégrez toutes les activités et réalisez que le projet va prendre bien plus longtemps qu'imaginé à l'origine. Les ingénieurs d'affaire sont mécontents.

Les managers ineptes essaient de régler ce problème en imaginant comment faire travailler les gens plus vite. Ce n'est pas très réaliste. Vous pourriez embaucher plus de personnes, mais ils auront besoin d'atteindre leur vitesse de croisière et travailleront probablement à 50% de leur efficacité pendant plusieurs mois (tout en diminuant l'efficacité de ceux qui les aident).

Vous pourriez obtenir temporairement des gens 10% de code brut en plus au prix de les avoir détruits à 100% dans une année. Ce n'est pas un gain significatif, et c'est un peu comme manger son blé en herbe. Bien sûr, lorsque vous surchargez les gens, le temps de mise au point double et un projet déjà en retard est plus en retard encore. Fabuleux karma.

Mais vous ne pourrez jamais obtenir n de 4n, jamais, et si vous pensez que vous le pouvez, envoyez-moi s'il vous plait le code valeur de votre boite afin que j'évite d'en acheter des actions.

4) Un planning est une boite de cubes. Si vous avez un tas de cubes, et que vous ne pouvez pas les faire tenir dans une boite, vous avez deux alternatives : trouvez une boite plus grande, ou retirer certains cubes. Si vous voulez livrer dans six mois, mais que vous avez un planning de douze mois, soit vous allez devoir retarder la livraison, soit trouver des fonctionnalités à supprimer. Vous ne pouvez pas raccourcir les cubes, et si vous prétendez le contraire, alors vous vous privez juste d'une opportunité utile de réellement lire dans l'avenir en vous mentant à vous-même sur ce que vous voyez.

Maintenant que je l'ai mentionné, un des grands bénéfices des plannings réalistes réside dans le fait que vous êtes obligé de supprimer des fonctionnalités. Pourquoi cela est-il bien ?

Supposez que vous avez deux fonctionnalités en tête. L'une est vraiment utile et fera de votre produit un fantastique produit. L'autre est réellement facile et les programmeurs ne peuvent pas attendre pour la coder (« Regarde ! <toc> ! »), mais elle n'apporte rien de bien utile.

Si vous ne faites pas de planning, les programmeurs développeront la fonctionnalité facile et marrante en premier. Alors ils n'auront plus assez de temps, et vous n'aurez pas d'autre choix que de décaler le planning pour réaliser la fonctionnalité importante et utile.

Si vous faites un planning, avant même de commencer à travailler, vous réaliserez que vous devez supprimer quelque chose, et vous retirerez la fonctionnalité facile et marrante et ne ferez que celle importante et utile. En vous astreignant à choisir des fonctionnalités à supprimer, vous arrivez à développer un meilleur produit, plus puissant, et avec un ensemble cohérent de bonnes fonctionnalités que vous livrerez plus tôt.

Revenons au temps où je travaillais sur Excel 5, notre liste de fonctionnalités initiale était énorme et nous aurait conduit bien au-delà du planning. « Purée ! » nous pensions. « Elles sont 'toutes' super importantes ! Comment pouvons-nous nous passer d'un éditeur de macros ? ».

Il s'est avéré que nous n'avions pas le choix, et nous avons supprimé ce que nous considérions comme étant « près de l'os » pour faire le planning. Tout le monde était mécontent des coupes. Pour remettre du baume au coeur des gens, nous nous sommes dit que nous n'étions pas en train de supprimer des fonctionnalités, nous étions juste en train de les différer dans Excel 6.

Alors que Excel 5 était presque terminé, j'ai commencé à travailler sur les spécifications d'Excel 6 avec un collègue, Eric Michelman. Nous nous sommes assis pour parcourir la liste des fonctionnalités de d'Excel 6 qui avaient été retirées du planning d'Excel 5. Vous savez quoi ? C'était la liste de fonctionnalités la plus hétéroclyte que vous puissiez imaginer. Pas une de ces fonctionnalités ne valait la peine d'être réalisée. Je ne crois pas qu'une seule d'entre elles ne l'ait jamais été. La méthode consistant à ne retenir que les fonctionnalités permettant de respecter le planning était la meilleure chose que nous ayons jamais faite. Si nous ne l'avions pas fait, Excel 5 aurait prit deux fois plus longtemps et aurait inclu 50% de fonctionnalités superflues qui auraient dû être maintenues, afin d'être compatibles, et ce jusqu'à la fin des temps.

Résumé

L'utilisation de la Planification Par les Faits est vraiment simple : cela vous prendra un jour ou deux au début de chaque itération pour produire des prévisions détaillées, et cela prendra quelques secondes chaque jour pour noter sur votre feuille d'heure quand vous commencez une nouvelle tâches. Les avantages, cependant, sont énormes : des plannings réalistes.

Les plannings réalistes sont essentiels pour développer de bons logiciels. Ils vous forcent à développer les fonctionnalités importantes en premier et vous permettent de prendre les bonnes décisions concernant le produit à développer. Ce qui rend votre produit meilleur, votre chef plus heureux, ravi vos clients, et -- le meilleur de tout -- vous permet de rentrer chez vous à six heures.

PS

La Planification Par les Faits est intégré dans FogBugz 6.0.

Thierry Machicoane 22:05, 28 novembre 2007

Personal tools