[Mix-IT] Recette pour parvenir à donner une conférence sur les embryons de manchot à Mix-IT

Pourquoi ça m’a intéressé : un sujet atypique présenté avec humour.
De quoi ça parle : comment trouve-t-on un sujet de recherche pour de la recherche fondamentale

À retenir :

  • La recherche fondamentale à pour but d’augmenter les connaissances de l’humanité, ça ne sert donc à « rien » et c’est absolument indispensable car toute découverte pourrait servir dans l’avenir.
  • Comment pose-t-on un sujet pareil? En mélangeant sa passion avec son travail.
  • Qu’est-ce qu’ils ont de particulier ces embryons de manchots? Une répartition des plumes atypique, avec une densité de 20 a 100 fois supérieure aux autres oiseaux, qui s’oppose même aux règles mathématiques.
  • Au passage… les manchots c’est des pingouins? Non! Les manchots (ou « pinguins » en anglais…) vivent dans l’hémisphère sud et ne volent pas. Rien a voir donc avec les pingouins (auk in english) !

Mon avis : j’adore les conférences qui me sortent un peu de l’informatique et m’apportent autre chose. Celle ci m’a permis de mieux comprendre le travail des chercheurs fondamentaux, qui m’était jusque là méconnu…

La vidéo : https://www.infoq.com/fr/presentations/mix-it-marie-manceau-embryons-manchot

XP Game

J’ai choisi de terminer la série de Lunch and Learns avec l’atelier du XP game.

Cet atelier propose un beau résumé des pratiques agiles, mais demande un peu de matériel et du temps de préparation.

Principe

Par équipe de 2 ou 3 personnes, les joueurs doivent réaliser le plus de points de valeur possible des items qui leur sont proposés. Les réalisations sont simples : faire des pliages de bateaux, des châteaux de cartes, trier des paquets….

Durant des sprints de 5 minutes, ils essaient de réaliser la backlog qu’ils ont défini. Lorsque le sprint est terminé, l’équipe debrief et essaie d’évaluer sa vélocité.

Matériel

  • 1 jeu de cartes par équipe
  • des feuilles de pliages
  • des dés
  • des crayons bleus et jaunes
  • des stylos
  • les suites d’opérations

Vous pouvez télécharger le Materiel

Conclusion

L’XP game permet de mettre les joueurs en condition d’application presque réelle : ils peuvent ainsi toucher du doigt les notions de vélocité, de planification, ainsi que d’auto-organisation.

Petit conseil néanmoins : prévoyez au moins 2h pour la réalisation de ce jeu, ainsi que plusieurs « validateurs »afin que chacun puisse profiter au mieux de l’atelier.

 

 

Agilité – Partie II – La fin du sprint

La deuxième partie du Lunch and Learn du mois d’avril portait sur les événements qui clôturent le sprint : la review et la retrospective. Vous trouverez ici le support: Jeux Agiles

Sprint Review

La revue du sprint est un moment clé de chaque itération : c’est là que l’on présente aux parties prenantes (utilisateurs, PO…) la réalisation du mois. C’est notamment l’endroit où l’on ajuste la vélocité de l’équipe.

 

Demonstrates what was achieved in the Sprint and collect feedback
Whole team participates
Invite anyone and everyone

 

La time box de la review est d’une heure par semaine de sprint, il faut donc habituellement compter jusqu’à 4 heures pour un sprint d’un mois. Un travail minimal de préparation est nécessaire. Néanmoins celui-ci reste assez restreint car tout ce qui est présenté est livrable.

 

Cet événement  voit sa valeur s’améliorer proportionnellement au nombre de participants. Pensez donc à l’organiser suffisamment tôt.

 

La rétrospective

À mon sens, c’est l’item le plus important pour l’équipe de développement. C’est le nerf de l’amélioration du projet et de la vie de l’équipe. On y lève les pain point, et on y cherche des solutions.

 

Il existe autant de formats de rétrospective que de scrum masters.

 

Le format le plus connu est probablement le speed boat : les réussites et livraisons  nous font avancer vers l’objectif tel le vent dans les voiles, les problèmes nous ralentissent tels des ancres, et nous faisons face à des risques (hauts fonds).

speedboatweb2

 

