L'artisan développeur

Blog de Sébastien Cormier
A la Une Conférences

Retour sur mon Codeurs en Seine

La conférence Codeurs en Seine

Codeurs en Seine est une conférence ayant lieu chaque année à Rouen. On y parle agilité, développement (back-end, front-end, mobile), qualité, et pleins de sujets gravitants autour du métier de développeur.

Si vous habitez en Normandie ou en région Parisienne, c’est un rendez-vous incontournable ! En effet, la qualité des orateurs est chaque année au rendez-vous, la conférence est gratuite et se déroule sur une seule journée. Il ne vous sera pas compliqué de convaincre votre employeur de vous laisser y aller.

Merci à Etienne pour sa dédicace!

Outre les conférences, plusieurs stands étaient présents. Les stands des sponsors bien évidemment, mais aussi une expo de vieilles bécanes : les « ordinausores ». Enfin, les auteurs de Commit Strip, avec Etienne Issartial pour faire les dédicaces et Thomas Guenoux pour la première Keynote.

 

Mon programme de la journée

Cette année, la conférence se déroule dans 5 salles différentes, augmentant le choix, déjà difficile du planning de la journée. Pour ma part, voici le programme que j’ai décidé de suivre :

  1. Le développeur Full Stack est mort. Vive le développeur universel ! (Keynote du matin avec Thomas Guenoux)
  2. Blablacar and the Agile Crusade (Nicolas Tricot et Francois Esch)
  3. Découvrir Android Things, et exterminer les reptiliens (Gautier Mechling)
  4. Développer un jeu vidéo (quand on n’y connait rien en développement de jeux vidéo) (David Wursteisen)
  5. Cessons les estimations ! (Frédéric Leguédois)
  6. TECHnostérone et UXtrogènes : c’est l’heure du bilan hormonal (Goulven Champenois et Marie Cécile Paccard)
  7. Hexagonal Architecture from scratch (Thomas Pierrain)

Le programme complet est visible sur le site Codeurs en Seine.

Les vidéos viennent d’être publiée à cette adresse : https://www.youtube.com/playlist?list=PLbbYL6fWx8WwSWMsgFh88PF_eV639y4hb


 

Le développeur Full Stack est mort. Vive le développeur universel !

  • Orateur : Thomas Guenoux

Pour le keynote d’ouverture, c’est donc Thomas Guenoux qui vient nous parler du développeur universel. En effet, pour Thomas, le concept de développeur full stack ne peut plus exister. S’il était encore possible de maitriser la chaine complète il y a une décennie, avec un peu d’HTML/javascript, du PHP, une base de données et un logiciel FTP pour les mise en production, ce n’est plus le cas aujourd’hui. Il est en effet devenu impossible de maîtriser à la fois :

  • les principales technologies front-end et back-end
  • la gestion des containers et leurs orchestrations
  • le mobile, l’IoT
  • les bots
  • le Machin learning, deep learning, l’IA

Il préfère aujourd’hui parler de dévelopeur universel : un dévelopeur qui ne fait pas que coder, mais qui pense plus globalement à la création de valeur. Aujourd’hui, il y a un grand écart entre le fait qu’un dévelopeur doit se spécialiser pour rester compétitif, mais aussi avoir une connaissance générale pour avoir une compréhension plus globalisée de la création de valeur.

Thomas a débuté sa présentation avec un rappel sur les 2 premières révolutions industrielles afin de les mettre en parallèle avec la troisième révolution industrielle (1970 à nos jours avec l’explosion de l’informatique et de l’énergie nucléaire). Puis il a abordé la 4ème révolution industrielle qui débute aujourd’hui : celle du Big Data et de l’Intelligence Artificielle. Le sujet ne pouvait que me passionner !

A chaque révolution industrielle, la société change, des métiers disparaissent, d’autres apparaissent. D’après Thomas, les métiers d’avocats et de radiologues par exemple sont très menacés. Je partage cet avis. Mais Thomas, va plus loin. Il imagine un avenir où l’IA prendra une telle importance qu’une grande partie de la population n’aura plus besoin de travailler (on leur donne du pain et des jeux). D’un autre coté, il y aurait les ultras riches, ceux qui ont la maitrise de l’I.A., bref, un avenir assez terrifiant.

