Portfolio

2017-2019 : développement de compétences DevOps et force de proposition chez mon client

Contexte : j’ai cherché à consolider les acquis des 2 années précédentes afin d’aider mes clients à optimiser la valeur apportée par les projets informatiques. J’ai pu participer à un grand projet de refonte du système d’information chez un grand compte de l'énergie.

Concrètement : pendant plus de 2 ans, j’ai pris plusieurs actions afin d’améliorer la façon de travailler et de s’approprier nos outils de développement :

  • animations de katas autour du TDD sur le temps du midi, 1 fois par semaine pendant 6 mois.
  • mise en place d’un serveur de build dédié à l'équipe. Auparavant, un autre serveur existait mais mutualisé pour tout le département et avait des limitations qui nous ralentissaient (pas assez de processeurs, espace disque limité). Il m’a paru important que l'équipe reprenne la main sur ce sujet crucial afin de se libérer des contraintes induites par l’ancien mode de fonctionnement.
  • automatisation de tâches régulières chronophages et sujettes à erreur de part l’intervention humaine. Notamment une tâche qui prenait auparavant plusieurs heures s’est transformée en un lancement de script de moins d’une minute et une pull request.
  • référent sur Git et le modèle de branching proche de Gitflow.
  • migration de Team Foundation Server vers Azure DevOps. Référent Azure DevOps pour l'équipe.
  • tech lead de facto sur un projet critique : approche test driven, mono repo et trunk based avec livraison semi-continue (jusqu’aux environnements pré-production où nous n’avions pas la main). Le périmètre complet du projet a été développé en 2 mois à 4 personnes (ETP de 2 personnes environ), avec très peu de bugs grâce à la bonne couverture de tests ainsi qu'à la séniorité et la rigueur de l'équipe.
  • remise en question permanente de la méthodologie, dans un but constant d’améliorer la qualité de fonctionnement de l'équipe et des livrables.

Les points positifs : belle montée en compétences “DevOps” dans un esprit de mieux maîtriser nos outils jusqu'à la livraison en production : Azure DevOps, serveur de build, livraison, archivage et versionnage des binaires.

Ce que je corrigerais avec le recul : savoir mieux reconnaître les batailles perdues d’avance.

2015-2016 : montée en compétences sur le software crafting : force de proposition chez le client

Contexte : dans une grande banque d’investissement, grâce à une prise de conscience au niveau du top management et une très bonne équipe, j’ai pu découvrir et développer des compétences craft pour ensuite devenir force de proposition sur des sujets impactants.

Concrètement : une excellente synergie dans l'équipe où je suis arrivé m’a permis de monter en compétence sur :

  • TDD via la pratique régulière de katas,
  • BDD et comment tirer le meilleur d’une discussion avec des experts métier,
  • DDD pour réduire les couplages forts qui handicapaient nos applications,
  • l’agilité pour éviter de se retrouver coincé dans une méthodologie en l’appliquant sans la remettre en question (notamment sur le sujet des planning pokers et autres techniques d’estimations coûteuses),
  • les valeurs du craft de manière générale, notamment l’amélioration continue et le partenariat avec les utilisateurs, dans la lignée de ce que j’avais vu lors de ma mission précédente.

Suite à cela, j’ai pu mener 2 actions concrètes :

  1. sur le plan de l’agilité et de l’organisation de l'équipe en général, j’ai proposé de passer petit à petit vers un modèle plus basé sur le flux (ex : Kanban) plutôt que de rester sur du Scrum avec lequel certaines cérémonies ne me paraissaient pas adéquates. On a fini par alléger puis supprimer les points de sprint planning qui étaient à la fois ennuyeux pour les intervenants métier et peu utile pour les intervenants IT.
  2. sur le plan technique, pour donner des pistes concrètes de solution au code legacy lourd auquel nous faisions face, nous avons démarré avec 2 collègues sur notre temps libre un prototype visant à mieux séparer les responsabilités de plusieurs composants. Cette initiative a rencontré un vif succès auprès du management mais n’a pas été continuée par la suite par manque de budget.

Les points positifs : ce fut pour moi une période charnière où j’ai pu réaliser l'étendue de l’existant en termes de bonnes pratiques (craft, agilité…). Ce sont des choses qui ont profondément changé ma façon de travailler et ma relation avec mes collègues, qu’ils soient utilisateurs, développeurs ou managers.

Ce que je corrigerais avec le recul : je modèrerais probablement mes envies et mes attentes. J’ai fourni vraiment beaucoup de travail à cette époque, surtout si l’on ajoute les à-côtés pour mon employeur (cf section suivante). J’ai fini par connaître une grosse fatigue et le changement de chef de projet en 2016 a porté un coup dur à ma motivation.

2015-2016 : montée en compétences sur le software crafting : force de proposition chez mon employeur

Contexte : découvrant les valeurs de l’agilité et du craft, je me suis demandé pourquoi personne n’avait essayé de promouvoir tout cela en interne à mon ESN alors que nous étions plus de 120 collaborateurs. J’ai donc monté diverses actions pour sensibiliser la plupart des corps de métier à ces sujets qui me semblaient être l’avenir voire le présent chez les acteurs IT.