Pour ma part j’utilise régulièrement  le format suivant :

  • Rappel de l’objectif du sprint
  • Rappel des actions proposées lors de la dernière séance et suivi de l’avancement de celle-ci
  • Levée des points forts et faibles de l’itération : pendant 10 minutes chacun réfléchit à au moins un point positif et un point négatif du sprint précédent
  • Après les 10 minutes chacun va présenter ses sujets, les regroupant si nécessaire
  • Lorsque tous les sujets sont regroupés, chaque membre de l’équipe a le droit d’attribuer 2 points aux sujets négatifs qui lui semblent prioritaires à corriger.
  • Les 3 sujets ayant remportés le plus de voix sont choisis pour action
  • Pendant le temps restant, on propose des actions pour corriger les problèmes choisis
  • Enfin après 1h (1h30 pour les grosses équipes), on effectue le ROTI de la réunion

 

Le ROTI, ce n’est pas le gigot du midi mais le « return on time invested ». Chaque membre vote à main levée, de 1 à 5, la rentabilité du temps consacré à la réunion.

roti-grosjean

 

 

Agilité – Partie II – Outils de suivi

Pour le Lunch and Learn du mois d’avril, nous avons présenté la deuxième partie du cycle sur l’agilité. Nous avons donc cette fois ci abordé les items permettant de suivre l’avancement puis la review et la rétrospective.

Je présente cet atelier en duo avec Fabien Meinnier, Scrum Master.

Scrum Board

Le premier des outils de suivi, et pas des moindres, est tout simplement le tableau Agile. Pour l’historique, le tableau vient des méthodes de type Lean et notamment de Kanban.

Le tableau est peut-être l’outil le plus connu de l’agilité. Il s’agit d’un outil simple d’utilisation et d’une grande plus-value.

Tous les items du backlog sont présents sur le tableau, regroupés par stories. Ils sont découpés en tâches unitaires, de préférence ayant un temps de réalisation inférieur à une journée.

Les développeurs ont donc sous les yeux la liste des réalisations à produire pour le sprint. À partir de là, c’est à eux de jouer. Chacun choisi une fiche et la passe à « en cours ».

On essaie de limiter autant que possible le nombre de fiches affectée à une même personne.

TableauScrum_m

Lorsqu’une tâche est terminée, on pousse la fiche vers la sortie, et on s’en affecte une nouvelle. Une user story est considérée comme terminée lorsque toutes les tâches qui la composent sont au statut « terminé » et qu’elle remplit la definition of done établie.

Daily Meeting

Strip-Daily-Standup-650-final

Chaque jour l’équipe de développement est conviée à participer au daily meeting. Chaque participant, debout, doit répondre aux trois questions :

  • Qu’est-ce que j’ai fait hier?
  • Est-ce que j’ai rencontré un problème?
  • Qu’est-ce que je vais faire aujourd’hui?

Un animateur (le Scrum Master si l’équipe ne s’en sent pas capable) est responsable du bon déroulement de la réunion. Il s’agit notamment de faire respecter les temps de parole, de vérifier que tout le monde à répondu aux 3 questions et de ne pas dépasser la time box de 15 minutes.

Seule l’équipe de développement est obligatoire au stand-up meeting.

Burndown chart

Le burndown chart est un outil de suivi de l’avancement. Une ligne oblique représentant la capacité d’exécution théorique de l’équipe est tracée allant de la vélocité à T0 à 0 à la fin du sprint.

Burn_down_chart

Chaque jour on trace un nouveau point représentant l’avancée réelle de l’équipe. On a donc un suivi graphique et au plus près de la réalisation. Néanmoins c’est un outil difficile à tenir à jour, souvent à cause d’un découpage des tâches pas assez fin.

 

 

 

 

Agiles Games – Part I

Pour le Lunch and Learn de février, nous vous avons proposé une première séance autour des jeux agiles. Pour rappel, le sujet Agile Games sera découpé en 3 séances, au rythme d’une séance tous les deux mois (février, avril, juin) et va nous permettre de survoler certains concepts agiles et de découvrir les 5 événements de Scrum.

Je présente cet atelier en duo avec Fabien Meinnier, Scrum Master.

L’agilité qu’est-ce que c’est?

En quelques mots l’agilité représente les méthodes de développement logiciel respectant l’Agile Manifesto :

   agile-manifesto1

