Joel on Software

Joel on Software   Joël à propos de logiciel

 

D'autres articles de "Joel on Software" en Français

D'autres articles de "Joel on Software" en Anglais

Contacter l'auteur (En Anglais uniquement)

 

Plannings de développement sans effort


Par Joël Spolsky
Traduit par Laurent Prud'hon
Vérifié par Trinh Vinh-An
29 mars 2000

En octobre dernier, le Nord-Est des États-Unis était envahi de publicités pour Acela, un nouveau train express reliant Boston à Washington. Avec des spots télévisés, des pancartes et des affiches omniprésentes, on pouvait imaginer qu'une certaine demande allait être créée pour le nouveau service express d'Amtrak.

Enfin, peut-être. Amtrak n'a pas eu l'occasion de s'en rendre compte. Acela a été retardé, retardé encore, de telle sorte que la campagne marketing est arrivée à son terme alors que le service Acela n'était même pas disponible. Ce qui m'a rappelé quelque chose que j'ai entendu dire par un directeur marketing dont le produit avait obtenu un excellent article d'évaluation un mois avant sa sortie dans le commerce : "Très bonne publicité ! Vraiment dommage qu'on ne puisse pas acheter l'objet en question !".

Les éditeurs de jeux gonflés à la testostérone aiment mettre en avant sur leur site web le fait que le prochain jeu sortira "lorsqu'il sera prêt". Un planning ? On n'a pas besoin d'un planning qui craint ! On est des codeurs de jeux cools ! La plupart des sociétés ne peuvent pas s'offrir ce luxe. Parlez-en à Lotus. Au début, lorsqu'ils ont livré 123 version 3.0, il nécessitait un PC 80286, ce qui n'était pas très courant à ce moment là. Ils ont retardé le produit de 16 mois pendant qu'ils travaillaient pour le faire rentrer aux chausse-pieds dans la limite mémoire de 640K du 8086. Le temps qu'ils y parviennent, Microsoft avait une avance de 16 mois dans le développement d'Excel, et, ironie du sort, le 8086 était de toute façon obsolète !

Au moment où j'écris ceci, le navigateur web Netscape 5.0 a presque deux ans de retard. Ce qui est en partie dû au fait qu'ils ont commis l'erreur suicidaire de jeter l'ensemble de leur code pour repartir de zéro : la même erreur qui a condamné Ashton-Tate, Lotus, et le MacOS d'Apple aux corbeilles de l'histoire du logiciel. Netscape a vu sa part de marché dans les navigateurs web passer d'environ 80% à environ 20% pendant ce laps de temps, alors qu'ils ne pouvaient rien faire pour relever des défis de la compétition, puisque leur produit clé était désassemblé en mille morceaux sur le sol et n'était en état de conduire nulle part. Cette unique et mauvaise décision, plus que tout autre chose, a été la bombe nucléaire avec laquelle Netscape s'est lui-même fait sauter. (Le célèbre coup de gueule de Jamie Zawinski donne les détails).

Donc vous devez faire un planning. C'est quelque chose que presqu'aucun programmeur ne veut faire. Selon mon expérience, la grande majorité essaie de s'en sortir sans faire aucun planning,. Parmi les rares qui font un planning, la plupart le font seulement parce que leur chef les y a contraints, à contrecoeur, et personne ne croit vraiment au planning en dehors de l'encadrement supérieur, qui croit simultanément que "aucun projet logiciel ne termine jamais dans les temps" et en l'existence des soucoupes volantes.

Alors pourquoi est-ce que personne ne fait de planning ? Deux raisons principales. Premièrement, c'est vraiment difficile. Deuxièmement, personne ne croit que ça en vaut la peine. Pourquoi se donner tant de mal à travailler sur un planning si on sait qu'il ne sera pas correct ? On pense que les plannings sont universellement faux, et que les choses ne font qu'empirer au fur et à mesure que le temps passe, alors pourquoi souffrir pour finalement sombrer ?

Voici une méthode simple pour faire des plannings effectivement corrects sans effort.

