Les tâches « gazeuses »

Est-ce que vous connaissez la particularité fondamentale de l’état gazeux ? Wikipédia le dit très bien :

Dans l’état gazeux, la matière n’a pas de forme propre ni de volume propre : un gaz tend à occuper tout le volume disponible.
 

Ce que j’appelle les « tâches gazeuses », ce sont les projets − ou les éléments d’un projet − qui ont la capacité de durer aussi longtemps que vous le permettez. Quel que soit le temps que vous pouvez y passer, ça ne sera jamais terminé ; il y a toujours un dernier truc à fignoler, quelque chose sur lequel il faut réfléchir, un point important qui nécessite d’y consacrer encore un peu de temps.

J’ai tendance à séparer ces tâches en 3 types : celles qui sont intrinsèquement gazeuses, celles qui ont été mal préparées, et celles qui sont mal gérées.

Les tâches intrinsèquement gazeuses

Il existe tout un tas de tâches dont la nature même implique qu’elles ne se terminent jamais. Il s’agit principalement de celles qui nécessitent du jus de cerveau, de la réflexion, de la cogitation. On peut passer un temps infini à réfléchir à une spécification, à penser une ergonomie, à échafauder des méthodes de travail.

Mais cela peut aussi concerner des choses qui sont plus concrètes, mais qui n’ont pas forcément une ligne d’arrivée bien visible : écrire une documentation la plus complète possible, chercher un code coverage de 110% sur ses tests unitaires, optimiser du code pour grappiller un dixième de seconde supplémentaire.

Dans ces cas-là, il existe deux solutions :

  • Se créer des objectifs atteignables et s’en satisfaire. Un design peut toujours être amélioré, mais il faut être capable de converger vers une version « suffisamment » bonne.
  • Se donner un budget-temps. Quoi qu’on en dise, une tâche possède toujours une valeur spécifique. Si on y passe plus de X heures, son coût devient trop élevé pour qu’elle vaille la peine d’être réalisée.

Les tâches mal préparées

Ça paraît super-évident. Quand une tâche ou un projet a mal été préparé, on est certain de générer de l’effet tunnel. Même avec de bonne spécifications fonctionnelles, il est assez facile de croire qu’on maîtrise techniquement son sujet, et qu’on peut se jeter dans le code de manière rock’n roll. C’est le meilleur moyen pour ne pas anticiper d’éventuels problèmes, voire simplement des choix techniques qui devraient être pensés en amont.

Fatalement, ce n’est qu’une fois qu’on est face aux questions techniques qu’on commence à y réfléchir. Ça fait perdre un temps précieux.
Mais surtout, on se retrouve ainsi à résoudre les points bloquants au fur et à mesure qu’ils apparaissent. On se dit tout le temps « Je résous ce truc, et après c’est bon !« , mais l’ennui c’est qu’on va ensuite tomber sur un autre truc à résoudre, puis un autre, etc. Aucune visibilité sur l’étendue du travail à réaliser, on nage en plein brouillard.

Dans ce cas-là, il n’y a pas tente-six solutions : Il faut se pencher sur la tâche et la décortiquer méthodiquement avant de commencer à travailler réellement dessus.

Les tâches mal gérées

Vous vous souvenez du triangle qualité-coût-délai ? L’enseignement principal qu’il nous apporte est qu’on peut fixer deux des trois paramètres d’un projet, et que le troisième en découle forcément.

Lorsqu’un projet est mal géré, cela provient rarement de la qualité du travail effectué dessus ou de la précision des spécifications fournies. Non, trop souvent le problème réside dans l’impulsion initiale du projet, dans la manière dont le client appréhende ses objectifs et qu’il les communique.

Si on veut faire un POC, on voudra créer un prototype rapidement et à faible coût. Mais trop souvent, le prototype donne satisfaction et se retrouve en production. Il faut alors gérer des contraintes qui avaient été laissées de côté. Au lieu de tout redévelopper (comme il aurait fallu le faire avant de mettre en production, c’est pour ça que ça s’appelle un prototype), on passe son temps à maintenir en vie le projet, qui devient alors gazeux : on ne sait pas combien de temps chaque évolution prendra à être ajoutée, car la base même n’est pas prévue pour recevoir ces évolutions.

