Nick Tune

[00:00:06] Merci beaucoup. Euh, bonjour à tous. Je suis très heureux euh de représenter Theodo aujourd'hui, et en tant que sponsor de cette incroyable conférence. Euh, donc je suis Fabrice Bernard, je suis le co-fondateur de Theodo. Nous sommes une entreprise de conseil en technologie d'environ 700 personnes basée à Paris, euh Londres et Casablanca. Et euh je suis aussi le co-auteur d'un livre, The Lean Tech Manifesto, qui porte sur la manière de maintenir une culture agile lorsque vous faites évoluer une organisation technologique basée sur notre expérience, mais aussi sur 12 ans d'études du Lean Thinking et d'études de ce que euh les meilleures entreprises technologiques font pour maintenir leur culture agile. Alors vous vous demandez peut-être pourquoi nous avons mis cet étrange personnage sur la couverture. Si vous ne vous le demandez pas, je vais quand même vous expliquer pourquoi.
[00:00:58] Donc c'est euh un caractère chinois en japonais, il est prononcé Hito, qui est le caractère pour l'humain. Et c'était important pour nous en tant que personnage, non seulement parce que bien sûr quand on parle d'Agile, on parle de euh vous savez, donner aux gens les moyens d'être plus innovants, d'avoir plus d'autonomie. Mais aussi parce que c'est en fait un personnage très important dans l'histoire de Toyota. Toyota étant l'entreprise qui a inspiré le Lean Thinking. Parce que très tôt, et je parle des années 1900, euh Toyota euh a réalisé que lorsqu'on parle de technologie et d'automatisation, il y a une bonne et une mauvaise façon de le faire. Et pour vraiment euh différencier les deux, il a décidé de créer un nouveau mot. Et la façon de créer de nouveaux mots en japonais est d'ajouter des caractères. Ainsi, le mot automatisation a été remplacé par un mot appelé Jidoka en japonais, a été remplacé par un mot appelé Jidoka. Donc pour nous, on ne comprend pas la différence. Mais pour les Japonais, c'est très clair car il y a un autre caractère humain qui a été ajouté au milieu. Et c'est pourquoi si vous allez visiter une usine Toyota et que quelqu'un vous explique le Jidoka, ils diront, c'est de l'automatisation. Parce que c'est comme ça qu'ils, vous savez, prononcent la différence. Et je pense qu'avec l'IA maintenant, ce sujet de ce que signifie une bonne automatisation, une automatisation habilitante, est très important. Et donc pour nous, clairement, l'idée était de dire que le Lean Tech concerne la culture Lean, donc donner aux gens les moyens avec la bonne culture, mais aussi fournir aux gens une technologie habilitante. Je vais juste vous donner un exemple de ce qui n'est pas une technologie habilitante. Euh, c'est un exemple d'une application mainframe euh qui a été la cause d'un bug gigantesque chez City Group. Euh, donc l'opérateur de port voulait transférer, je crois que c'était quelque chose comme 81 dollars. Euh, mais par défaut, le montant a été rempli de 15 zéros, et il était censé, la personne était censée supprimer les 15 zéros en premier. Et à ce moment-là, la personne a oublié de supprimer les 15 zéros et donc au lieu de 81 dollars, ils ont transféré avec succès 81 billions de dollars.
[00:03:10] Et donc c'est un J'adore l'exemple bien sûr. C'est vraiment arrivé d'ailleurs et ça vraiment, je veux dire, City Groups a dit ne vous inquiétez pas, nous n'avions pas l'argent donc cela ne serait jamais arrivé à destination, mais oui, quand même. Euh et donc ce sont des exemples extrêmes, mais en fait, quand vous regardez comment nous interagissons avec la technologie au quotidien, euh souvent c'est vraiment horrible. Cela nous pousse à faire des choses vraiment étranges euh juste pour, en quelque sorte, pouvoir faire ce que nous voulons réellement faire. Et c'est vraiment un problème technologique. Souvent, ce n'est pas habilitant, mais au contraire, cela nous rend la vie plus difficile. La bonne nouvelle, c'est que l'IA n'est pas seulement bonne pour les images Ghibli. C'est aussi en fait un véritable bouleversement pour la monétisation. Nous l'avons déjà expérimenté sur plusieurs projets. Euh avec des résultats spectaculaires sur la partie vraiment traduction, donc la traduction de code. Euh donc juste pour vous montrer quelques exemples, c'est assez agnostique. Nous avons migré des applications mobiles natives vers React Native, nous avons migré euh une technologie 4GL des années 2000 vers Spring Boot Angular, nous avons migré Eclipse RCP vers Spring Boot Angular, nous avons migré Node vers Node, etc.
[00:04:20] Euh donc ce n'est pas magique, clairement, si vous poussez juste le tout dans une IA, ça ne va pas marcher. Euh mais ça accélère vraiment euh la partie ingénierie. Donc si vous parvenez à vraiment euh découper votre héritage en petits composants que vous pouvez mapper à euh l'architecture cible et ensuite pour chaque mapping écrire le bon prompt, itérer sur un très bon prompt, c'est là que vous euh gagnez vraiment des améliorations de vitesse incroyables.
[00:04:50] Euh j'ai terminé, donc euh deux points à retenir. Premièrement, vous pouvez venir visiter notre OPA de monétisation de l'IA. Nous sommes euh à Paris. Nous sommes Boulevard des Batignolles. Si vous ne savez pas comment euh demander la visite, c'est assez simple, vous allez sur LinkedIn, vous me trouvez et vous m'envoyez un message. Et si vous êtes vraiment 300 personnes à m'envoyer un message, je trouverai une solution. Euh mais je serai quand même très heureux. Euh et la deuxième chose, c'est qu'après la conférence de Nick, euh nous fournirons en fait quelques exemplaires du Lean Tech Manifesto. Donc vous pouvez venir à notre stand, le stand Theodo. Merci beaucoup, et maintenant je suis très heureux de présenter Nick.
[00:05:31] Alors, je dois parler un peu avant qu'il n'installe son ordinateur.
[00:05:39] Donc, c'est ma faute, j'ai décidé d'inviter un simple ingénieur. Comme il aime le dire. Donc, mais c'est un peu plus que ça, c'est un écrivain incroyable, si vous ne le suivez pas sur LinkedIn, suivez-le tous les jours, des histoires incroyables. Et parce qu'il aime écrire, il a écrit un très bon livre intitulé Architecture Modernization. C'est un livre trop long. Combien de pages ?
[00:06:06] Euh, oui.
[00:06:07] Non. Non. Oh, oui. Il parle français. Mais je ne sais pas s'il va essayer de le faire en français. Hum, combien de pages avez-vous ? Non, c'est trop, c'est trop concentré. C'est un simple ingénieur. Il ne peut pas faire les deux choses.
[00:06:25] Il a dit quelque chose.
[00:06:26] Combien de pages y a-t-il dans votre livre ?
[00:06:29] Je ne suis pas sûr.
[00:06:31] Je suis sûr qu'il ne sait pas. C'est juste.
[00:06:34] Combien ? 440.
[00:06:38] 440, oui. 440. Je n'arrive pas à le finir. C'est trop long. Sois plus bref la prochaine fois. Sois un simple ingénieur. C'est à toi de voir. D'accord, merci.
[00:06:49] Bonjour à toutes et à tous.
[00:06:58] 2 secondes.
[00:07:01] Voilà. Donc, tout d'abord, je tiens juste à remercier, euh, les organisateurs. Je suis venu à Flowcon pour la première fois, je crois, il y a neuf ans, quand il avait un ancien nom et un ancien lieu. C'est la deuxième conférence à laquelle j'ai jamais parlé, donc j'ai beaucoup de bons souvenirs de cet événement. Je crois que je parlais de Oui, c'était une conférence étrange la dernière fois, mais aujourd'hui, je vais parler de la modernisation. Mais en fait, je pensais que ce ne devrait pas vraiment être moi ici aujourd'hui. Ce devrait être Stefan Rottenberg. Il est le présentateur d'une émission de télévision appelée Pékin Express. Et tout comme la modernisation, c'est un long voyage. Vous ne vous présentez pas à Pékin Express avec votre présentation PowerPoint en disant, voilà comment nous allons moderniser tout le système. Il faut se présenter tous les jours. Si vous n'avez pas regardé l'émission de télévision, euh les gens sont en groupes, par paires, ils sont embarqués. Euh, ça pourrait être un grand-père, une petite-fille, des amis, des couples, un frère et une sœur. Ils n'ont nulle part où vivre, rien à manger, et pas d'argent. Et ils doivent se déplacer dans différents pays, faisant face à toutes sortes de défis. Et chaque jour, c'est juste une bataille continue. Par exemple, vous les verrez, genre, 'Vous devez parcourir 50 kilomètres aujourd'hui, sans argent, sans voiture, sans rien.' Et ils sautent sur la route en disant, 'S'il vous plaît, s'il vous plaît, s'il vous plaît!' 'Arrête, arrête, arrête!' essayant de faire arrêter les voitures. Et pour moi, c'est comme la modernisation. C'est vraiment une chose continue. Vous devez vous présenter chaque jour. Et affronter continuellement des batailles comme votre collègue Yannick qui vous met au courant des bugs clients et d'autres choses parce qu'il veut que votre équipe les corrige.
[00:08:39] Euh alors commençons la conférence. Je me demande ce que dirait Stefan Rottenberg s'il était là en ce moment. Faisons ça ensemble. Qui sait ?
[00:08:48] Trois, deux, un. C'est parti!
[00:08:56] Donc, ma propre histoire, euh, Stefan n'est pas dans cette histoire. Je travaillais avec une entreprise aux États-Unis il y a quelques années avec des collègues. Et l'objectif était de les aider à commencer la modernisation. Et nous avons passé du temps à discuter de la façon dont les différentes équipes travaillent, de ce sur quoi elles travaillent actuellement, des défis auxquels elles sont confrontées, etc. Et nous avons trouvé un domaine et nous avons parlé à l'équipe. C'était une équipe interne, ils géraient les processus commerciaux internes, traitant les demandes des clients, gérant la conformité, orchestrant ces processus complexes. Et nous avons dit, euh nous comprenons vos problèmes, vous devez utiliser ces différents outils internes. Vous vous connectez ici, entrez des informations ici, puis vous allez à cet outil, et vous vous connectez ici, et vous vous connectez à cet outil. Et cela vous prend des lustres pour intégrer de nouvelles personnes, vous devez leur enseigner trois systèmes différents. Et donc nous avons dit, d'accord, euh il semble assez évident que la modernisation ici signifierait remplacer vos trois outils différents, de sorte que vous n'ayez qu'un seul outil. Et c'est le plan. Nous avons parlé à la direction et ils sont d'accord avec cette consolidation.
[00:10:01] Et ils ont dit, non, ne faites pas ça. Ils ont dit assez fermement, 'Nous ne voulons pas ça.'
[00:10:08] Et on était là, hein? Quoi? C'est pas logique. Pourquoi il dit ça? Ils sont fous! Mais ensuite ils nous ont expliqué pourquoi ils ne voulaient pas de ce nouvel outil. Parce qu'ils ont dit : 'Il y a quelques années, nous avions ces deux outils que nous devions utiliser. Et quelqu'un comme vous a dit, nous allons moderniser vos systèmes et ensuite vous n'aurez qu'un seul outil. Et maintenant nous en avons trois. Et nous n'en voulons pas quatre !' Et ils avaient raison, en fait, c'est ce qui se passe dans beaucoup de ces cas. Et je rencontre beaucoup de gens qui ont des expériences très similaires. Différentes entreprises, différents titres de poste. Ceci vient d'un ingénieur logiciel. Je parlais à Christine l'autre jour qui a dit quelque chose de très similaire. Et elle a dit : 'Je préférerais ne pas commencer cette migration, cette modernisation, si nous ne la terminons pas. Parce que si nous ne la terminons pas, nous nous retrouvons avec quelque chose d'encore plus complexe que ce avec quoi nous avons commencé.' Et je pense que c'est le cas pour Je ne sais pas si c'est la plupart, mais cela semble être une expérience très courante. Et donc la modernisation, c'est un peu comme la Vallée de la Mort. Elle devrait être accompagnée de panneaux d'avertissement vous disant que c'est une chose extrêmement dangereuse. Vous pourriez être fou si vous essayez de faire ça.
[00:11:23] Et c'est pourquoi je pense que nous avons notre propre Vallée de la Mort. Je l'appelle la Vallée de la Mort de la Migration de l'Héritage. Parce que si vous commencez à moderniser, et que vous n'arrivez pas ici, et que vous restez bloqué ici, vous êtes dans de gros problèmes. Vous allez avoir plus de complexité, plus de problèmes à gérer. Et ce n'est tout simplement pas un bon endroit où être. Et vous pensez à cela qui se produit dans différentes parties de l'entreprise en même temps. Vous avez plusieurs modernisations échouées dans l'entreprise. Et c'est ainsi que les gens se retrouvent avec ces trois outils différents. Des ingénieurs de votre entreprise qui ne veulent pas moderniser parce qu'ils ont eu de mauvaises expériences. Mais ça ne veut pas dire que vous ne devriez pas moderniser. Voici mon ami James. Il a les cheveux roux. Il prend des coups de soleil très facilement. Et il est là, dans la Vallée de la Mort, ignorant les panneaux. Mais le fait est qu'il n'ignore pas les signes, car les signes, les signes ne disent pas de ne pas faire ceci. Les signes disent de faire ceci si vous êtes adéquatement et correctement préparé. Et c'est mon travail aujourd'hui, de vous montrer quels sont les, quels sont les signes avant-coureurs de la Vallée de la Mort de la modernisation et ce que vous devez faire pour pouvoir traverser et ressortir de l'autre côté de la Vallée de la Mort de la modernisation. Donc le premier signe avant-coureur est de se méfier de l'écart de compétences en matière de modernisation.
[00:12:47] Donc, lorsque vous commencez à moderniser, votre entreprise, vos ingénieurs, vos architectes vont probablement utiliser des technologies et des outils plus modernes. Et c'est très dangereux car si vous n'appliquez pas ces choses correctement, elles peuvent créer plus de complexité et plus de problèmes pour votre entreprise. C'est un exemple assez ancien de ce que nous avions la décennie dernière, lorsque les microservices étaient la grande nouveauté excitante. Les gens ont commencé à utiliser les microservices, parce que tout le monde en faisait l'éloge, c'était la chose cool. Modernisez vos systèmes hérités monolithiques avec des microservices, et puis quelques années plus tard, nous commençons à voir ces problèmes où les gens les ont appliqués incorrectement et ont créé plus de problèmes qu'ils n'en ont résolus. Et c'est ce qui va se passer si vous ne comblez pas le fossé des compétences. Vous ne saurez pas comment moderniser correctement et utiliser les techniques et les outils de manière efficace. Et donc vous ne pouvez pas simplement demander à vos équipes de commencer à moderniser. Genre, 'Oh, vous travaillez sur l'héritage depuis un certain nombre d'années, euh pas besoin de commencer à moderniser.' C'est la première erreur. Donc vous devez commencer à réfléchir, comment combler ce fossé de compétences ? Et je vais vous donner un court exemple de ce que nous faisons chez Payfit. Quelque chose qui a été lancé avant que je ne rejoigne l'entreprise. Quelque chose qui implique Christina, alors s'il te plaît, réveille-toi pour cette partie, Christina. Euh, donc l'un des concepts que Payfit a reconnu est que pour atteindre, euh, les objectifs de transformation qu'ils se sont fixés en termes d'architecture, le Domain-Driven Design est une compétence importante qui manque à l'entreprise. En gros, comme la plupart des entreprises, l'entreprise veut croître, construire de nouveaux produits, améliorer ses produits, s'introduire sur de nouveaux marchés, améliorer son efficacité, améliorer sa rentabilité, sa rentabilité, euh, ce genre de choses. Et pour ce faire, il doit y avoir un peu plus de structure dans l'organisation et le logiciel pour découpler les choses afin que les choses puissent évoluer et croître de manière indépendante, à la fois le logiciel et les équipes. Et c'est essentiellement ce qu'est le Domain-Driven Design, il vous aide à architecturer votre entreprise, vos équipes et votre logiciel. Donc, pour combler ce manque de compétences en DDD, il y a deux choix. Et c'est très similaire pour de nombreuses compétences que votre entreprise doit acquérir. Vous pouvez envoyer quelques personnes sélectionnées suivre une formation de deux jours. Ou vous pouvez investir dans des opportunités d'apprentissage continues et permanentes. Payfit a choisi la deuxième option, ce qui est excellent. Et l'une des façons dont euh Payfit fait cela, par exemple, ce sont les DDD Open Hours, que Christina a commencé il y a combien de temps ? Deux ans. Il y a deux ans. Donc cela a lieu tous les lundis. C'est 1,5 heures, une heure et demie, tous les lundis, et tout le monde est le bienvenu. Euh n'importe quelle équipe, n'importe quelle compétence. Ce n'est pas seulement une chose de développeur. Nous avons toutes sortes de personnes qui viennent à ces sessions. Euh, l'une des choses que nous essayons de faire beaucoup, quelque chose que vous ne pouvez pas faire lors d'une formation de deux jours, c'est vraiment apprendre quelque chose et l'appliquer à des projets réels sur lesquels vous travaillez, ou qui se déroulent dans votre entreprise, ou des choses que vous connaissez. Et c'est à cela que nous utilisons beaucoup ces DDD Open Hours. Pour résoudre des problèmes réels, appliquer le DDD à des projets réels. Rassembler ces différentes personnes qui connaissent différentes parties de l'entreprise et du logiciel. Et je pense que c'est une excellente initiative. Et je pense qu'une autre chose importante est que Christina et d'autres, euh, étaient là pour soutenir les gens, mais nous allons chercher des opportunités. Et nous disons, 'Hé, ce sur quoi vous travaillez, apportez-le aux DDD Open Hours la semaine prochaine. C'est parfait, un excellent forum pour cela.' Et je pense que maintenant il y a beaucoup d'élan, n'est-ce pas ? Et les gens disent, 'Oui, peut-on avoir la plage horaire DDD Open Hours la semaine prochaine ? Oui, peut-on avoir cette plage horaire DDD Open Hours ?' Vous parliez jusqu'à 22h hier soir en organisant une DDD Open Hours, n'est-ce pas ? Ce n'est pas normal, c'est une exception car c'est un peu urgent, mais c'est l'élan qui s'est créé autour de cette idée. Alors, j'ai un exemple pour vous d'une de ces sessions DDD Open Hours. Et celle-ci portait essentiellement sur la transformation d'une partie du système et c'est quelque chose qui a touché plusieurs équipes. Je pense que ce que nous essayions d'atteindre était d'avoir une architecture cible où nous pourrions voir comment ces différentes parties du système s'assembleraient, et comment différentes équipes collaboreraient, comment différentes équipes seraient propriétaires de différentes choses, et comment les différentes parties du système communiqueraient entre elles. Mais nous avions une certaine imprécision au niveau conceptuel, et c'est ce que nous avons essayé de résoudre ici, en cartographiant les processus de l'état actuel et les différentes entités et leurs cycles de vie. Et pas seulement les cartographier, mais essayer d'obtenir de la clarté car différentes personnes voient ces perspectives différemment. Donc, lors des DDD Open Hours, nous avons réuni toutes ces personnes, euh et et nous avons réussi en fait. Autre chose, ça peut être très différent, parfois nous avons des concepts plus théoriques et techniques comme parler de l'event sourcing. Donc ces DDD Open Hours sont très flexibles. Et nous essayons de comprendre quels sont les différents défis et opportunités pour apprendre ces concepts et les appliquer sur des projets réels. D'autres choses que nous faisons pour soutenir cela, nous y pensons aussi complètement que possible, comme toutes les choses que nous pouvons faire pour aider à combler ce fossé de compétences, pour aider la modernisation à progresser plus rapidement et plus efficacement. Euh, donc vous savez, comme les communautés internes, les canaux Slack, le blog interne, euh quelque chose que j'écris sur le blog et j'encourage d'autres personnes à partager leurs expériences sur le blog interne, euh comme moyen de partager des connaissances. Nous avons de bonnes directives dans la stratégie d'ingénierie, qui encourage les gens et explique les concepts clés, comment les appliquer, où chercher, et ce genre de choses. Et je pense que l'une des choses les plus importantes que nous faisons est d'avoir des personnes intégrées dans les équipes. Et de faire réellement le travail avec les équipes pour les aider à apprendre et à appliquer ces concepts très concrètement, très spécifiquement à ce sur quoi ils travaillent. Tellement différent d'un stage de formation de deux jours. Et c'est un peu ce qui est nécessaire pour l'investissement et l'apprentissage continus des concepts qui sont essentiels pour combler le fossé dans votre entreprise. Alors, quel est le deuxième avertissement ? Le deuxième avertissement est qu'une incapacité à prendre des décisions peut être fatale. Et c'est quelque chose que, j'en suis sûr, vous avez tous expérimenté. Vous pourriez entendre des commentaires comme celui-ci. 'Nous ne pouvons pas prendre de décision tant que quelque chose d'autre n'a pas été clarifié.' Et quand les équipes ne peuvent pas prendre de décision, que font-elles ? Soit elles ne font rien, soit elles construisent des solutions temporaires à court terme. Et plus longtemps vous ne prenez pas de décision, plus longtemps rien ne se passe, ou plus il y a de solutions temporaires à court terme qui sont construites. Et ensuite, ces solutions temporaires à court terme deviennent assez complexes en elles-mêmes, et vous rendez le système plus complexe à ce stade, et non moins complexe. Donc, être capable d'identifier les décisions clés et de les prendre effectivement peut être crucial. Euh, et les décisions peuvent être à différents niveaux. L'exemple précédent était plus au niveau architectural, mais les, euh, les inconnues et le manque de clarté peuvent aussi être au niveau commercial. Comme, nous avons ces différentes parties du système que nous devons moderniser, ou que nous pensons devoir moderniser. Mais nous ne savons pas laquelle sera la plus importante. Nous ne voulons pas passer six mois à moderniser A si l'équipe produit dit, 'D'accord, nous nous concentrons sur B au cours des deux prochaines années.' Donc nous avons besoin, nous n'avons pas besoin d'une clarté à 100%, mais nous avons besoin d'une clarté raisonnable sur la direction que prend l'entreprise afin de prendre des décisions de modernisation, je pense, euh, et donc chaque fois que vous en avez l'occasion, je pense qu'il est toujours bon d'essayer de réduire les possibilités et d'obtenir de la clarté et de simplement dire, 'Y a-t-il une chance que nous puissions nous étendre dans un nouveau pays au cours des trois ou quatre prochaines années ?'
[00:19:24] et ces solutions de contournement à court terme deviennent assez complexes en elles-mêmes et vous rendez le système plus complexe à nouveau à ce stade et non moins complexe. Donc, être capable d'identifier les décisions clés et de prendre ces décisions peut être crucial. Euh, et les décisions peuvent être à différents niveaux. L'exemple précédent est plus au niveau architectural, mais les euh, les inconnues et le manque de clarté peuvent aussi être au niveau commercial. Comme nous avons ces différentes parties du système que nous devons moderniser ou que nous pensons devoir moderniser. Mais nous ne savons pas ce qui sera le plus important. Nous ne voulons pas passer six mois à moderniser A. Si l'équipe produit dit, d'accord, nous nous concentrons sur B au cours des deux prochaines années. Alors, nous avons besoin nous n'avons pas besoin d'une clarté à 100 %, mais nous avons besoin d'une clarté raisonnable sur la direction que prend l'entreprise afin de prendre des décisions de modernisation, je pense. Euh, et donc, chaque fois que vous en avez l'occasion, je pense que c'est toujours bon d'essayer de réduire les possibilités et obtenir de la clarté et simplement dire, y a-t-il une chance que nous puissions nous étendre dans un nouveau pays au cours des trois ou quatre prochaines années ? Et s'ils disent non, vous pouvez dire, d'accord, eh bien, nous n'avons pas besoin de nous soucier trop de la construction d'une solution encore plus flexible, nous pouvons nous concentrer sur des choses plus concrètes que nous avons déjà pour les pays que nous soutenons déjà, par exemple.
[00:20:45] Donc j'ai un autre exemple de Payfit, quelque chose sur lequel nous avons travaillé récemment, quelque chose sur lequel j'ai travaillé, quelque chose sur lequel Christine a aussi travaillé. Donc, euh, quelqu'un pourrait réveiller Christine un peu, s'il vous plaît. D'accord, s'il te plaît. Donc celui-ci portait sur un modèle cible, euh, c'était à un niveau conceptuel, eh bien, allons juste dans les détails.
[00:21:04] Donc je ne vais pas lire tout ça. Je ne sais pas pourquoi j'ai mis autant de texte sur une seule diapositive. Mais l'idée de base est, euh, que la transformation est en cours, modernisant des parties du système depuis quelques années. Nous avons une bonne clarté à un niveau macroscopique et Christine a joué un rôle influent dans la création d'une carte des grands domaines de toute l'entreprise. Donc nous comprenons à un niveau global et dans certains détails les parties clés de l'entreprise, les domaines, les équipes qui les possèdent. Mais quand même, à mesure que vous modernisez et que vous approfondissez les détails et que vous modernisez des parties plus complexes et encore plus centrales du système et que vous atteignez un nouveau niveau de détail, vous découvrez de nouveaux problèmes et des problèmes non résolus qui doivent être réglés. Et si encore une fois, si ces problèmes non résolus restent non résolus, les gens ne peuvent pas prendre de décisions et progresser ou ils commencent à construire des solutions de contournement.
[00:21:58] Donc, juste pour donner un exemple de cela dans le domaine de Payfit dans n'importe quel domaine. Vous avez beaucoup de concepts différents. Chez Payfit, nous avons des choses comme employé, collaborateur, utilisateur, compte, administrateur, dépenses, rôles, vous en reconnaissez probablement beaucoup d'autres domaines. Et le défi clé est que nous devons décider comment représenter tous ces concepts dans le logiciel ? Et comment ces choses s'assemblent-elles ? Quelle équipe possède quelle partie ? Comment pouvez-vous créer une API ou publier des événements depuis votre logiciel si les concepts ne sont pas clairs et si vous ne savez pas quelle équipe possède chaque partie ? Et c'est ce que nous avons commencé à remarquer, qu'il y avait un certain niveau conceptuel où nous devions décider ce que signifient ces choses maintenant. Et je dis maintenant, parce que nous devons gérer ce concept de dérive sémantique au fil du temps. Lorsque vous construisez un logiciel, il représente l'entreprise à ce moment-là. Mais à mesure que l'entreprise évolue et que votre produit évolue et que les gens commencent à utiliser une terminologie différente et à penser différemment, votre logiciel ne suit pas toujours le rythme. Donc, dans une explication très simple, vous pouvez imaginer ici que nous commençons à construire un nouveau produit et que les experts du domaine parlent de ce concept de triangle. Et les développeurs disent, oh oui, nous allons implémenter cette fonctionnalité et avoir ce triangle dans notre code, nous aurons une classe appelée triangle ou un agrégat, si vous connaissez le DDD. Et puis, au fur et à mesure que le produit évolue et que le modèle mental change, c'est comme si, eh bien, cette chose que nous pensions être un triangle, c'est plutôt un carré. Et les développeurs se disent, eh bien, pour transformer ce triangle en un carré, ce serait beaucoup d'efforts, beaucoup de refactoring. Nous n'avons pas vraiment le temps de faire ça, alors si nous le copions et que nous coupons le coin et que nous tournons ça et que nous tournons ce morceau là et que nous le réutilisons. Il a quatre coins, c'est presque le carré, et le produit fonctionne comme nous le voulons, juste ce décalage commence à s'accentuer. Et puis, à mesure que le produit et l'entreprise évoluent, nous avons ce nouveau concept qui se rapporte au premier concept. Comme, oui, nous avons A, et nous avons B. Mais encore une fois, les développeurs se disent, eh bien, ce que nous avons ne correspond plus vraiment, euh, comment faire fonctionner cette nouvelle fonctionnalité et l'intégrer à la base de code que nous avons actuellement ? Eh bien, si nous copions cette chose encore et que nous changeons sa couleur et que nous l'insérons ici, cela fonctionne en quelque sorte, le produit fonctionne et le code n'est pas un désastre complet. Donc nous allons prendre ça. Et c'est ainsi que ces choses évoluent avec le temps. Et c'est tout à fait naturel. Ce n'est pas juger vos développeurs. Il est très difficile d'avoir un code qui soit toujours complètement aligné avec votre entreprise. Et donc un exemple de Payfit sera ce concept d'employé ou de contrat. Je ne peux pas en dire trop et ce n'est pas une critique des décisions prises dans le passé. C'est juste une évolution naturelle. Donc, vous avez ce concept d'employé. Qui a des informations personnelles, nom, adresse, détails du contrat comme quel est votre titre de poste, combien de temps travaillez-vous pour l'entreprise. Et puis, à mesure que le produit et le produit évoluent et que l'entreprise évolue, c'est comme si un employé pouvait avoir plusieurs contrats. Donc, cette chose n'est plus un employé, c'est maintenant un contrat. Mais maintenant, le défi ici est que si je suis un employé et que j'ai deux contrats, mes informations personnelles sont dupliquées sur deux contrats et si j'ai plus de contrats, ça commence à être dupliqué. Et maintenant, nous en sommes à un stade où nous devons commencer à déterminer ce qu'est un employé, ce qu'est un contrat, où vivent les différentes informations. Quand nous parlons aux experts du domaine, ils disent, eh bien, nous pensons que ce qui a vraiment du sens, c'est d'avoir un collaborateur et qu'il ait un seul profil et que les informations du profil personnel ne fassent plus partie des contrats. J'ai en fait parlé aux équipes juridiques en France, au Royaume-Uni et en Espagne, j'ai dit, est-il légalement requis d'avoir des informations personnelles sur un contrat ? Et ils ont dit non, super, retirons-le alors. Définissons ce modèle cible et déplaçons le code dans cette direction. Alors, oui, j'en ai parlé. Donc ce que nous avons fini par créer était cette carte des entités clés et comment elles se relient les unes aux autres et ce qu'elles signifient maintenant ou ce que nous voulons qu'elles signifient à l'avenir. Le système actuel ne va pas ressembler magiquement à cela avec tous ces mots et relations. Mais nous avons un modèle cible clair. Ainsi, quand une équipe construit une API ou modernise une partie du système ou publie de nouveaux événements, nous utilisons ce modèle cible pour déterminer quelle équipe devrait en être propriétaire. Quels devraient être les noms de ces API et événements si j'ai un ID de collaborateur ? Cela peut-il être lié à un contrat ou à plusieurs contrats ? Et ce sont les genres de questions auxquelles nous avons répondu à un niveau conceptuel. Je pense que c'était aux alentours d'août, septembre de l'année dernière et maintenant nous l'utilisons comme point de référence pour prendre nos décisions.
[00:26:48] Euh, oui, donc je pense que, en termes de la façon dont nous avons abordé ce processus, c'est un autre ensemble de compétences dont vous avez besoin pour réellement identifier le problème. Je pense que ce problème est apparu de diverses manières. Euh, Je pense que Yannick montrait un problème qu'il avait dans son équipe. Nous avons eu ces conversations pendant les heures d'ouverture de DDD et nous avons commencé à réaliser que, c'est un problème non résolu et si nous ne le résolvons pas bientôt, ce sera un blocage et les équipes vont commencer à construire des solutions de contournement. Qu'il y ait peut-être déjà pire en termes de solutions de contournement à ce moment-là, donc nous étions déjà arrivés à un point où prendre cette décision était critique. Donc le processus que nous avons suivi, euh, il peut varier.
[00:27:28] Nous avons d'abord commencé par les options, en parlant aux experts du domaine, aux personnes produit, euh, à d'autres experts de l'entreprise, comme que signifient ces mots pour vous ? Comment organiseriez-vous ces concepts ? Et nous avions des opinions différentes. Même les experts du domaine ne sont pas toujours d'accord, qu'est-ce qu'un employé par rapport à un contrat ? Nous avons dû faire un travail pour rassembler des options.
[00:27:49] Euh, personnellement, je travaillais dans une équipe sur une partie du modèle. Et puis nous avons dû comprendre, d'accord, nous pensons que c'est ce qui a du sens dans notre équipe. Maintenant, nous devons aller parler aux autres équipes et nous devons faire participer Christine pour nous aider. Donc il y a beaucoup d'efforts dans les ateliers d'équipes individuels, les ateliers d'équipes multi-groupes, nous utilisons beaucoup les heures d'ouverture du DDD. Et puis, une fois que nous avons cartographié les options et que nous ne recevons pas de commentaires nous encourageant à envisager d'autres options, nous commençons alors à converger chez Payfit, nous utilisons des RFC et des ADR pour prendre des décisions. Et je pense qu'il y a juste un peu de personnel, il faut des gens qui puissent faire avancer les choses en avant et parce qu'il y aura toujours, ah, nous avons choisi l'option un, mais les gens continuent de parler de ce qui se passe si nous faisons l'option deux. Il faut des compétences et des directives pour s'assurer qu'à un certain moment, après un certain temps, la décision est prise et c'est tout. Et ensuite, continuez à utiliser ce modèle juste pour que les gens en soient conscients.
[00:28:44] Donc il y a un deuxième avertissement. Quel est le troisième avertissement ? Vous devez vous protéger contre les forces implacables de la gravité anti-modernisation. Donc cette gravité anti-modernisation est toujours, est toujours contre vous. C'est dans cette pièce maintenant. Si votre entreprise se modernise, elle vous suit partout. C'est dans chaque partie de votre entreprise, tout ce que vous faites, cette gravité vous pousse constamment contre vous parce qu'elle ne veut pas que vous modernisiez. Elle veut que vous ne modernisiez pas et que vous continuiez à travailler et à maintenir vos systèmes actuels tels qu'ils sont en ce moment. C'est toujours là, vous ne pouvez pas vous en débarrasser. Et nous le voyons dans ce genre de commentaires. Il ne s'agit pas d'une entreprise en particulier, c'est une observation générale que j'ai vue dans de nombreux endroits. Je sais que nous avons dit que la modernisation de cette chose était importante. Mais l'un de nos plus gros clients nous demande cette nouvelle fonctionnalité. Et nous devons vraiment faire ça. Je suis vraiment désolé d'arrêter de moderniser. Mais ne vous inquiétez pas, vous pourrez continuer à moderniser dans trois ou six mois, quand cette grande nouveauté sera construite. Si vous voyez ce commentaire, si vous entendez ce genre de commentaire, vous savez où vous allez aboutir, d'accord ? C'est ce que ça veut dire. Vous vous dirigez vers la Vallée de la Mort de la migration des systèmes hérités si vous voyez ce genre de commentaires et que cela commence à se produire plus fréquemment. Donc, pour combattre la gravité anti-modernisation, nous avons besoin de quelque chose d'aussi puissant. Et c'est là que nous pouvons utiliser le cadre anti-FO. Il s'agit donc essentiellement d'encadrer, d'aligner les compromis, la peur et l'espoir, et la vigilance constante. Ces choses peuvent aider votre entreprise à arrêter de perdre du temps et à éviter d'avoir une expérience horrible dans quelques années lorsque toutes les choses que vous vouliez réaliser ne sont jamais réellement implémentées.
[00:30:33] Donc le cadrage est fondamentalement, quand vous parlez de modernisation, qu'est-ce que les gens entendent, pensent et voient ? Qu'est-ce que cela signifie pour eux ? S'il s'agit d'une chose produit versus tech, vous êtes déjà à moitié bloqué dans la Vallée de la Mort de la migration d'héritage. Parce que ce sera toujours une discussion sur le fait que le produit veut construire une nouvelle fonctionnalité, mais que les techniciens veulent continuer à moderniser des choses. Cela devient donc une sorte de compromis pour que les techniciens puissent moderniser même s'ils ne voient pas vraiment la valeur. Le bon type de cadrage que nous devons avoir dans ce genre de situation est qu'il s'agit d'un niveau commercial. Nous faisons des compromis à court terme pour un investissement à long terme plus important. C'est ce qui doit être le cadre ici, le court terme contre le long terme. Donc, c'est le genre de choses comme, nous pouvons avoir quelque chose de petit maintenant et l'avoir rapidement, ou nous pouvons investir beaucoup et avoir quelque chose de beaucoup plus grand à l'avenir. Comme, construire un nouveau produit ou se développer dans une nouvelle entreprise. Il s'agit de travailler dans le système actuel où le coût du changement est élevé, par rapport à l'investissement et à la capacité de construire de nombreuses choses qui sont actuellement trop chères. Si vous travaillez dans un système qui a des incidents et des bugs et que vous passez beaucoup de temps et que cela devient une situation difficile. C'est ce qu'est la modernisation. Il s'agit de résoudre ces problèmes et cela doit toujours être lié à ces choses. Et cela amène au deuxième point.
[00:31:58] Il doit y avoir un alignement sur les compromis au niveau stratégique, en particulier, à quoi disons-nous non ? Donc, si nous pensons au cadrage du court terme par rapport au long terme, 100 % à long terme signifie que nous allons seulement moderniser et atteindre les objectifs à long terme le plus rapidement possible. Comme si nous nous contentions de travailler à la modernisation, si nous nous concentrions à 100 % sur le long terme, nous pourrions nous étendre à trois pays en 1,5 an.
[00:32:29] Si nous, euh, si nous optons pour l'option, si nous optons pour la feuille de route B, nous pouvons nous étendre à un seul nouveau pays en deux ans, mais nous obtenons certaines fonctionnalités du produit à court terme. Il s'agit donc d'être vraiment clair : à quoi disons-nous non ? Nous devons, nous devons avoir la direction qui dit, nous ne faisons pas cela afin que nous puissions avoir cet objectif à plus long terme. Si les dirigeants donnent des messages contradictoires, ce sera toujours un problème et une source de gravité anti-modernisation, car les équipes recevront des messages contradictoires et elles feront généralement ce que le produit veut ou plus de travail de produit.
[00:33:05] Donc je viens de dire ça. Euh, alors il y a la peur et l'espoir. Donc je pense que la peur et l'espoir sont des outils très, très puissants pour nous aider à combattre les forces de la gravité anti-modernisation. Et c'est quelque chose que nous pouvons tous faire de manière continue. C'est l'une de ces petites choses que nous pouvons faire tous les jours. Juste pour rappeler aux gens, juste pour les maintenir concentrés, juste pour continuer à projeter cette vision future de ce qui devient possible. Donc il y a eu un exemple il y a quelque temps où quelqu'un a dit : pouvons-nous construire cette nouvelle API ?
[00:33:39] Et l'équipe dans laquelle je travaillais a dit, eh bien, nous ne pouvons pas vraiment faire ça à cause des contraintes existantes, euh, et c'était un peu gênant.
[00:33:49] Mais j'ai utilisé une situation, je n'ai pas pu, nous n'avons pas pu résoudre ce problème alors. C'était une situation décevante, alors j'ai pensé, essayons juste d'utiliser un peu d'espoir ici. Et j'ai dit,
[00:34:00] mais si nous continuons à moderniser ou non, j'ai dit, quand nous aurons terminé la modernisation, ces choses seront très simples. Cela prendrait un mois à faire en ce moment. Si nous terminons la modernisation, ce genre de travail ne prendra que quelques heures. Cela devrait être aussi simple que cela. Ce n'est donc rien de révolutionnaire, mais parfois ces petites interactions, chaque interaction est une chance de combattre un peu la gravité. Et je pense aussi que la peur est un outil que nous devons utiliser. Et c'est un outil parfois très puissant et nous devons rappeler aux gens, nous avons des problèmes en ce moment. Nous avons des incidents, nous avons des bugs, les gens ne sont pas contents de ces choses. Et ceux-ci ne disparaîtront jamais si nous ne terminons pas cette modernisation. Ils pourraient même empirer si nous restons bloqués dans la Vallée de la Mort de la migration d'héritage. Donc, je pense que la peur et l'espoir, des choses que nous pouvons toujours utiliser pour faire de petites améliorations, comme de petites aides au quotidien.
[00:34:54] Et puis il y a la vigilance continue. Et le point ici est que c'est juste une bataille sans fin, ininterrompue, euh, avec la gravité, peu importe à quel point vous modernisez et à quel point vous pensez que la vision est bonne et à quel point vous pensez que les priorités sont claires, les choses essaieront toujours de s'insinuer. Chaque session de planification de sprint. Je suppose que les gens à cette conférence ne font probablement pas de sprint.
[00:35:14] Chaque, euh, Quel est le mot à la mode ces jours-ci pour prioriser dans le monde agile ?
[00:35:22] Euh, la priorisation. D'accord, quel que soit le nom que vous donniez à ces sessions de nos jours où vous faites de la planification et de la priorisation, il y aura toujours une chance que des choses essaient de s'y infiltrer. Et en fait tous les jours, tous les jours dans vos stand-ups. Vous ne faites probablement pas de stand-ups non plus. Mais chaque jour, il y aura des décisions à prendre concernant les priorités. Et les forces de la gravité de la modernisation essaieront de pousser des choses qui ne sont pas de la modernisation. Et vous devez être là et chaque petite bataille compte. Vous pourriez penser, oh, faisons juste cette chose, ça ne prendra que quelques heures ou une journée. Mais si vous multipliez cela sur deux ans, cela peut entraîner d'énormes retards. Et l'autre chose est que si vous commencez à céder à ces opportunités, vous encouragez la promotion d'une gravité anti-modernisation encore plus forte. Ce que vous dites, c'est : oh oui, c'est acceptable de faire des compromis. Nous pouvons faire un peu moins de modernisation pour cette seule chose. Et c'est juste un cycle qui va s'aggraver de plus en plus. Donc la vigilance constante, chaque jour, chaque jour quand vous allez au travail, vous devez penser, je vais combattre la gravité, la gravité anti-modernisation autant que je peux aujourd'hui. Chaque petite décision fera une grande différence cumulée au cours des trois prochaines années.
[00:36:36] Oui, donc juste pour terminer ce point, je pense que la vraie clé ici est que les équipes elles-mêmes doivent être capables de faire cela. Les équipes doivent être alignées au niveau stratégique. Parce que lorsque les équipes reçoivent une demande de quelqu'un qui est en produit, très souvent elles auront l'impression de ne pas pouvoir dire non à cela. Les équipes doivent donc connaître les priorités. Modernisation versus produit, les équipes doivent être habilitées à dire, nous ne pensons pas que ce soit le bon compromis. Les équipes elles-mêmes doivent savoir que ce n'est pas le bon choix, nous devons combattre la gravité ici.
[00:37:12] Je pense qu'une autre chose importante avec la vigilance continue est d'essayer d'identifier la source de cette gravité particulière. Parce que, d'après mon expérience, cela peut venir de n'importe où dans l'organisation. Parfois, il peut s'agir du PDG qui dit une chose au CTO et une autre au CPO. Et donc les managers intermédiaires et les équipes, ils reçoivent des messages contradictoires. Et qu'est-ce qui se passe ? Les équipes feront simplement plus de travail sur le produit et moins de modernisation. N'est-ce pas ? Parce que c'est le choix sûr et il y a généralement plus de pression qui pousse dans cette direction. Mais ce n'est pas toujours le cas. Parfois ce sont les managers intermédiaires. Parfois l'intention au niveau de la direction est bonne, mais les managers intermédiaires ne comprennent pas. Les managers intermédiaires, euh, j'ai entendu des commentaires comme, Je pense que le CTO sera terminé dans six mois et si nous passons du temps à moderniser et que le CTO part à la fin de l'année, nous n'aurons rien à montrer. Donc, si nous continuons simplement à développer des fonctionnalités produit, nous serons sur la bonne voie à la fin de l'année, quoi qu'il arrive, nous aurons quelque chose à montrer. Ce manager intermédiaire ne comprend pas que le travail de modernisation, l'investissement à long terme est tout aussi ou plus important que certains travaux sur le produit qu'il priorise. Et cela peut aussi être les ingénieurs. Les ingénieurs peuvent se mettre dans l'état d'esprit de livrer des fonctionnalités et même les ingénieurs peuvent dire, nous ne voyons pas la valeur de la modernisation, nous ne sommes pas sûrs que cela durera. Il est donc important d'observer réellement d'où cela vient réellement ? Vous pourriez voir une demande d'une personne pour faire quelque chose, mais d'où vient-elle finalement ? part. À la fin de l'année, nous n'aurons rien à montrer. Donc si nous continuons à développer des fonctionnalités de produit, nous sommes sur la bonne voie, à la fin de l'année, quoi qu'il arrive, nous aurons quelque chose à montrer. Ce cadre intermédiaire ne comprend pas que le travail de modernisation, l'investissement à long terme est tout aussi important, voire plus, que certains des travaux de produit qu'il priorise. Et cela peut aussi être les ingénieurs. Les ingénieurs peuvent adopter une mentalité de livraison de fonctionnalités, et même les ingénieurs peuvent dire, nous ne voyons pas la valeur de la modernisation, nous ne sommes pas sûrs que cela durera. Il est donc important d'observer d'où cela vient vraiment. Vous pourriez voir une demande d'une personne pour faire quelque chose, mais d'où cela vient-il finalement ?
[00:38:48] Très bien, donc, le quatrième avertissement
[00:38:52] est que lorsque vous modernisez, la charge cognitive à laquelle vous ferez face, à laquelle votre entreprise fera face, peut facilement dépasser les niveaux que tout être humain est capable de gérer. Et laissez-moi vous expliquer d'où viennent certaines de ces pressions, de ces stress et de ces sources de charge cognitive.
[00:39:15] Donc, un développeur doit peut-être apprendre une nouvelle pile technologique vers laquelle vous modernisez. Un développeur pourrait devoir apprendre une nouvelle infrastructure, de nouveaux fournisseurs de cloud, euh de nouveaux outils d'infrastructure, des choses comme Terraform, par exemple. Ils doivent apprendre de nouveaux outils comme le DDD, et peut-être que vous apprenez d'autres choses aussi, peut-être que vous changez votre processus. Ils doivent encore travailler dans un héritage, comprendre comment il fonctionne et le modifier, corriger les bugs dans l'héritage, mettre à jour les dépendances dans l'héritage. Les équipes sont également attendues pour travailler avec les experts métier afin d'identifier les problèmes dans le modèle conceptuel, pour gérer la dérive sémantique dont nous avons parlé. Nous nous attendons à ce qu'ils développent de nouvelles fonctionnalités, qu'ils gèrent les incidents et les bugs. L'ancien et le nouveau système fonctionnant en parallèle créent plus de complexité, plus de sources de données à synchroniser. En même temps, les équipes ne travaillent pas isolément.
[00:40:06] Il y a d'autres équipes qui se modernisent, et d'autres équipes qui construisent de nouvelles fonctionnalités, et elles pourraient avoir besoin de votre aide. Ils ont besoin de vous pour construire des choses pour eux, ils pourraient créer des bugs qui vous impactent ou vous pourriez créer des bugs qui les impactent. Et donc quand quelqu'un dit, pourquoi les développeurs ne mettent-ils pas plus d'efforts à apprendre la nouvelle pile technologique ou pourquoi les développeurs ne mettent-ils pas plus d'efforts dans ce truc DDD, c'est parce qu'ils ont tout cela en même temps, cette charge cognitive est juste folle.
[00:40:33] Et parfois, oui, quand vous commencez une modernisation, vous rejoignez une nouvelle équipe, et vous entendez une chose de la part de la direction, et puis vous parlez aux développeurs et vous voyez ce qu'ils traversent, vous vous dites, il y a... Je ne sais pas comment cette équipe survit à ça, la charge cognitive est folle d'essayer de faire tout ça en même temps. Mais comme je l'ai dit, ce n'est pas une raison pour ne pas moderniser. Nous devons juste nous assurer d'avoir les bonnes précautions pour gérer ces choses. Et l'une des premières solutions que nous avons est les plateformes. Donc j'utilise la terminologie des topologies d'équipe ici parce que j'aime la façon dont elle représente les deux concepts. Si nous pensons à notre plateforme et à nos équipes alignées sur le flux, ce que nous voulons essayer de faire est de prendre cette charge cognitive des équipes et de la pousser vers les plateformes. Quelles décisions l'équipe doit prendre, quelles étapes l'équipe doit accomplir, si la même chose se produit dans plusieurs équipes, essayons de pousser cela dans la plateforme, supprimons simplement cette charge cognitive des équipes, et elles pourront se concentrer sur toutes les autres choses, c'est une source de charge cognitive de moins. J'ai vu de superbes plateformes et j'ai vu des plateformes horribles, et les mauvaises plateformes peuvent créer plus de charge cognitive, malheureusement. Et je suis arrivé à la conclusion que si vous voulez bien faire les plateformes, surtout lors de la modernisation, vous devez avoir des opinions, je pense que c'est vraiment inévitable. Vous devez prendre des décisions et standardiser certaines choses. Parce que plus vous standardisez, plus vous pouvez pousser cela dans la plateforme et construire des outils autour, et enlever cette charge cognitive aux équipes. Et euh oui, j'ai vu des plateformes bien faites en modernisation, et je pense que cela peut faire une énorme différence. Cela peut vraiment, cela peut être la raison pour laquelle vos équipes ont une charge cognitive trop importante, ou cela peut être la raison pour laquelle votre équipe est capable de se concentrer sur ce qui compte vraiment et d'avoir beaucoup moins de charge cognitive.
[00:42:22] Quelque chose d'autre que je pense être crucial pour lutter contre la charge cognitive, est vraiment de se concentrer sur la décomplexification des choses autant que possible. Comme j'ai donné l'exemple plus tôt avec les segments et leurs microservices.
[00:42:39] Les gens de la technologie, nous pouvons vraiment devenir fous quand on nous donne de nouvelles technologies et des chances de refactoriser et de moderniser les choses, c'est comme un terrain de jeu. Même si nous ne le voulons pas intentionnellement, il y a beaucoup de choses à essayer, de nouvelles idées, de nouvelles techniques, des choses que nous n'avons jamais faites auparavant et nous pouvons en fait créer beaucoup de complexité. Et donc nous avons besoin de quelque chose d'aussi fort qui nous encourage à identifier et à supprimer cette complexité. Et l'une des meilleures choses que j'ai vues récemment, c'est euh quand Nelson a rejoint notre équipe, et il a dit et après un certain temps dans l'équipe, il a dit, nous devrions passer 30 minutes chaque jour à refactoriser les parties essentielles de notre modèle de domaine. C'est là que réside une grande partie de notre complexité, si nous pouvons clarifier le modèle de domaine, utiliser des motifs de manière cohérente, nous allons passer beaucoup moins de temps à avoir des problèmes, euh des incohérences dans le code, réduire certains types de bugs. Et nous faisons ça tous les jours, euh c'est l'un des meilleurs moments de la journée pour moi. Euh les avantages sont que nous améliorons le code. Mais en même temps, toute l'équipe reçoit un message très clair. Dans cette équipe, nous valorisons la refactorisation et la décomplexification. Nous sommes prêts à réunir toute l'équipe pour une session de mobbing de 30 minutes chaque jour afin de réduire cette complexité. Et c'est ce qui est nécessaire, il n'est pas nécessaire d'avoir une session de mobbing de 30 minutes tous les jours, mais vous devez être vraiment concentré sur l'élimination de la complexité qui peut facilement s'accumuler à mesure que vous modernisez.
[00:44:10] Et je pense aussi que quelque chose auquel nous ne pensons peut-être pas toujours lorsque nous parlons de charge cognitive, c'est que nous créons de la charge cognitive. La façon dont nous nous parlons et la façon dont nous nous traitons crée ou supprime la charge cognitive. Et ça ne fait pas de mal parfois, vous pourriez être frustré, c'est très facile d'être frustré, comme si je causais un bug et que cela affectait l'équipe de Christina ou l'équipe de Pierick ou
[00:44:33] euh, comment vous appelez-vous encore ? Max, oui, l'équipe de Max. Parfois, parfois je fais des choses qui causent des bugs dans leur équipe. Et ils ont tout à fait le droit d'être agacés par moi, mais ils disent toujours, oh, ne t'inquiète pas, Nick, euh faisons une session de pair programming, réunissons-nous, nous trouverons le problème et le corrigerons. Même s'ils ont tout à fait le droit d'être agacés par moi et de se mettre en colère et de me causer une charge cognitive, ils choisissent de ne pas le faire, et nous avons tous ce choix. Et je pense que la façon dont vous parlez aux gens fait vraiment une énorme différence. Je pense que cela a un impact énorme sur la charge cognitive à laquelle ils sont confrontés. Comme je le disais avant, toutes ces petites choses chaque jour, comme choisir cette bénédiction, tout s'accumule et la simple façon dont vous parlez aux gens peut avoir un impact énorme. Alors, ce sont les quatre signes avant-coureurs, ce sont mes quatre conseils. Je vais rapidement faire un récapitulatif. Et puis nous pourrons faire quelques questions s'il y a le temps.
[00:45:29] Alors, vous voulez moderniser. Vous voulez moderniser vos systèmes existants et permettre des choses qui ne sont actuellement pas possibles pour votre entreprise. Première question que j'ai pour vous. Qui sont vos Christinas ? Qui sont les personnes qui vont se concentrer sur la réduction continue de cet écart de connaissances et de compétences, en aidant votre entreprise à acquérir les compétences dont vous avez besoin, à les appliquer à des projets réels, afin que vous puissiez réellement moderniser efficacement et ne pas commettre les erreurs qui se produiraient si vous n'aviez pas les bonnes compétences. Si vous n'avez pas ces personnes qui sont vraiment axées sur l'apprentissage et une attention continue à l'apprentissage, Je dirais même de ne pas vous donner la peine, car vous allez vous retrouver coincé dans la Vallée de la Mort, c'est mon opinion sur ce point.
[00:46:12] Le deuxième point concerne les décisions, donc encore une fois, si vous envisagez de moderniser, vous devez regarder autour de votre entreprise et réfléchir aux types de décisions que nous allons devoir prendre. Quelles lignes directrices et quels processus avons-nous pour prendre des décisions ? Quelles personnes dans notre entreprise sont bonnes pour s'assurer que nous suivons les directives, que nous prenons une décision et que nous pouvons nous y tenir. Qui sont les personnes dans votre entreprise ? Si vous ne pouvez pas regarder autour de votre entreprise et voir ces personnes, alors vous devez trouver ces personnes ou vous serez bloqué dans la Vallée de la Mort de la modernisation, la Vallée de la Mort de la migration des systèmes hérités.
[00:46:48] Et puis il y aura cette gravité anti-modernisation, elle sera tout autour de vous quand vous êtes éveillé, quand vous dormez, elle vous poussera à ne pas moderniser. Et vous devez avoir quelque chose avec quoi riposter, pour vous assurer que lorsque les forces s'exercent contre vous, vous pouvez riposter. Et je pense que c'est là que vous pouvez appliquer quelque chose comme le cadre Anti-Fragile. Le cadrage. S'assurer que les gens parlent de modernisation de la bonne manière, cela ne devrait pas être un alignement produit versus technologie sur les objectifs stratégiques. Sommes-nous tous clairs sur ce que nous ne construirons pas dans le produit cette année ? Pouvons-nous être clairs là-dessus pour qu'à tout moment si quelqu'un dit, construisons ceci, il y ait un accord clair qui dise non, nous avons convenu de ne pas faire cela, nous n'allons pas y penser. Ce n'est pas dans le plan. Ensuite, bien sûr, il y a la peur et l'espoir, qui rappellent aux gens et les avertissent. Si nous ne respectons pas ce que nous nous sommes engagés à faire, de mauvaises choses se produiront, mais si nous respectons nos plans, voici ce qui se passera et nous progressons. Nous avons déjà fait des pas vers cela, voici ce que nous pouvons déjà montrer comme progrès. Comme nous avons de l'élan et de la confiance, si nous continuons, nous pouvons avoir encore plus de bonnes choses.
[00:47:57] Alors il y a la charge cognitive. Il va être très difficile pour vos équipes de moderniser avec toutes ces différentes pressions en même temps. Et vous devez penser, vous devez être conscient de cela comme je l'ai dit auparavant dans certaines entreprises, elles ne sont même pas conscientes de ce que c'est pour leurs développeurs, tout le stress et les difficultés auxquelles ils sont confrontés. Et ils se demandent pourquoi nous ne modernisons pas, pourquoi les choses avancent lentement ? Parce que vos développeurs sont complètement épuisés. C'est donc là que nous pouvons utiliser des plateformes. Les bonnes plateformes réduisent la charge cognitive.
[00:48:28] Et nous pouvons aussi nous concentrer sur la décomplexification, comme je l'ai dit auparavant. Je pense que c'est vraiment, vraiment ce qui peut faire une énorme, une révolution, je déteste le mot révolution, je ne voulais pas le dire là, mais je l'ai dit, mais cette concentration sur la réduction de la complexité autant que possible et aussi souvent que possible,
[00:48:45] avoir des gens avec cet état d'esprit, je pense vraiment que c'est crucial. Parce que, encore une fois, la modernisation peut se faire de deux manières. Vous pouvez accumuler encore plus de complexité et de problèmes, ou vous pouvez utiliser la modernisation pour supprimer la complexité et rendre le travail dans vos systèmes beaucoup plus facile.
[00:49:07] Mais ça ne suffit pas. Même si vous faites toutes ces choses très bien.
[00:49:15] Même si vous avez Christina, Pierrick, Max et Yanick, ce n'est toujours pas suffisant pour garantir que votre modernisation se passe bien. Qu'est-ce qui est encore nécessaire ?
[00:49:32] Il faut bien manger. Quand j'ai rejoint Payfit, j'avais quelques doutes, entreprise française, gens français. Pas sûr que ça va être une bonne chose pour moi. Je ne suis pas vraiment sûr de cette euh culture différente, de ce genre de blagues différentes. Mais la première fois que je suis venu au bureau de Paris, euh l'équipe plateforme, ironiquement l'équipe plateforme, ils ont fait ce grand événement culinaire. Ils ont fait de la cuisine la veille au soir. Et ils l'ont apporté au bureau le lendemain. Et nous avons eu ce risotto au chorizo incroyable, il y avait aussi un risotto aux champignons, beaucoup plus axé sur le chorizo moi-même. Nous avons eu un bon déjeuner ensemble avec une vingtaine de personnes qui mangeaient cette excellente nourriture et j'ai pensé, oui, j'ai fait un bon choix, c'est la bonne entreprise pour travailler. Et donc c'est mon principal enseignement pour vous aujourd'hui.
[00:50:20] Si vous mangez bien,
[00:50:23] qui se soucie de la modernisation ?
[00:50:32] Y a-t-il des questions ? Oui. D'accord, nous allons essayer.
[00:50:39]
[00:50:42] Pouvez-vous le donner au gars là-bas ?
[00:50:50] Merci pour la présentation. J'ai une question concernant les sessions de mob programming de 30 minutes. n'est-ce pas trop court, peut-on vraiment faire des choses en 30 minutes de mob programming ?
[00:51:05] D'où vient cette voix ? Je ne peux pas localiser. Ah ici. Ah. Alors, 30 minutes, c'est trop court pour faire une session de refactoring en mob tous les jours ? Euh, j'aurais pu le penser moi-même avant que nous essayions cela et en fait, ma conclusion est non, pas vraiment pour diverses raisons. Euh, l'une des raisons est que nous pouvons travailler sur une partie du code qui n'est pas étroitement travaillée dans d'autres fonctionnalités. Euh, donc nous pouvons travailler sur des choses séparées, donc en termes de conflits avec d'autres choses qui se produisent, ce n'est pas un problème. Nous travaillons sur une branche, nous ne déployons pas toujours les refactorisations tous les jours. Nous pouvons avoir certaines choses sur la branche et c'est bon.
[00:51:45] Euh, en termes de commutation de contexte, pas vraiment un problème non plus, nous avons travaillé dessus hier, et nous pouvons regarder le commit d'hier. Et vous prenez l'habitude de vous souvenir de ce refactoring, c'est comme si je faisais ce travail, mais ce projet de refactoring sur lequel nous travaillons, il reste frais dans votre esprit aussi. Donc, de ces deux points de vue, en termes de conflits de fusion de code, ce n'est pas vraiment un problème. En termes de changement de contexte, oui, parfois vous passez quelques secondes à vous demander, ah oui, qu'est-ce qu'on faisait hier, c'est comme, ah oui, tu as cassé le test, corrigeons les tests, quelque chose comme ça. Alors euh non, je ne pense pas que ce soit un problème de ces deux points de vue. Hum. Qu'en est-il d'autre chose ? Quelles pourraient être d'autres préoccupations ?
[00:52:29] et vous avez le temps de faire le vrai codage, pas seulement d'en discuter et de le coder plus tard, parce que oui, quand je faisais du mob programming, je faisais des sessions de deux heures.
[00:52:38] Et c'est comme un bon moyen d'être dans le euh codage.
[00:52:45] Oui, c'est bon de prendre le rythme. Euh, et nous pourrions faire une session de deux heures par semaine si nous le voulions. Mais je pense que les 30 minutes quotidiennes sont un bon renforcement, cela renforce les habitudes et c'est comme développer ce muscle de la refactorisation, de la décomplexification. Établir un bon signal, c'est comme, oui, nous faisons ça tous les jours, c'est une bonne chose, construisons cette habitude dans l'équipe, donc pour cette raison, je pense que ces compromis fonctionnent très bien. Et je dirais euh que je préférerais, je préférerais faire cela plutôt que la session de deux heures. Peut-être que si nous faisons la session de deux heures, cela pourrait être plus efficace globalement en termes de code que nous réalisons. Mais en termes de construction de l'état d'esprit de l'équipe et d'établissement du signe, les signaux que cette concentration constante sur la décomplexification est importante, je pense que pour cette raison, c'est vraiment crucial. Donc, et je pense aussi qu'avec ces refactorisations constantes, cela reste frais dans votre esprit. Donc, même lorsque nous reprenons le travail sur des fonctionnalités, je le vois aussi chez d'autres personnes, ils ont toujours cette idée, oui, nous avons refactorisé aujourd'hui, c'est toujours dans leur esprit de faire plus de refactoring. Et cela commence à faire partie du travail qu'ils font toute la journée, pas seulement lors de ces sessions. Je pense que même si nous ne fusionnions pas le code dans ces sessions, le simple fait de pratiquer le refactoring tous les jours sur les parties centrales du domaine, sur des morceaux réellement difficiles, je pense que cela seul en vaudrait probablement la peine.
[00:54:07] Vous le faites donc plus pour le changement d'état d'esprit que pour les changements de code.
[00:54:12] Non, non, nous le faisons pour les deux, je dis que je pense que le changement d'état d'esprit seul en vaudrait la peine, mais les avantages du code sont aussi excellents. Euh, nous travaillons sur des parties vraiment essentielles de la base de code, concernant la façon dont nous modélisons le domaine, comment nous faisons des choses comme l'event sourcing, par exemple, en appliquant de bons schémas et les choses que nous apprenons dans ces parties, nous voulons souvent les appliquer aussi dans d'autres parties du code. Pour faire certaines choses de manière standard. Donc je pense que les deux avantages vaudraient la peine à eux seuls, mais ensemble,
[00:54:41] Merci.
[00:54:52] Merci pour les perspectives, salut Nick.
[00:54:57] Non, merci. Merci pour cela, c'est très très instructif et euh je comprends, d'après l'histoire que vous racontez, que vous avez
[00:55:08] euh une grande grande modernisation de toute l'entreprise. Et sinon, vous parlez de mob programming, surtout dans une équipe. J'ai donc vu une sorte de paradoxe entre le besoin de changer toute l'entreprise et surtout toutes les équipes. Alors, avez-vous des conseils pour choisir le combat que nous devons mener maintenant et peut-être pour les prochains mois ?
[00:55:35] Oui, c'est une excellente question, donc vous savez, dans une entreprise avec de nombreuses équipes et de nombreux domaines, le temps est limité quant à l'endroit où vous vous concentrez, il est toujours important d'être
[00:55:45] mettre tout en œuvre pour utiliser ce temps le plus efficacement possible. Je pense qu'en termes de où nous passons beaucoup de notre temps à travailler est lié au travail de modernisation. Ainsi, par exemple, je travaille dans une équipe qui est assez en amont et nous sommes censés produire des événements pour toutes les autres équipes, des événements de domaine, afin qu'elles n'aient pas à interagir avec l'héritage. Donc, évidemment, c'est assez central et fondamental pour d'autres choses, donc y mettre beaucoup d'efforts maintenant a du sens. Mais en même temps, nous avons la communauté des ingénieurs du personnel et les ingénieurs du personnel sont intégrés dans différents domaines et la communauté du personnel se réunit, donc nous essayons de faire progresser toute l'entreprise en même temps. Mais c'est juste que certaines équipes recevront plus d'attention à un certain moment que d'autres, en fonction des priorités et des défis particuliers.
[00:56:37] Donc je pense que dans cet exemple particulier, il s'agissait de la pièce maîtresse qui permettra à d'autres de moderniser plus tard. Nous y mettons un peu d'effort supplémentaire pour l'instant. Mais ensuite, une fois qu'un certain jalon est atteint, euh il se pourrait que Nelson et moi allions travailler dans différentes équipes et que nous nous séparions.
[00:57:04] Dernière question.
[00:57:16] Merci. Merci. Euh, vous avez mentionné la charge cognitive qui peut être assez, je sais, excessive pour les équipes, qui doivent apprendre toutes les choses en même temps et prendre des décisions sur des choses qu'elles apprennent tout juste. Euh, la quantité de choses qu'ils doivent décider peut également être accablante. Et cette plateforme peut prendre ces décisions ou du moins alléger une partie de cette charge. Euh, mais nous voulons aussi, pas spécifiquement ici, mais généralement nous disons que nous voulons que les équipes soient autonomes et capables de prendre leurs propres décisions.
[00:57:48] Euh, donc vous pourriez tomber dans un schéma où la plateforme prendrait des décisions non pas mauvaises, mais des décisions auxquelles l'équipe n'adhérerait pas. Euh, alors comment articulez-vous ces deux sujets ? Euh, alors comment articulez-vous ces deux sujets ?
[00:58:02] Excellente question. Chaque fois que nous parlons de plateformes, nous sommes toujours dans l'espace du compromis et nous avons une plateforme qui sert de nombreuses équipes, qui ont des parcours différents, des points de vue différents, et nous ne pouvons jamais plaire à tout le monde. Et comme je le disais plus tôt, je pense que l'un des premiers principes clés de la plateforme est que nous devons avoir des opinions sur certaines choses, ce à quoi vous faisiez allusion. Et puis la question est, vous savez, où traçons-nous la ligne en termes de ce qui est dans la plateforme et de ce que les équipes possèdent elles-mêmes. Euh j'ai eu une excellente opportunité de travailler pour le gouvernement britannique il y a 10 ans, quand j'ai fait ma première conférence à Flowcon, je travaillais là-bas à l'époque. Et l'un des orateurs qui a parlé à Flowcon, Steve Smith, je recommanderais de consulter son travail sur ce sujet. Il était donc au gouvernement britannique, dirigeant le développement d'une plateforme, et ce fut ma première véritable expérience de plateforme "wow".
[00:58:57] Et je vais expliquer cet exemple, vous n'êtes pas obligé de le suivre, mais en gros, ils se sont standardisés sur Scala. Semblait une bonne idée à l'époque, ne le ferais probablement pas maintenant. Euh, et ils ont standardisé le développement basé sur le tronc, donc vous ne pouviez pas travailler sur une branche de fonctionnalité et la déployer en développement, ce n'était tout simplement pas autorisé. Ils se sont standardisés sur le framework web, qui était un framework de jeu, donc beaucoup de standards. Mais si, mais à cause de ces standards, vous avez tout ce dont vous avez besoin en tant qu'équipe. Il y avait 50 équipes à l'époque et elles pouvaient toutes lancer une nouvelle application en une demi-heure, une heure, quelques heures et la déployer jusqu'en production. En fait, pas en production, mais en staging et ça pouvait être prêt à aller en production, il fallait juste le faire tester d'abord. Vous obtenez tout cela prêt à l'emploi, tout ce dont vous avez besoin pour être prêt pour la production, comme les métriques, la surveillance, la journalisation, tout est prêt à l'emploi. Et depuis que j'ai eu cette expérience, je penche plus vers l'idée que les plateformes devraient être très opinionnées. Cela pourrait contrarier certains développeurs, cela pourrait les contraindre de certaines manières. Mais je pense que le simple fait de pouvoir construire une API et de la mettre en production en quelques jours. Avoir tout ce dont vous avez besoin disponible pour réellement soutenir cela et commencer à construire des fonctionnalités pour moi, c'est un vrai moment 'wow' et je pense que cela ne peut venir que de normes très solides au niveau de l'entreprise. Peut-être que vous aurez des équipes qui sont très douées avec l'infrastructure et qui peuvent la construire elles-mêmes efficacement. Mais la plupart du temps, euh, vous voyez des exemples d'équipes qui euh résolvent le même problème, ayant des variations de processus là où ce n'est pas nécessaire. Et ces équipes pourraient dire, mais oui, nous voulons faire les tests de cette façon, et nous voulons faire les tests de cette façon, et nous voulons avoir cette stratégie de branchement, et nous voulons avoir cette stratégie de branchement. Et c'est là qu'il faut décider, pour nous, en tant qu'entreprise, allons-nous permettre et soutenir ces différentes façons de faire ? Ou bien sommes-nous plus opinionnés et pouvons-nous ensuite pousser cela dans la plateforme ? C'est à votre entreprise de décider, mais personnellement, je suis plus favorable aux plateformes standardisées et opinionnées.

Transcription (Traduit)