1) Utilisez Microsoft Excel. N'utilisez rien d'exotique comme Microsoft Project. Le problème avec Microsoft Project est qu'il suppose que vous voulez passer beaucoup de temps à vous préoccuper des dépendances. Une dépendance c'est lorsque vous avez deux tâches, l'une devant être terminée avant que l'autre commence. J'ai remarqué que dans le cas du développement logiciel, les dépendances sont si évidentes que ça ne vaut simplement pas la peine de faire l'effort de les enregistrer de manière formelle.

Un autre problème avec Project est qu'il suppose que vous voulez être capable de presser un petit bouton pour "réajuster" le planning. Inévitablement, cela signifie qu'il va réarranger les choses et les réaffecter à différentes personnes. Pour le développement logiciel, cela n'a aucun sens. Les programmeurs ne sont pas interchangeables. Il faut sept fois plus de temps à John pour corriger le bug de Rita qu'à Rita pour corriger le bug de Rita. Et si vous essayez d'affecter votre programmeur d'interface utilisateur à un problème Winsock, il va bloquer et perdre une semaine à devenir efficace en programmation Winsock. Le problème de base est que Project est conçu pour la construction d'immeubles de bureaux, pas de logiciels.

2) Restez simple. Le format standard que j'utilise pour les plannings est tellement simple et que vous pouvez le mémoriser. Vous démarrez avec seulement sept colonnes :

Fonctionnalité Tâche Priorité Estimation initiale Estimation actuelle Temps passé Temps restant

Voici un petit example (en anglais):

Si vous avez plusieurs développeurs, vous pouvez soit maintenir une feuille séparée pour chaque développeur, soit insérer une colonne avec le nom du développeur qui travaille sur chaque tâche.

3) Chaque fonctionnalité devrait être décomposée en plusieurs tâches. Une fonctionnalité est quelque chose comme ajouter un correcteur orthographique à votre programme. Ajouter un correcteur orthographique consiste en un certain nombre de tâches distinctes que le programmeur doit effectuer. La partie la plus importante de la réalisation d'un planning est l'élaboration de cette liste de tâches. D'où la règle essentielle :

4) Seul le programmeur qui va écrire le code peut le planifier. Tout système dans lequel le management établit un planning et l'impose au programmeur est condamné à l'échec. Seul le programmeur qui va effectuer le travail est capable de déterminer les étapes qui seront nécessaires à l'implémentation de la fonctionnalité. Et seul le programmeur peut estimer la durée nécessaire à chacune d'entre elles.

5) Définissez des tâches à un niveau de détail très fin. C'est l'élément le plus important pour faire fonctionner votre planning. Vos tâches devraient être mesurées en heures plutôt qu'en jours. (Lorsque je vois un planning mesuré en jours, ou même en semaines, je sais qu'il ne correspond pas à la réalité). Vous pourriez penser qu'un planning avec des tâches détaillées est certainement plus précis. Faux ! Complètement faux ! Lorsque vous commencez avec un planning composé de tâches grossières que vous décomposez ensuite en tâches plus petites, vous vous rendez compte que vous obtenez un résultat différent, pas seulement un résultat plus précis. C'est un nombre complètement différent. Pourquoi cela se produit-il ?

Lorsque vous devez définir des tâches un niveau de détail très précis, vous vous contraignez à étudier effectivement par quelles étapes vous allez devoir passer. Écrire la fonction toto. Créer une boîte de dialogue de telle manière. Lire le fichier wawa. Ces étapes sont faciles à estimer, parce que vous avez déjà écrit des fonctions, créé des boîtes de dialogue, et lu des fichiers auparavant.

Si vous êtes un fainéant, et si vous définissez des tâches "globales" ("implémenter la correction grammaticale"), alors vous n'avez pas vraiment réfléchi à ce que vous allez faire. Et si vous n'avez pas réfléchi à ce que vous allez faire, vous ne pouvez pas savoir combien de temps cela prendra.

En règle générale, chaque tâche devrait durer de 2 à 16 heures. Si vous avez une tâche de 40 heures (une semaine) sur votre planning, vous ne l'avez pas suffisamment décomposée.