Autre exemple, le projet qui a été fait dans les règles de l’art au niveau de sa réalisation, mais sur lequel on a pris quelques raccourcis pour réduire les délais de livraison. Tout va bien jusqu’au jour où le projet interne est ouvert à des partenaires, et qu’on s’aperçoit qu’aucune interface n’est prête. On se dépêche de les ajouter, pour se rendre alors compte que la documentation nécessaire n’a pas été écrite. Et ainsi de suite…

Il est donc important de communiquer avec son client (qu’il soit interne ou externe), pour s’assurer que sa vision des choses est suffisamment pragmatique pour éviter les déconvenues et les déceptions.

Gestion des spécifications

Je vous ai déjà parlé de différentes méthodes de gestion de projet. Entre autre, j’ai déjà écrit des articles sur le cycle en V et le cycle itératif, ainsi que sur les méthodes agiles. Ces méthodes, et plus particulièrement les méthodes agiles, sont globalement axées sur la gestion des développements. Comprenez par là que leur but est d’arriver à la création d’un produit fini avec le meilleur rapport qualité/coût/délai.

Bien souvent, quand on met en place une méthode de travail, on se focalise sur les phases de réalisation du travail. Puis on s’intéresse à ce qui a lieu en aval, le processus qualité et les étapes de livraison. Par contre, on aborde assez rarement la manière dont les spécifications sont réalisées et gérées.

C’est paradoxal : à quoi bon améliorer les processus de développement, si le travail à effectuer est mal défini ?

Spécifications agiles

Une − mauvaise − réponse est apportée par certaines personnes qui interprètent mal les principes agiles. Quand on applique les méthodes agiles, on cherche la satisfaction du client plutôt que l’accomplissement d’un cahier des charges figé. Malheureusement, cela se traduit parfois par la disparition de toute forme de spécification. Au lieu d’apporter une souplesse salutaire, cela peut conduire à un va-et-vient incessant entre le client et l’équipe technique en charge de la réalisation.

La mise en place de cycles itératifs a pour but évident de fluidifier le cheminement expression-de-besoin / spécification / réalisation. À chaque itération, le besoin du client est écouté, analysé, interprété, rediscuté. Les zones d’ombre sont identifiées et laissées de côté pour les prochaines itérations.

Le corollaire de cela, c’est que chaque itération doit pouvoir être réalisée dans des conditions essentielles de stabilité. La méthode Scrum prévoit d’ailleurs deux rôles bien spéciaux : le product owner représente le client et peut répondre aux questions concernant le produit ; le scrum master protège l’équipe des requêtes impromptues.

Mon expérience

J’ai déjà expliqué dans un précédent article comment nous appliquons les méthodes agiles dans mon entreprise. Pour résumer : des cycles de développement d’un mois, séparés en sprints hebdomadaires ; 2 ou 3 sprints de développement, un sprint de stabilisation (tests, débugs), un sprint de MEP (mise en pré-production, validation, mise en production).

La mise en place de ces cycles a eu des effets très positifs. Nous perdons moins de temps tout en augmentant la qualité de notre travail. Nous continuons à identifier les points qui peuvent être encore améliorés.

L’application de cette méthode de travail a toutefois mis en exergue les lacunes que nous avions au niveau de la gestion de nos spécifications fonctionnelles. C’est assez facile de s’en rendre compte : pour qu’un projet soit développé, il faut que sa spécification soit écrite et validée avant la fin du mois précédant le cycle de développement. Si la spec n’est pas prête ou si elle est incomplète, elle devrait être simplement refusée et repoussée au cycle d’après ; mais bien souvent, cela a amené à des négociations concernant les dates de livraison, le niveau de précision, ou la latitude de validation technique autorisée sur les spécifications fonctionnelles.

Ce qui m’a amené à réfléchir au processus global qui mène à l’élaboration des spécifications. Continuer la lecture de « Gestion des spécifications »

Ma méthode «musicale»

Je n’en ai jamais parlé sur ce blog, mais j’ai quelques activités en dehors de l’informatique et de l’entrepreneuriat. L’une d’elles est la musique. Je joue de la basse depuis l’âge de 16 ans, de la basse 6 cordes depuis 10 ans, et de la basse fretless depuis 2 ans. J’ai joué dans plusieurs groupes ; mon groupe actuel − Perpetual (e)motion − existe depuis 2002 et a sorti son premier album il y a peu de temps. C’est du métal progressif : l’énergie du métal avec une vraie recherche musicale.

