- L’estimation d’un projet ou la délégation commencent par la transformation d’une grosse demande comme « construire ça » en une liste de tâches claire, et chaque élément doit faire apparaître le changement attendu et l’état de complétion
- Le processus de décomposition consiste à noter les étapes nécessaires à partir d’une idée, d’un croquis ou d’une liste initiale, puis à affiner récursivement chaque élément jusqu’à ce qu’il soit suffisamment défini
- L’exemple d’un streak tracker pour les activités de plein air se divise progressivement en modèle de données, vue calendrier, journalisation des activités, calcul de streak et streak freeze, tout en révélant les zones d’incertitude
- Une « tâche suffisamment définie » est un état où l’on peut répondre oui à la question du changement voulu, de l’apparence du résultat fini, de toutes les étapes jusqu’à l’achèvement et des informations nécessaires pour commencer immédiatement
- La décomposition du travail est une compétence qui demande du pattern matching fondé sur l’expérience ; les équipes débutantes ont donc besoin d’occasions sûres de s’exercer à planifier et de recevoir du feedback
Transformer un gros projet en liste de tâches
- Les discussions précédentes sur l’estimation de projet supposaient qu’une liste de tâches claire existait déjà, mais sur le terrain il peut d’abord être nécessaire de passer par l’étape préalable de la décomposition du travail
- La décomposition du travail est le processus qui consiste à diviser un gros projet en tâches constitutives ; pour estimer ou déléguer, il faut un niveau plus fin qu’une tâche unique du type « faire cette illustration »
- Pour un projet personnel mené seul, un simple croquis peut suffire, mais si l’on veut le confier à quelqu’un d’autre ou en estimer la durée, il faut augmenter le niveau de détail
Exemple : un streak tracker personnel
- Un streak tracker personnel pour suivre les jours où l’on a pratiqué une activité de plein air est utilisé comme exemple
- On veut quelque chose de similaire à l’application Streaks
- On veut inclure des options d’activités de plein air comme la course, le vélo et le ski
- On veut aussi intégrer la fonction de streak freeze de Duolingo
-
1re étape : partir d’un croquis
- Une maquette visuelle est un bon point de départ, car elle montre clairement ce qu’il faut construire
- Pour un projet réalisé seul, on pourrait commencer à coder directement à partir d’un croquis de ce niveau
- Si l’objectif est l’estimation ou la délégation, il faut une liste de tâches plus fine qu’un simple « faire cette image »
-
2e étape : découper en grandes fonctionnalités
- La première décomposition consiste à séparer le projet en composants approximatifs
- Modélisation des données
- Vue calendrier montrant les dates de la semaine en cours
- Calendrier interactif permettant d’enregistrer une activité par clic sur une icône et de marquer la date comme accomplie dans le suivi du streak
- Calcul et affichage de la longueur du streak actuel
- Implémentation du streak freeze
- Pour simplifier l’exemple, les tâches opérationnelles comme le déploiement ou la configuration de la base de données sont exclues
- Dans un vrai projet, surtout avec plusieurs personnes, il serait plus approprié de séparer le déploiement, le frontend et le backend en éléments distincts
- Même à ce stade, une certaine estimation est possible, mais il reste des incertitudes sur la façon d’accumuler et de suivre les freeze, l’historique, ou l’ajout et la suppression de types d’activités
-
3e étape : découper davantage pour faire apparaître les critères d’achèvement
- Le modèle de données se divise en types d’activités, activités enregistrées, freeze et streak
- Pour les types d’activités, une liste codée en dur comme run/bike/ski/climb suffit
- Les activités enregistrées ont une date et un type
- Les freeze ont une date d’obtention et une date d’utilisation
- Les streak ont une date de début, une date de fin et des informations agrégées par type d’activité
- La vue calendrier statique se décompose en vue hebdomadaire, écran d’accueil, vue mensuelle, navigation et saisie de déplacement à une date
- Pour le déplacement à une date, on peut utiliser le widget de date HTML5 sans recourir à une saisie fuzzy compliquée
- Pour le calendrier hebdomadaire dynamique, au lieu d’ajouter une saisie dynamique à la vue mensuelle, on enregistre l’accomplissement en cliquant sur un type d’activité pour une date donnée
- Le calcul et l’affichage du streak consistent à parcourir les activités enregistrées pour calculer le streak, à afficher le streak actuel dans l’interface, puis à le recalculer quand une activité est enregistrée depuis l’interface
- Le streak freeze inclut l’accumulation, la prévention des accumulations en double, ainsi que l’affichage dans l’interface de l’utilisation et du nombre restant
- Le seuil de X jours pour obtenir un freeze peut être codé en dur dans un premier temps
- Les freeze peuvent être reportés au streak suivant
- Lors du recalcul du streak après modification d’activités passées, il faut empêcher l’accumulation en double des freeze réattribués
Procédure de décomposition à appliquer de manière répétée
- La décomposition du travail n’est pas une conception terminée en une seule fois, mais un processus itératif
- On part d’une liste de tâches ou d’un gros projet unique
- On réfléchit aux étapes nécessaires pour terminer ce travail et on les note
- On vérifie si chaque étape est suffisamment définie
- Si ce n’est pas le cas, on redécompose cet élément
- Chaque itération n’a pas besoin d’être complète ni exacte ; il suffit qu’elle développe un peu plus la liste précédente
- On répète le même processus jusqu’à ce que toutes les tâches soient suffisamment définies
Critères de « tâche » et de « suffisamment défini »
- En développement logiciel et en estimation de projet, une tâche est une unité de travail suffisamment définie, complète et porteuse de changement
- « travailler sur des trucs » n’est pas une tâche, car les contours des exigences ne sont pas définis
- « couper un arbre » n’est pas une tâche complète si l’on n’a apporté qu’une tronçonneuse
- Dans un contexte professionnel, une tâche n’a de sens que si quelque chose change après son exécution
- Pour déterminer si une tâche est suffisamment définie, on vérifie si la personne qui la réalise peut répondre « oui » à toutes les questions suivantes
- Comprend-elle quel est le changement souhaité ?
- Comprend-elle à quoi ressemble l’état « terminé » ?
- Peut-elle définir toutes les étapes nécessaires jusqu’à l’achèvement ?
- En supposant l’absence de blocage ou de dépendance, dispose-t-elle dès maintenant de toutes les informations nécessaires pour commencer ?
- Selon le contexte organisationnel, des observateurs comme le chef de projet, les principales parties prenantes ou les auditeurs peuvent aussi devoir répondre « oui » à ces questions
- Certaines tâches, comme la correction de bugs, comportent des inconnues difficiles à décomposer davantage
- Dans ce cas, on peut utiliser des techniques comme le timeboxing
Le sens de la décomposition se construit avec l’expérience
- La décomposition du travail est une compétence qui demande de la pratique, et il est normal qu’elle ne paraisse pas simple au début
- Si la modélisation des données a été placée en premier dans l’exemple, ce n’est pas à cause d’un algorithme clair, mais d’une intuition fondée sur l’expérience
- L’expérience a montré que, pour construire des outils similaires, le travail avançait mieux quand le modèle de données était défini en premier
- Django offre des affordances mieux adaptées à un flux axé d’abord sur les données du modèle
- S’il manque l’expérience consistant à avoir vu ou mené plusieurs projets, il peut être difficile de déterminer par où commencer
- Pour qu’une équipe développe cette capacité, il faut qu’elle puisse élaborer des plans de projet dans un environnement sûr, s’essayer à la décomposition et recevoir du feedback
- Si les premiers plans, même très erronés, ne sont pas sanctionnés, ces erreurs deviennent des données d’expérience réutilisables pour le pattern matching ultérieur
Résultat de l’estimation du projet d’exemple
- Dans l’estimation bonus, après avoir affiné les tâches, on leur attribue une complexité, une incertitude, une durée attendue et une durée dans le pire des cas
- L’estimation totale est calculée à 15,5 jours, et le pire des cas à 23,5 jours
- Parmi les principaux éléments, le calcul du streak et l’accumulation des freeze sont tous deux de complexité medium et d’incertitude moderate, avec une estimation de 3 jours et un pire cas de 4,5 jours chacun
- La prévention des accumulations de freeze en double est de petite complexité, mais avec une incertitude extreme, estimée à 1 jour et jusqu’à 5 jours dans le pire des cas
- En pratique, le projet a été achevé en une douzaine de soirées et un long vol, mais le design a été largement simplifié et l’algorithme des freeze comporte peut-être des bugs qui apparaîtront plus tard
1 commentaires
Avis de Hacker News
D’abord, il est très rare que j’aie réellement exécuté toutes les étapes comme prévu jusqu’au bout. Après seulement quelques étapes, on comprend quelque chose de nouveau, on découvre un oubli, ou on voit une méthode plus simple, et on finit par ne plus suivre le plan
Ensuite, j’ai l’impression que tout l’effort créatif consistant à réfléchir à la manière de construire quelque chose est concentré au début, et je n’aime pas travailler comme ça. Le reste représente toujours la majeure partie du travail, mais il ne reste que la partie la plus ennuyeuse ; je trouve plus intéressant — donc plus rapide, avec de meilleurs résultats — de mêler plus régulièrement créativité et tâches répétitives
Les deux sont probablement liés, et il n’est pas impossible que j’aie un TDAH
Si vous explorez ou construisez votre propre projet, sans véritable structure de responsabilité, il n’est pas nécessaire de planifier autant, sauf si vous aimez planifier pour le plaisir
Mais dès que votre chef demande « combien de temps cela va prendre ? Qui fait quoi ? Par où commence-t-on ? », il faut bien un cadre
Moi aussi je déteste devoir me plier à des systèmes arbitraires ou trop rigides, mais un système doit être simple et flexible, et un système de productivité est censé aider les gens
Je ne pense pas que l’auteur ait voulu en faire une recette détaillée ; il montrait plutôt son approche pour que d’autres puissent y puiser leurs propres idées
C’est parfois encore pire que « le plan n’est jamais suivi tel quel ». Quand on continue à ajouter des tâches pendant l’exécution, on se retrouve à la fin avec une liste désordonnée de tâches inachevées, mélangées à celles créées lors de la planification, dont on n’a plus besoin
Parce que ces tâches ont été créées sans le contexte global qui n’apparaît qu’au moment de l’exécution
Le plaisir de la programmation vient du fait que c’est une activité créative, souple et fluide. On construit au fil de l’avancement, de manière organique
Dans un environnement de travail, la surveillance et l’imputabilité sont nécessaires, et cette organicité est donc en grande partie supprimée
La prochaine fois que vous planifierez une tâche identique ou similaire, le plan futur sera meilleur
Les chefs de projet ont aussi ce slogan : « ne pas planifier, c’est planifier l’échec »
Parce que je me rends souvent compte que je laisse passer beaucoup de choses parmi tout ce dont il faut se souvenir
Un plan n’est qu’une manière, pour le moi du passé, de rappeler au moi du futur le résultat idéal qu’il avait en tête. Plutôt que de modifier sans cesse le plan en poursuivant des lucioles
Le « découpage des tâches » est un sujet assez vaste pour devenir un genre de livres ou de podcasts à part entière. Dans les livres de développement personnel ou d’organisation, on part souvent du principe que découper une tâche est une capacité humaine élémentaire que les lecteurs possèdent déjà
Mais d’après mon expérience, et ce que j’ai entendu lors de séances de groupe, le découpage des tâches est très difficile et peut provoquer de l’évitement ou un sentiment de désespoir
Le conseil le plus largement applicable que j’aie vu est de continuer à découper jusqu’à atteindre 90 % de certitude de pouvoir terminer la tâche avec succès. Ce niveau de confiance varie selon la confiance en soi et l’appétence au risque : certaines personnes peuvent s’arrêter à une probabilité de réussite d’environ 70 %
On dispose d’environ 6 heures utiles par jour ; quand quelqu’un affirme avec assurance que cela prendra « une demi-journée », puis qu’on lui fait remarquer que cela veut dire environ 3 heures, il devient soudain beaucoup moins sûr de lui, ou se vexe. Et trois jours plus tard, il est encore dessus
Cette méthode s’est révélée étonnamment précise pour les estimations de temps, au total, même si les estimations individuelles se trompent largement
Au fond, c’est une estimation probabiliste. Sur beaucoup d’événements, on converge vers la moyenne
Le problème que la plupart des gens ignorent, c’est que le développement logiciel est avant tout proche d’une activité créative. Bien sûr, il comporte des aspects techniques sérieux, mais le problème lui-même est virtuel et n’est pas contraint par le monde réel comme le génie civil ; il n’existe donc pas de solution optimale unique
Si l’on essaie de définir la solution avant d’avoir vraiment examiné le problème, on ne fait que limiter le résultat final. L’essentiel de l’exploration n’a lieu qu’après avoir commencé à coder
Dans le logiciel, le fait que le résultat final et le temps ne soient pas clairement définis n’est pas si important, car il n’y a pas de coût unitaire. Les managers qui n’ont pas de bagage en génie logiciel comprennent mal cela
Un produit générique peut être vendu à plusieurs clients sans coût de développement supplémentaire
Mais comme la plupart des entreprises fonctionnent comme des usines, toutes les procédures finissent par produire un produit très limité destiné à un client précis. C’est précisément ce que les grandes entreprises tech ont évité
On dirait que toute l’industrie a adopté ce modèle
Mais honnêtement, je pense que ce qui bloque la plupart d’entre nous, c’est plutôt le manque de capacité à ne pas le faire. Si vous avez quelque chose que vous voulez construire, ne planifiez pas toutes les pièces : construisez simplement la plus petite chose susceptible d’avoir de la valeur
Dans l’exemple, il suffit de commencer par l’écran « aujourd’hui » et quatre boutons. Vous pouvez probablement construire aujourd’hui l’affichage des quatre boutons d’exercice sur lesquels appuyer chaque jour. Pas besoin de série, de gel ni de vue calendrier
Toutes ces idées sont bonnes et viendront plus tard, mais il faut d’abord créer de l’élan. Quelques jours plus tard, vous pourriez décider que cette vue calendrier ne vous plaît pas
Davantage de projets ont besoin qu’on les pousse avec un « fais-le, même petit ». Termine-le aujourd’hui, puis regarde quelle est la prochaine tâche à partir de là. Il y a de fortes chances que ce soit différent de ce qu’on imaginait à l’étape de planification
Bien sûr, ce n’est pas facile non plus. Trouver la plus petite chose, et décider de la livrer sans se laisser distraire, demande de la réflexion et de la discipline. Mais cela vaut la peine de s’y exercer
C’est le principe selon lequel, face à l’incertitude, il faut se concentrer sur « la prochaine bonne chose à faire » [0]
Je ne veux pas dire par là que c’est trivial. Déterminer quelle est la prochaine bonne chose à faire est difficile, et de mon point de vue c’est la partie la plus précieuse de la planification
0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
Par exemple, une personne crée une méthode de comparaison pour les tests, une autre essaie une approche, une autre une deuxième approche, une troisième encore une autre, puis tout le monde évalue les résultats après une période définie
Bien sûr, cela n’a de sens que s’il n’existe pas déjà une approche préférée ou manifestement supérieure
Dans le développement réel, la modularisation peut être une méthode de parallélisation. Chaque personne ou équipe prend en charge un composant
Dans mon travail, surtout quand je suis encore en train de chercher la direction à prendre, j’aime alterner entre les parties visibles par l’humain et les entrailles techniques. Développer uniquement la technique sans connaître l’usage force les façons de l’utiliser dans une certaine direction, et concevoir seulement l’interface sans connaître la technique comporte aussi des pièges
Mais dans les activités qui, comme la recherche, nécessitent des expérimentations créatives et des preuves de concept pour valider des choses qu’on ne peut pas connaître à l’avance, la décomposition du travail elle-même s’effondre
C’est pourquoi j’ai pris l’habitude de faire la plupart de mes travaux de preuve de concept en privé, sans en parler à personne
Si ça marche, je peux le rendre public ; si ça ne marche pas, je peux l’abandonner et passer à autre chose sans perdre la face ni me faire dire de trouver un moyen de le faire fonctionner, même après avoir constaté qu’il ne faut pas continuer
Il suffit de dire : « consacrons 3 heures à examiner X, 3 heures à Y, 3 heures à Z, puis tenons une réunion de planification pour décider quoi faire ensuite »
Il y a quatre résultats possibles. Le premier résout le problème, le deuxième le résout, le troisième le résout, ou rien ne le résout
Si c’est un problème qui peut être résolu avec un peu d’effort, il y a 50 % de chances qu’il le soit au deuxième essai, c’est-à-dire en 6 heures
Et à un moment, il faut simplement faire les choses
La décomposition du travail et l’estimation sont presque la même chose. Une fois la décomposition faite, quelqu’un qui a quelques années d’expérience dispose d’estimations standard pour les petites tâches, donc il ne faut que quelques minutes pour attribuer une estimation à chaque morceau
Dans mon cas, je découpe le travail en morceaux que je peux estimer, et pour les parties que je ne peux pas estimer, je demande l’avis d’autres personnes
Cela dit, je ne pense pas que la vraie voie de la maîtrise soit la décomposition du travail. N’importe qui peut produire une mauvaise décomposition
La vraie maîtrise consiste à remarquer quand les preuves montrent que cette décomposition est suffisamment fausse pour poser problème, puis à le communiquer ou à réestimer [0]
Il est aussi important d’accepter sereinement que cela arrivera, afin de ne pas stresser dès le départ en proposant un planning susceptible de changer fortement
Les managers veulent généralement une roadmap exacte dès le début, mais c’est demander l’impossible. À mon avis, une bonne gestion repose sur la flexibilité et sur la compréhension du fait qu’avec le temps, à mesure que les développeurs apprennent, la nature du travail attendu change
Le petit exemple à la fin de l’article mérite aussi réflexion. Même si quelqu’un lui avait donné une estimation exacte — « ce sera fini en quelques dîners pendant des voyages en avion » —, il aurait refusé parce que c’était trop risqué
Cela montre que l’estimation n’est pas seulement une question de précision. Il y a beaucoup de facteurs qui ne se révèlent pas entièrement avec des mots comme gestion du risque, gestion des attentes ou familiarité avec le travail
[0] https://jacobian.org/2021/jun/8/incorrect-estimates/ - il y a aussi un article sur ce sujet
Ce sont de bons nouveaux professionnels du logiciel, mais comme le domaine est nouveau pour eux, il leur arrive de ne vraiment pas savoir comment mettre en place des fonctionnalités de base. D’après mon expérience, ils veulent des tâches sur lesquelles ils peuvent apprendre et réussir, et cela mène à leur progression
Ce qu’il faut absolument garder à l’esprit, c’est que le coût du processus est un continuum à ajuster à l’équipe. Les joueurs de NBA n’apprennent pas à lancer le ballon depuis le huddle pendant un match, mais les élèves de CE2, eux, l’apprennent
Les deux modes de planification et de coaching sont appropriés lorsqu’ils sont adaptés à chaque équipe
C’est peut-être une vérité fondamentale du génie logiciel. Il existe peut-être déjà une version open source de l’application Streak que l’auteur veut créer, et il est peut-être en train de réinventer la roue
Le cerveau ne semble pas aimer les listes de tâches. Faire une liste peut être agréable, mais l’essentiel de la création d’une startup ou du codage relève de l’exploration
Et les listes de tâches empêchent l’exploration
Sinon, qu’est-ce qui est différent dans le développement logiciel pour que « je ne sais pas » soit une réponse raisonnable dans notre métier ?
C’est parfois juste, parfois non. « La carte n’est pas le territoire »
Pour diviser le travail en tâches plus petites, il faut faire du travail redondant, et l’astuce consiste à le minimiser
Si l’on essaie de ne faire absolument aucun travail inutile, on finit par devoir tout faire d’un coup
Par exemple, supposons qu’on refactore un programme avec deux modules A et B, où B dépend de A. La méthode la moins coûteuse en gaspillage consiste à refactorer les deux modules ensemble. Mais c’est aussi la plus risquée et la plus difficile à estimer
La façon dont le découpage a été fait consistait à refactorer A, puis à adapter B pour qu’il fonctionne avec A refactoré. Ensuite, si l’on refactore de nouveau A, le travail d’adaptation effectué juste avant risque vite d’être jeté
Si l’on veut ramener à zéro le travail voué à être abandonné, il y a souvent des cas où l’on ne peut pas découper le travail. Même avec 20 ans d’expérience, j’hésite encore souvent à faire du travail temporaire destiné à être jeté simplement pour pouvoir découper une tâche
À la place, il m’arrive de travailler pendant quelques semaines et de finir par raser tout le yak, sans laisser un seul poil de côté
Réfléchir au problème que l’on veut résoudre avant de commencer a du sens, et des jalons approximatifs sont importants. Mais la plupart du temps, il y a tellement d’inconnues inconnues qu’un découpage complet est soit totalement inutile, soit impossible
J’ai l’impression que si l’on avait simplement consacré le temps passé à découper le projet à chercher ou construire la solution, on aurait terminé bien plus vite. En tout cas, c’est ce que je ressens
En général, j’aborde la question autrement. Il s’agit d’estimer l’effort nécessaire pour décider, au départ, s’il faut construire la chose ou non. Autrement dit, la première raison est d’aider à faire une analyse coût-bénéfice
Cela peut aussi être très utile à l’équipe. Surtout quand on travaille avec des personnes moins expérimentées, on peut beaucoup découper les tâches et les paralléliser
Je ne pense pas non plus que Jacob ait beaucoup fait ce genre de décomposition lorsqu’il a implémenté sa propre application Streak ; il semble donc avoir pris un exemple récursif pour l’explication
Dans ces cas-là, diviser en tâches plus petites et les terminer une par une s’est révélé utile. Même lorsqu’on est bloqué ou qu’on n’a pas envie de travailler, cela crée du progrès, et ce progrès génère l’élan nécessaire pour continuer
Le fait que les managers puissent estimer la vélocité a clairement de la valeur. Le problème, c’est qu’une fois qu’ils y ont pris goût, ils deviennent vraiment incapables de comprendre ce que veut dire « ce n’est pas certain »
Moi aussi, je suis consultant, donc même si nous travaillons de manière « agile », il est très important de pouvoir dire : « nous livrerons ceci dans ce délai »