Voici une autre raison de définir des tâches à un niveau de détail précis : ça vous force à concevoir cette satanée fonctionnalité. Si vous avez une fonctionnalité attrayante appelée "Intégration Internet" et si vous planifiez trois semaines pour elle, vous êtes foutu, mon vieux. Si vous devez déterminer quelles fonctions vous allez écrire, vous êtes obligés de détailler la fonctionnalité. En étant forcé de planifier à ce niveau, vous éliminez une grande part des causes de déstabilisation d'un projet logiciel.

6) Gardez une trace des estimations initiales et actuelles. Lorsque vous ajoutez pour la première fois une tâche au planning, estimez le temps nécessaire à sa réalisation en heures et saisissiez ce nombre dans les deux colonnes Estimation Initiale et Estimation Actuelle. Au fur et à mesure que le temps passe, si une tâche prend plus (ou moins) de temps que prévu, vous pouvez mettre à jour la colonne Estimation Courante autant que nécessaire. C'est la meilleure manière de tirer des enseignements de vos erreurs et d'apprendre à estimer les tâches correctement. La plupart des programmeurs n'ont aucune idée sur la manière de deviner combien de temps les choses vont prendre. Ce n'est pas un problème. Du moment que vous apprenez continuellement et que vous mettez à jour régulièrement votre planning au fur et à mesure de votre apprentissage, le planning fonctionnera. (Vous devrez peut-être abandonner des fonctionnalités ou vous décaler, mais le planning fonctionnera quand même correctement, dans le sens où il vous dira en permanence si vous devez abandonner des fonctionnalités ou vous décaler). J'ai remarqué que la plupart des programmeurs deviennent de très bons planificateurs avec environ un an d'expérience.

Lorsque la tâche est terminée, les champs Estimation Actuelle et Temps Passés sont égaux, et le champ Temps Restant est recalculé à zéro.

7) Mettez à jour quotidiennement la colonne Temps Passé. Vous n'avez pas vraiment besoin de regarder votre montre pendant que vous développez. Juste avant de rentrer à la maison, ou d'aller dormir sous votre bureau si vous êtes un de ces geeks, faites comme si vous aviez travaillé 8 heures (ah !), rappelez-vous les tâches sur lesquelles vous avez travaillé, et répartissez en fonction de cela environ 8 heures dans la colonne Temps Passé. Le champ Temps Restant est ensuite calculé automatiquement par Excel.

En même temps, mettez à jour la colonne Estimation Actuelle pour ces tâches afin de refléter la nouvelle réalité. Mettre à jour votre planning chaque jour devrait vous prendre seulement deux minutes environ. C'est la raison pour laquelle il s'agit de la méthode Plannings sans effort -- elle est facile et rapide.

8) Ajoutez des lignes pour les absences, les vacances, etc. Si votre planning prend environ un an, chaque programmeur va certainement prendre dix ou quinze jours de congés. Vous devriez avoir une fonctionnalité appelée vacances dans votre planning, une fonctionnalité appelée absence, et tout autre chose qui peut consommer du temps pour quelqu'un. L'idée est que la date de livraison puisse être calculée en sommant la colonne Temps Testant et en divisant par 40 -- c'est le nombre de semaines de travail restantes, en prenant tout en compte.

9) Ajoutez du temps de débogage de votre planning ! Le débogage est la chose la plus difficile à estimer. Rappelez-vous du dernier projet sur lequel vous avez travaillé. Il est probable que le débogage a pris 100 à 200 % du temps nécessaire pour écrire le code initial. Cela doit représenter une ligne dans le planning, et ce sera certainement la plus grosse.

Voilà comment ça marche. Disons qu'un développeur travaille sur wawa. L'estimation initiale était de 16 heures, jusqu'à maintenant ça a pris vingt heures, et il semble que ça nécessite encore dix heures de travail. Donc le développeur saisit 30 dans Estimation Actuelle et 20 dans Temps Passé.

