David a assisté à trois conférences lors du MiXiT 2022. Il nous partage ses ressentis et nous dévoile les sujets abordés : enjeux géopolitiques des infrastructures numériques, agilité et egoless programming !

Enjeux géopolitiques des infrastructures numériques

Cette première conférence, dispensée par Ophélie Coelho, porte sur les enjeux géopolitiques des infrastructures numériques.

Aujourd’hui, tout est géopolitique. L’infrastructure numérique n’y échappe pas. Mais à quel point ? A quel point l’infrastructure représente-t-elle une vulnérabilité ou des forces pour certains pays ?

Commençons par décrire l’infrastructure numérique. Elle est composée de datas-centers, généralement situés dans des pays à position géographique et/ou climatique avantageuse, comme les Pays-Bas. Ce pays, idéalement situé en Europe, a une forte production électrique renouvelable et attire les investissements des GAFA. Google en est l’exemple : 1 milliard d’euros investis dans la construction d’un nouveau site dans le pays. Ce type d’investissement avantage économiquement les pays concernés.

L’infrastructure numérique mondiale repose également sur ses câbles sous-marins. Pour rappel, internet est fondamentalement dépendant de ce réseau ouvert. Initialement, ce réseau était administré majoritairement par des sociétés télécoms qui formaient des consortiums. Aujourd’hui, ce sont principalement les big tech qui sont devenues propriétaires des câbles sous-marins.

Pour se rendre compte de l’immensité du réseau, un simple lien suffit : https://www.submarinecablemap.com/ . On remarque une véritable corrélation entre accès à ce réseau et développement économique et technologique.

Ces réseaux portent des technologies telles que le cloud, qui sont majoritairement des propriétés des big-tech nord-américaines. Comme beaucoup d’autres outils, le milieu du logiciel n’échappe pas à la géopolitique. Nous en avons eu un exemple récemment avec le conflit Russo-Ukrainien. La Russie a été déconnectée du système SWIFT, mais de manière plus insidieuse, la population russe a perdu l’accès aux services Google Pay et Apple Pay. Tous ces éléments sont devenus de véritables outils de pression sur les populations lorsqu’il s’agit de s’attaquer à d’autres pays.Ce sont également des outils de contrôle de la population, comme on peut le constater avec un réseau internet fermé et contrôlé en Chine.

Les chantiers politiques à considérer dans les années à venir sont :

Cette seconde conférence, animée par Romain Couturier, porte sur les enjeux pour l’Agilité du futur.

Ma vie est un ticket ! Eloge de la communication paresseuse et enjeux pour l’Agilité du futur

Cette conférence sortait du lot grâce à son format. En effet, en plus de l’éloquence de Romain Couturier, il dessinait en direct sur feuille ses présentations, rendant le rythme parfait pour l’acquisition de nouvelles connaissances !

Il commence donc par une brève explication de ce qu’est l’agilité. En soit, rien de plus qu’un simple Framework, un outil. Rien de nouveau sous les tropiques ! Mais à quel point maîtrise-t-on ce Framework ? Et quelles sont les bonnes pratiques ?

La présentation se poursuit avec l’explication d’un cas concret et la réponse à une question : comment une équipe s’organise-t-elle avec son flux de production ? Nous avons une liste de features découpées en User-stories, que faire maintenant ? Romain Couturier répond à ces questions grâce à 6 étapes :

Cependant, Romain lève un point qui à mon sens est la clef de voûte de la réussite d’un flux de production contrôlé : définir quand est-ce qu’une tâche est terminée. En effet, c’est bien là que vont se trouver bon nombre d’allers-retours entre l’équipe de production et le client/métier. C’est pourquoi il est important de définir dans quelles conditions une tâche est terminée. Et pour cela rien de plus simple : il faut écrire les sacro-saints cas d’acceptances. Les happy-paths sont définis par le Product Owner (PO) et les cas d’échecs par le Testeur Assurance Qualité (QA).

Romain poursuit par l’analyse d’une situation que nous connaissons tous : l’urgence.