Thomas a aussi mis l’accent sur un constat que beaucoup font, mais que nos politiques peinent à comprendre : l’Europe est complètement à la rue sur l’Intelligence Artificielle. Les USA ont les GAFA (Google, Amazon, Facebook & Apple). Les chinois rivalisent avec les BATX (Baidu, Alibaba, Tencent et Xiaomi). Même si cette rivalité a été rendue possible en bloquant l’utilisation des GAFA sur leur territoire, le constat fait mal : l’Europe est déjà à des années lumières.

Dernier point intéressant retenu sur cette présentation : les Interfaces Homme/Machine qui étaient essentiellement graphiques, vont muer très rapidement pour devenir des interfaces vocales. On le voit d’ailleurs avec les performances des assistants vocaux. Les besoins en terme de développement front-end risquent donc de diminuer dans les années à venir. Il pronostique d’ailleurs qu’une grande partie de l’audience aura migré dans les 10 ans à venir vers les technologies de machine learning.

Bref, une excellente keynote pour démarrer la journée, je vous laisse la découvrir en vidéo.


 

 

Blablacar and the Agile Crusade

  • Orateurs : Nicolas Tricot et François Esch

Nicolas Tricot est IT Manager chez Blablacar et François Esch, Coach Agile. C’est sur le thème d’Indiana Jones que va se dérouler cette présentation visant à raconter l’aventure agile chez Blablacar.

Au début, cela a commencé simplement, avec une petite équipe. La seule pratique empruntée à Scrum étant les stand up meetings. Au final, peu de changement sur l’ancien fonctionnement. Le premier constat fait par Blablacar était de réaliser qu’en l’absence de leader pour mener un tel projet, cela était voué à l’échec.

Ensuite, les notions de complexité et de vélocité ont été introduits. Cependant, cette notion de vélocité a eu un effet pervers car elle a été mesurée de façon individuelle. De ce fait, cela a créé une compétition entre les dévelopeur. Cette compétition étant bien entendue néfaste à la collaboration entre les développeurs.

Ensuite, l’accent a été mis sur la récompense du travail accompli, l’explication de la vision et une meilleure communication avec les équipes et en dehors des équipes. Avec l’aide d’une personne externe, Scrum a été appliqué plus méthodiquement (plus au niveau de la philosophie que des outils). Les choses commencent à fonctionner.

A parti de mi-2015, quelques équipes commencent à passer en Kanban (approche par flux) pour répondre à certains problèmes comme la gestion des bugs de production, incompatible avec un backlog figé. De plus, cela permet d’avoir moins de temps passé en réunion. En revanche, le produit perd en visibilité et on perd sur la clarté des objectifs.

Début 2016, Scrumban arrive : essayer de prendre le meilleur de Scrum et de Kanban pour en sortir une méthodologie adaptée aux besoins, chaque équipe conservant une méthodologie propre à son fonctionnement.

Organisation en tribus

A partir de fin 2015 Blablacar a mis en place le système de tribu, notion apparue avec Spotify. Une tribu est composée d’un Product Lead, un Business Lead et d’un Tech Lead. Cette tribu est en charge d’une ligne produit bien identifiée. La tribu est aussi composé de plusieurs Squads. Un Squad est une équipe composée de différents profils permettant d’intervenir sur n’importe quelle partie technique.

Les avantages : moins de dépendances inter-équipe, décisions plus rapides et surtout, un ownership plus important.

Un autre problème survient alors : comment partager l’expertise sachant que chaque expert est réparti dans des squads différents ? C’est ici qu’arrive la notion de « Chapter » et de « Guild ». Les « Chapters » réunissent les personnes ayant la même expertise (par exemple les font-end). Les « Chapters » se réunissent une fois par semaine. Quand aux Guild, elles sont des groupes de travail de personnes n’ayant pas forcément la même expertise, portant sur des sujets tel que la qualité ou l’agilité.


 

Découvrir Android Things, et exterminer les reptiliens

  • Orateur : Gautier Mechling

