Julien Libert
Développeur Web depuis plus de 15 ans, j’aime coder, gérer des équipes et faire en sorte de garder une bonne cohérence dans mon code et une architecture de projet élaborée. Je passe la majorité de mon quotidien à jongler entre du Laravel, du VueJS, mais aussi de bons gros morceaux de code legacy (PHP, jQuery…). Après une formation en informatique générale, c’est toujours le web et ses technos qui m’ont attirées. La véritable révélation s'est faite avec l’arrivée des frameworks (CSS, PHP, JS) qui ont commencé à structurer et donner des lignes directrices pour des projets plus ou moins complexes. Malgré les reproches qu’on peut parfois leur faire, ils permettent aux équipes de développement d’accélérer la production, d’éviter la redite de tâches laborieuses et ainsi se concentrer sur du code à forte valeur ajoutée pour les utilisateurs. Actuellement Lead développeur chez Evoliz, j'ai dû aborder un framework dans un autre domaine : l’agilité dans la réalisation de projets, avec SCRUM. Notre philosophie : on essaie, on échoue, on améliore, on réussit, on améliore encore… Après 6 ans à leurs côtés, je me dis qu’on a tenté pas mal de choses, réussi sur certaines, échoué sur d’autres, et surtout acquis une modeste expérience sur divers sujets. C’est donc tout naturellement que me vient l’envie de partager tout cela avec d’autres.
format_quote
Ce talk est la juste représentation d'un pari réussi !
Je suis lead d'une équipe de développeurs depuis environ 4 ans et l'entreprise dans laquelle j'évolue connaît aujourd'hui une forte croissance. Les besoins de structuration, d’harmonisation et de partage du savoir sont devenus un enjeu majeur pour l'ensemble des départements.
Dans un flux qualité plutôt classique (gitflow, validation par revue de code, fusion des branches…) et relativement efficace, quelques lacunes ont commencé à émerger, notamment avec la multiplication des développeurs : merge conflicts entre développeurs sur la même fonctionnalité, goulot d’étranglement sur la validation des pull requests, allers/retours entre différentes branche pour les développeurs avant validation du code, code approuvé mais qui ne répond pas à la demande initiale…
Après avoir assisté à une conférence sur le Mob Programming, ma manière de voir les choses a changé et laissé place à la volonté d'oser une nouvelle méthode. Mais cette méthode ne semble pas sans risque : 3 ou 4 personnes derrière un seul clavier, la productivité risque de chuter…
Aujourd’hui après un an d’adoption, le mob est initié sur plusieurs projets, dans différents contextes. De la mise en place aux ressentis des équipes de développeurs, j'explique ici ce que nous retirons de notre expérience, quels sont les points faibles et quelles ont été les surprises rencontrées au fil de cette aventure.
format_quote