Il expose l’urgence comme l’ennemi de la concentration et par conséquent de la productivité. Pourquoi ? Car elle occasionne un changement de contexte qui nous demande de nous repositionner dans l’environnement technique et métier de l’urgence, généralement différente de celui dans lequel nous nous situons. Il propose donc de supprimer la notion d’urgence du flux de production normal. (Bien sûr cela a provoqué des ricanements dans le public et soulevé de nombreuses questions en fin de conférence).

Je résumerai les échanges ainsi : chaque urgence doit être priorisée et prévue dans le temps. La seule exception possible est si l’application ou le service est KO car cela occasionne d’immenses pertes. Mais globalement, des outils de roll-back/sauvegardes doivent être mis en place afin d’éviter ou au moins contrôler, autant que possible, ce type d’urgence.

Enfin, dans les bonnes pratiques, il propose également d’éviter les systèmes saturés. C’est-à-dire, voir quel est le rythme de production (en quantité d’US par exemple) de l’équipe et enlever une unité (d’US pour reprendre l’exemple) lors du sprint-planning.

Enfin, Romain délivre un dernier conseil : faire le ménage dans les tickets. Il recommande de supprimer les tickets trop vieux, incompris, trop complexes. Ils ont certes été créés dans un objectif, mais si le projet tourne depuis 2 ans et que le ticket est toujours actif, c’est qu’il n’est pas vraiment important, donc faites-le disparaître ! Cela rendra votre backlog plus lisible, accueillant (pour de nouveaux tickets) et renforcera la connaissance de l’équipe de ce qui est à venir et/ou à faire.

Egoless programing «Les 10 commandements de la programmation sans ego»

Enfin, la dernière conférence à laquelle David a assisté était présentée par Olivier Thelu sur les dix commandements de la programmation sans ego ) »egoless programming« )

La conférence commence par le principe N°1 du manifeste Agile :

“Les individus et leurs interactions plus que les processus et les outils”. En effet, nous avons tendance à oublier que les process ne sont que des outils d’organisation, et que cette organisation est d’abord composée d’humains qui doivent interagir et non pas échanger par commentaires interposés sur un ticket Redmine.

Afin de traiter ce sujet il est important de définir ce qu’est l’égo. Cela se traduit généralement chez une personne par :

Dans le milieu du développement nous y faisons souvent face lorsque nous devons prendre des décisions techniques, lorsque nous faisons des choix d’architecture, ou encore lorsque nous définissons les standards de qualité de code interne à l’entreprise. Cela se traduit généralement par du troll (pour les boomers qui ne savent pas ce que c’est, il s’agit de moqueries cyniques 😉. Il peut donc apparaître une certaine difficulté à montrer son code voire à ressentir une honte de s’exposer au jugement de l’autre.

L’exemple le plus simple est souvent celui du développeur sorti d’école, qui s’est habitué à être continuellement en compétition lors de ses travaux pratiques. Ce modèle pédagogique a bien sûr ses limites, c’est pourquoi il est important de leur apprendre qu’il n’existe pas de questions bêtes, que l’entraide est absolument essentielle et que c’est même le meilleur moyen d’acquérir des compétences et des connaissances.

Mais pour être certain de devenir un egoless programmer, il existe 10 commandements, écrits par Lamont Adams (initialement tirés de « The Psychology of Computer Programming » de Gerald Weinberg écrit en 1971)

1. Comprenez et acceptez que vous allez faire des erreurs
              
2. Vous n’êtes pas votre code
              
3. Peu importe votre niveau, vous trouverez toujours plus fort que vous
              
4. Ne réécrivez pas le code sans en discuter
              
5. Traitez les personnes qui en savent moins que vous avec respect, égard et patience
              
6. La seule constante dans le monde c’est le changement
              
7. La seule vraie autorité vient du savoir et non de la position
              
8. Battez-vous pour vos idées mais acceptez “la défaite” avec bienveillance
              
9. Ne soyez pas la personne du bureau du fond (la personne qui travaille seule dans son coin)
              
10. Critiquez le code au lieu des personnes, soyez gentil avec elles mais pas avec le code

Le dernier point me paraît essentiel. Il est important d’être factuel, d’écrire de manière positive et de se rappeler que c’est bien une personne qui va lire votre commentaire. Il est primordial de TOUJOURS proposer des améliorations si la solution ne vous convient pas.