Gérer votre dette technologique lorsque les dirigeants ont besoin de caractéristiques
Hayden Baillio
Droit.
Hayden Baillio
Voyons voir.
Hayden Baillio
Nous sommes en direct et nous attendons les gens ici.
Kelvin Del Monte
Bienvenue à tous.
Hayden Baillio
Oui, j'ai du mal à voir tout le monde. Si vous êtes dans le chat, faites-moi un coucou.
Hayden Baillio
Lancez un "howdy", lancez un "hello".
Ne me lancez pas quelque chose, d'accord ?
Kelvin Del Monte
Vous
Joyeux mercredi à tous ceux qui nous regardent. Joyeux jour de la bosse.
Hayden Baillio
Oui. Oui.
Hayden Baillio
Eh bien, eh bien, eh bien, nous y voilà.
Hayden Baillio
Très bien, je pense que nous devrions commencer.
Kelvin Del Monte
D'accord ? D'accord.
Hayden Baillio
Je veux juste m'assurer que vous êtes au premier plan. Calvin to me to you and my friend center or are you friends in a right now ?
Kelvin Del Monte
Nous sommes tous les deux au premier plan.
Hayden Baillio
Également au premier plan et au centre. J'adore ça. J'aime cela comme nous devrions l'être. Ok, parfait.
Eh bien, nous y voilà. Merci de vous joindre à nous pour cet excellent webinaire où nous allons parler de la gestion de votre dette technologique lorsque les dirigeants ont besoin de nouvelles fonctionnalités. Je vais aller droit au but. Nous n'avons que 30 minutes et je vais donc vous présenter notre intervenant. Mesdames et messieurs, il possède peut-être à la fois la voix la plus douce du monde de la technologie et la rare capacité d'expliquer la dette technique.
sans faire pleurer les cadres. En tant qu'architecte de solutions chez HeroDevs, il a passé sa carrière à transformer des systèmes hérités en plateformes de pointe et à aider les gens à résoudre leur problème de dette technique en la faisant disparaître. Je plaisante. Mais c'est vraiment un homme qui comprend parfaitement les sables mouvants que sont les logiciels en fin de vie, et la place qu'occupe HeroDevs dans la gestion du cycle de vie de ces logiciels.
Et aujourd'hui, il va vous montrer comment livrer des fonctionnalités sans que votre base de code ne s'effondre comme la table pliable de votre dernière réunion de famille, n'est-ce pas ? Veuillez accueillir la voix ASMR de la gestion de la dette technique. Calvin Del Monte. Merci de nous avoir rejoints. Calvin s'en va, mec. C'est tout toi, tu sais. C'est tout toi.
Kelvin Del Monte
Merci beaucoup.
Kelvin Del Monte
Merci beaucoup. Je vous remercie. Merci, Hayden. Je vous souhaite la bienvenue à tous. Je souhaite la bienvenue à tous. Merci d'être venus, de vous être joints à nous. Et pour ceux qui regarderont plus tard, puisque cette réunion, puisque ce webinaire est enregistré, bienvenue en ce beau mercredi. Parlons un peu de dette technique. Avant de commencer, j'aimerais me présenter. Je m'appelle Kelvin Del Monte. Je suis ingénieur en solutions chez Hero Devs. Je suis ingénieur logiciel depuis 2008.
Au cours de ma carrière, j'ai également eu l'occasion de diriger et de gérer plusieurs équipes d'ingénieurs. Et les choses dont je vais parler aujourd'hui sont issues de mon expérience personnelle, n'est-ce pas ? J'ai travaillé dans toutes sortes d'organisations, des grandes, des petites, des startups. Et oui, j'ai beaucoup appris au cours de ce processus en ce qui concerne la dette technique. Et je veux le partager avec vous. Tout d'abord, je pense que nous devrions commencer par ce qu'est la dette technique.
Et, vous savez, c'est à cela que ressemble la mort technique, n'est-ce pas ? Je sais que c'est une représentation populaire, un mème, que je trouve très drôle. Je trouve ça super drôle.
Hayden Baillio
Kelvin, Kelvin, je suis désolé. Je ne pense pas que vous ayez encore partagé votre présentation. Tout va bien. Les gremlins de la technologie. C'est le premier de la série.
Kelvin Del Monte
Désolé, désolé. Je vous remercie. Je vous remercie pour cela. Oui, laissez-moi faire. Oui, pas de problème, pas de problème. Vous devriez donc pouvoir le voir maintenant.
Hayden Baillio
Nous y voilà.
Kelvin Del Monte
Parfait. Oui. Donc, oui, d'abord nous devrions... Je vous ai montré ce mème que vous n'avez pas pu voir tout à l'heure, mais c'est un mème très populaire qui dépeint en quelque sorte ce à quoi ressemble la dette technique. Bien qu'elle ressemble à ceci, elle...
Ce n'est pas toujours comme ça, n'est-ce pas ? La maison n'est pas en ruine comme ça et votre patron vous demande si vous pouvez ajouter une nouvelle fenêtre. Comment allez-vous ajouter une fenêtre si la maison tombe en ruine comme ça ? Mais c'est certainement ce que l'on ressent. Nous en parlerons un peu plus dans les prochaines diapositives. Avant d'aborder ce qu'est la dette technique, nous devrions vraiment parler de...
dette technique qui a inventé ce terme ? qui l'a inventé ? c'est ce monsieur ici présent, M. Ward Cunningham, qui a inventé le terme dette technique en 1992, j'avais trois ans, et il a utilisé cette métaphore alors qu'il travaillait sur un produit financier qui s'appelait "y cash" et "y cash".
Il a utilisé cette métaphore pour expliquer à son patron ce que son équipe vivait au fur et à mesure qu'elle construisait ce logiciel, le logiciel Ycash. Au fur et à mesure du développement, leur compréhension du système et leur opinion sur le système qu'ils construisaient et sur la manière dont ils le construisaient évoluaient.
Ils ont donc commencé à construire d'une certaine manière. Puis, au fil du temps, ils ont trouvé de nouveaux paradigmes, de nouveaux modèles qu'ils jugeaient plus utiles, qui correspondaient mieux au type de travail qu'ils effectuaient. C'est un peu comme s'ils avançaient dans le temps, les décisions qui étaient optimales pour eux au moment où ils écrivaient ce code ou mettaient en place l'application étaient des décisions optimales, mais
Kelvin Del Monte
vous savez, six mois ou un an dans le futur, ils ont évolué en tant que personnes, en tant qu'ingénieurs, et le logiciel a évolué et ils ont évolué dans leur façon de travailler ensemble. Ils ont peut-être de nouveaux outils. Il y a une tonne de choses qui peuvent se produire pendant cette période. Et ils se sont retrouvés dans cette situation où ils cherchaient en quelque sorte dans le code qu'ils avaient construit dans le passé.
Ce code ne correspondait plus à la façon dont ils construisaient les choses aujourd'hui. Il s'agit donc d'une petite équipe de personnes travaillant sur un logiciel. Le code n'avait pas changé. Ils ont changé. Leurs opinions ont changé. C'est ainsi qu'est né le terme de dette technique. Il l'a expliqué par le fait que l'équipe revenait en quelque sorte en arrière et interagissait avec ce vieux code qu'elle avait écrit dans le passé,
Ils ont connu des ralentissements lorsqu'ils interagissaient avec ce code et M. Cunningham, ici présent, l'a expliqué à son patron en disant que c'est un peu comme, vous savez, lorsque vous payez des intérêts sur un prêt. C'est de là qu'est née la dette technique. Je voudrais prendre un moment pour réfléchir à tout cela, n'est-ce pas ? Qu'est-ce qui a créé la dette technique originale ? Ce sont les opinions.
et une évolution de la compréhension de l'équipe, n'est-ce pas ? Et il est important d'y réfléchir parce que, si vous pensez à la dette technique aujourd'hui, elle n'a pas changé.
La métaphore est puissante, si puissante que beaucoup de gens l'utilisent. 30 ans plus tard, 33 ans plus tard, les gens l'utilisent encore. Nous en parlons encore aujourd'hui. C'est super puissant. Et elle est liée à beaucoup d'opinions. Et comme vous le savez, les opinions changent. Et tout le monde en a une. Nous devons donc nous assurer de garder cela à l'esprit. La dette technique est basée sur l'opinion de ce qui est, vous savez, la meilleure approche pour construire un logiciel.
Kelvin Del Monte
Qu'est-ce qui cause la dette technique ? La dette technique est, comme nous venons de le dire, une évolution de la compréhension des membres de l'équipe. Il peut s'agir de n'importe lequel de ces éléments. Au fur et à mesure que vous en apprenez davantage, vos choix antérieurs n'ont plus de sens ou en ont moins que ceux que vous faites maintenant. Décisions à court terme. Vous construisez un projet et vous êtes peut-être pressé par le temps. Vous n'avez pas assez de temps.
et vous ne pouvez pas vous projeter dans l'avenir ou planifier le projet d'une manière qui vous aiderait à voir un peu plus loin ou à planifier à l'avance. Vous prenez donc toutes ces décisions à court terme et elles s'accumulent. Et au fur et à mesure que vous les prenez, vous accumulez de la dette technique. Vous pouvez également faire de mauvais choix d'architecture, ce qui peut être dû à l'inexpérience ou...
C'est très, très courant lorsque vous avez des choix d'architecture et que l'application entière est une sorte de grosse dette technique. Il y a aussi du code désordonné ici et là, des modèles qui viennent de différents contributeurs qui entrent et sortent. La duplication, parfois vous n'avez pas de tests. C'est aussi de la dette technique. Et cela crée de la dette technique. Changements d'équipe. Très, très importants.
en tenant compte de la création d'une dette technique. Vous avez peut-être une équipe qui travaille avec vous. Disons que vous êtes le propriétaire du produit ou la partie prenante et que vous avez une équipe de développeurs qui travaille avec vous sans aucun changement depuis cinq ans. Ils peuvent penser qu'il n'y a pas de dette technique dans leur projet.
Mais il se trouve que quelques ingénieurs partent et que vous en recrutez d'autres qui viennent d'autres environnements. Et pour eux, une fois de plus, c'est une question d'opinion. Pour eux, vous avez une tonne de dette technique qu'ils commencent à dénoncer. Il peut s'agir d'une dette technique réelle ou d'une opinion. Et elle n'est pas fondée, n'est-ce pas ? Il n'y a pas de preuve réelle, ce dont nous parlerons un peu plus tard.
Kelvin Del Monte
Et bien sûr, l'évolution des besoins est très courante. Vous avez des développeurs qui modifient le même morceau de code encore et encore pour augmenter une fonctionnalité, changer un peu la fonctionnalité sans casser leur implémentation précédente. Et cela se fait très rapidement. Les itérations sur ce morceau de code sont donc liées à des décisions à court terme. Beaucoup de décisions sont prises en cours de route.
sur cette fonctionnalité particulière ou sur une partie de votre code source, ce qui entraîne une dette technique. La dette technique est un phénomène naturel. Nous en avons déjà parlé. C'est une évolution, n'est-ce pas ? Au fur et à mesure que vous progressez, vous accumulez de la dette technique. Il n'y a absolument aucun projet sur Terre qui existe ou qui existera jamais, réalisé par un humain ou une IA, qui n'aura pas une sorte de dette technique qui se produit au fur et à mesure que l'on avance.
Comment cela vous affecte-t-il ? La dette technique affecte votre projet, votre organisation, votre produit de plusieurs façons. En matière de sécurité, vous pourriez avoir plusieurs vulnérabilités que vous ne connaissez pas parce qu'elles sont noyées quelque part dans ce code spaghetti ou ce code qui n'est pas entretenu correctement.
Il y a aussi ce problème de vitesse qui est l'une des plus grandes plaintes. En fait, le terme a été inventé à partir d'un problème de vélocité, n'est-ce pas ? M. Cunningham a expliqué à son patron qu'à chaque fois que nous interagissons avec ce vieux code, nous ralentissons. Votre équipe est donc votre équipe d'ingénieurs.
Il est moins rapide parce qu'ils doivent interagir avec ce vieux code qu'ils ne savent pas vraiment comment maintenir ou qu'ils pensent difficile à maintenir. Et cela nuit, cela est parfaitement lié au point suivant, c'est-à-dire que cela nuit au moral des développeurs, n'est-ce pas ? J'ai connu des situations où l'on se trouvait dans un environnement où il semblait que l'application entière était étiquetée comme morte. Et vous avez peur de faire un changement parce que vous pourriez introduire un bogue qui ferait perdre de l'argent à l'entreprise en raison d'un problème de production.
Kelvin Del Monte
n'a pas envie d'être coincé dans un environnement comme celui-là parce qu'il est très stressant et vous savez, honnêtement, la vie est courte, vous voulez faire du bon travail et ne pas avoir à ressentir autant de stress, donc cela coûte beaucoup de stress aux développeurs et cela nuit à leur vie quotidienne au travail.
J'ai donc ici une citation qui dit que les chefs d'entreprise devraient considérer la dette technologique comme un risque de livraison, et pas seulement comme un problème d'ingénierie. Cela fait partie de la façon dont vous obtenez l'adhésion, et nous allons en parler un peu plus en détail dans les prochaines diapositives.
Hayden Baillio
bien.
Hayden Baillio
Kelvin, j'adore cette citation. J'adore cette citation. J'aime cette citation parce que j'ai souvent l'impression que nous parlons avec beaucoup d'ingénieurs qui voient qu'ils ont dû parler avec des chefs d'entreprise dans leur unité qui ne font que repousser cette préoccupation du genre, ouais, ok, nous avons un logiciel en fin de vie, il suffit de le résoudre alors que c'est un problème beaucoup plus important. Il suffit de s'en occuper alors qu'il s'agit d'un problème beaucoup plus important. Ce vieux logiciel, cette dette technologique nous empêche de fournir un meilleur produit, une meilleure expérience ou une meilleure solution. J'ai beaucoup aimé cette citation. C'est génial. C'est plus important. La dette technologique est plus importante que le département d'ingénierie. Et j'aime bien ça.
Kelvin Del Monte
100 % 100 % Il est parfois difficile de faire comprendre cela aux personnes de niveau C ou aux cadres, mais nous devons leur faire comprendre parce que c'est à leur avantage, non seulement pour nous, ingénieurs ou propriétaires de produits, ou pour vous, gestionnaire de produits, non seulement pour nous, mais aussi pour eux, n'est-ce pas ? Nous essayons de nous aider Vous aider fondamentalement dans ce genre de situation
Et la diapositive suivante est un autre mème que j'ai, qui est lié au moral des développeurs, n'est-ce pas ? Vous avez des ingénieurs qui quittent votre entreprise à cause de la dette technique avec laquelle ils doivent interagir. J'ai vu cela se produire à maintes reprises. Et parfois, ce qui est amusant, c'est que la personne qui a créé
La plus grande partie de la dette technique est celle qui s'échappe de la maison sur la pointe des pieds, alors que la dette technique est en train de tuer tous les membres de l'équipe qui restent sur place. Et oui, cela rejoint le fait que certains de ces gars qui partent ne sont pas dans la dette technique, ils sont la dette technique.
Hayden Baillio
Awesome.
Kelvin Del Monte
Oui, ça arrive. Cela arrive. Et cela pousse les gens à quitter votre entreprise, vos équipes, c'est certain, les ingénieurs. Que pouvons-nous faire ? C'est un problème évident. Il nuit à notre entreprise, à nos produits, à nos collaborateurs, au moral de notre équipe. J'aimerais donc passer en revue quelques pièges courants. En fait, nous devrions commencer par ce qu'il ne faut pas faire. Ce sont des choses que j'ai faites dans le passé.
Et je tiens à mettre en garde contre le fait de ne jamais essayer de faire ces choses parce que vous finirez probablement par faire fausse route. Ainsi, la dette technique n'est réparée que de manière réactive. C'est une approche très naïve, qui est l'approche que vous direz à votre équipe. Vous l'entendrez un jour ou l'autre dans votre carrière. Quelqu'un dira, nous allons simplement réparer au fur et à mesure.
Ou si vous êtes dans un fichier et que ce fichier contient une partie de la dette dont il est question ici, alors allez-y et corrigez-la. Non, cela ne fonctionne pas. Cela affecte le champ d'application, cela pose de nombreux problèmes. Cela affecte la portée de ce sur quoi vous travaillez réellement.
ce qui pourrait vous faire manquer une ligne temporelle et votre solution de repli sera, je m'inquiétais de cet autre problème que j'ai trouvé dans le fichier. Cela pollue donc votre champ d'application. Nous ne voulons jamais cela, n'est-ce pas ? Lorsque l'on suit une méthode agile, on veut s'assurer que le champ d'application est bien délimité et qu'il n'y a pas de problèmes de dette technique qui peuvent ou ne peuvent pas se produire.
chaque fois que vous ouvrez un fichier ou que vous travaillez sur une section du code. Ce n'est donc pas quelque chose que vous voulez faire. Il ne s'agit pas d'adopter une approche réactive, mais bien une approche proactive. Il faut absolument adopter une approche proactive. Il faut d'abord l'identifier, puis le planifier, puis l'obtenir, c'est-à-dire l'identifier, l'écrire, obtenir l'adhésion des membres de votre équipe, ce dont nous parlerons plus tard.
Kelvin Del Monte
Et c'est pourquoi il ne faut jamais agir de manière réactive, c'est une mauvaise approche. Ensuite, il n'y a pas de visibilité, ce qui est également un problème si vous le faites de manière réactive. Par exemple, vous savez seulement, ou celui qui a revu votre code que, que ce problème était là et qu'il a été corrigé. Votre équipe ne le sait pas. Il n'y a aucun moyen de le suivre. Donc non, il n'y a pas de visibilité ou de priorités liées à ces problèmes.
C'est aussi quelque chose que vous ne voulez pas faire. Et voici le roi de ce qu'il ne faut jamais faire. C'est l'engagement excessif dans des refactorisations massives. Je l'ai déjà fait par le passé. J'ai participé à quelques unes d'entre elles, en particulier au début de ma carrière, lorsque j'étais moins expérimenté et plus passionné, devrais-je dire. Plus et certainement plus naïf.
dans certaines de ces choses où je voulais utiliser la dernière technologie et je voulais le faire aussi vite que possible sans vraiment penser à l'entreprise, qui est ce qui paie les factures pour vous et vos collègues et qui sécurise tant de choses pour vos familles, vos clients utilisent. C'est ce qui est important. Ce n'est pas cette refonte massive que vous envisagez. Donc cette refonte massive, même si, disons, vous réussissez.
les chances que vous échouiez sont beaucoup plus grandes. Et même les gens qui vous soutiennent dans cette refonte massive que vous pourriez faire à l'avenir, quelque part au milieu de cette refonte massive, quand ils commenceront à détester vraiment leur vie quotidienne, ils oublieront qu'ils vous ont soutenu. Et à cause de toute la douleur qu'ils traversent, un peu comme quand Israël est parti, a quitté l'Égypte et qu'ils regardaient en arrière et disaient, l'Égypte c'était si bien.
Bien sûr, vous êtes au milieu du désert, presque mourant, vous ne trouvez pas d'eau. Bien sûr, vous regardez en arrière et vous vous dites que l'Égypte était un endroit incroyable, n'est-ce pas ? Mais c'est exactement ce qui va se passer. C'est trop. Cela va retarder un peu les choses. Cela empêchera votre équipe de livrer des fonctionnalités parce que tout le monde est sur le pont, en quelque sorte engagé dans cette refonte massive.
Kelvin Del Monte
ce qui est très probable, c'est-à-dire que toutes les chances sont contre vous, vous conduira très probablement à, vous mettra dans une position où vous êtes celui qui a causé cette, cette refonte massive. Et même si vous le manquez de deux jours, c'est une grande réussite. Vous l'avez manqué de deux ou trois jours. Vous vous retrouvez dans une situation où tout le monde a trop souffert et où l'entreprise était en danger, et tout cela à cause de vous ou de la personne qui a soutenu cette refonte massive. Ce n'est pas la bonne façon de procéder.
vraiment. Et si, par hasard, c'est la seule façon viable pour votre équipe de procéder, il doit y avoir une très, très bonne raison. La plupart du temps, ce n'est pas la bonne façon de procéder. C'est une chose que j'ai apprise au cours de ma carrière. J'ai mis cette citation ici : "L'enfer est pavé de bonnes intentions". Vous pouvez avoir les meilleures intentions pour ce remaniement.
Mais écoutez, il ne s'agit pas de vous ou de votre ami qui veut utiliser la dernière technologie. Il s'agit de votre équipe. Il s'agit d'obtenir un consensus avant d'aller de l'avant. Vous devez vous assurer que vous faites les choses d'une manière méthodique avec laquelle tout le monde est d'accord, et pas seulement avec vos bonnes intentions. Cela vous mènera sur un chemin terrible, terrible.
Bon, passons aux tactiques qui fonctionnent. Je les ai essayées et elles fonctionnent à merveille. C'est en quelque sorte l'inverse de ce dont nous venons de parler. Nous allons donc les aborder en détail, mais je vais simplement les énumérer ici. Suivre la profondeur, s'endetter visiblement, estimer, obtenir l'adhésion de l'exécutif, puis exécuter, ce qui est le concept de ce rédacteur. C'est une façon un peu nuancée d'exécuter, mais j'en parlerai dans un instant.
Et que, si nécessaire, vous devez faire appel à une aide extérieure. Il n'y a pas lieu d'en avoir honte. En fait, dans notre organisation, c'est une sorte d'avantage pour les employés. Nous en reparlerons dans un instant. Voilà, c'est bon. Suivre la dette de manière visible. J'ai mis ces points ici pour vous. Vous devez donc vous faire entendre.
Kelvin Del Monte
Vous devez être très clair avec toute votre équipe au sujet de la dette. Si vous estimez que l'équipe doit se pencher sur une question, vous devez l'évoquer. Parlez-en lors de vos sessions d'équipe. Que ce soit en stand up, peut-être dans la rétrospective, peut-être que vous avez quelque chose, peut-être dans le backlog grooming, vous pouvez commencer à dire certaines de ces choses. Trouvez un espace où vous pouvez...
Il est important de rappeler certaines de ces choses et d'en faire part à votre équipe. Vous voulez savoir ce qu'il en est de votre équipe, ce qui nous ramène à la question de l'opinion depuis le début. Vous pouvez avoir l'impression que ceci est mort, mais vos collègues peuvent vous expliquer pourquoi ce n'est pas mort et peut-être que vous n'avez pas lu une partie de la documentation. Peut-être ne connaissez-vous pas cette partie du code et ne savez-vous pas pourquoi elle a été écrite de cette manière. Et il y a...
de la documentation qui vous facilitera la vie. Elle n'est peut-être pas morte. Vous devez d'abord obtenir un consensus sur la question de savoir s'il s'agit d'une dette officielle que votre équipe considère comme morte et qui peut être marquée comme telle, n'est-ce pas ?
Pour s'améliorer, pour avoir cette visibilité, il faut y penser. Il doit figurer sur votre tableau de bord. Il doit figurer quelque part dans votre carnet de commandes. Il doit être discuté lors des séances de toilettage du carnet de commandes, sinon il sera oublié. Ainsi, en tant qu'ingénieur, en tant que gestionnaire de projet ou de programme, vous consacrez peut-être du temps à plusieurs projets.
ou un propriétaire de produit, par exemple, tout le monde, et même certains cadres, à mon avis, regardent votre outil de carnet de commandes ou vos outils de gestion de projet. Il peut s'agir de Jira, Santa, Trello, Monday, n'importe lequel de ces outils.
Kelvin Del Monte
Ils ont une grande visibilité. En fait, ils existent pour vous permettre de faire votre travail et de l'organiser. La technologie, pardon, la dette technique doit absolument être consignée ici et consignée d'une manière qui permette d'agir. Ainsi, lorsque vous documentez la dette, vous devez collaborer avec votre chef de projet ou votre responsable technique.
ou si c'est vous-même, alors collaborez avec votre gestionnaire de projet pour enregistrer ces données et mettre toutes les informations que vous pouvez pour les rendre exploitables, d'accord ?
Il n'est pas nécessaire de le faire en une seule fois, mais c'est à cela que sert le toilettage du carnet de commandes. Saisissez les détails et peaufinez-les au fur et à mesure. Veillez à ce qu'il soit exploitable et séparez-le en créant, par exemple, un Epic. Je l'ai déjà fait par le passé en créant un Epic dans JIRA ou dans d'autres outils. Et c'est un Epic avec, vous savez, pas un Epic qui tourne en permanence. C'est une Epic où il y a un nombre limité de tâches qui sont là pour résoudre un problème.
et vous pouvez le traiter de cette façon. Veillez donc à l'organiser comme vous l'entendez dans d'autres environnements pour lesquels nous avons déjà utilisé des étiquettes, des environnements très chargés en étiquettes qui utilisent beaucoup les étiquettes JIRA. Nous les avons déjà utilisés. Quelle que soit votre organisation, assurez-vous qu'elle est organisée et visible par votre équipe et qu'elle est abordée lors de vos sessions d'équipe. La visibilité est mortelle.
en quelque chose que vous pouvez réellement prioriser et sur lequel vous pouvez travailler. On ne peut pas réparer ce que l'on ne voit pas. Loin des yeux, loin du cœur.
Kelvin Del Monte
D'accord, parlons d'abord de l'estimation des coûts. Votre dette est en quelque sorte déjà visible, votre équipe en parle, et vos sessions de toilettage du backlog y consacrent du temps.
Vous savez, vous pouvez faire des points d'histoire, vous pouvez faire d'autres estimations, mais tout se résume à une sorte de coût, n'est-ce pas ? Cela vous permettra donc de prendre cette tâche que vous jugez importante, qui ralentit votre équipe, et de la présenter à votre équipe de direction, ce qui est la prochaine chose dont nous allons parler. Vous voulez vous assurer que, vous savez, les cadres, c'est ce qui leur importe, c'est...
Dans quelle mesure est-il possible d'entreprendre ce que vous voulez faire ? Et ils veulent, vous savez, penser en termes de chiffres. Ils veulent peser le pour et le contre et voir si cela a du sens de prendre des mesures pour cette dette.
ou s'il s'agit de quelque chose qui peut être reporté à l'avenir. Il faut donc leur donner ce coût, que ce soit en temps ou sous la forme d'une estimation que l'équipe de direction comprendra. Vous devez vous assurer que vous travaillez en partenariat avec votre équipe et avec votre chef de projet pour vous assurer que vous préparez ces histoires de dette technique et que vous y mettez une sorte d'estimation.
Et bien sûr, cela vous mènera sur le chemin où vous aurez une ou plusieurs épopées de la dette technique très soignées que vous pourrez présenter à votre équipe de direction. Ensuite, vous pouvez obtenir l'adhésion, c'est-à-dire l'autorisation de commencer le travail et une sorte d'orientation sur la manière et le moment où nous pouvons nous permettre de commencer ce travail. Voici quelques-uns des exemples que j'ai donnés.
Kelvin Del Monte
Ce bogue existe parce que ce sont toutes des choses qui me sont arrivées dans le passé où j'ai soulevé quelque chose comme, hey, pourquoi ce bogue s'est-il produit ? Eh bien, le bogue s'est produit parce que nous n'avions pas de tests unitaires ici. Nous n'avions pas de couverture des tests d'intention, ce que nous demandions. Il faut donc leur en parler. Voilà pourquoi la dette technique, voilà comment la dette technique vous affecte, vous et vos résultats. Et je vous assure qu'ils vont prendre la dette technique beaucoup plus au sérieux, n'est-ce pas ?
lorsque vous l'évoquez. À ce stade, vous disposeriez d'une pile de tâches totalement exploitables auxquelles seraient associés des coûts, ce qui vous permettrait d'obtenir plus facilement l'adhésion des dirigeants dont vous avez besoin lorsqu'ils vous demandent de livrer les fonctionnalités. Vous devez traduire votre douleur, votre douleur d'ingénieur, votre douleur de gestion de projet en quelque chose qu'ils comprennent. Rapidité de livraison, risque, savoir, risque sur la livraison de fonctionnalités qui rapportent de l'argent à l'entreprise.
Enfin, maintenant que vous avez obtenu l'approbation, comment devez-vous exécuter le projet et aller de l'avant ? Vous avez obtenu l'approbation de votre équipe de direction pour aller de l'avant. Maintenant que vous avez obtenu cette approbation, il se peut qu'elle ait été trop souple. Ils ne vous ont pas donné de conseils et vous ont laissé faire ce que vous vouliez. Cela nous ramène aux choses à ne pas faire ou à ne pas faire, c'est-à-dire à l'absolu.
Ne procédez pas à une refonte massive. Faites-le comme ceci, des rédacteurs. Au lycée, j'ai appris qu'au sein du gouvernement américain, ou du Congrès, devrais-je dire, il existe ce concept de rédacteurs, c'est-à-dire de petits projets de loi qui sont attachés à de grands projets de loi qui sont sur le point d'être adoptés, ou qui ont fait l'objet de beaucoup de travail.
Et ils attachent ces petites factures qui n'ont parfois rien à voir avec la facture plus importante qui est attachée, à laquelle ils sont attachés. Il faut donc aborder la dette technique de la même manière, c'est-à-dire en réservant quelques cycles à chaque sprint. Cela vous permet de continuer à livrer vos fonctionnalités tout en réduisant la dette technique. Je sais que parfois vous ne pouvez pas faire cela. Il se peut que vous ne puissiez pas le faire, mais cela devrait être l'approche optimale.
Kelvin Del Monte
Procédez par petites touches, de manière à obtenir de petites améliorations continues. Il est certain qu'elles s'accumuleront à 100 % avec le temps. Que ce soit sur une période de six mois ou d'un an, vous verrez la différence. Tout en continuant à livrer des fonctionnalités, votre application sera beaucoup plus saine. Et tout le monde est content. Vous êtes heureux en tant que responsable. Votre équipe est heureuse parce que vous agissez en tant que chef ou en tant qu'équipe.
et vos parties prenantes seront évidemment satisfaites parce qu'elles envoient des fonctionnalités.
Cela m'amène à la dernière suggestion, qui est de faire appel à une aide extérieure si nécessaire, et c'est là que nous entrons en jeu. Nous aidons, je vais en fait parler de ce que nous faisons exactement dans la prochaine diapositive, mais c'est notre pain et notre beurre. Vous pouvez donc faire appel à une entreprise comme la nôtre pour vous aider avec votre dette technique.
Nous allons nous concentrer sur cela pendant que votre équipe est, vous savez, en train d'expédier des fonctionnalités. C'est très utile pour les mises à jour massives ou si vous êtes dans l'enfer des dépendances de support et, ou si vous devez, vous savez, faire une réécriture profonde dans une autre technologie ou un autre langage. Nous pouvons vous aider à cet égard et vous pouvez certainement faire appel à une aide extérieure. Cela améliore le moral des développeurs car c'est un peu comme un avantage de la part de votre entreprise. Vous êtes ingénieur. Vous pouvez continuer à développer des fonctionnalités.
votre entreprise fait appel à une aide extérieure pour faire les choses que vous ne trouvez peut-être pas si intéressantes, c'est-à-dire résoudre toute cette dette technique. Il est donc très important de toujours envisager de faire appel à des spécialistes. J'aimerais vous parler un peu de nous, Hero Devs. Nous existons depuis 2018.
Kelvin Del Monte
Nous avons 800, plus de 800 clients parmi les entreprises Fortune, beaucoup d'entre eux parmi les entreprises Fortune 500, Fortune 100. Nous sommes spécialisés dans le soutien des logiciels en fin de vie dans de nombreux domaines. Nous avons une équipe formidable, absolument formidable. Nous faisons ce travail depuis longtemps. Voici quelques-unes des entreprises qui travaillent avec nous. Il s'agit d'une...
vous savez, une diapositive qui rassure, comme l'appellent mes collègues, qui vous montre, vous savez, que nous sommes en affaires. Nous avons travaillé avec toutes ces entreprises et les avons aidées à effectuer des migrations. Nous aidons également ces entreprises d'une autre manière, par le biais de notre NES (Neverending Support).
qui est une ligne de produits. Nous l'appelons simplement NES. Cela permet donc de résoudre la dette technique d'une manière différente. J'aimerais prendre comme exemple la migration AngularJS Twangular. Beaucoup d'équipes, peut-être si vous avez construit votre application en 2010,
En 2011, vous utilisiez probablement AngularJS. Mais le temps que vous finissiez votre produit, ils étaient déjà passés à Angular. Vous ne pouviez donc pas, peut-être n'aviez-vous pas les ressources nécessaires pour migrer vers Angular. Que faites-vous alors ? Vous êtes maintenant coincé en dehors du support. Eh bien, le support sans fin se marie très bien avec notre, évidemment nous pouvons vous aider à migrer, mais vous n'avez pas besoin de migrer.
Nous allons étendre le support pour beaucoup de ces bibliothèques que vous voyez ici et plus encore. Si vous nous contactez, nous en avons encore plus dans notre offre. Et oui, nous pouvons vous aider à maintenir le support de votre logiciel en fin de vie que vous utilisez ou de votre bibliothèque. Cela permet également d'éliminer la dette technique forcée, c'est-à-dire que la technologie que vous utilisez n'est plus prise en charge. Cela crée donc en quelque sorte cette dette pour vous. Donc oui, nous sommes...
Kelvin Del Monte
Nous élargissons sans cesse notre offre et, oui, je pense que Hayden, combien de produits avons-nous lancés au cours de l'année écoulée ?
Hayden Baillio
L'année dernière, nous avons sorti plus de 20 nouveaux produits NES. Je pense qu'il est intéressant de voir qu'une grande partie de ces nouveautés ont été créées par nos clients et par les personnes que nous aidons déjà avec la bibliothèque Interlife et qui viennent nous voir pour nous dire : "Hé, nous avons besoin d'aide pour cela aussi. Pourriez-vous tous le faire ? Nos clients actuels sont donc à l'origine d'un grand nombre d'affaires ou de nouveaux produits.
Oui, je suis toujours prêt à entendre parler de nouveaux besoins. C'est certain.
Kelvin Del Monte
Oui, il y a beaucoup d'intérêt et bien sûr, si je viens chez Hero Devs en tant que client et que je suis confronté à une migration massive que je ne peux pas faire, c'est une bouée de sauvetage. Donc oui, vous n'avez rien à faire. Vous pouvez continuer à livrer des fonctionnalités même en fin de vie. Même en maintenant votre logiciel en fin de vie parce qu'au moment où vous achèterez la NES, elle ne sera plus en fin de vie.
Quoi qu'il en soit, voici les derniers conseils et enseignements à tirer. Commencez petit, assurez-vous de rendre votre dette technique visible. Intégrez-la dans la livraison autant que possible. Demandez de l'aide extérieure si vous en avez besoin. Et ne cherchez pas à avoir une dette nulle. C'est normal. C'est une partie naturelle de la construction d'un logiciel. Elle sera toujours présente. Il suffit de la gérer. Je vous remercie pour votre temps et je passe la parole à Hayden pour la conclusion.
Hayden Baillio
Oui, non, merci beaucoup, Kelvin. Merci d'avoir fait le tour de la question. La dette technologique est vraiment quelque chose que tous ceux à qui nous avons parlé et qui est répandu partout, n'est-ce pas ? On ne peut pas échapper à la dette technologique. Je pense que le dicton que nous avons commencé à adopter ici est comme, vous savez, si vous adoptez l'open source, alors vous adoptez la dette technologique. C'est comme ça. C'est comme si vous adoptiez la dette technologique future. Et je pense que vous avez donné de très bonnes idées. Nous publierons très probablement l'enregistrement sur notre YouTube. Merci à tous de vous être joints à nous.
Je sais que nous avons dépassé les sept minutes, nous allons devoir, vous savez, si vous avez des questions, veuillez contacter les personnes qui, vous savez, vous ont invité à ce webinaire ou, ou contacter, Kelvin en particulier si vous le souhaitez. Kelvin, quel est votre, quel est le bon endroit où les gens peuvent vous joindre s'ils ont des questions à ce sujet.
Kelvin Del Monte
À ce stade, vous pouvez m'envoyer un courriel, kelvin at herodevs.com. Je serai heureux de vous répondre et de me mettre en relation avec vous.
Hayden Baillio
Kelvin at Herodotus.com. Merci beaucoup et merci à tous d'être venus. Merci, Kelvin. Restez en sécurité et commencez à planifier la façon dont vous allez gérer votre dette technique. Paix, héros.
