Guide pratique
Pomodoro pour développeur : coder sans casser le contexte
Le développement supporte mal les coupures arbitraires. Le timer devient utile quand il encadre une unité de code et impose une note de reprise avant la pause.
La réponse courte
Travaillez 40 à 50 minutes sur un résultat testable, puis réservez cinq à dix minutes à la récupération. Ne coupez pas une opération risquée au milieu : terminez un point sûr et notez l’état exact.
Définir un incrément testable
« Implémenter l’authentification » est trop large. « Ajouter le test d’échec pour un jeton expiré » tient dans un bloc et donne un signal clair. Préparez le dépôt, la branche et les logs avant de lancer le timer.
Debug : conserver la piste
À la sonnerie, écrivez l’hypothèse actuelle, la dernière observation et la prochaine expérience. Cette trace évite de reconstruire le raisonnement après la pause. Si une commande longue tourne, la pause peut commencer sans modifier l’état.
Pair programming synchronisé
Le driver et le navigator partagent le timer mais peuvent changer de rôle à chaque pause. Pendant le bloc, le navigator garde une liste de questions au lieu d’ouvrir une discussion latérale. La pause sert à décider le prochain test et, si nécessaire, à inverser les rôles.
Protéger les revues de code
Une revue gagne à être limitée à un objectif : exactitude, sécurité ou lisibilité. Regrouper toutes les dimensions dans un seul bloc favorise les commentaires superficiels. Coffee Focus peut synchroniser le rythme d’un binôme, mais ne remplace ni les tests ni la discussion technique.
Sources et travaux cités
- Leroy (2009), Why Is It So Hard to Do My Work?
- Ariga & Lleras (2011), Brief and rare mental breaks keep you focused
Ces sources étayent uniquement les mécanismes précis discutés plus haut. Leurs méthodes, populations et limites ne permettent pas d’affirmer qu’un même rythme convient à tout le monde.