Concrètement : en un peu plus d’un an et demi et avec l’aide de mon responsable, voici les actions qui ont été entreprises :

  • présentations sur le TDD, le software crafting, Clean Code. Ces présentations avaient lieu le midi dans les locaux de mon ESN ; une quinzaine de personnes assistaient à ces présentations.
  • invitation d’intervenants externes reconnus sur divers sujets autour du craft. Live coding, refactoring de code legacy, etc…
  • présentation aux internes (commerciaux, direction générale, RH) de notre vision de l'évolution des métiers autour du développement logiciel. Craft, coach, DevOps… autant de mots-clés qui sont aujourd’hui monnaie courante mais ne l'étaient pas forcément en 2015.
  • présentation du craft puis atelier pratique chez d’autres clients, en partenariat avec eux. Nous avons repris divers éléments de nos présentations en interne pour les appliquer dans un atelier avec un kata.
  • création de supports visant à mettre en place un cursus de formation craft pour les nouveaux arrivants. 2 supports ont été créés mais la formation n’a finalement pas vu le jour.
  • organisation de code retreats lors du Global Day of Coderetreat en 2015 et 2016. À chacune des dates, une dizaine de personnes sont venues participer.
  • accord avec les RH pour mettre en place le système “une conférence par an”, dans lequel chaque collaborateur a le droit de participer à la conférence de son choix au titre de la formation.
  • officialisation du compagnonnage, une structure permettant d’accompagner chaque collaborateur dans sa progression et de le récompenser pour ses contributions en interne.

Les points positifs : j’ai beaucoup appris et j’ai vraiment eu l’impression d’aider d’autres personnes à s'épanouir dans leur vie professionnelle.

Ce que je corrigerais avec le recul : comme dans la section précédente, je m’emballerais moins et diminuerais probablement ma charge de travail.

2012-2014 : initiation à l’agilité et la livraison de valeur

Contexte : chez un client de l’asset management, je travaille sur plusieurs projets et suis notamment responsable technique d’un projet de suivi pour le Middle Office.

Concrètement : j’ai pu apprendre les vertus de travailler en direct avec les utilisateurs ou un de leurs représentants, sans intermédiaire et avec une approche respectueuse de chaque côté. On a ainsi pu piloter les changements rapidement, avec livraisons rapprochées sur des environnements de test afin de livrer de la valeur pour les utilisateurs. On retrouve ici plusieurs piliers de l’agilité et du software crafting : individus et interactions, collaboration avec le client, réponse au changement, partenariats productifs, ajout de valeur.

Les points positifs : j’ai pu appréhender sans le savoir une approche concrète de certains points prônés par les méthodes agiles. Je suis ressorti de là avec le sentiment d’avoir réellement pu aider les utilisateurs dans leur travail quotidien et développer une vraie relation entre le métier et l’IT.

Ce que je corrigerais avec le recul : je ferais probablement des points formels un peu plus rapprochés ; on avait une réunion hebdomadaire d’une heure alors que des points de 10-15 minutes 3 fois par semaine auraient été à mon sens plus appropriés. Du point de vue technique, je ne connaissais pas encore les pratiques comme TDD, le BDD et encore moins le DDD, qui m’auraient permis d’aller plus loin à la fois dans la fiabilité de l’application et son architecture.

Avant 2012 : prise de conscience

Contextes : de la startup aux grands groupes, en interne ou en prestation, j’ai pu voir des environnements très divers et me forger ma propre opinion sur la qualité des pratiques utilisées.

Concrètement :

  • une expérience de plus de 6 ans chez un grand éditeur français m’a permis à la fois de voir l’importance des tests automatisés et d’un process de livraison clair, malgré l’utilisation à l'époque d’une approche très waterfall. J’ai aussi pu constater que réinventer la roue était rarement très utile ou profitable…
  • ensuite, mon premier contact avec le monde de la finance m’a fait prendre conscience que toutes les équipes IT ne portaient pas la même attention à la qualité ! Heureusement, un management compréhensif a pu me donner les clés pour avancer sur plusieurs sujets de stabilisation applicative et assainir les relations avec les équipes Ops. J’ai là aussi pu découvrir les vertus du blue/green deployment, ce qui nous a permis de livrer en journée sans interruption de service ni pression dans un environnement international exigeant.
  • l’expérience suivante dans un cadre où le legacy était très présent m’a montré combien il pouvait être difficile de mettre la qualité en avant dans une organisation où l’urgence était la norme depuis des dizaines d’années. En fin de mission, j’ai pu émettre une liste de recommandations qui allaient dans le sens de l’intégration continue, de la philosophie aujourd’hui connue sous le nom de DevOps, utilisation des standards (pas besoin de développer tout en interne), investissement dans les tests automatisés, implication plus forte du métier dans le process pre-release (UAT, specs…), etc…

Les points positifs : je m’aperçois aujourd’hui que j’ai bien mûri à l'époque et pu apprendre au fur et à mesure de chacun de mes postes pour commencer à être force de proposition chez mes clients.

Ce que je corrigerais avec le recul : beaucoup de choses :) Probablement l’arrogance de mes débuts, commune à beaucoup de juniors dans notre métier. Et aussi avoir ignoré si longtemps d’investiguer la piste du TDD malgré plusieurs signaux tout au long des années ; je pensais que la séniorité demandait plus d’expertise technique et ne m’intéressait pas à la méthodologie ou aux pratiques de travail. J’avais tellement tort !