Si, si, je vous jure, c’est vrai. La preuve en image :
Concert

Il existe grosso modo deux manières d’aborder la musique : soit on rejoue la musique des autres, soit on invente la notre. Ce n’est pas antinomique ; la plupart des groupes, amateurs ou stars mondiales, jouent des reprises au milieu de leurs propres compositions.

J’ajouterais un cas supplémentaire auquel on ne pense pas forcément, celui de la composition en groupe. On se retrouve forcément à devoir jouer certaines parties qui ont été composées par un autre membre du groupe, et d’autres parties qui sont de notre propre fait.

Tout l’intérêt de la création de groupe, c’est justement l’équilibre et la mise en danger que l’on ressent quand on essaye de créer une œuvre qui transcende les individualités, tout en exprimant la créativité de chacun.

Les principes

Pour ma part, j’ai toujours abordé la musique en appliquant la même méthode. Elle tient en 3 principes simples :

  1. Simplifier. Quand il s’agit de musique, je suis un peu fainéant. Travailler une partition à la note près, je l’ai fait assez souvent pour savoir que j’en suis capable. Mais c’est fatiguant et castrateur. Alors la première chose que je fais − qu’il s’agisse d’une reprise ou d’une composition du groupe − est de simplifier les lignes de basse qui ont été écrites. J’en extraite la substance fondamentale, qui peut être la mélodie principale ou le groove de base de la chanson.
  2. Écouter. La simplification permet d’ajouter de l‘espace, qui m’offre des options pour m’exprimer, composer mes propres variations sans dénaturer le morceau. Mais le seul moyen d’apporter ma pierre à l’édifice musical, c’est de trouver la bonne mélodie, de placer la note juste au bon moment. Et pour y arriver, je prend le temps d’écouter l’ensemble du morceau, j’essaye de sentir ce qui lui manque. En abordant une chanson avec une oreille neuve, en écoutant tous les instruments en même temps, on peut apprécier ce qu’on peut lui apporter.
  3. Improviser. Je n’ai malheureusement pas le temps de travailler longuement nos morceaux. Quand j’étais plus jeune, je travaillais mes lignes de basse tous les soirs, mais maintenant c’est bien plus difficile. Je répète toutes les semaines avec mon groupe. Je mets ce temps à profit pour expérimenter, pour essayer de nouvelles choses. Je me laisse aller à l’improvisation, mais ce n’est possible que parce que j’ai d’abord épuré les lignes de basse, puis pris le temps d’écouter. Quand une mélodie intéressante se dessine, je la ciselle en l’améliorant à chaque répétition.

Continuer la lecture de « Ma méthode «musicale» »

Le «harcèlement positif» comme méthode de travail

Il y a environ un an, je vous parlais du logiciel Action Method. Il propose une fonctionnalité «nagging», qui permet de rappeler au responsable d’une tâche que celle-ci réclame une attention particulière ou une exécution rapide.
J’aime bien cette fonction toute simple mais très utile. J’ai implémenté la même chose dans l’outil de gestion de projets qu’on utilise en interne dans mon entreprise, et je pense l’inclure au projet Skriv.

Les leviers de productivité

Avec le temps, je me suis rendu compte que je me servais − et je ne suis pas le seul − du «harcèlement» comme d’une manière normale de travailler. Non pas que je harcèle les gens avec qui je bosse (c’est puni par la loi !), mais je les incite à me harceler.

Je m’explique : De par mon poste de directeur technique, je suis amené à réaliser un certain nombre de choses par moi-même, mais une part importante de mon travail est de permettre aux autres de travailler. Que ce soit en débloquant un développeur qui reste scotché sur un bug, en aidant l’administrateur sur des tâches IT, en discutant de spécifications avec un chef de projet, en organisant les procédures d’une équipe, … je passe plus de la moitié de mon temps à “mettre de l’huile dans les rouages“.
C’est un calcul simple à faire : Cette vingtaine de personnes, si je peux faire quelque chose pour la rendre plus productive, elle générera plus de résultats que si je me concentre uniquement sur mes tâches. Et même si je ne réussis qu’à améliorer la productivité de 3 personnes, ça en vaudra la peine.