Ce sont des méthodes itératives, se basant sur 12 principes, regroupant pèle-mêle la qualité logicielle, une bonne communication, ainsi que de nombreux et rapides feedbacks.

Nous avons choisi de présenter Scrum, qui est actuellement la méthode agile la plus populaire.

Scrum se définit comme une méthode empirique, basée sur l’inspection et l’adaptation.

Ball Point Game

Pour cette première session, nous avons décidé d’introduire un concept indispensable : la vélocité. Pour cela nous avons utilisé le jeu du Ball Point Game. Le principe est simple : armé d’un sac de balles, l’équipe doit en faire passer le maximum entre eux en l’espace de 2 minutes.

  • La personne qui prend les balles dans le sac est la personne qui repose les balles.
  • La balle doit impérativement être lancée entre deux participants.
  • La balle ne doit pas être transmise à un voisin direct.
  • Toute balle qui enfreint les règles est perdue.

Ces règles toutes simples vont permettre de comprendre rapidement les forces de l’agilité.

Le déroulement

On demande à l’équipe une estimation du nombre de balles qui feront un tour complet en deux minutes avant chaque itération,  et on laisse un temps de rétrospective à l’équipe à la fin de chaque cycle.

La première estimation s’avère en générale catastrophique. L’équipe doit profiter de la rétrospective pour ajuster celle-ci et améliorer leur organisation.

Je fais faire habituellement 5 itérations. À partir de la troisième, l’équipe a en général pris conscience de sa vélocité, et je rajoute des éléments perturbateurs, comme demander des balles de certaines couleurs.

Au final ce jeu permet aux joueurs de comprendre la notion de vélocité, de voir l’intérêt des cycles itératifs et de la rétrospective. Ils entrevoient également l’intérêt de l’auto-organisation, et on voit souvent se dessiner des profils de leader, qui entraîneront l’équipe.

Planification

Nous avons terminé cette première partie en parlant du Sprint Planning. Il s’agit du premier évènement d’un sprint Scrum : l’équipe se rassemble et le product owner présente les items qu’il souhaite voir intégrer au sprint.

Lorsque tous les items ont été présentés, les développeurs estiment la charge de chacun, afin de définir le périmètre sur lequel ils sont prêts à s’engager.

Nous avons présenté deux méthodes d’estimation.

Poker Planning

Chaque item est soumis au vote de l’équipe. Chaque développeur, armé de ses cartes de poker planning (ou via l’utilisation d’une des nombreuses applications de poker planning) estime simultanément la complexité qu’il prête la story.

On révèle alors les votes, et l’équipe discute jusqu’à trouver un accord sur le coût de la story.

Lorsque toutes les stories ont été estimées, l’équipe s’engage sur le périmètre du mois.

Extreme quotations

Contrairement au poker planning, on va chiffrer la totalité des stories en même temps.

  1. On répartit les cartes de poker sur la table.
  2. Les développeurs posent chaque story sous le coup qu’ils estiment. On ne débat pas à cette étape : on cherche une estimation rapide même si elle est fausse.
  3. On écrit sur chaque fiche le coût estimé, puis si un développeur n’est pas d’accord avec l’estimation initiale, la fiche est déplacée, une seule fois. On ne discute toujours pas.
  4. Lorsqu’il n’y a plus de mouvements sur la table, on reprend les fiches qui ont été déplacées, et on recherche un consensus sur celles ci.

Pour finir

Voici les slides utilisés pour cette présentation. La partie II aura lieu le mercredi 20 avril, et traitera des autres événements de Scrum.

Agilité – partie 1-final.pptx

 

 

 

Behaviour Driven Development

La  7ème séance des Lunchs and Learn a eu lieu aujourd’hui autour du sujet BDD Behaviour Driven Development.

Malgré une démonstration légèrement chaotique, les participants ont pu se faire la main sur quelques exercices Cucumber.

Le code source est disponible sur mon github, ainsi que les corrections des sujets (sur la branche solution).

Vous trouverez les slides ici : slides_BDD

La librairie présentée en fin de démo s’appelle Serenity, et permet de génerer des résultats glamours à vos tests d’intégration. Distribuée sous licence Apache vous trouverez le code et les démos sous github…

 

Merci à Christophe Pont pour sa présentation 🙂