Entretien entre César Mourot et Rui Carvalho

 

Entretien retranscrit avec Rui Carvalho sur ses expériences et son savoir faire autour du Craft. 

Vous pouvez retrouver l’intégralité du podcast sur notre soundcloud.

 

César : Bonjour, ravi de pouvoir échanger avec toi. On s’était rencontrés il y a quelques années au sein de la fameuse conférence NCrafts que les gens connaissent autour de toutes les bonnes pratiques de développement. Tout d’abord, je te propose de te présenter puis de nous expliquer de quelles manières tu as découvert l’agilité, les bonnes pratiques et qu’elle était ton approche à cela ?

Rui Carvalho : Bonjour César, je m’appelle Rui Carvalho et je suis développeur. Avant toute chose, j’ai vingt et quelques années de carrière derrière moi, avec à peu près tous les métiers que l’on peut imaginer dans le développement. Notamment dans les bases de données, en commençant à développer professionnellement vers 1998, à l’époque où j’étais encore étudiant. Ce job était idéal avec mes heures de cours et j’y ai développé mon premier site web marchand. Tout en sachant que je n’avais pas fait d’étude d’informatique. À part ça, je suis quelqu’un de très impliqué dans les communautés. J’ai commencé à faire du développement open source depuis 12-15 ans, à une époque où cela était moins. J’écris également des articles depuis une vingtaine d’années. 

À une plus grande échelle, j’organise les conférences NewCrafts depuis 2014. Aujourd’hui, je continue dans le conseil, en accompagnant des gens à mieux développer de façon agile tout en continuant à gérer des infrastructures, des services. Je suis aussi professeur dans une école d’ingénieur depuis 2011. Je peux ainsi transmettre les questions qui m’ont fait connaître l’agilité, comme « Pourquoi est-ce que je suis en train de faire ça ? Comment est-ce que je vais le faire ? ». En se replaçant dans la norme de l’époque, celle du développement logiciel du début des années 2000 du plus classique qui soit, il n’y a pas vraiment de culture de test en dehors des tests manuels, etc.

Aussi, il n’y avait pas cette culture que tu peux avoir aujourd’hui. On est beaucoup plus informé et avertis des bonnes pratiques grâce à Internet et aux livres. La plupart des gens en entreprise n’en n’ont pas forcément conscience. Ce ne sont pas des choses communes et finalement, la première chose sur laquelle je suis tombé, c’est le TDD. Ça m’a tout de suite intéressé. Mais quand tu es tout seul, il n’y a pas forcément de lieu d’échange en ligne, de lieu de rencontre physique. Pas comme on pourrait en avoir avec les meetups, ou encore de documentation assez fiable et abondante.

Cela m’a donc pris des années pour essayer de voir ce que je pouvais en faire réellement. Il faut trouver un cycle de développement autour de ça, de ses bénéfices. Et aussi comprendre l’impact que cela pouvait aussi avoir dans ma manière de travailler autour de moi. J’ai commencé à introduire des manières de développer plus orientées, où j’essayais de raccourcir mes boucles de feedback. De voir si j’allais dans la bonne direction, si j’apprenais sur ce que j’avais envie de faire, etc.

César : On est presque sur de la recherche. Et cela me fait penser à une contre-culture subversive qui apparaîtrait sans vraiment aucun moyen de communication autour, où tu vas te forger ton propre avis, mais sans être vraiment capable de pouvoir le confronter. Mais puisque tu as connu toute l’évolution de celle-ci, comment est-ce que tu la vois aujourd’hui. Comment est-ce que cela s’implémente à l’échelle d’une entreprise ?

Rui Carvalho : Le sens premier de XP était de faciliter le dialogue avec le client. C’était en améliorant le feedback et en essayant d’implémenter des choses. Néanmoins, l’extreme programming est quelque chose de très difficile à implémente. Cela demande une certaine rigueur et les contraintes que ça impose sont à la fois difficile pour les développeurs, pour le management et pour les clients. À un même moment arrive tout un tas de méthodes à tendance agiles, dont Scrum. (Qui est d’ailleurs basé sur l’équipe et sur les flux de travail, mais principalement les 4 valeurs du Manifeste Agile. Il a été créé par un groupe de 17 personnes au fin fond de la montagne en 2001.) 

C’est le point de départ. On se rend alors compte que Scrum, au détriment d’XP, est capable de s’adresser au management, aux personnes. Il permet d’organiser les équipes, alors qu’il voulait de base « implémenter correctement XP en entreprise ». Toutes les bonnes pratiques techniques qui dérivent d’XP sont fondamentales. Elles sont basées sur des valeurs qui se focalisent sur cette notion d’excellence technique et de boucle de feedbacks. Si les gens sont bien organisés entre eux, qu’ils arrivent à bien travailler ensemble, ils arriveront à faire du travail de qualité. Ils arriveront à sortir des produits de qualité et dans des délais corrects.

César : Mais justement, est-ce que tu penses que ce n’est pas déjà là un peu, la dérive de Scrum ? Aujourd’hui, il est quand même décrié par sa position de passerelle entre XP et les entreprises. Il a fluidifié les échanges des équipes et implanté XP. Est-ce que c’est un échec de Scrum dans l’implémentation d’XP ou simplement un usage qui a été détourné selon toi ? Aussi, comment est-ce que tu accompagnes et éduque les entreprises dans ce changement ?

