Les températures actuelles vous rappellent vos vacances au soleil ? Pour vous remettre dans le bain et faire la transition avec vos lectures estivales, je me suis dit qu’il était temps (enfin) de sortir cet article.
En Avril dernier s'est déroulée l’édition 2023 de Devoxx France et en tant que développeur qui aspire à devenir agiliste, je me devais de tirer le maximum de cet événement dont il émane tant de connaissance utile.
Je vous propose donc un florilège de retours sur les conférences, keynotes et autres quickies auxquels j'ai pu assister.
Tout d'abord, commençons par celles qui touchaient directement à l'agilité.
Mob et Extreme programming : REX d’une développeuse junior - Marjorie AUBERT
Durant un Quickie (15 min.) Marjorie Aubert nous a présenté son expérience autour d’Extreme Programming et du Mob en tant que junior et de la manière dont ils ont intégré ces pratiques dans son équipe.
Tout d’abord, Marjorie et son équipe ont fait le choix de passer par l’utilisation d’un monorepo sans utiliser de branche. Cette pratique couplée à l’utilisation de feature-flag pour les déploiement ont permis une prise en main plus facile par les juniors de l’équipe.
Durant leurs sessions de Mob Programming, ils se sont essayés au TDD. Mettre en oeuvre cette pratique leur a apporté plusieurs avantages :
- Segmenter les problématiques par usage de “petits pas”
- Mieux comprendre ces dernières (par la retranscription de leur compréhension via l’écriture du test avant l’implémentation de la feature en tant que telle)
- Mettre en place une documentation vivante (à traver des tests clairs)
- Faciliter et avoir confiance en leur refactoring
Elle a également présenté les points d’attention à surveiller sur du Mob.
Le fait d’avoir un espace dédié à cette pratique (en présentiel ou à distance),
Adapter son rythme à son équipe et l’ajuster aux différents besoins.
Faire en sorte que le junior passe plus de temps sur le clavier pour s’assurer du bon énoncé et de la compréhension de la solution/problématique.
Prioriser la communication et l’écoute égale entre tous les participants.
Et enfin prévoir des pauses fréquentes, l’exercice du Mob, par les changements de rôles et l’attention constante, peut être éprouvant.
Pour finir nous avons pu faire un constat de ce que le Mob peut apporter,
Techniquement :
- Une simplification du code
- Une connaissance partagée
- Des Seniors et Juniors qui challengent leurs acquis/habitudes
- Un code adapté au contexte et plus compréhensible
En terme de productivité :
- Un apprentissage continu peu importe le niveau d'expérience
- Moins ou plus de review de code
- Des livraisons de valeur plus rapides et fréquentes
En parlant de valeur, nous pouvons conclure avec les valeurs que promeuvent ces pratiques, le respect, la communication, la simplicité, l’humain. Et si la recette est correctement suivie (avec les adaptations nécessaires à votre équipe) cela devrait vous apporter une meilleure cohésion et un apprentissage rapide et efficace.
Lectures recommandées :
Extreme Programming Explained - Kent Beck
Code with the wisdom of the crowd - Mark Pearl
Bâtir des équipes d’ingénierie logicielle mémorables. - Jean-Laurent DE MORLHON
Jean-Laurent est à son tour venu nous parler de son expérience en tant que VP Engineering chez Docker et plus précisément de l’objectif qu’il s’est fixé :
“Faire en sorte que son équipe d’Engineering soit la meilleure possible, et qu’on s’en souvienne”
Pour avoir un contexte, on parle ici de l’organisation d’un groupe d’environ 180 individus, répartis dans 15 pays autour du globe, qu’il va falloir aligner, synchroniser et mettre en collaboration. Et pour ce faire …
Des Valeurs
Inspiré par les valeurs présentées dans le livre Extreme Programming Explained de Kent Beck, qui sont : Simplicité, Communication, Feedback, Respect et Courage. Il a, avec son équipe, défini quatre valeurs qui leur sont propres afin qu’ils puissent se les approprier et leur donner du sens. Ces valeurs sont :
- Developer obsession :
Leurs clients finaux étant les développeurs, ils mettent un point d’honneur à se mettre à la place de ces derniers, collecter leurs feedbacks, comprendre leurs besoins. Chaque décision est “customer-centric”, et à pour but de favoriser la simplicité.
- Bias considered actions :
Cette valeur prônant la mise en mouvement rapide suite à une décision prise implique de ne pas avoir peur de se tromper, de s’en rendre compte rapidement et de rebondir.
- Humility :
Rien de transcendant me direz vous, mais il est bon de rappeler que le monde de la tech n’a pas besoin de ses éternels combats de coqs (“Ma techno elle est mieux que la tienne” 😇). Chacun doit connaître ses limites et embrasser une collaboration dénuée d’égo, accepter tout feedbacks pouvant pousser le collectif vers le haut et reconnaître que quiconque puisse faire des erreurs.
- Open collaboration :
Ce type de collaboration implique une manière singulière de communiquer, si l’on doit poser une question, on la pose à toute la “boite”. Cette manière de faire encourage l’interaction à travers les équipes, les fonctions et les zones géographiques. Tout cela apportant des feedbacks, des opinions, de la transparence au travers des équipes et de nouvelles manières de challenger ses idées.
Ces valeurs sont revues tous les trimestres pour s’assurer qu’elles sont toujours en adéquation avec les équipes qui les portent. Parlons en, de ces équipes …
Topologie d'équipe
Ici, l’idée de base est que l’équipe est la pièce principale, pas l’individu. Il reste important mais c’est l’équipe en tant que collectif qui “fait”, qui porte sa mission et elle doit être autonome dans l’accomplissement de cette mission. Le plus important dans cette autonomie est de laisser au personnes qui sont le plus proche du problème la capacité de résoudre ce dernier.
Une équipe autonome se doit donc d’être pluridisciplinaire pour résoudre ces fameux problèmes, en exemple : une équipe composée d’un Product Manager, un UX Designer, un Engineering manager et de plusieurs Software Engineers. Bien évidemment cet exemple varie en fonction du besoin et de la mission de l’équipe (Data, Sécurité, Front, Back, …)
Afin d’approfondir ce sujet, Jean-Laurent nous conseille la lecture de Team Topologies de Manuel Pais & Matthew Skelton, un ouvrage traitant de l’organisation des équipes et de leurs collaborations.
Pour résumer :
- Une structure par défaut des équipes (modulable, ce n’est qu’un template)
- Un alignement des objectifs de l’équipe avec ceux de l’entreprise
- Des équipes autonomes, responsabiliser et ne pas brider ces équipes
- Itérer sur les frontières/limites/scopes des équipes et les adapter afin de faciliter les interactions
Maintenant qu’on a parlé des équipes, parlons des individus …
Impact Managers et Ingénieurs
Une fois que ces fameuses équipes sont construites et qu’elles collaborent efficacement et suivant des valeurs communes, nous pouvons nous intéresser à la manière de faire grandir les individus de ces équipes et pour cela, notre VP Engineering a mis en place deux échelles d’évolutions.
L’une est propre aux Individual Contributors (IC), qui sont les développeurs, ingénieurs et autres “faiseurs” de l’entreprise.
Et l’autre propre au Managers de l’entreprise.
L’idée derrière cette séparation est que tout ingénieur n’aspire pas nécessairement à devenir manager, et que de cette manière il peut évoluer en accroissant son rayonnement au niveau de son équipe, son département et même celui de l’entreprise.
Chaque niveau de cette échelle est acquis grâce au leadership et au rayonnement dont l’individu fait preuve par ses compétences techniques et sa capacité à les communiquer.
La finalité de ce découpage est d’avoir des évolutions de carrière pouvant convenir à un maximum de profils tout en gardant une équivalence de statut entre les personnes souhaitant devenir manager et celles souhaitant rester sur une expertise technique, ainsi qu’une équivalence au niveau des grilles de salaires. On cherche à pousser les individus à évoluer, devenir leader, pas manager.
Lecture conseillée à ce sujet : The manager’s path par Camille Fournier, un ouvrage instructif pour les managers ET les managés.
Remote
Ces fameux individus sont tous en remote chez Docker Inc. Cette décision de passer en “full remote” est prise suite au constat des bureaux qui se vidaient de plus en plus au fil des semaines suite au Covid.
Pour notre VP en question, cela a changé les choses en matière de management. Avant cela, faire un tour dans une salle permettait de prendre la température d’une équipe, untel tire une figure de trois pieds de long, untel est à fond dans sa tâche en cours, untel à besoin d’aide etc. Désormais, c’est un enchaînement d’appels vidéo avec qui voudra bien mettre sa caméra. En tant que manager cela change drastiquement la manière dont il doit s’organiser.
En plus de cela, les employés de Docker sont situés dans des zones géographiques très différentes, de la Roumanie jusqu'à la côte Ouest Américaine. Ce delta de 10h entre deux individus, vous vous en doutez, rend la création et l'orchestration de ces équipes nettement plus compliquées. Ajoutant à cela les différences culturelles intra-équipes, ainsi que dans la relation manager/managé.
Le remote force également une revisite de la question du salaire, car il vient bouleverser les frontières géographiques et autres limitations qui forcent les entreprises à s'aligner avec les autres entités avec lesquelles elles sont en compétition.
Lecture conseillée à ce sujet : Remote Office not Required par Jason Fried et David Heinemeier Hansson
Pour conclure, Jean-Laurent nous invite à nous poser quatre questions :
- Quelles sont les valeurs de mon groupe ?
- Quelle est ma stratégie de topologie d’équipe ?
- Quelle est la fonction de mes managers ?
- Comment tirer partie au mieux du remote ?
Indice : les réponses sont en partie dans les livres cités au cours de la présentation 😇
L'étonnante efficacité des petits pas - Philippe BOURGAU
Ce n’est sûrement pas la première fois que vous entendez parler de ces fameux Baby Steps (petits pas), Philippe Bourgau, coach agile, est venu nous prouver leur efficacité.
Il nous a introduit aux Baby Steps avec une image assez parlante :
Il est tard, votre fils refuse d’aller se coucher et en plus de cela n’a pas rangé ses briques de LEGO qui tapissent le sol. Le chenapan, assis sur son lit de l’autre côté de la pièce… éteint la lumière !
Deux options s’offrent à vous :
Je pense que vous avez saisi l’idée, et bien dans un projet technique ce n’est pas si différent, c’est même encore plus flagrant. Entre les problèmes de communication, de specs, de CI, de bugs, de tests, de gestion de projet, de build, cela fait un beau nombre de briques de LEGO sur lesquelles on peut atterrir, surtout si on y saute la tête la première.
Suite à cette introduction, Philippe nous a guidé à travers plusieurs ateliers ayant pour but d’échanger avec nos voisins, puis avec l’assemblée, nos expériences avec les Baby Steps. Nous avons entendu différentes histoires, sur de la communication, du développement, du déploiement continu, pour cela, pas le choix, il fallait y être. 🤫
Vient ensuite l'expérience de notre speaker, dans ses premières années en tant que développeur il faisait beaucoup d’erreurs d'inattention, on lui disait : “Il est ok ton code, mais bon t’as encore pas mal de bugs”. Se connaissant, il sait que se “forcer” à faire attention n’aurait pas fonctionné, il lui fallait trouver un moyen de changer sa manière de faire.
C’est là qu’intervient une nouvelle lecture: Refactoring de Martin Fowler.
En parcourant ses pages, il est tombé sur une explication du TDD et la conception des Baby Steps selon l’auteur et introduire ces concepts à son travail a pu pallier ses soucis d’inattention.
Au fil des années, sa maîtrise de ces pratiques s’est renforcée et il a pu les mettre en application au niveau de son équipe. Cette application, même sur des tâches de refactoring important de code legacy, a permis de travailler de manière plus sûre et sans accros pour aboutir à un code plus propre et aussi plus robuste.
Finalement, les petits pas permettent beaucoup de choses, ils permettent de livrer plus tôt une version basique correcte et d’ajouter de la complexité par la suite, ils permettent aussi de réduire le stress car tout fonctionne toujours (quand les petits pas sont maîtrisés), ils permettent enfin de découper de grandes tâches de refactoring de code comme une séquence de petits pas, simplifiant ainsi le planning, le suivi, la communication, etc.
Pour nous aider à mettre en place ces petits pas un peu plus rapidement, Philippe nous invite à utiliser la pratique délibérée. Ayant pour exemple le TCR : Test and Commit or Revert, qui est une pratique restrictive mais efficace pour comprendre les petits pas. On écrit nos modifications, on lance les tests, si les tests passent on commit nos changements, sinon, nos changements sont annulés. C’est rude mais ça fonctionne, à vous d’essayer !
A la découverte d'Accelerate - Geoffrey GRAVEAUD
Prenez à présent votre lampe frontale et vos chaussures de randonnée, nous partons à la découverte d’Accelerate avec pour guide Geoffrey Graveaud, un consultant Accelerate / DevOps qui se passionne pour ce sujet depuis un peu plus de deux ans.
Note : Cette présentation concerne la version d’Accelerate de 2018, il y a eu quelques changements depuis.
Accelerate est un livre, pas un framework, pas une solution miracle. Un livre qui résume 4 ans d’investigation autour du DevOps pour répondre à la question suivante :
Comment prouver que l’utilisation des concepts DevOps ou Lean sont des investissements et non des coûts ?
Pour tenter de répondre à cette question, 23 000 personnes ont été sondées sur 4 années (de 2014 à 2018). De ces données, ils ont pu extraire 24 pratiques DevOps et Lean utilisées à travers les organisations dites “performantes”.
Ces pratiques, appelées des capacités, ont été regroupées dans 5 familles :
- Culture (5 capacités)
- Lean Management & Monitoring (5 capacités)
- Product & Process (4 capacités)
- Continuous Delivery (8 capacités)
- Architecture (2 capacités)
Les 24 capacités sont autant d’outils permettant à une organisation d’atteindre une certaine performance de livraison continue qui va naturellement impacter la performance organisationnelle (business) et “non-commerciale” (catalogue de produit plus large, de meilleure qualité, meilleure satisfaction cliente, ...).
Accelerate nous propose aussi 4 KPI, 2 indicateurs de vitesse :
- La fréquence de déploiement
- Le délai de livraison des modifications, aussi appelé Lead Time for Change (LTC) est le temps que mets une modification à passer de l’environnement de développement à l’environnement final
ainsi que 2 indicateurs de stabilité :
- Le Mean Time to Restore (MTTR), le temps moyen pour détecter un incident, mobiliser les équipes, et résoudre le problème.
- Le Change Failure Rate (CFR), le taux d'échec sur les modifications en production
Ces metrics sont des repères servant à évaluer la performance de notre organisation et ne doivent en aucun cas servir d’objectif à atteindre.
L’objectif étant de mettre en œuvre ces capacités pour générer de l’impact, de l’impact sur le business, sur la stabilité et la qualité ainsi que sur le bien-être au travail.
De plus, Accelerate nous dit que tout est mesurable. Si vous mettez en place ces capacités vous pouvez mesurer leur impact, soit par des chiffres, soit par des signaux faibles qui sont un concept très important du livre.
Parlons maintenant des capacités énoncées plus tôt;
Culture :
- Contexte/cadre de travail & satisfaction au travail
- Encourager la collaboration entre les équipes
- Encourager l’apprentissage continu
- Le Leadership transformationnel
- Culture organisationnelle de Westrum (Ron Westrum)
Continuous Delivery :
- Tests automatisés
- Déploiement automatisés
- Intégration continue
- Livraison continue
- Version Control
- Trunk-based development
- Shifting left security
- Gestion de données de tests
Product & Process :
- Petites unités de travail
- Rendre visible votre flux de travail
- Expérimentation en équipe
- Retour client
Architecture :
- Architecture faiblement couplée
- Equipes autonomes et responsables pour le choix de leur outil
Lean Management & Monitoring :
- Limitation des Work In Progress
- Management visuel
- Observabilité
- Alléger les processus de déploiement
- Notification proactives
Ces capacités s’inscrivent dans un modèle (cf. schéma suivant) et sont liées par des liens de prédictibilité et non de cause à effet, ce qui veut dire : A peut impacter B. Les mettre en place nous permet de prédire l’amélioration de notre performance organisationnelle, de livraison continue, etc.
Si vous ne comprenez pas complètement le schéma précédent, ne vous en faites pas, Accelerate est une analyse statistique complexe et 45 minutes de conférences ne nous permettent que d’en effleurer la surface.
Ce qu’il faut retenir est que l’on peut produire vite mais pas au détriment de la qualité, du contexte de travail et sans détériorer nos relations. Accelerate peut nous aider à accomplir cela, cependant Geoffrey nous invite à rester critique sur notre lecture et sur le potentiel que peuvent nous apporter ces outils. Ils ne sont pas applicables dans tous les contextes.
Maintenant que nous avons bien parlé d’agilité nous allons pouvoir aborder les autres sujets de la journée, je vous promets du Craft, de la gestion d’incident et même de l’observabilité ! Nous parlerons de ces sujets… Après une pause café ☕