Gautier Mechling est un habitué des conférences tech et vous le retrouverez régulièrement sur les principaux évènements où il vous parlera de l’écosystème Android. J’avais eu la chance de le rencontrer lors d’un BBL organisé chez Ogury. Lors de son passage à Codeurs en Seine, Gautier est venu nous parler d’Android Things.

Si vous pouvez créer une application, vous pouvez créer un appareil.

Android Things vous permettra en effet de vous attaquer à l’IoT (les objets connectés) en utilisant toutes les librairies Google et en se basant sur le framework Android. Gautier nous a ensuite parlé de TensorFlow : un outil permettant l’apprentissage automatique basé sur un réseau de neurones.

Quel lien entre Android Things et TensorFlow ?

Ces 2 technologies vont permettre à Gautier de pouvoir sauver l’humanité en combattant les reptiliens. Les extra-terrestres prenant notre apparence, impossible à différencier d’un humain. Vous l’aurez compris, c’est sur le ton d’un humour bien senti que Gautier nous présentera un cas pratique associant Android Things et TensorFlow. Le système est un capteur permet de déclencher une photo au passage d’un individu. La photo sera ensuite analysée à l’aide de TensorFlow afin de classifier l’individu : humain ou reptilien. Si c’est un reptilien, alors, un servo moteur est activé : relié astucieusement avec du scotch et un bout de ficelle sur un Nerf, le système fait feu sur le reptilien.

Cette présentation a eu un grand succès, je vous la conseille vivement si elle est programmée dans une autre conférence, d’autant plus que la vidéo de cette session semble avoir été sabotée par les reptiliens…


 

Développer un jeu vidéo (quand on n’y connait rien en développement de jeux vidéo)

  • Orateur : David Wursteisen

A l’occasion de cette courte présentation de 20 minutes, David Wursteisen donne différents conseils pour développer un jeu. En effet, l’émergence des plateformes mobile est un nouvel eldorado pour ceux qui veulent développer un petit jeu avec de petits moyens, sans pour autant être à l’abri d’un gros succès.

David nous parle dans cette présentation de l’importance de l’UI, du choix du moteur de jeu, et démontre surtout que développer un jeu vidéo reste accessible et que seul notre imagination sera la limite !


 

Cessons les estimations !

  • Orateur : Frédéric Leguédois

Dans une salle pleine à craquer et sans micro, Frédéric Leguédois nous explique pourquoi il faut cesser les estimations. Malheureusement aucune vidéo n’a été enregistrée, mais laissez moi vous dire dès maintenant que Frédéric Leguédois aura été la rock star de cette édition 2017. Son énergie, son argumentaire, tout simplement son talent d’orateur lui aurait permis de remplir le Zenith situer 1 km plus loin!

Nous avons tous été confronté à la situation suivante : devoir estimer rapidement le temps que prendra un projet dont le périmètre fonctionnel n’est pas bien défini. Avec des stacks technologiques que l’on ne maitrise pas forcément, une dette technique importante, et tout un tas de paramètre que l’on ne peut pas prévoir, impossible de réaliser une estimation fiable ! Mais comment l’expliquer à notre client, responsable ou encore PO ? Personnellement je n’ai jamais réussi à convaincre mes interlocuteurs, ne trouvant pas les bons arguments. Probablement que je n’avais pas bien analyser le fond du problème. Puis j’ai vu la conférence « Cessons les estimations » !

La définition du retard selon Frédéric :

Le retard, c’est la différence entre le rêve et la réalité !

L’exemple donné pare Frédéric est celui de la météo : quand il fait 5° de moins qu’annoncé la veille par Météo France, on ne va pas se plaindre auprès du soleil qu’il ne chauffe pas assez ! Au contraire, on se dit que la météo s’est trompée. En informatique, on va parler tout de suite de retard et ne pas remettre en cause l’estimation.

Les méthodes pour estimer

Frédéric nous a présenté différentes méthodes pour estimer et expliqué pourquoi elles étaient inefficaces. Il y a bien sûr celle appelée « le doigt mouillé », aussi connue sous le nom de « pifomètre ». Il y a aussi celle qui consiste à se baser sur le nombre de lignes de code à la fin du projet. Comment connaître ce nombre de lignes de code ? Et surtout, chaque ligne prendra-t-elle le même temps à écrire ? Une expression régulière est-elle aussi rapide à écrire qu’une affectation de variable ?