A la fin du projet, tous ces "dérapages" ont probablement ajouté pas mal de temps. En théorie, pour équilibrer ces dérapages, vous devez abandonner des fonctionnalités afin de livrer à temps. Par chance, la première fonctionnalité que nous pouvons abandonner est cette grosse fonctionnalité appelé Buffer pour laquelle un grand nombre d'heures ont déjà été allouées.

En principe, les développeurs déboguent le code au fur et à mesure qu'ils l'écrivent. Un programmeur ne devrait jamais écrire du nouveau code alors qu'il pourrait plutôt corriger des anomalies. Leur nombre doit toujours rester aussi bas que possible pour deux raisons :

1) Il est plus facile de corriger des anomalies le même jour que vous avez écrit le code. Il peut être très difficile et très coûteux en temps de corriger des anomalies un mois plus tard lorsque vous avez oublié comment le code fonctionne exactement.

2) Corriger des anomalies est comme faire de la recherche scientifique. Il est impossible d'estimer quand vous ferez une découverte et résoudrez l'anomalie. S'il n'y a à tout moment qu'une ou deux anomalies importantes, il est facile d'estimer la date de livraison du produit, parce qu'il n'y a pas beaucoup de mystères scientifiques impossibles à estimer dans votre futur. Inversement, s'il a des centaines ou des milliers d'anomalies importantes, il est impossible de prévoir quand elles seront toutes corrigées.

Si les développeurs corrigent toujours les anomalies au fil de l'eau, quel est l'intérêt d'avoir une ligne débogage ? Eh bien, même s'ils essaient de corriger toutes les anomalies au fil de l'eau, à la fin de chaque projet, il y a inévitablement un temps important de correction d'anomalies lorsque les testeurs (internes ou bêta) trouvent des anomalies vraiment difficiles.

10) Ajoutez du temps d'intégration dans votre planning. Si vous avez plus d'un programmeur, il va inévitablement y avoir des choses que deux programmeurs feront et qui seront incompatibles, puis qu'il faudra réconcilier. Ils peuvent implémenter tous deux des boîtes de dialogue pour des besoins similaires qui seront inutilement différentes. Quelqu'un va devoir parcourir tous les menus, les raccourcis clavier, la barre d'outils, etc... pour mettre au propre et organiser tous les éléments de menu que chacun aura ajouté de manière anarchique. Des erreurs de compilation vont apparaître aussitôt que deux personnes auront fait un check-in de leur code. Cela doit être corrigé, et ça devrait correspondre à une ligne du planning.

11) Ajoutez une marge de sécurité dans le planning. Les choses ont tendance à déborder. Il y a deux types importants de marge à considérer. Premièrement, de la marge pour prendre contre les tâches qui ont duré plus longtemps que prévu. Deuxièmement, de la marge pour prendre en compte ce que vous ne saviez pas que vous auriez à faire, en général parce que le management a décidé qu'il était EXTREMEMENT IMPORTANT d'implémenter wawa et que ça ne pouvait pas être laissé en dehors du périmètre de la prochaine version.

Vous pourriez être surpris de constater que les absences, les vacances, le débogage, l'intégration et la marge de sécurité ajoutent une durée supérieure à celle des tâches effectivement à réaliser. Si vous êtes surpris par ce fait, vous ne programmez pas depuis longtemps, n'est-ce pas ? Ignorez cela à vos risques et périls.

12) Ne laissez jamais, jamais des managers vous dire de réduire une estimation. Beaucoup de managers débutant dans le monde du développement pensent qu'ils peuvent "motiver" leurs programmeurs à travailler plus vite en leur donnant de jolis plannings "serrés" (raccourcis de manière non réaliste). Je pense que ce genre de motivation est stupide. Lorsque je suis en retard sur un planning, je me sens coupable, dépressif et démotivé. Lorsque je travaille en avance sur le planning, je me sens joyeux et productif. Le planning n'est pas un endroit où jouer avec la psychologie.