Rui Carvalho : Pour revenir à ta première question, c’est un usage qui a été détourné. Les fondamentaux d’XP ne sont pas forcément mauvais. Si tu prends n’importe laquelle de ces pratiques comme une recette de cuisine, elle va échouer. Les personnes ne comprendront pas la philosophie derrière. Ils seront forcées à écrire du code en test first ou à faire du Pair Programming sans comprendre pourquoi. C’est extrêmement complexe de faire de l’agilité à l’échelle. N’importe quelle personne qui essaie de te vendre une solution miracle qui dit le contraire et est grosso modo un menteur.

En appliquant cette méthode aux entreprises, on augmente sa taille. Et donc sa complexité. Tu fais appel à un ensemble de points différents et indépendants. Si tu prends le problème dans son ensemble, le niveau de complexité est énorme et il faudra agir localement. Alors, on a deux approches : le bottom-up et le top-down. La première consiste à améliorer le développement local d’une équipe puis de faire monter les méthodes agiles jusqu’à la direction, et l’autre consiste à partir d’une direction qui est convaincue par l’agile et qui souhaite l’implanter dans son équipe.

Sauf que dans les deux cas, cela se passe mal. Il arrivera forcément un moment où tu seras confronté au middle management. Soit il ne verra pas la transformation et ne sera pas convaincu ; soit il verra au contraire l’indépendance grandissante de son équipe et qui sera réticent à l’idée de perdre de l’influence. Dans les deux cas, la transmission de l’agilité s’arrête. Avec le principe du Waterfall, le cycle en V et le triangle Budget, Temps et Scope, tu as deux données fixes : le temps et le scope. Seul le budget est variable, c’est-à-dire le nombre de personnes investies dans le projet. Sauf que les équipes sont généralement déjà prêtes et très peu modifiables. Alors qu’avec l’agile, on se focalise bien plus sur le Scope pour faire au mieux, en étant transparent et ouvert dans les discussions sur les problèmes rencontrés.

César : Donc, le fait d’avoir une équipe qui est centrée autour d’un projet commun, c’est de pouvoir ensuite regrouper des gens fonctionnels autour de la technique des développeurs et de cette problématique pour qu’ils réfléchissent ensemble aux solutions, c’est ça ?

Rui Carvalho : Oui, c’est vraiment un point essentiel. Si tu n’as pas de notion de produit, tu n’as aucune raison de faire de la qualité, même en ayant des gens techniques, mais avec une vision différente de la qualité et de la façon d’y arriver. Ce que l’on constate dorénavant, c’est que si tu n’as pas un but commun ni de responsabilité et de propriété collective, il n’y aura pas de qualité, mais plutôt une perte de temps, une confusion entre les équipes et un fond instable. Il faut se dire « Je suis responsable de ce code, je veux qu’ils rendent le service pour lequel il est censé fonctionner ». 

J’essaie de transmettre cette idée-là à mes étudiants. Mais aussi, le fait de savoir qu’ils ne savent pas, et par extension qu’ils ne peuvent pas commencer à avoir envie d’apprendre sans s’en rendre compte. La plupart des étudiants que j’ai croisés sont quand même relativement humbles par rapport à leur situation et savent qu’il y a tout un monde qu’ils ne connaissent pas et ils écoutent ce que va leur dire le monde du travail. À l’école, on leur apprend à faire plein de projets simples sans approfondir, ils ont un grand éventail, mais aucune réelle spécialisation et donc aucune envie de qualité dans un domaine spécifique.

César : Qu’est-ce que tu recommanderais à des jeunes développeurs ou développeuses, ou, au-delà des communautés, des livres qui, pour toi, sont des références ?

Rui Carvalho : Déjà, de se demander « Qu’est-ce que j’essaie d’apprendre ? De quelle manière et pour quelle finalité ? Aussi, j’ai plein de gens à plus ou moins conseiller. Kent Beck pour la base, avec cette phrase qui disait « Je ne suis pas un développeur exceptionnel, j’ai juste des habitudes exceptionnelles », pour éviter la médiocrité, d’être conscient de ses limites et de trouver des manières de les outrepasser. Uncle Bob aussi, pour sa vulgarisation et ses conférences, et le livre de Nathan Ensmenger « The Computer Boys ».

Enfin, une dernière personne dont je suis absolument fan, c’est Victor Bret. il a beaucoup travaillé sur cette notion de feedback loop et de développement temps réel, et pour le graphisme : tu définis tes paramètres, tu peux les modifier graphiquement et voir l’impact que cela a sur le reste du code. Et je trouve que c’est une approche extrêmement importante pour essayer de comprendre justement l’importance de raccourcir ses boucles de feedback et de comprendre ce qu’on est en train de faire.

César : Un grand merci à toi d’avoir participé à ce podcast. Je rappelle que l’on peut te retrouver sur LinkedIn et Twitter. Merci beaucoup et à très bientôt.

Rui Carvalho : Merci à toi de m’avoir reçu, en tout cas, et bonne journée.

Bibliographie :

    • Kent Beck : “Test Driven Development”, “Extreme Programming Explained”, “Implementation Patterns”
    • Uncle Bob / Robert Cecil Martin : “Coder Proprement“, “The Clean Coder : A Code of Conduct for Profesionnal Programmers”, “Clean Agile : back to basics”
      • https://www.amazon.fr/s?i=english-books&rh=p_27%3ARobert+Martin&s=relevancerank&text=Robert+Martin&ref=dp_byline_sr_book_1
    • Nathan Ensmenger : “The computer Boys Take Over”, “Computer : A History of the Information Machine”
      • https://www.amazon.fr/Computer-Boys-Take-Over-Programmers/dp/B00LXMNKCE/ref=sr_1_3?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=nathan+ensmenger&qid=1637314792&s=books&sr=1-3

Vous aimerez aussi...

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.