Frédéric a aussi évoqué la technique qui consiste à demander l’estimation au dévelopeur et à multiplier par deux : simplement, une valeur aléatoire multipliée par deux donne toujours une valeur aléatoire.

Enfin, il a évoqué le planning poker, méthode visant à faire estimer les tâches avec une note de complexité par toute l’équipe. Une fois que que les auteurs de la plus petite et la plus grande estimation ont exposé leurs arguments, un autre tour de table est effectué. On arrive ainsi à une estimation relativement fiable. La fiabilité, ici, étant estimée à 100% de marge d’erreur !

Alors utilisons le planning poker ?

Et bien non, encore une fois. Frédéric nous explique que l’estimation est nécessaire pour budgéter un projet avant qu’il ne démarre. Hors, le planning poker ne peux fonctionner qu’une fois le projet commencé, que la relation avec le Product Owner a pris son rythme de croisière. En effet, la vélocité de l’équipe dépendera aussi de l’implication du Product Owner.

L’exemple de l’épicier

Souvent, on nous demande des estimations pour un projet dont le périmètre fonctionnel n’est pas bien défini. Demander une estimation dans ces conditions c’est un peu comme demander à son épicier combien cela va nous couter avant de passer dans les rayons. Il va forcément nous demander ce que l’on va acheter. Si on insiste pour lui demander un prix et qu’on ira se servir après, il va nous virer de son épicerie. Alors pourquoi les chefs de projets ne sont-il pas aussi rationnels que les épiciers ?

La deadline

La deadline est la plus grande génératrice de bugs.

Rien que le nom : DEAD Line. En effet, dans un projet, nous avons 3 variables d’ajustements :

  1. Le périmètre fonctionnel
  2. Le délai
  3. La qualité

Etant donné que contractuellement il n’est pas possible de jouer sur les 2 premiers, ce sera donc la qualité qui sera la variable d’ajustement.

Le #NoEstimate, je commence demain !

Tout cela c’est bien beau, mais comment je fais pour convaincre mon client ou mon responsable qu’il ne faut pas faire d’estimation ?

Réponse : La confiance.

L’estimation en elle même est une perte de temps, et pendant qu’on estime le projet n’avance pas. Une mauvaise estimation, ce qui sera le cas le plus courant, fera que le projet sera un échec avant de commencer. Le plus important est de s’accorder sur un MVP (l’ensemble des fonctionnalités essentielles), et rapidement être capable de livrer de façon incrémental. Cela permet de rassurer le client. Il pourra aussi changer d’avis en cours de route. Le dévelopeur, lui, devra fournir un travail de qualité, car le client pourra à n’importe quel moment stopper la collaboration. Une fois la relation de confiance établie, le client ne voudra plus revenir à l’ancien système.

Dans un modèle sans estimation, il n’est pas pas possible de voler son client!

Conclusion

Cette présentation a quelque part raté son objectif : elle se voulait non consensuelle et elle aura fait l’unanimité dans l’auditoire ! Quel dévelopeur ne s’est pas reconnu dans l’une de ces situations ? Qui n’a pas été dans une équipe technique était mise en échec en raison d’un modèle basé sur l’estimation ? Ce que j’en tire de cette conférence, c’est d’être armé d’un argumentaire solide la prochaine fois où l’on me demandera une estimation et de pouvoir expliquer comment un autre système pourra mieux fonctionner.

Malheureusement, il n’y aura pas de vidéo publiée. Alors si vous croisez Frédéric Leguédois à une conférence, allez-y les yeux fermés !

 

TECHnostérone et UXtrogènes : c’est l’heure du bilan hormonal

  • Orateurs : Marie-Cécile Paccard et Goulven Champenois

Dans cette présentation, Goulven Champenois et Marie-Cécile Paccard abordent un sujet assez sensible et d’actualité : comment nous reproduisons les biais sexistes et racistes dans nos applications, elles mêmes, codées par des « barbus ».