Si votre manager vous oblige à réduire une estimation, voici ce qu'il faut faire. Créez une colonne appelée Estimation de Rick (en supposant que votre nom est Rick bien sûr). Placez-y votre estimation. Laissez votre manager faire ce qu'il veut avec la colonne Estimation Courante. Ne prenez pas en compte les estimations de votre manager. Lorsque le projet est terminé, regardez qui était le plus près de la réalité. J'ai constaté que la simple menace de faire cela fonctionne à merveille, en particulier lorsque votre manager se rend compte qu'il vient de s'engager dans un concours pour voir à quel point vous travaillez lentement !

Pourquoi est-ce que les managers pas très malins essaient d'inciter les programmeurs à réduire les estimations ?

Lorsque le projet démarre, les responsables partent rencontrer les gens du commerce, et reviennent avec une liste de fonctionnalités dont ils pensent qu'elle nécessite trois mois, mais qui en prendrait en réalité neuf. Lorsque vous pensez à écrire du code sans réfléchir à toutes les étapes par lesquelles vous devez passer, il semble toujours que cela va prendre un temps n, alors que ça va probablement prendre un temps supérieur à 3n. Lorsque vous faites un vrai planning, vous ajoutez toutes les tâches et vous réalisez que le projet va prendre beaucoup plus de temps que ce qu'on pensait à l'origine. La réalité se fraie un chemin.

Les managers stupides essaient de résoudre ce problème en cherchant comment faire travailler les gens plus vite. Ce n'est pas très réaliste. Il pourra vous être possible d'embaucher plus de monde, mais les gens auront besoin de se mettre dans le bain et vont certainement travailler à 50 % d'efficacité pendant plusieurs mois (et tirer l'efficacité des gens qui doivent les coacher vers le bas). Quoi qu'il en soit, dans le contexte actuel, ajouter de bons programmeurs va prendre 6 mois.

Vous pourriez peut-être temporairement obtenir des gens 10 % de code en plus, au prix d'en épuiser 100 % en une année. Pas un gros gain, et c'est un peu comme manger vos semis de maïs.

Vous pourriez peut-être obtenir des gens 20 % de code en plus en suppliant chacun de travailler très dur, peu importe leur fatigue. Boom, le temps de débogage double : un coup idiot qui a riposté d'une manière magnifiquement karmique.

Mais vous ne pouvez jamais tirer 3n de n, jamais, et si vous pensez en être capable, envoyez-moi l'identifiant des actions de votre compagnie pour que je puisse vendre.

13) Un planning c'est comme des morceaux de bois. Si vous avez un ensemble de morceaux de bois, et qu'ils ne rentrent pas dans une boîte, vous avez deux possibilités : prendre une boîte plus grande, ou enlever quelques blocs. Si vous pensez pouvoir livrer en six mois, mais que vous avez douze mois sur le planning, vous allez devoir retarder la livraison, ou trouver certaines fonctionnalités à abandonner. Vous ne pouvez pas réduire la taille des blocs, et si vous prétendez en être capable, alors vous vous privez d'une opportunité utile de voir dans le futur en vous mentant à propos de ce que vous y voyez.

Et vous savez, l'autre grand avantage associé au fait de gérer des plannings de cette manière et que vous êtes forcé d'abandonner des fonctionnalités. Pourquoi est-ce intéressant ? Supposons que vous avez deux fonctionnalités : une vraiment utile qui va rendre votre produit excellent (exemple : les tables dans Netscape 2.0), et une autre qui est vraiment facile et que le programmeur adorerait développer (exemple : le tag BLINK), mais qui ne sert à rien d'un point de vue utilitaire ou marketing.

Si vous ne faites pas de planning, les programmeurs vont traiter les fonctionnalités faciles/amusantes en premier. Ensuite leur crédit de temps va être épuisé, et vous n'aurez pas d'autre choix que de décaler le planning pour traiter les fonctionnalités utiles/importantes.

Si vous faites un planning, avant même de continuer à travailler, vous réaliserez que vous devez abandonner quelque chose, donc vous allez abandonner la fonctionnalité facile/amusante et seulement traiter la fonctionnalité utile/importante. En vous forçant à choisir des fonctionnalités à abandonner, vous êtes poussé à créer un produit plus puissant, meilleur, contenant un meilleur éventail de nouvelles fonctionnalités, qui sera livré plus tôt.