Petit aparté : Cette manière de faire peut être dangereuse si on ne la maîtrise pas. Il ne faut pas devenir le point de passage obligatoire pour toutes les réalisations, sinon on se transforme en goulot d’étranglement. Au lieu de rendre les gens plus productifs, on ralentit au contraire leur travail.

Priorités vs réactivité

Malheureusement, devenir un tel «point central» fait qu’il y a souvent un défilement incessant de personnes qui viennent me demander quelque chose. Parfois c’est juste pour avoir une info ou pour me demander mon avis avant de prendre une décision, d’autres fois c’est pour me demander de réaliser une opération qui va prendre plus de temps.

Au début, je notais les requêtes au fur et à mesure qu’elles arrivaient, en utilisant ma todo-list personnelle, ou notre buglist ou notre logiciel de gestion des tâches. Mais ça ne fonctionnait pas. Les requêtes s’empilaient sans que les demandeurs ne fassent l’effort de réfléchir aux priorités de leurs demandes. Je les traitais suivant leur ordre d’arrivée et non pas suivant leur importance ; j’étais dans la réaction et pas dans la planification.
Évidemment, j’aurais pu simplifier les choses en répondant à chaque demande «Tu as créé un ticket dans la buglist ?», et attendre le lendemain pour revoir l’ordre de priorité de toutes les tâches en attente. Mais perdre en réactivité n’est pas la bonne réponse à un problème d’identification des priorités.

Le harcèlement positif

Au final, quand quelqu’un a besoin de moi, il y a 3 scénarii :

  1. Je suis occupé à faire quelque chose d’important et long. Je demande de revenir plus tard, mais je m’informe quand même de l’importance de la demande (au cas où).
  2. Je suis occupé, mais je n’en ai plus que pour 2 minutes. Je demande à la personne de s’asseoir à côté de moi et d’attendre que j’ai fini. Quand les demandes ne sont pas si importantes que ça, les gens n’ont naturellement pas la patience d’attendre. Ils agissent comme si j’allais systématiquement m’arrêter de travailler pour traiter leurs requêtes dans la seconde ; mais si on leur demande à eux d’attendre, ils y réfléchissent à 2 fois.
  3. Il y a déjà plusieurs personnes qui font le pied de grue pour utiliser mon «temps machine». Dans ce cas, on évalue collégialement les priorités. Mais il y a un effet naturel qui s’ajoute : Lorsque quelqu’un attend depuis longtemps, il fait ce qu’il faut pour ne pas continuer à attendre ; soit il finit par abandonner (ce n’était pas si important finalement), soit il réussit à nous convaincre de l’importance de sa demande.

Quand quelqu’un a réussi à m’atteindre (si je puis dire), je lui demande de rester assis à côté de moi pendant tout le temps que je vais prendre pour réaliser ce qu’il me demande. Ceci est valable pour toutes les tâches «normales». Si une tâche va me prendre plusieurs heures, je l’intègre à ma todo-list globale.
On pourrait s’étonner du fait que je force des non-techniciens à rester près de moi, même quand je ne fais qu’exécuter des actions techniques. Pourtant, c’est justement ce qui fait que cela fonctionne :

  • Si la personne s’en va, il y a de gros risques que quelqu’un d’autre arrive juste derrière et me fasse travailler immédiatement sur une tâche plus urgente. Cela a moins de chances d’arriver si je suis visiblement occupé avec une autre personne.
  • Si la personne qui me demande quelque chose ne peut pas rester avec moi, si elle a plus important à faire que de s’assurer que je m’en occupe rapidement, c’est sûrement que ce qu’elle me demande n’est pas très important. Ou en tout cas, cela veut dire que j’ai moi aussi d’autres tâches plus importantes dont il faut que je m’occupe.
  • En gardant les requérants auprès de moi, je peux leur donner les informations qui leur permettront d’être indépendants la prochaine fois. Si par contre je m’en charge toujours de A à Z, tout seul dans mon coin, il n’y a aucune chance qu’ils montent en compétence.
  • Au moment où la tâche est terminée, ils en ont aussitôt un statut exact et complet. Il n’y a pas de tergiversation, il n’y a pas de perte d’information à cause d’une communication incomplète.

Qu’en penser ?

Je suis conscient de l’aspect complètement empirique de cette manière de travailler. Peut-être qu’elle ne peut pas s’appliquer à toutes les personnes ni à toutes les situations. Mais je l’ai vu fonctionner à maintes reprises, et ça fonctionne dans mon entreprise.

