Faciliter la reprise d'un travail

J'ai lu dans Bird by bird un conseil qui à l'époque s'était logé quelque part dans la pile des "bonnes idées à appliquer" : pour un auteur, il est plus facile de se remettre à écrire s'il s'est arrêté en plein milieu d'un paragraphe, d'un chapitre, plutôt que s'il doit commencer une partie toute nouvelle de son travail.

Effectivement, se relancer dans un cycle de travail n'est pas toujours facile, et pouvoir simplement poursuivre la phrase laissée en suspends permet de faire le premier pas, ce si difficile premier pas qui me retient souvent de commencer quelque chose. Les suivants sont plus faciles à faire, même s'ils doivent reprendre le travail du premier (on tombe alors sur un autre conseil du même livre : accepter les brouillons de merde, le premier jet qui devra être jeté, mais qui aura lancé la machine).

En code c'est pareil : si je laisse un test unitaire cassé, la première chose que je vais faire en reprenant mon travail va être de le corriger. Pour un projet partagé un test cassé est une mauvaise pratique, et dans ce cas j'utilise la possibilité de marquer le test comme incomplet. Cela ne bloque pas mes collègues mais permet de créer un point de démarrage.
Une autre pratique aide bien, trouvée dans TDD By Example : faire une liste des choses à faire pour un projet. Noter au fur et à mesure tout ce qui nous vient à l'esprit, pour continuer sur la tâche en cours sans l'interrompre et sans rien oublier. Cette liste offre une première action à faire, rappelle sur quoi précisément nous nous sommes arrêté la dernière fois.
On peut aussi penser aux TODO notés en commentaires, et que les IDE modernes nous listent aisément, mais je préfère les réserver aux petites choses à revoir et faire des sessions de chasse aux TODO.

C'est pour moi une manière d'établir une continuité d'une session à l'autre, une sorte de flow à l'échelle de la semaine.