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…
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.…
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.…
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…
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 :
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.
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…
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) : 
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
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.
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 :