D’une certaine manière, cela me rappelle certains aspects de la méthode Getting Real de 37signals. Entre autres son paragraphe Start With No. On peut y retrouver des notions similaires :

  • On doit parfois ajouter des contraintes pour devenir plus efficace.
  • Les idées importantes finissent toujours par se faire entendre. Sans système de filtrage, c’est la cacophonie.

Découper les tâches comme un gnome

Peut-être connaissez-vous l’auteur anglais Terry Pratchett, connu ses romans de science-fiction et de fantasy à succès.

J’aime beaucoup son ouvrage Le grand livre des gnomes. Et entre autre, il contient une phrase toute simple, pensée par le héros principal :

“ Pour accomplir une tâche impossible, on la débite en petits bouts de tâches simplement très difficiles, qu’on divise ensuite en tâches horriblement pénibles, qu’on segmente à leur tour en travaux délicats et ainsi de suite… ”

Pour le coup, Masklinn (c’est le nom du gnome) se fait cette réflexion en réfléchissant à la manière de découper et ramener à sa tanière un rat qu’il vient de tuer… Mais c’est en appliquant la même méthode qu’il finit par sauver son peuple en l’emmenant dans l’espace.

Je répète sans cesse que les listes sont à la base de toute organisation personnelle. Mais avant même de pouvoir placer des tâches sur une liste, il faut déjà définir le niveau de granularité nécessaire.

Pourquoi découper

Trop souvent, j’ai vu des gens qui se satisfaisaient d’une todo-list contenant des tâches dont les intitulés résumaient à eux seuls un projet entier. C’est complètement insensé !
Ce type de comportement a plusieurs effets pervers :

  • On a une mauvaise vision de l’ensemble des actions nécessaires pour la réalisation du projet. Cela laisse la porte ouverte à de mauvaises interprétations. Arrivé aux trois-quart de la réalisation de la tâche, on peut découvrir qu’elle nécessite un développement imprévu, qui va durer à lui seul 3 fois plus longtemps que la tache initiale. Si on l’avait anticipé, cette tâche aurait peut-être été planifiée différemment, voire même abandonnée.
  • Cela participe à l’effet tunnel : Comme on ne sait pas précisément ce qu’il va falloir faire, il est impossible d’évaluer la charge de travail correctement. Ça va peut-être prendre 3 jours, peut-être 3 semaines…
  • Et quand on ne voit pas le bout d’un projet, on se démotive rapidement.

Comment découper

Si tout le monde s’accorde habituellement sur la nécessité de découper ses tâches, on ne sait pas toujours comment s’y prendre. Ce n’est pourtant que du bon sens :

Continuer la lecture de « Découper les tâches comme un gnome »

Communication et productivité : synonymes ou antonymes ?

Je suis assez étonné et amusé de remarquer qu’il existe des « courants de pensée » assez contradictoires concernant les méthodes à employer pour maximiser sa productivité personnelle. Certaines solutions proposées sont un peu extrêmes dans leur propos et revendiquent leur manque de nuance. Qu’elles soient le résultat d’une démarche personnelle et la dernière méthode à la mode, il semblerait que leur adoption doit être obligatoirement sans demi-mesure…

La sur-communication

Je vais commencer par vous parler de ce qu’on appelle l’«Entreprise 2.0». Derrière ce terme un peu brumeux (et repompé du «Web 2.0») se cache un ensemble de pratiques qui ont pour but d’amener les plate-formes de travail en entreprise vers des pratiques plus participatives, plus “organiques” − quoi que cela veuille dire.

Si on regarde bien, cette démarche a été entamée il y a un bon nombre d’années déjà, lorsque les entreprises ont commencé à migrer leurs gestions documentaires simplistes (partage de documents en réseau) ou difficiles d’accès (GED de premières générations) par des intranets intégrant wikis, blogs et bookmarks partagés. Et il faut bien avouer qu’en procédant ainsi, l’accès à l’information est devenu plus facile et leur mise à jour est plus fréquente.
Rapprocher l’information de ceux qui en ont besoin, tout en leur permettant de la modifier facilement, permet de rendre celle-ci moins « monolithique ».

C’est un bon exemple de cas où ce sont les outils qui ont amené un changement d’utilisation en douceur, ce qui n’aurait pu être fait par un changement d’organisation et de process.

