Sur cette page
Quatre produits en plus du travail pour des clients, cela ressemble à une recette pour le chaos. Ce qui rend la chose tenable n’est pas l’héroïsme, mais un emploi du temps hebdomadaire ennuyeux que nous respectons presque toujours.
La forme de la semaine
Lundi : support et tri
Toutes les boîtes de réception sont vidées en premier. Les rapports de bugs sont reproduits, étiquetés, puis corrigés le jour même ou planifiés. Commencer par les utilisateurs garde le reste de la semaine honnête sur ce qui compte.
Mardi et mercredi : construire
Deux jours sans interruption sur un seul produit à la fois. Les notifications sont coupées et aucune réunion n’est planifiée. L’essentiel du vrai travail sur les fonctionnalités se fait ici.
Jeudi : relecture et préparation
Revue de code, tests et notes de version. Les versions sont préparées le jeudi mais pas livrées le jeudi après-midi.
Vendredi : écriture et planification
Documentation, articles de blog, journaux des modifications et plan de la semaine suivante. Écrire nous oblige à expliquer ce que nous avons construit, et l’explication révèle souvent ce que nous avons raté.
Pourquoi rien n’est livré le jeudi après-midi
Si quelque chose casse, une version livrée le jeudi après-midi est corrigée la nuit ou reste cassée jusqu’au week-end. Nous livrons le mardi ou le mercredi matin, quand il y a du temps pour surveiller et revenir en arrière.
Un produit par bloc
Plutôt que de toucher aux quatre produits chaque jour, chaque bloc de travail appartient à un seul produit. Le coût du passage d’une base de code à l’autre est surtout celui de recharger le contexte, donc nous évitons de le faire plus d’une fois par jour.
Ce qui ne rentre pas
Les incidents ignorent l’emploi du temps. Quand quelque chose est en panne, tout le reste s’arrête. Nous gardons de la marge dans le plan en ne nous engageant que sur environ les trois quarts du temps disponible.
Ce que nous changerions
L’emploi du temps ne fonctionne que si chaque bloc reste protégé, et la connaissance peut encore s’accumuler autour de la personne qui a construit une fonctionnalité. Une partie du plan de cette année consiste à produire une documentation assez bonne pour que n’importe quel ingénieur puisse reprendre n’importe lequel des quatre produits.
Essayez par vous-même
Vous n’avez pas besoin de quatre produits pour que tout cela vous soit utile. Choisissez un jour pour le support, un jour pour l’écriture et un jour où vous ne déployez jamais, puis observez ce qui change.
Cet article vous a été utile ? Partagez-le avec votre équipe.
Partager sur LinkedIn