Les orateurs ont attaqués cette présentation par un vote faisant remarquer que l’auditoire était en majorité composé d’hommes, blancs, et la plupart barbus. Alors oui, inutile de le nier, le monde de l’IT est très masculin. Ayant longtemps participé au recrutement d’équipes IT je sais par expérience qu’il est très difficile de construire des équipes avec plus de 15% de femmes. Mais il suffit de regarder les proportions à la sortie des l’école pour comprendre que cela ne peut s’expliquer uniquement par ma misogynie des recruteurs de l’IT. Après est-ce l’image masculin du milieu IT qui dissuade les femmes de se lancer dans cette voie ? Difficile à dire, toujours est-il que dès la formation le milieu n’est pas toujours évident pour la gente féminine comme le montre quelques récents articles sur l’école 42.

http://www.lepoint.fr/societe/des-cas-de-harcelement-sexuel-a-l-ecole-42-de-xavier-niel-17-11-2017-2173117_23.php

Au delà de la présence des femmes dans l’IT Marie-Cécile et Goulven ont surtout souligné de façon plus général l’absence de diversité dans les équipes techniques.

Mais le sujet de fond de cette présentation est de montrer comment ce manque de diversité impact la façon dont nous réalisons nos applications : elles sont loin de prendre en compte la diversité de leurs utilisateurs. Par exemple, le formulaire d’inscription à Facebook qui force à choisir son genre : Masculin ou Féminin. Une personne qui est en train de changer de sexe doit-elle être forcée à choisir entre masculin et féminin ?

Puis un autre exemple, toujours concernant Facebook, est montré. Une jolie notification d’anniverssaire envoyée à un papa, dont la fille est décédée 6 mois plus tôt. Bien évidemment qu’il n’a pas envi de recevoir cette notification !

Si je suis d’accord sur le constat que nos applications ne prennent pas en compte la diversité de la population, je pense que malheureusement, il nous est impossible de réaliser des applications s’adressant à tous, sans exceptions. Il y aura toujours des exceptions. Bien évidemment, tout dévelopeur web dévelopeur web devrait connaître les bonnes pratiques d’accessibilité fournies par l’Opquast. On peut certainement faire mieux que ce que l’on fait aujourd’hui, mais les exceptions existeront toujours.

Si dans un de mes articles j’écris par exemple qu’il est préférable de se lever pour aller parler à son collègue plutôt que de lui envoyer un mail : Peut-être qu’une personne tétraplégique sera amenée à me lire ? Je peux chercher une autre formule, mais cette autre formule pourrait être déplacée dans un autre cas ? Alors Facebook doit-il s’interdire de créer une notification d’anniversaire ? Au final, le sujet soulevé ici est pour moi est un sujet de société qui va bien au delà du monde de l’IT : les personnes ne rentrant pas « dans les cases » éprouvent clairement des difficultés dans leur vie quotidienne, comme devant leur écran.

J’aurai aimé que cette présentation nous apporte plus de pistes pour améliorer les choses. Ceci est bien entendu mon avis personnel, je vous suggère de vous en faire un en visionnant la vidéo ci-dessous.


 

Hexagonal Architecture from scratch

  • Orateur : Thomas Pierrain

Thomas Pierrain nous présente ici une session de live coding sur le concept d’architecture hexagonale. Ayant déjà vu plusieurs fois le terme sans savoir de quoi il s’agissait, c’était la bonne occasion pour moi de venir le découvrir.

En deux mots, Hexagonal Architecture est un pattern qui vous permettra d’isoler le code métier du code d’infra structure. L’idée est que le code métier ne dépende de rien. Comme il est compliqué de résumé un Live Coding, je vous invite à regarder la video ci-dessous si le sujet vous intéresse.


 

Conclusion

Cette année 2017 aura été un excellent cru. Après un coup d’oeil aux différentes notations, il apparait que les 2 keynotes et la conférence de Gautier sur Android Things ont eu un grand succès. Parmi les présentations que je n’ai pas vu, celle de Cédric Dué sur GraphQL a aussi eu beaucoup de retours positifs. Je vous ajoute donc la vidéo avant même de l’avoir vue.

Rendez-vous l’année prochaine pour l’édition 2018 de Codeurs en Seine !

 

3 Comment

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.