Certains partisans de l’«Entreprise 2.0» veulent pousser ce concept beaucoup plus loin. Pour faire simple, Facebook et Twitter sont des outils super géniaux (et surtout particulièrement à la mode en ce moment), il faut à tout prix généraliser et codifier leur utilisation. Ils théorisent donc sur le fait que la prochaine étape est d’avoir des collaborateurs qui communiquent de manière proactive, informent leurs collègues de ce qu’ils font et à quoi ils réfléchissent, en utilisant des canaux de micro-information propres à l’entreprise.

La sous-communication

A contrario, un bon nombre de méthodes d’organisation personnelle obligent à fermer les vannes de l’information entrantes. Qu’il s’agisse du téléphone (toujours laisser le répondeur gérer les appels), des emails (à ne lire qu’une à deux fois par jour) ou des réunions (à éviter comme la peste), l’idée est la même : Ce sont des sources de distraction qui empêchent de se concentrer sur les tâches qui réclament notre attention. Éliminer les sources de distraction permet donc, par un effet mécanique, de consacrer plus de temps à faire du travail « utile », et donc de devenir plus productif.

Continuer la lecture de « Communication et productivité : synonymes ou antonymes ? »

Pas de productivité miracle

Il existe un grand nombre de soit-disant « méthodes », qui sont censées nous enseigner tout ce que nous avons besoin de savoir pour augmenter notre productivité de manière incroyable. Qu’ils s’agisse de livres ou de sites web, vous les trouverez sous des noms plus tentants les uns que les autres : « 101 trucs pour booster votre productivité« , « Travaillez à 400%« , « Soyez 10 fois plus productif« .

Évidemment, il existe des vraies méthodes d’organisation personnelle qui permettent d’augmenter notre efficacité et donc notre productivité, comme la très connue méthode GTD.

Il faut comprendre la différence entre ces deux approches.
Les méthodes d’organisation personnelle offrent des outils qui aident à faire les bons choix dans le traitement des tâches qui nous incombent. Elles se focalisent principalement sur la définition et l’identification des priorités, et le tri rapide des tâches. Leur efficacité est réelle, même si elle est inversement proportionnelle à l’organisation « naturelle » de la personne qui en applique les principes.

A contrario, les méthodes de « productivité miracle » font miroiter la possibilité de traiter plus de tâches sur la même période de temps.
Cela peut être atteint en agissant sur deux fronts : traiter les tâches plus rapidement, et réduire les périodes non consacrées au travail directement productif. C’est très honorable, et au final assez naturel quand on essaye d’optimiser notre productivité. Mais espérer multiplier sa productivité par 3, 4 ou 10, semble plutôt naïf.

  • La plupart du temps, quand on traite une tâche on le fait avec une efficacité relativement satisfaisante. Même s’il est toujours possible d’améliorer les choses (par exemple en supprimant les éléments perturbateurs, afin d’améliorer la concentration), il est souvent vain de vouloir traiter une tâche deux fois plus vite que d’habitude. On est surtout sûr de la traiter deux fois moins bien.
  • Réduire le temps non productif est une très bonne idée. Une partie de ce temps est nécessaire et relativement incompressible : tout le temps qu’on passe en formation (à en donner et à en recevoir), à réfléchir à des spécifications, à encadrer son équipe, …
  • Reste le temps pendant lequel on se gratte la tête, on joue avec des trombones, on touille son café, on va lire le journal au toilettes… Hum. Même en imaginant que vous perdiez ainsi 2 heures par jour (grosse feignasse !), et en espérant diviser ce temps par trois − ce qui constitue déjà un bonne optimisation − vous ne gagnerez que 40 minutes par jour. On est loin de la productivité décuplée !

Donc oubliez les solutions miracles. Faites votre boulot posément et dans le bon ordre. Identifiez les urgences. Déléguez.

Simple GTD

Je vous ai déjà fait une introduction à la méthode GTD (Getting Things Done) de David Allen. C’est une méthode d’organisation personnelle très efficace, mais qui réclame une discipline et une rigueur constantes, qui peuvent être usantes à la longue.

Je suis tombé il y a quelques temps sur un article très intéressant du site WebWorkerDaily, qui présente une alternative simplifiée. Cette alternative ne concerne que la partie de « tri » des tâches. Il semblerait qu’elle soit extraite du livre Les 7 habitudes de ceux qui réalisent tout ce qu’ils entreprennent de Stephen R. Covey.

