Fix it ! chez Ostorlab

La pratique Fix it! d'Ostorlab est l'une de nos pratiques d'ingénierie les plus réussies. C'est un événement sous forme de compétition, qui dure une à deux semaines, où les membres de l'équipe s'affrontent pour corriger le plus grand nombre de bugs possible.

Si la participation à Fix it! est généralement facultative, chez Ostorlab nous veillons à ce que toute l'équipe y participe. Cela montre notre engagement à travailler en équipe et à faire en sorte que notre travail soit le moins bogué possible.

Pour mieux expliquer pourquoi nous utilisons cette pratique : chez Ostorlab, nous fonctionnons généralement en mode projet, en formant des squads de 2 à 8 personnes pour travailler sur des fonctionnalités, des corrections de bugs majeures ou la suppression de dette technique. Les bugs et problèmes à fort impact sont en général traités immédiatement, mais beaucoup de petites irritations n'arrivent jamais en haut de la liste des priorités. Fix it! aide à y remédier en étiquetant fixit! tous les problèmes qui ne justifient pas une correction immédiate.

Si vous souhaitez appliquer le même concept dans votre équipe, voici quelques enseignements tirés de notre expérience :

• Durée : la durée de Fix it! a varié d'une à deux semaines ; des périodes plus longues deviennent trop pesantes, et une semaine est trop courte. Corriger des bugs peut être éprouvant pour les nerfs, il est donc crucial de prévoir un temps raisonnable.

• Suivi : pendant l'événement, nous utilisons en outre une plateforme interne pour suivre les corrections et afficher un classement qui montre la progression au fil du temps, ce qui rend l'exercice amusant et pousse chacun à donner le meilleur de lui-même.

• Système de points : il est important de traiter tous les bugs de la même manière et d'éviter de créer un système de points pour les bugs. Cela évite les discussions sur le fait que certains bugs vaudraient plus ou moins que d'autres et garde les choses simples. En conséquence, les bugs faciles sont généralement éliminés en premier, et il ne reste que les plus difficiles vers la fin. Pendant Fix it!, de nouveaux bugs peuvent être découverts avant ou pendant la correction. Par exemple, lors de notre dernier Fix it!, nous avons commencé avec 161 bugs, en avons éliminé 142 et il nous en restait 132. Même si le calcul ne tombe pas juste, cela nous aide à tester la plateforme de façon exhaustive et à repérer des bizarreries d'utilisabilité que nous pouvons traiter en corrigeant les bugs.

• Revue de code : comme le système d'incitation de Fix it, qui vise à corriger le plus de bugs possible, relègue souvent la qualité du code au second plan, il est crucial de disposer d'un pipeline CI/CD solide, avec linting, vérification des types, couverture de tests unitaires et un processus de revue de code rigoureux, pour éviter d'introduire plus de bugs que l'on n'en corrige.

• Week-end : si Fix it! dure plus d'une semaine, nous veillons à ce qu'il n'y ait aucune correction pendant le week-end. Cela garantit que tout le monde est sur la même longueur d'onde et peut profiter de son temps personnel sans se sentir obligé de travailler.

• Clôture : à la fin de Fix it!, nous partageons les résultats et discutons des moyens de l'améliorer encore. Nous mettons aussi en avant quelques aspects intéressants, comme le bug le plus cool à corriger ou celui qui s'est révélé étonnamment difficile. Nous partageons également les enseignements tirés, qui orientent nos futures décisions sur la pile technique ou la conception des systèmes. En partageant nos expériences, nous pouvons identifier les points où améliorer nos processus et éviter des problèmes similaires à l'avenir. Cela nous aide à améliorer en continu la qualité de notre travail et à rendre nos systèmes plus robustes et plus fiables.