REX - Agi'Lille 2023 - H@Coeur

REX Agi'Lille 2023

Fred SCHEIDEL
Développeur
Passionné de gameplay
Membre du GAG

Thèmes liés

Produit ou projet, Veille

Conférence « Soft Skills »

Un individu – et par extension une équipe – a des aptitudes (skills) qui peuvent généralement être classées en 2 grands pans :

· Hard skills : compétences techniques, savoir-faire
· Soft skills : compétences humaines, savoir-être

« Le savoir et les compétences techniques, on en trouve à tous les coins de rue« . Cette phrase fait réfléchir sur la qualité de l’apport de chacun à une équipe. Le sujet n’étant pas d’être l’incarnation d’un savoir, mais de savoir participer à une collaboration d’équipe pour que ce savoir soit commun… grâce aux soft skills.

La liste des soft skills n’est pas figée ou même finie. Voici un site qui détaille les plus importantes : Listing

Certaines sont innées, font partie du caractère, d’autres peuvent se travailler avec le goût de progresser. Au final pas de conclusion sur comment faire, mais plutôt d’avoir conscience qu’elles font partie de chacun et qu’elles ont une importance primordiale au sein d’une équipe.

Conférence « Les 10 commandements de la programmation sans ego »

Le code produit par un développeur est souvent assimilé au développeur lui-même.
Avec le risque que :

Le code devienne une unité de jugement
Le doute grandisse pour poser des questions (légitimes)
Ce soit difficile de montrer ce code

Evidemment cette démarche peut être toxique, il faut donc s’efforcer de suivre ces « commandements » :

Comprenez et acceptez que vous allez faire des erreurs (les autres aussi)
Vous n’êtes pas votre code : détachez-vous
Il y a toujours plus fort que soi
Ne réécrivez pas le code d’un autre sans en discuter
Respectez ceux qui en savent moins. Evitez les explications commençant par « Ben c’est facile… » : vous n’êtes pas l’autre
La seule constante c’est le changement
La seule vraie autorité vient du savoir, pas de la position
Combattez pour vos idées, mais acceptez la « défaite » avec bienveillance. Si vous avez suivi le point 7, cette défaite n’est que la victoire du savoir commun
Ne soyez pas « solo ». Rien de pire qu’un code lisible seulement par celui qui l’a écrit (et encore pas trop longtemps après)
Critiquez du code, pas des personnes

Conférence « Et si on arrêtait de produire du software inutile »

Le monde de l’IT est spécialisé dans la création d’outils inadaptés, voire dont personne n’a exprimé le besoin.
Il est important de ne pas créer des outils inadéquats, de ne pas créer juste par habitude de produire.
Pour remettre un produit dans un contexte, voici les clés proposées lors de cette conférence :

1) Utiliser des persona

Ne pas hésiter à créer autant d’US que de persona détectés.
Si aucun persona ne correspond, l’US est inutile

2) Une US n’est pas une spécification

Une US prend 15min à rédiger
Elle exprime un besoin fonctionnel simple, qui provoque la discussion avec la team afin de définir les actions à mener

3) Mesurer les utilisations avant de prendre une décision

Se baser sur la donnée factuelle pour éviter d’imaginer de faux besoins

4) Attention aux dév qui font trop compliqué

Ne pas complexifier le code pour se faire plaisir
Un code complexe est plus long à créer et plus difficile à maintenir

5) Pratiquer la suppression à fond (des items de backlog)

Supprimer si elle n’a pas les 4 critères suivants :

Valuable : quelqu’un est prêt à payer pour cette fonctionnalité ?
Feasible : ai-je la compétence pour la réaliser
Viable : financièrement
Usable : par les utilisateurs, pas seulement les « élus »

Et si on arrêtait de produire du software inutile – David Laizé – Bing video

Conférence « Rendez l’agilité aux développeurs »

À travers un scénario catastrophe, nous avons évoqué les points cruciaux pour qu’une équipe se sente bien et impliquée.
Voici ces points :

L’intégration de chacun à l’équipe

· Pas besoin : la personne n’a pas de repère, de référents => perte de confiance en soi
· Oui : l’intégration est mutuelle, chacun s’intéresse à l’autre et lui apporte au maximum

Les outils de suivi opérationnel

· Imposé à l’équipe : outil mal calibré, équipe bloquée, perte de temps et de motivation
· Choisi par l’équipe : outil forcément adapté, laisse place à l’innovation, motivant, solidarité de l’équipe

L’incrément

· Rarement : le produit n’est pas challengé, pas de retours, il ne correspond plus à un besoin
· Le plus souvent possible : et avec le client final en direct, pour s’assurer de répondre à son besoin

La livraison

· Livré par un ops : conflit en cas de problème
· Facilité par un ops : l’équipe devient multi-disciplinaire, responsable. Une entraide est créée entre les personnes