Le tri de tâches GTD

Souvenez-vous, voici les étapes imposées par le GTD, pour trier les informations entrantes (et j’ai déjà pas mal simplifié les choses) : Getting Things Done - déroulement

Le tri de tâches simplifié

Maintenant, l’alternative évoquée sur WebWorkerDaily propose de trier les tâches suivant 4 possibilités simples :

  • UI : Urgent – Important
  • NUI : Non Urgent – Important
  • UNI : Urgent – Non Important
  • NUNI : Non Urgent – Non Important

Continuer la lecture de « Simple GTD »

La refactorisation

La refactorisation est un exercice qui devrait être maîtrisé par tous les développeurs, encadré par tous les chefs de projets et encouragé par tous les directeurs techniques.

Le refactoring, qu’est-ce que c’est ?

Derrière cet affreux anglicisme se cache le fait de réécrire du code qui a déjà été développé. Le but n’est donc pas d’ajouter de nouvelles fonctionnalités, mais plutôt d’assurer un suivi de l’existant, de faire un ménage qui en facilitera la maintenance.

Nous nous sommes tous retrouvés un jour ou l’autre devant des bouts de code sans queue ni tête, manifestement écrits à la va-vite, ne respectant aucune norme, avec une documentation périmée, sans commentaire, ou truffés de code mort. À chaque fois, nous sommes horrifiés. Dans le meilleur des cas, on se souvient des raisons historiques qui ont conduit à cela (« Ah oui, ça date du projet X, qu’on avait dû faire à toute vitesse il y a 2 ans ») ; dans le pire des cas, on va retrouver le responsable de cette horreur pour lui passer un savon.

Mais la bonne attitude, c’est d’organiser l’amélioration de ce code. Il faut garder en tête qu’on ne travaille pas continuellement sur les mêmes fichiers. Ce qu’on est en train de développer un jour sera utilisé pendant des mois voire des années sans qu’on revienne dessus. Mais au fil du temps, le code ancien devient « friable » : chaque correction de bug devient plus délicate et sujette aux bugs de régression ; chaque ajout de fonctionnalité prend de plus en plus de temps et devient plus difficile.

Je vais faire un parallèle avec la construction immobilière. Quand on construit une maison, on commence par faire les fondations, puis on monte les murs extérieurs, puis le toit et enfin les cloisons intérieures. Quand on développe un logiciel, c’est un peu la même chose ; chaque développement, chaque ajout de fonctionnalité, s’appuie sur des objets ou des librairies qui doivent rester fiables dans le temps. Il faut donc pouvoir revenir à tout moment sur n’importe quel bout de code, accéder à sa documentation, lui ajouter de nouvelles capacités, voire résoudre des bugs qui ne s’étaient encore jamais déclarés.
Parce que le jour où vous faites tomber des cloisons, vous ne devez pas devoir refaire les murs extérieurs ; et si vous ajoutez une étage à votre maison, vous devez pouvoir faire confiance à la chape de béton de vos fondations.

Comment s’y prendre

On peut découper un refactoring en 4 étapes précises. Les trois premières sont importantes et nécessaires, alors que la dernière est à mettre en oeuvre si le besoin s’en fait sentir uniquement.

Continuer la lecture de « La refactorisation »

L’estimation du travail

Quand on veut planifier son travail ou celui de son équipe, il faut obligatoirement commencer par faire une estimation du temps nécessaire pour réaliser chacune des tâches qui sont listées. Et c’est souvent un casse-tête, car on ne sait jamais par quel bout s’y prendre.

Nous allons voir les raisons qui doivent vous pousser à réaliser des estimations, les réactions les plus récurrentes, et les pistes à suivre pour y arriver.

À noter : J’avais commencé à écrire ce texte au sein d’un article consacré à la planification et aux approches top-down et bottom-up. Mais un article présent dans le dernier numéro du magazine PHP Architect (très bon magazine canadien, en anglais) m’a convaincu d’y consacrer un billet à part entière. Le sujet est intéressant.

Les motivations

On peut voir plusieurs aspects qui conduisent à la nécessité d’estimer préalablement la durée d’une tâche ou d’un projet :

Continuer la lecture de « L’estimation du travail »