Je me rappelle le travail sur Excel 5. Notre liste de fonctionnalités originale était immense et nous aurait emmenés largement au-delà du planning. Mon dieu ! pensions-nous. Toutes ces fonctionnalités sont très importantes ! Comment pourrions-nous vivre sans un assistant d'édition de macros ?

Quoi qu'il en soit, nous n'avions pas le choix et nous avons "découpé au plus près de l'os" pour faire le planning. Tout le monde se sentait malheureux au sujet des suppressions. Pour modérer nos sentiments, nous nous disons simplement que nous n'étions pas en train de supprimer des fonctionnalités, mais que nous les reportions simplement vers Excel 6, puisqu'elles étaient moins importantes.

Alors que Excel 5 était presque terminé, j'ai commencé à travailler sur la spec d'Excel 6 avec un collègue, Eric Michelman. Nous nous sommes assis pour parcourir la liste des fonctionnalités "Excel 6" qui avait été écartées du planning Excel 5. Nous fûmes positivement choqués de voir que la liste des fonctionnalités abandonnées était la liste de fonctionnalités la plus fantaisiste qu'on puisse imaginer. Pas une seule de ces fonctionnalités ne valait la peine d'être réalisée. Je ne pense pas qu'une seule d'entre elles ait jamais été développée, même dans les trois versions suivantes. Le processus de sélection des fonctionnalités pour rentrer dans un planning était la meilleure chose que nous pouvions faire. Si nous ne l'avions pas fait, Excel 5 aurait pris deux fois plus longtemps et aurait inclus 50 % de fonctionnalités inutiles et pourries. (Je suis absolument certain que c'est exactement ce qui est en train d'arriver à Netscape 5 / Mozilla : ils n'ont pas de planning, ils n'ont pas de liste de fonctionnalités fixée, personne n'a voulu abandonner aucune fonctionnalité, et ils n'ont simplement jamais livré. Lorsqu'ils livreront, ils auront un tas de fonctionnalités hors sujet comme un client IRC sur lesquels ils n'auraient pas dû passer du temps.)

Annexe : Des choses que vous devriez savoir sur Excel.

Une des raisons pour lesquelles Excel est un si bon produit pour travailler sur les plannings de développement, c'est que la seule chose pour laquelle la plupart des programmeurs d'Excel utilisent Excel est pour suivre leurs plannings développement ! (peu d'entre eux exécutent des simulations commerciales ... il s'agit de programmeurs, ici !)

Listes partagées En utilisant la commande Fichier / Listes partagées tout le monde peut ouvrir le fichier en même temps. Comme l'ensemble de votre équipe devrait tenir constamment le planning jour, c'est une aide précieuse.

Filtre automatique C'est une excellente manière de filtrer le planning de manière que, par exemple, vous ne voyiez que la liste des fonctionnalités qui vous sont assignées. En combinant avec Filtre automatique, vous pouvez voir toutes les fonctionnalités qui vous sont assignées dans l'ordre de priorité, ce qui constitue effectivement votre liste des choses "à faire". Coooool !

Pivot tables C'est une très bonne manière de voir des résumés et des croisements de données. Par exemple vous pouvez créer un graphique qui montre le nombre d'heures restantes pour chaque développeur et pour chaque priorité. Les Pivot tables sont comme des tranches de pain ou des milk-shakes au chocolat. Vous devez apprendre vous en servir car ils rendent Excel un million de fois plus puissant.

La fonction WORKDAY (Jours ouvrés) du package d'outils d'analyse Excel est un bon moyen de récupérer des dates de calendrier à partir d'un planning sans effort



Cet article est paru en version originale anglaise sous le titre Painless Software Schedules  

Joël Spolsky est le fondateur de Fog Creek Software, une petite société éditrice de logiciel située à New York. Il est diplômé de l'Université de Yale et a travaillé comme programmeur et manager chez Microsoft, Viacom et Juno.


Le contenu de ces pages représentent l'opinion d'une personne.
Contenu protégé par le copyright ©1999-2005 par Joël Spolsky. Tous droits réservés.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky