Le crafts dans tous ses états – Avec Rui Carvalho (Retranscription)
C – Eh bien Rui, bonjour, ravi de pouvoir échanger avec toi. On s’était rencontrés il y a quelques années au Ncrafts à la fameuse conférence que les gens connaissent autour de toutes les bonnes pratiques de développement. Je te propose de te présenter.
R : – Bonjour César, je m’appelle Rui Carvalho, je suis développeur avant toute chose, j’ai environ vingt années de carrière derrière moi. J’ai commencé à développer professionnellement en 1998, j’étais encore étudiant. J’ai fait plusieurs choses, à peu près tous les métiers qu’on peut imaginer dans le développement. Je continue aujourd’hui mais plus pour conseiller, disons que j’accompagne des gens à mieux développer. Je continue à faire quelques petites choses en parallèle où je continue à gérer des infrastructures, des services et faire un peu de développement. Mais surtout aujourd’hui, j’accompagne des équipes pour travailler de manière un petit peu plus agile.
A part ça, je suis quelqu’un de très impliqué dans les communautés, j’ai commencé à faire du développement Open Source en .Net depuis presque une quinzaine d’années (une époque où c’était moins commun dans l’écosystème dot net). J’écris des articles depuis une vingtaine d’années, je m’occupe du meetup Alt.Net depuis une dizaine d’années, qui est évidemment un petit peu en sommeil en ce moment…mais voilà la communauté existe et au moins en ce moment elle est vivante grâce à un Slack en ligne. Et puis, à plus large échelle, j’organise la conférence Newcrafts depuis 2014, qui, elle aussi, malheureusement est un petit peu en sommeil en ce moment dû à la situation actuelle.
C : – Eh bien écoute génial ! Ça me donne envie de te poser une première question : En étant dans le développement, comment as-tu découvert l’agilité ? Les bonnes pratiques ? Et quelle était un peu ton approche par rapport à ça au début ?
R : – Comme je t’ai dit, j’ai commencé à développer il y a un certain moment. Professionnellement, vers 1998, j’avais un boulot étudiant mais qui était pour le coup un vrai boulot de développement. C’était génial car je faisais ça 12 heures par semaine et donc des horaires parfaits pour un boulot étudiant. Et en fait, c’était une sorte de petite boutique du coin, où l’on faisait cybercafé, centre de formation et vente de matériel. Et j’ai développé mon premier site web marchand, vers 1998. Sachant que moi à la base je n’ai pas fait d’étude d’informatique, j’étais dans les télécoms. Donc je n’ai pas eu tout cet apprentissage qu’on peut avoir éventuellement en école. Je reviendrai dessus, d’ailleurs, un point que j’ai oublié de dire : Je suis prof aussi en école d’ingénieur de bonnes pratiques depuis 2011.
Justement, j’essaie de partager un petit peu cette vision Craft dans les écoles qui en manquent un petit peu. Mais tout ça pour dire que je me suis mis au développement un petit peu sur le tas. Et du coup quand je suis arrivé après en entreprise, j‘avais une certaine vision du développement que je m’étais forgé un peu tout seul et je me suis confronté à une culture d’entreprise différente. Je ne sais pas si c’est le fait de ne pas avoir été guidé par un certain formalisme, tout ça combiné avec certainement un syndrome de l’imposteur (parce que justement je n’avais pas fait le parcours classique), ce qui m’a amené rapidement à me poser un certain nombre de questions. En me disant : « Il y a des choses qui ont l’air de ne pas bien fonctionner, il manque de quelque chose de plus concret. » Quand je fabrique quelque chose, j’ai besoin de savoir ce que je suis en train de fabriquer. Je me pose des questions, comme : « Pourquoi suis-je en train de faire ça ? Comment vais-je le faire ? Vais-je y arriver ? Et comment ? »
C : – Tu veux dire, par rapport à un feedback que tu n’aurais pas nécessairement au moment où tu le fais ?
R : C’est ça, c’est-à-dire qu’on se replace dans le développement logiciel du début des années 2000. La norme finalement c’est du Cycle en V, du Waterfall du plus classique qui soit. Il n’y a pas vraiment de culture de test en dehors des tests manuels. Après l’échelle est plus ou moins grande en fonction du type d’entreprise ou du type de projet dans lequel tu te trouves. Mais la norme c’est vraiment ‘tiens quelqu’un de vachement plus intelligent que toi a été discuter avec le client et a écrit ce Cahier de Spec de 300 pages’. Maintenant tu essaies de lire ça, tu essaies de comprendre ça et tu développes tout ce qui va bien derrière et si ça ne va pas c’est parce que tu as mal implémenté, ce n’est pas parce que le mec était à côté de ses pompes quand il a écrit le document. Et à ce moment-là tu te dis… « Je ne comprends pas, quand j’ai cet énorme document de Spec, je n’arrive pas à me projeter… » Et là tu commences à sentir qu’il y a des choses qui ne vont pas. Mais bon c’est la norme en fait, c’est comme ça que tout le monde travaille.
C : – Tu n’es pas à l’aise avec le fait de le faire, en te disant ‘ça grippe un peu dans le rouage’ mais tu n’as pas forcément de solution ou d’idées à l’époque pour pouvoir régler ça.
R : – C’est exactement ça ! Mais tu sens qu’il y a quelque chose qui ne va pas, tu n’es pas très à l’aise avec ça. Et à l’époque il n’y a pas cette culture que tu peux avoir aujourd’hui, c’est-à-dire que malgré le fait qu’aujourd’hui on soit beaucoup plus informés et avertis des bonnes pratiques, la plupart des gens en entreprise n’en ont pas forcément conscience. Mais, tu as l’information en ligne aujourd’hui, alors qu’à l’époque, on n’avait pas de site de référence, de bouquins de référence… Parce que, effectivement, à cette époque-là, ce n’est pas quelque chose de commun et ce n’est pas quelque chose que tu découvres. Même le terme d’agilité, ça ne vient pas faire écho à mes oreilles.
Finalement, le premier truc sur lequel je suis tombé, c’est le TDD vers 2004-2005, j’ai dû tomber par hasard sur les premières implémentations de NUnit et autres choses comme ça. Et là j’ai commencé à me dire, ‘tiens c’est rigolo ce truc là, ça à l’air vachement intéressant’. Mais encore une fois, quand tu es tout seul, isolé et que tu essayes de parler de ces choses-là autour de toi (seulement entre collègues, à l’époque il n’y avait pas forcément de lieux d’échange en ligne, de meetup…) donc tu essayes de sauter plus ou moins d’un article à un autre, d’essayer de creuser un peu cette information-là dans un internet naissant et dans des pratiques émergeantes. Et après, avec ce côté des pratiques complètement émergeantes, il n’y a rien de sûr, il n’y a pas forcément de propos très cohérents entre un article que tu lis à droite et un article que tu lis à gauche…
C – On est presque quasiment sûr de la recherche et ça fait penser presque à une contreculture subversive qui apparaitrait sans vraiment moyen de communication autour et donc tu es presque dans une recherche où tu vas au gré des articles, te forger ton propre avis mais sans vraiment être capable de pouvoir t’y confronter ?
R – C’est ça, oui. Enfin, je te donne ma perspective et de ce que moi j’ai ressenti à l’époque. Après avoir discuté avec d’autres personnes, je me suis rendu compte qu’il y avait des gens qui étaient, effectivement, vachement avancés sur le sujet à cette époque-là, mais il n’y avait pas cette culture qui était présente, ni les moyens de communication que l’on peut avoir aujourd’hui pour propager cette culture. Et donc, du coup, à cette époque-là, ça m’a pris des années et j’ai commencé vers 2004-2005 à m’intéresser au TDD. Ça m’a pris des années pour essayer de voir ce que je pouvais en faire réellement, de trouver un cycle de développement autour de ça, de voir les bénéfices que ça pouvait m’apporter, de comprendre en fait l’impact que ça pouvait aussi avoir dans ma manière de travailler. Je tirai un petit peu les ficelles au fur et à mesure, c’était aussi une époque où j’étais très spécialisé comme développeur de base de données. Là, tu vois c’est un monde qui est encore plus figé et qui encore aujourd’hui, on a du mal à sortir de ça. On était complètement guidé par des modèles statiques où la base de données était le cœur de tout et donc il fallait faire des designs sur le papier. Et là c’est pareil, j’ai commencé à introduire des manières de développer plus orientées où j’essayais de raccourcir les boucles de feedback parce que finalement, c’est toujours de ça dont on parle. Et j’essayais de voir ‘tiens est-ce que je suis toujours en train d’aller dans la bonne direction ? Est-ce que ce que je suis en train de faire m’apprend sur ce que j’ai envie de faire ?’ Et vers 2007, c’est là où j’ai commencé à écrire un petit peu plus et donc du coup à essayer de me poser quelques bases de réflexion personnelle. Finalement, il y a deux manières d’écrire des articles : soit tu compiles de l’information à droite à gauche et tu relais de l’information de manière à faire un maximum d’articles avec un maximum de besoin parce que ton objectif c’est de faire grossir une audience pas forcément sur des choses concrètes. Ou, soit tu te sers de cet article comme moyen de réfléchir sur un sujet et de creuser un petit peu plus un sujet. Et donc du coup c’est ce que j’ai essayé de faire et cela m’a amené à rencontrer d’autres personnes, c’était aussi le moment où Alt.Net commençait à émerger et donc ça s’est fait comme ça.
C – Comment vois-tu l’évolution de ce qu’on appelle l’agilité (qui était en fait effectivement une méthodologie mise en place au début par les développeurs pour les développeurs, on peut dire qu’il y a eu une OPA par les chefs de projets).
R – Il faut voir deux choses en fait, c’est-à-dire que tu dis effectivement que c’était par les développeurs pour les développeurs, c’était vraiment le sens premier du XP qui était effectivement : ‘Essayons encore une fois de raccourcir notre boucle de feedback, asseyons-nous directement avec le client et essayons d’implémenter les choses.’ Néanmoins, l’eXtrême Programing c’est quelque chose qui est très difficile d’implémenter parce que ça demande une certaine rigueur et les contraintes que ça impose sont à la fois difficiles pour les développeurs, pour le management et pour les clients. Là-dessus, il y a tout un tas de méthodes à tendance Agile, qui ne s’appellent pas encore Agile à ce moment-là mais Scrum arrive à peu près au même moment que XP mais avec une autre perspective, c’est-à-dire que Scrum est plus basé sur l’équipe et sur les flux de travail. Dans le milieu des années 90, il y avait d’autres méthodes alternatives aussi qui commençaient à émerger. Il y a tout un groupe de personnes qui gravitait autour de ça, qui, finalement ont décidé de se réunir pour essayer de faire quelque chose ensemble et c’est comme ça qu’ils se sont isolés dans un chalet au fin fond de la montagne en 2001. Ces 17 personnes ont réussi à se mettre d’accord à peu près sur 4 lignes. Ces 4 lignes correspondant aux valeurs du manifeste agile, qui sont fondamentales pour tout l’écosystème agile qui va émerger pendant les vingt premières années. Donc ça c’est le point de départ, et le point important, surtout, c’est que Scrum par rapport à XP est capable de s’adresser au management et donc il est capable de dire : ‘ok XP c’est très technique, c’est pour les devs, maintenant, Mr, Mme le management, prenez mon outil qui s’appelle Scrum et avec ça, il suffit d’organiser les équipes. Vous avez juste à appliquer ça et tout va bien se passer, vous allez être hyper agile’.
Et d’ailleurs je ne sais pas si tu as déjà remarqué mais si tu prends le premier vrai bouquin de Scrum qui a été écrit par Ken Schwaber (le Co-créateur de Scrum), dans la 4ème de couverture, il est clairement décrit que Scrum c’est une méthode pour réussir à implémenter correctement XP en entreprise. Mais du coup c’est très intéressant sur le mindset de départ, c’est que l’on reconnait que XP c’est quelque chose de très bien et les pratiques techniques qui dérivent de XP sont fondamentales.
C – Est-ce que peut-être tu peux en redire un mot parce que souvent la conception des gens par rapport à XP c’est le fait de faire du faire du Test-Driven-Development d’avoir des cycles itératifs très courts et beaucoup de pair programming. Est-ce que toi tu peux en dire un mot, et d’ailleurs je recommande souvent le bouquin « Joy-Inc. » de Richard Sheridan. Mais est-ce que tu peux en dire juste un mot pour que les gens aient ça en tête ?
R – Je ne vais pas rajouter grand-chose de plus mais c’est un ensemble de pratiques finalement et surtout de valeurs qui sont vraiment centrées sur cette notion d’excellence technique et de boucles de feedback courtes. En dérivant un petit peu là-dessus, il faut comprendre le pourquoi de chacune des méthodes et je ne sais pas si ça va répondre à ta question mais quand on parle de Scrum, l’objectif ce sont les gens donc on essaye d’optimiser le mode de travail des gens parce qu’on part du principe que s’ils sont bien organisés entre eux et qu’ils arrivent à bien travailler ensemble, ils arriveront à faire du travail de qualité et on arrivera à sortir des produits de qualité et dans des règles correctes.
C – Mais est-ce que ce n’est pas déjà là un petit peu la dérive de Scrum ? Car Scrum est malgré tout décrié du fait de cette reprise par les chefs de projets en se disant que c’était trop compliqué d’implémenter XP. On s’est servi de Scrum comme une passerelle pour permettre d’avoir plus de fluidité dans les échanges de l’équipe, et in fine intégrer les principes de XP. Aujourd’hui est-ce qu’on peut dire qu’une équipe qui échangerait mal et sur du faux Scrum est un échec de Scrum dans l’implémentation d’XP ou simplement c’est un usage qui a été détourné ?
R – Je pense que c’est un usage qui a été détourné, je m’orienterai plus là-dessus car au niveau des fondamentaux, ce n’est pas forcément mauvais c’est juste dire qu’il y a des philosophies différentes. Scrum est orienté gens, on essaye d’optimiser le travail des gens, le principe d’XP c’est de faire de la qualité dès le départ et on travaille comme si on mettait en production en continue avec des cycles de feedback courts en permanence. Si on a de la qualité à ce niveau-là, les gens vont être heureux et notre logiciel va être de bonne facture et après tu as quelque chose comme Kanban qui est plus orienté flux de valeur et qui dit : ‘si on essaie d’éliminer tous les obstacles qui sont sur notre chemin, on aura un flux qui va être bien optimiser donc on aura forcément quelque chose de qualité, et les gens vont être contents car ils vont délivrer de manière continue et correcte’. C’est une petite question de philosophie et il faut comprendre la philosophie qu’il y a derrière. Et c’est là où ça pêche un petit peu. Si tu prends n’importe laquelle de ces pratiques, façon recette de cuisine, tu vas échouer. Car si tu obliges les gens à faire du pair programming, à écrire du code en test first sans comprendre la philosophie et le pourquoi qu’il y a derrière, tu vas échouer aussi.
C – Il ne faut pas suivre les modes ou faire du by the book mais au contraire se poser des questions. Être vraiment agile c’est être pragmatique par rapport à une problématique qu’on a. Donc comment est-ce que tu accompagnes dans ce changement les boîtes avec lesquelles tu collabores afin d’avoir une agilité à l’échelle dans un contexte où parfois ils le font by the book ?
R – C’est extrêmement complexe de faire de l’agilité à l’échelle et n’importe qui essaie de te vendre une solution miracle qui dit le contraire est grosso modo un menteur. Par définition c’est quelque chose qui se passe à une échelle limitée et il n’y a pas de « bonne manière » de faire car plus la taille de l’entreprise augmente, plus ça devient complexe. Donc on essaye de faire des cycles les plus courts possibles à petite échelle. Maintenant, si tu commences à changer d’échelle et à te mettre au niveau de l’entreprise ce n’est pas suffisant. Parce que là tu rentres dans de la systémique et c’est extrêmement complexe parce que tu fais appel à un ensemble de points différents de centres de gravité dans cette entreprise qui ont chacun leur vie propre.
C – Et puis j’imagine qu’il y a de la politique dans l’entreprise, de la stratégie par rapport à différentes personnes qui auront peut-être des intérêts différents et qui ont des niveaux de décisions où ça s’entrechoque. J’imagine que ça intègre beaucoup plus de choses que de la simple méthodologie, quand on parle d’acculturation c’est peut-être d’avoir soit des DSI ou même des directeurs généraux qui sont convaincus que ce sont des choses à implémenter…
R – Il y a de ça, c’est-à-dire qu’effectivement, si tu pars du principe que c’est un système, il faut prendre le problème dans son ensemble. Évidemment si tu prends le problème dans son ensemble le niveau de complexité est énorme. Donc du coup, il faut faire un petit peu tout, c’est-à-dire qu’il faut agir localement et il faut aussi agir au niveau du système. Et ce qui est intéressant, parce que je suis passé par là et c’est mon cas aujourd’hui, c’est que j’ai accompagné des équipes en partant du bas. Donc avoir une approche bottom-up ou tu essayes d’améliorer le développement local d’une équipe et puis après de cross-polliniser un petit peu autour de toi et de faire monter les choses comme ça. Et j’ai aussi fait l’inverse qui est plutôt ce que je fais en ce moment où on part de la direction, avec une direction qui est convaincue par l’agilité, et qui veut accompagner ses équipes de la meilleure façon possible pour qu’elle devienne plus agile. Dans les deux cas ça se passe mal. C’est-à-dire qu’en faisant du bottom-up, j’ai toujours été convaincu que tu arrives à un moment donné où tu tapes dans du middle-management et tu n’arrives pas à monter plus haut. Tu as besoin d’avoir quelque chose de plus culturel dans l’entreprise pour que ça puisse fonctionner. Il ne suffit pas de faire de l’agilité au niveau des équipes, il faut que ça puisse monter et en faisant l’inverse (en faisant du top-down) tu as exactement le même problème. Effectivement, tu as une volonté de la direction d’être agile et tu as quand même un blocage…
C – Les deux en même temps finalement, et avec un interlocuteur qui a parlé à la direction ?
R – C’est là où c’est intéressant, c’est-à-dire que dans les deux cas quand tu fais du bottom-up ou du top-down, tu te rends compte que finalement, le point de blocage essentiel c’est réellement le middle management. D’une manière ou d’une autre, tu as des choses qui bloquent. Aussi, quand tu fais du top-down tu accompagnes les équipes localement, tu as une direction qui est d’accord, néanmoins tu as un middle management qui ne se sent pas impacté par la transformation. Dans tous les cas, il faut que tu commences un petit peu à penser à : ‘j’ai des centres de gravité qui sont mes équipes. Néanmoins, j’ai aussi besoin d’avoir des choses plus transversales comme des Chapter des Guilds. De regrouper toutes ces équipes par Stream de valeur etc…
C – En fait c’est ça, c’est intégrer le middle management à travers des entités plus agiles pour qu’ils se sentent partie intégrante du changement. Qu’ils n’aient pas l’impression non seulement d’être mis de côté mais en même temps que ça leur apporte quelque chose.
R – C’est ça toute la difficulté, et ça monte jusqu’à la direction un petit peu plus haut, tu te rends compte que ce sont des gens qui sont un petit peu spectateurs de la transformation. Car grosso modo tu as la direction, tu as le top management qui veut être agile car il sent la nécessité et après il y a de l’implémentation sur le terrain. Mais je ne te parle pas des chefs de projets, car eux effectivement, ils sont directement impactés car les modes de travail sont différents…
C – Oui, tu as parlé du N+2, N+3, qui sont à des niveaux de direction qui vont eux-mêmes gérer des chefs de projet sans se rendre parfois compte des problématiques terrains ; et qui, en même temps subissent l’agilité en disant : ‘On nous l’impose mais on ne sait pas tellement quel est l’impact’.
R – C’est ça et puis surtout aussi il y a un effet de bord qui est assez rigolo. C’est-à-dire que tu commences avec un certain nombre d’équipe et puis tu fais progresser ça parce qu’il y a aussi un phénomène culturel qui rentre en place. Enfin, tu ne peux pas faire un big bang du jour au lendemain. Ce qui est intéressant c’est qu’il y a un impact direct sur les équipes de Cycle en V parce que le principe du Waterfall c’est que tu as un triangle où tu as le budget, tu as le temps…
C – Une partie recueil du besoin, développement jusqu’aux recettes à la fin et au bout d’un moment ton cycle qui est fini.
R – C’est ça, c’est une bonne définition du Cycle en V. Dans le Cycle en V tu as un temps et un scope et tu as ce triangle où tu as le budget, le scope et le temps. Et dans le Cycle en V, tu fermes le temps et le scope (donc tu as défini ton besoin à priori) et tu veux qu’il soit livré pour telle date et le seul paramètre dynamique c’est le budget. Le budget c’est le nombre de personnes que tu mets dedans, tu ne peux pas changer la date et le scope car il est déjà défini. Le seul truc que tu peux faire c’est de mettre plus de bonhommes sur le thème alors que l’agilité, en théorie, quel que soit la pratique agile, va plutôt avoir tendance à dire : ‘ok on a un temps défini, donc on a des cycles qui sont définis, on a un budget qui est défini à priori puisque ce budget correspond à des équipes’. On veut qu’il y ait des équipes stables donc tu ne peux pas changer ton budget et la seule variable c’est le scope donc on va essayer d’adapter le scope.
C – Est-ce que ce n’est pas là le problème qui survient du côté de certains chefs de projets ou responsables qui du coup sont contraints ? Car ils sont engagés au niveau de leur direction et ils ne se rendent pas vraiment compte des tenants et aboutissants. Ils ne comprennent pas forcément l’éventail autour de la qualité. Est-ce que du coup il n’y a pas une décorrélation entre ce que devrait faire l’équipe et les objectifs des responsables n+2, N+3 ?
R – Potentiellement, oui et effectivement c’est une question de perspective et d’attente de chacun. Néanmoins, l’agilité doit apporter un certain niveau de transparence pour rendre les problèmes transparents et ouvrir la discussion. Car tu ne peux pas améliorer un problème que tu ne vois pas et si tu ne peux pas mesurer ces problème-là, ils deviennent complètement invisibles. Donc, oui, l’agilité d’une certaine manière te permet de rendre ça un petit peu plus transparent.
Mais dans cette culture d’entreprise avec une agilité émergeante, tu as des gens qui sont plutôt du middle management mais qui vont être impactés par ces changements car plus tu as d’équipes agile, moins tu vas avoir de ressources. Ces gens-là souffrent énormément d’une agilité émergeante et ils vont avoir du mal à maintenir ces qualités à la fois dans les équipes agiles et à la fois dans les équipes Waterfall. Et après tu as une direction qui est encore au-dessus, qui elle va être complètement spectateur de ça. Dans la plupart des boites tu continues à avoir des silos et c’est vraiment ça le problème principal. C’est-à-dire que comme on fait un design sans que ce soit une vérité absolue mais un design à la Spotify où tu as des chaines de valeur qui sont orientées par produit par fonctionnalités et tu as quelque chose de bout en bout. Tu as une partie business qui est dans un groupe aligné avec une partie technique et que tout ça est regroupé ensemble. Ces gens-là ont l’autonomie de développer quelque chose et surtout ont une orientation à la valeur et une orientation produit qui va amener cette qualité…
C – Tu fais référence quand tu parles de Spotify, aux notions de feature team. Avec le fait d’avoir une équipe qui est centrée autour d’une feature soit d’un produit. Donc de regrouper des gens fonctionnels et techniques autour de cette problématique pour qu’ils réfléchissent ensemble aux solutions.
R – Oui, c’est vraiment un point essentiel. Si tu n’as pas de notion de produit et d’ownership autour du produit, tu n’as aucune raison de faire de la qualité. Tu peux avoir des gens techniques qui ont envie de se faire plaisir, de développer d’une manière ou d’une autre.
Après tu as différentes visions de la qualité… mais tu vas avoir des gens qui vont être complètement techno centrés et faire des choses qui vont être compliquées juste parce que techniquement c’est hyper sympa à faire ; des choses qui vont être éloignées du service rendu pour l’utilisateur final. A l’inverse, tu peux avoir des choses qui sont très centrées utilisateurs et qui sont un amoncellement de fonctionnalités sans queue ni tête et qui surtout n’ont aucune qualité en termes techniques et de stabilité au niveau de l’archi.
Ce qu’on constate, c’est que si tu n’as pas un but commun entre le business et la Tech pour essayer d’aller dans une même direction c’est compliqué. Il faut centrer cet ownership en disant : ‘ça c’est notre produit, je suis responsable de ça’. Et c’est pour moi un des problèmes majeurs, qui se passe dans les entreprises, c’est cette dilution de la responsabilité et du sens de propriété. Il faut retrouver ce sentiment de : ‘ceci est mon code, je suis responsable de ce code, je veux qu’il rende le service pour lequel il est censé fonctionner’. C’est pour moi fondamental pour essayer de retrouver un minimum de qualité et justifier la qualité aussi car à partir du moment où tu as des équipes projet, une fois le projet rendu, elles passent à autre chose.
‘Qui est responsable de ça ? Pourquoi tu vas essayer de faire la meilleure chose possible ? Pour quelles raisons ? Tu n’as aucune raison de le faire’…
Donc tu peux essayer d’invoquer les grands dieux du Craftsmanship et la qualité du logiciel en te disant : ‘non mais je fais ça parce que c’est mon devoir’ mais il est très difficile d’avoir l’écosystème autour de toi pour justifier d’aller dans cette direction-là. Parce que finalement, tu ne sais pas vraiment pourquoi tu le fais, tu ne sais pas quel est le cycle de vie de ce truc-là. Le fait d’avoir des équipes produit (des équipes stables, multidisciplinaires, qui ont cette notion de produit et d’ownership) c’est ce qui est extrêmement important pour essayer d’insuffler cette qualité et c’est très certainement par là qu’il faudrait commencer. Il faut vouloir développer avec plus d’agilité et comprendre pourquoi.
C – Oui, ça revient à se poser les questions un peu fondamentales, et c’est là le pragmatisme et l’agilité puisque de faire les chose by the book c’est de se dire quelle va être la finalité et l’utilité ? Si je délivre beaucoup plus rapidement, est-ce que j’ai une meilleure qualité ?
R – Il faut que ça se justifie aussi, si tu reprends les paroles de Ken Beck sur XP, qui disait que si tu compares le coût d’un produit sur le temps, tu te rends compte que le développement initial c’est environ 5%. Tu vas avoir entre 5 et 10% de coût de développement initial au lancement de ton produit et 90% de ton budget de développement de ton produit qui va être consommé dans la phase d’exploitation de ton produit. Et c’était ça le point de départ de XP, de se dire : ‘bon on va raccourcir au maximum ce développement initial et en permanence faire comme si on travaillait en production avec une exploitation du produit et j’optimise ma manière de travailler pour ça’. Et je trouve que c’est une vision vraiment excellente car ça t’oblige à avoir des cycles vraiment très courts et d’avoir une qualité vraiment imprégnée à l’intérieur. Mais pour que ce soit valable, il faut que tu aies un produit. Si tu n’as pas de produit et que tu travailles en mode projet, ce truc là n’est plus valable et c’est là toute la problématique. Il faut selon moi commencer par définir ce qu’est le produit et les limites puis, essayer de se dire : ‘ok on développe un produit, on a quelque chose qui est clair au niveau du business et au niveau de la Tech pour essayer de regrouper des gens ensemble’.
Et ça, c’est un driver essentiel pour arriver à implémenter des cycles courts, être plus agile et mettre de la qualité. Parce que c’est pareil, je rencontre énormément de Product honneur dans un environnement Scrum où cet honneur du produit c’est un ex-chef de projet coté exploitation. Mais il n’est pas du tout Product honneur, il ne se sent pas responsable de ce truc-là. Et c’est bien là toute la problématique. Et si tu arrives à avoir des vrais Product honneur, c’est-à-dire des gens qui sont réellement impliqués côté business, tu arriveras très facilement à discuter qualité et à discuter cycle court et ça va très bien se passer. Alors que si tu as en face des gens qui sont là juste pour appliquer le process, qui ne sont pas honneur de leur produit et qui ne se sentent pas vraiment porteur de ce produit, ils vont juste appliquer le process. Et c’est normal puisque c’est gens-là ont été mandatés pour faire un tout. Donc ils n’ont pas cette vision de produit, ils ne ressentent pas ce besoin de faire quelque chose de plus court, de tester, de voir si ça va dans la bonne direction puisqu’ils ne connaissent pas cette bonne direction. Et pour moi c’est certainement l’un des facteurs les plus impactant pour changer les manières de travailler dans les boîtes. Évidemment, il faut accompagner ça à tous les niveaux, il faut structurer l’entreprise afin qu’elle utilise des Streams de valeur et qu’elle ait des vrais produits. Et après, avec à l’intérieur de ces produits, ces features teams en fonction de ton contexte d’entreprise, effectivement appliquer des manières de travailler qui sont orientées cycles courts d’une manière ou d’une autre et essayer de mettre de la qualité à l’intérieur.
C – Oui, donc il y a vraiment cette notion organisationnelle. Tu me parlais pas mal de qualité, au début du TDD tu disais que c’était la pratique qui t’avait fait rentrer dans l’XP et que tu formais aussi à la SGI. Qu’est-ce que tu penses qu’il pourrait manquer aujourd’hui aux jeunes développeurs, développeuses, qui sortent d’école ? Comme par exemple, Epitech 42 où la norme ne va pas forcément aussi loin sur l’approche TDD ou l’XP.
R – La première chose, c’est ce que j’essaie de transmettre à mes étudiants, c’est déjà de savoir que tu ne sais pas. C’est-à-dire que si tu ne sais pas que tu ne sais pas tu ne peux pas commencer à avoir envie d’apprendre. Il y a encore trop cette culture, c’est-à-dire que la plupart des étudiants que j’ai croisé sont relativement humble par rapport à leur situation. A moins qui ne sortent de supers écoles où ils pensent qu’ils sont les rois du monde et meilleurs que tous les autres… Néanmoins, la plupart des étudiants que j’ai croisé temps ont une certaine humilité, : ‘voilà moi je suis un petit étudiant, je viens de commencer, oui il y a tout un monde que je ne connais pas’… Mais ils ont cette accroche-là par rapport au fait qu’ils sont jeunes et qu’ils ne connaissent pas le monde de l’entreprise et qu’ils s’attendant à ce que des gens d’entreprises soient beaucoup plus qualifiés et expérimentés qu’eux. Là-dessus, il y a deux contrevérités par rapport à l’expérience du monde du travail mais ils n’ont pas encore le recul nécessaire par rapport à leur propre apprentissage. Souvent, tu ne te rends pas compte des limites de ton apprentissage, c’est-à-dire que ce que tu as appris à l’école, c’est le résultat d’un programme pédagogique, donc qui a eu un choix éditorial de ce qu’on a envie de te mettre dans la tête. Et dans un deuxième temps, tu as aussi ce que le prof lui-même décide de mettre dans ce cours.
Sachant que beaucoup de profs n’ont pas forcément une démarche où ils se remettent en question en permanence, de revoir leur cours, de s’adapter aux réalités du quotidien aux dernières évolutions. Et souvent, les profs transmettent quelque chose qu’eux même ont appris 20 ans avant quand ils étaient étudiants. Donc il y a un énorme décalage par rapport à ce que les étudiants apprennent réellement. Donc, ça c’est la première contrevérité c’est de croire que ce que tu as appris à l’école est exhaustif. Et après, la deuxième contrevérité c’est le fait de dire qu’en entreprise je vais rencontrer des personnes beaucoup plus compétentes et expérimentées que moi. Ce qui n’est pas forcément vrai parce que beaucoup de gens n’ont pas forcément fait des grandes études, ils ont appris le développement par eux-mêmes etc. Et certains ont peut-être fait une école d’ingénieur mais même s’ils ont 10 ans d’expérience dans une entreprise, en fait tu n’as pas 10 ans d’expérience car cela fait 10 ans que tu es au même endroit donc ça fait 10 ans que tu as 1 an d’expérience. Donc il faut essayer de commencer à ouvrir ces portes et normalement tu dois essayer à chaque fois d’avoir plus de questions.
C – Sur la qualité notamment, pour qu’ils se posent les questions de comment faire un code qui soit maintenable, scalable, et pour qui je le fais ?
R – Oui, oui, par exemple mais c’est beaucoup plus large que ça en fait. Indépendamment de la qualité et ça c’était un deuxième problème sur lequel je voulais revenir au niveau de l’école. Donc tu vois ce programme pédagogique et cet enseignement par les différentes profs n’est pas forcément très coordonné. Il est là pour répondre à un besoin c’est-à-dire au besoin de l’école mais pas forcément à celui de l’entreprise. L’école reste un business, l’école mesure son succès par rapport au taux d’employabilité des étudiants qui en sortent et aux prix auxquels ils sont chassés. Du coup, on va te faire 30 heures de telle matière, 50 heures d’une autre matière et tout ça est assez décorrélé. Ce qui manque, c’est qu’effectivement les étudiants ils apprennent 15 langages différents et ils vont faire un « hello world » dans 15 langages et il n’y a pas de construction autour de ça. Et donc cette douleur de travailler sur du code legacy, d’essayer de faire quelque chose de bien dans le temps, de comprendre le pourquoi du comment. Ils ne le ressentent pas car dans quasiment tous les projets qu’ils ont à faire c’est à peine plus que le « hello world ». Ce sont des projets relativement simples et focus sur la technique ou l’outil qu’on essaye de t’enseigner.
C – C’est pour apprendre plein de langages, de micro-langages ou de Framework et aller assez vite. Ils se disent : ‘bon bah ils auront eu plein de choses et ils vont pouvoir se concentrer sur ce qui leur plaît le plus sans rentrer en profondeur’. Par exemple dans la SLR sur le C# ou sur des notions un peu plus poussées pour se poser les bonnes questions et se spécialiser un peu quitte ‘demain je vais vouloir tester d’autres choses pour avoir un peu plus de compétences’.
R – C’est ça, mais pour que tu puisses prendre conscience de ça, il faudrait qu’il y ait une espèce de coordination où tu essayes de travailler sur un seul et même projet pendant toute ton année. Mais je sais bien que c’est difficile d’imaginer d’avoir un seul gros projet. Néanmoins, il manque ça parce que si tu fais ce que j’appelle un « hello world » dans tous tes outils et langages, tu ne vas jamais sentir ce besoin de qualité. Puis à la fin de ton cursus, tu ne comprends pas ce que c’est ce besoin de qualité. Tu ne sais même pas pourquoi tu devrais faire de la qualité, faire des tests ou essayer de travailler en cycle court.
C – Il y a une relation avec les start-ups qui sont un peu aussi dans ce mode là où en tout cas quand elles se lancent avec parfois le POC ou le MVP à réaliser. Ce qui est dans une logique de vitesse et pas réellement de se dire on construit un produit sur le long terme ou en tout cas on verra après.
R – Au niveau de la start-up, c’est un autre problème mais effectivement, il y a quand même un problème c’est quand tu as validé ta start-up. Une start-up, par définition c’est un écosystème, un contexte que tu créées pour valider une vision de business et un produit. Et normalement, à partir du moment où tu as validé ton produit tu n’es plus une start-up et tu rentres dans une phase d’exploitation. Et c’est ce saut-là en fait ou tu as validé ton produit et où tu sors un peu du POC et tu rentres dans une phase d’exploitation. Et c’est ce saut-là qui fait que parfois beaucoup de start-ups meurent parce qu’elles n’arrivent pas à faire cette transition-là. Elles n’arrivent pas à faire cette transition, car en général, il faut reconstruire le produit et mettre de la qualité. Mais effectivement, le contexte de la start-up est parfaitement valable parce que tu n’as aucune raison de faire de la qualité car tu n’es pas en train d’essayer de résoudre le problème qui est d’essayer de faire un produit stable et de la meilleure qualité possible. Le problème que tu essayes de résoudre c’est : ‘quel est mon produit’ ? Donc du coup tu vas essayer de travailler en optimisant ce truc-là, c’est-à-dire je fais des tests, je fais des POC, je fais quelque chose qui est très souple, très simple, de manière à pouvoir changer très rapidement. En revanche, il faut faire ce saut et effectivement, souvent les start-ups vont être faites par des jeunes dont certains sortent d’école. Justement, ils n’auront rien vu d’autre des projets fait à l’arrache à l’école et c’est pour ça aussi que je ne suis pas forcément très en faveur d’école de type 42 où en fait on ne te pousse pas à avoir cette réflexion-là. Et ce saut, il est nécessaire, c’est parfaitement acceptable de faire quelque chose de pourri si l’objectif de valeur est de découvrir le chemin et le produit que je veux construire.
C –Oui donc ce que tu dis vraiment c’est cette notion de pérennisation d’un projet et sur la durée se rendre compte des vraies problématiques qu’il peut y avoir : de la dette technique, de la qualité et que ça amène la personne à se poser des questions et c’est là où naturellement elle va s’intéresser aux méthodologies, c’est un peu ça que tu dis.
R -Il faut qu’il y ait une vision de produit, il faut qu’il y ait un besoin d’une manière ou d’une autre pour arriver à driver ton code. Tu peux essayer de faire des choses de qualité pour le plaisir, pour l’amour du Craft mais il faut qu’il y ait un sens à ça. Et à la limite, c’est là-dedans que j’essaierai de diriger les plus jeunes c’est de toujours essayer de comprendre où se situe la meilleure boucle de feedback. C’est-à-dire de savoir quelle est la direction dans laquelle j’ai besoin d’aller, qu’est-ce qui me guide et pourquoi et comment est-ce que je peux optimiser cette boucle de feedback et qu’est-ce qu’elle m’apporte ?
Et ça peut être faire du TDD, ça peut être faire quelque chose de tout à fait pourri et d’acceptable parce que tu veux tester une nouvelle technologie. De la même manière, si tu travailles sur des langages fonctionnels, le fait de développer ton idée dans un Apple, dans une interface où tu interagis avec le code c’est potentiellement plus important.
C – Est-ce que tu as eu des mentors ou des gens que tu recommanderais à des jeunes développeurs ou développeuses ou au-delà des communautés, des bouquins qui pour toi sont un petit peu des références ?
R – J’ai plein de gens plus ou moins à conseiller, déjà à la base je reste complètement impressionné par Kent Beck quoi qu’il en soit, il a une certaine humilité en disant qu’il n’est pas forcément un super développeur. Justement cette phrase qui disait : « je ne suis pas un développeur exceptionnel, j’ai juste des habitudes exceptionnelles. »
C – Il le dit presque comme un garde-fou finalement en disant c’est pour m’éviter la médiocrité que je me suis imposé des méthodologies assez poussées.
R – C’est ça, et j’aime beaucoup ce côté de c’est parce que justement je suis conscient de mes limites que j’essaie de trouver des manières d’outrepasser ces limites. Et ça impose de se connaître bien soi-même et de savoir quelles sont tes limites. Et potentiellement, les limites de Kent Beck ne sont pas les mêmes que les tiennes et je l’ai rencontré souvent, quand tu discutes du travail avec des gens extrêmement intelligents ; quelquefois ils vont dans un mur car ils ont tellement l’habitude de résoudre leur problème avec un coup de génie parfois, face à des situations courantes, ils ont du mal à gérer. Du coup, je trouve que la philosophie derrière Kent Beck et le fait qu’il arrive encore à apporter de la fraicheur de de la nouveauté par rapport aux questions qu’on se pose, je trouve ça absolument extraordinaire. Donc ça c’est quelqu’un qui me paraît essentiel même aujourd’hui à suivre.
Quelqu’un que j’aime beaucoup aujourd’hui c’est James Coplien qui n’est pas d’accord avec tout le monde en général. C’est quelqu’un qui est un peu problématique et qui va te défoncer complètement des pratiques autour du TDD et des choses comme ça. Néanmoins, je pense qu’il est absolument essentiel en termes de pratique c’est-à-dire qu’il a été une source d’inspiration pour Scrum. En puis avec ses travaux sur les patterns c’est un monsieur qui a aussi beaucoup amené de travail sur les patterns autour de Scrum. Il a écrit un bouquin qui s’appelle Lean Architecture où il y a plein de concepts absolument fondamentaux sur l’archi et le design. Et il a aussi travaillé autour d’un pattern et j’invite tout le monde à regarder qui s’appelle DCI (Data Context Interaction) qui est aussi assez intéressant et qui recentre un petit peu le développement orienté objet.
Après, effectivement j’ai beaucoup suivi des gens comme Uncle Bob, aujourd’hui j’aurai tendance à moins le suivre et moins l’écouter car il ne donne pas envie, enfin j’ai beaucoup de mal à faire abstraction du personnage en privilégiant juste la technique. C’est-à-dire que tu as des gens parfois vraiment horribles mais comme ils ont fait des trucs vraiment extraordinaires alors on fait abstraction. Néanmoins, je trouve qu’il a eu une contribution extraordinaire en termes de vulgarisation. Je me souviens d’Uncle Bob en conférence il y a une dizaine d‘année. Où il arrive, il n’allume même pas l’écran pour projeter, il s’assoit sur le bord de la scène et il te raconte une histoire. Sur un talk d’1 heure il te raconte une histoire pendant 58 minutes pour finir sur 2 minutes de contenu. Et ce côté de story-telling est absolument extraordinaire et j’ai appris énormément de choses grâce à ça, avec lui et avec d’autres. Le story-telling est particulièrement développé chez les américains mais c’est très important de comprendre que finalement ces 58 minutes d’histoire qui n’avaient rien à voir avec le sujet étaient absolument essentielles pour réussir à faire passer les 2 minutes de contenus. Et rien que pour ça, c’est quelqu’un d’important.
Essayer de s’intéresser à l’histoire c’est aussi un point essentiel. Il y a un bouquin historique génial là-dessus qui s’appelle : The Computer Boys Take Over, qui t’explique depuis le commencement des premiers ordinateurs. C’est fait par un historien qui n’a rien à voir avec le développement, il s’appelle Nathan Ensmenger. A travers ce bouquin, il t’explique le monde dans lequel tu vis, pourquoi il y a du développement aujourd’hui et ce qu’il est en partant des bases.
Et une dernière personne dont je suis absolument fan c’est Bret Victor. Vous pouvez retrouver tout son travail sur worlddream.com et Bret Victor est lui aussi un vulgarisateur. Il a travaillé avec Alan Kay et aussi sur la notion de feedback Loop et de développement en temps réel. Il montre des manières de développer où graphiquement tu définis tes paramètres et tu peux voir l’impact que ça a sur le reste du code. Je trouve que c’est une approche très importante pour essayer de comprendre l’importance de raccourcir ces boucles de feedback et de visualiser ce qu’on est en train de faire.
C – Bah Rui, un grand merci ! Je rappelle qu’on peut te retrouver et sur LinkedIn et sur Twitter. Pour tous ceux qui ne le savent pas encore, tu es aussi le fondateur des Ncrafts qui est la communauté phare autour des bonnes pratiques de développement, du coup merci beaucoup Rui et à très bientôt !
