Cet évênement de 2 jours a rassemblé près de 250 personnes au chalet de la porte Jaune, un cadre idylique, et a fourni un contenu de qualité encadré par une organisation sans faille. Bravo aux organisateurs.

L'assemblée générale de l'association XP France  qui propose cet évênement, a eu lieu pendant le soir du premier jour, avec le vote du renommage de l'association en Agile France.

Le plus difficile dans cet évênement, c'est de choisir la prochaine session, alors on s'y est mis à plusieurs, et on vous propose de vous donner des petits bouts de XP days :)

Soigner sa schizophrénie projet MOA/MOE : voyage autour des exigences fonctionnelles exécutables

Durant cette présentation Emmanuel Hugonnet, Rémy Sanlaville, et Hervé Lourdin ont traité une maladie grave qui touche encore de nos jours une grande partie des projets informatiques : la schizophrénie.

Cette maladie dont le principal symptôme est le fractionnement de l’esprit est diagnostiquée par la relation ‘conflictuelle’ entre la MOA et la MOE. Cette relation particulière de ces deux ‘collègues ennemies’ qui auraient dû formait une seule et unique équipe du projet (ou patient), se matérialise justement par leur séparation. La MOA commence par rédiger les spécifications ‘détaillées’, mais peu compréhensibles ! La MOE, les traduit ensuite aussi bien que mal en logiciel. Le résultat est un produit qui repend peu aux attentes et aux besoins, et qui a dépassé son budget.

Heureusement, les remèdes existent ! Et nos médecins du jour, prescrivent a cet effet, la ‘Acceptance Test Driven Development’.

En effet, cette méthode agile présente un cycle de développement qui fait intervenir les deux parties, jadis ennemies, d'une manière a ce que les MOA et les MOE agissent en étroite collaboration pour discuter en premier temps des 'exemples d'utilisation' du système à produire. Un langage métier commun aux différents membres de l'équipe va émergé, et permettra une meilleure communication entre eux malgré leur différence de casquette (techniciens/métier). De ces discussions des 'cas d'utilisation' vont naitre des spécifications exécutables. Ces spécifications, ont en effet l'avantage, par rapport a celles produites au cours d'un cycle en V, d'être déterministes et donc non sujettes a l'interprétation des développeurs qui auront pour but ultime de les faire passer du rouge au vert. Après quoi, a lieu la démonstration en présence notamment de membre de la MOA/testeur/utilisateurs. Tout ceci, se fait dans la bonne tradition agile, d'une manière itérative.

Une panoplie d'outils, existe pour répondre a l'implémentation de cette méthode dont ont été cité Jbehave, Rspec et EasyBehave; Toutefois ces frameworks faillent par leur manque de 'maturité' qui se manifesté surtout par:

·         leur difficulté a être géré par les SCM en parallèle du code source des scenarii, 

·         leur difficulté de manipulation par les MOA,

·         leur aspect 'refactoring unfriendly'.

Enfin, on a rappelé que cette méthode proche de la BDD et de la DDD, met l'accent sur le pilotage des développement par les experts métiers, qu'il faut faire intervenir activement au le cycle du développement, dans un esprit de respect et d'étroite collaboration.

Slim Tebourbi

Le développement Hédoniste

Dans cette session 'originale', Dominic Williams, a fait un rapprochement entre l'Hédonisme et l'Agilité.

Tout d'abord, on a eu droit a un petit cours de philosophie dans le but de présenter le courant hédoniste qui se présente comme une 'idéologie' considérant le plaisir comme étant le bien ultime.(et si j'ai bien compris ;) ) .

Ensuite, Willams, a commencé a faire sortir les traits d'analogie entre les deux courants. En effet, tout comme l'hédonisme, « qui a traversé les siècles mais a toujours été dominé, dénigré et occulté par le courant dominant: l'idéalisme»; les méthodes agiles 'peinent' encore a passer devant les «les méthodes prédictives (cycle en V, CMMI, RUP)»; ce point commun met aussi en avant une autre particularité partagé qu'est leur esprit rebelle; cet esprit engendrant un mouvement d'anarchie libertaire' qui nie les structures rigides et l'idealisme.

Enfin, Willams, a itéré les piliers de l'hédonisme en faisant, a chaque fois, le rapprochement avec un aspect de l'agilité .

Slim Tebourbi

La parabole du trafic urbain – l'Agilité expliquée autrement

Après celle avec l'hédonisme, on a eu droit a une autre analogie, aussi originale et réussie que la première, entre l'Agilité et le trafic urbain.

En fait, François Bachmann, a habilement projeter le domaine familier du trafic routier a celui du développement logiciel où les voies étaient assimilées aux ressources humaines du projet, les véhicules (voitures, motos, vélos, piétons...) aux livrables, et les signalisations aux méthodes de gestion. En effet, il a mis en avant l'impact qu'ont ces dernières sur la vitesse moyenne de circulation d'une part, et le débit de production de l'autre. Ainsi, et pour le trafic urbain, les méthodes classiques 'prédictives' ou orienté 'command and control' comme les feux tricolores, donnaient des résultats assez aléatoires et une vitesse moyenne très faible. Par exemple a Tokyo cette moyenne se situe au alentours de 15 km/h, une valeur digne de l'age 'des déplacements a cheval'! Cela est bien sûr, assimilable à la manière waterfall, qui mise aussi sur la prédiction. Ensuite, il a mis en évidence l'intérêt et l'importance de valeurs prônées par l'Agilité telles la communication, la réactivité et l'autogestion dans la fluidité du trafic. Et comme exemple de méthode 'agile-like' au problème du trafic, il a pris le sens giratoire qui incarne :

·         Communication : observer les autres

·         Simplicité : un seul de circulation

·         Rétroaction : aucun flux privilégié

·         Courage : délégation de responsabilité

·         Respect :  responsabilité des conducteurs

Cette présentation, a donnée une vision assez simple et concrète des valeurs de l'Agilité avec des concepts aussi banales que ceux du trafic urbain; Cette vision pourrait servir à faire l'initiation de personnes peu familiarisé et constituée le premier pas de les convaincre de son adoption.

Slim Tebourbi

Au delà de l'intégration continue traditionnelle : l'intégration de la production

Cette présentation traitait le fait que notre vision 'traditionnelle' de l'intégration continue exclue les opérations de déploiement à la production de leur périmètre d'action. Cette exclusion était même considérée 'selon' nos orateurs, dans la littérature du web, comme étant une bonne pratique.

L'un des centre d'intérêt de cette session était le fait qu'elle fut dirigée par deux ingénieurs de production, ce qui permettait de redécouvrir les problématiques liés et traités par l'IC sous un autre angle. Bien conscient de cet aspect, ils ont insister sur le fait que les équipes de production était souvent mis a coté par leur collègues du développement; Cette exclusion se projette par exemple dans la définition du 'terminé' qui se suffit d'un travail livrable; alors qu'il serait plus adéquat d'élargir cette définition jusqu'à la mise en production du produit!

Et c'est la que réside la clé de l'intégration des opérations de production dans le processus du développement agile. En effet, cette modification de la définition de ce concept du 'terminé', va faire inclure celles ci dans le spectre des pratiques agiles et en particulier l'itérativité et l'IC. D'autant plus que les opérations en questions possèdent les caractéristiques requise pour rentrer dans le processus appliqué au code source:

·         gestion du versionning des configurations système, script d'installation des paquets...

·         automatiquement générable par des scripts

·         testable

Ces considérations, nécessitent une nouvelle vision du dépôt de code qui sera désormais le dépôt système; ce dernier regroupera le code source ainsi que les fichiers de configuration  et script d'installation et autres artefacts qui représentent le système en entier et pas seulement le logiciel produit par l'équipe de développement. Désormais, l'IC traitera de nouvelles problématiques orienté système (performance, infrastructure), et sera plus efficace car on elle sera une vrai projection de l'environnement réel de déploiement sous tous ces angles. Choses qui devrait facilité et fiabilisé les déploiements.

Toutefois, les outils nécessitent à cette extension de l'IC sont encore peu nombreux et immatures pour ceux existant sur le marché; contrairement a ceux de l'IC sous sa forme traditionnelle.

Slim Tebourbi

   Blanche Neige et les 7 nains

Pascal Van Cauwenberghe et Portia Tung nous proposent une version Tarantino du célèbre conte pour enfants.

Des protagonistes, ils déclinent des comportements:

• Prof: Savant, axé sur les solutions, arrogant
• Timide: attentif aux besoins des autres, calme, n'aime pas les conflits
• Dormeur: distrayant, facilement distrait, difficile à motiver
• Atchoum: amical, créatif dans la prévention du travail, allergique au travail
• Joyeux: positif, motivé, peut ignorer les problèmes
• Simplet: enthousiaste, manque de discipline, porte peu d'attention aux détails
• Grincheux: analytique, critique, mauvais communicateur
• Chasseur: discipliné, pragmatique, mercenaire
• La Méchante Reine: arrive à ses fins, a soif de pouvoir, manipulatrice
• Blanche Neige: bonne équipière, travaille dur, naïve

 En découvrant les personnages, je me suis reconnu plusieurs fois.

Après une séance de networking organisé, le premier exercice proposé était de se poser les questions suivantes: 

Pour un personnage tiré au hasard, à quelle personne de mon entourage je l'associe?

Ensuite, qu'est-ce que ce choix peut m'apprendre sur ma relation avec lui et sur moi-même?

Quelle action action pourais-je mener afin de changer cette relation et m'améliorer?

Le second exercice etait de définir un projet ambition capable d'attirer les pièces (en chocolat bien sûr) des investisseurs.

Les membres de cette équipe étaient bien sûr des personnage de l'histoire dont 3 sont tirés au hasard, et 2 choisis.

Notre groupe est partie sur des robots 'nains' qui font de la micro chirurgie du coeur.

Et cela nous fait poser la question de "C'est quoi une équipe qui déchirre?", cela donne quelque réflexions amusantes du genre

"Prof est indispensable pour ce sujet très pointu, ce sera notre TechLead", "Grincheux sera un bon testeur", "et simplet...

ce sera notre cobaille", "Grincheux risque de ne pas s'entendre avec Prof", "il faut quand même des chasseur ou des blanches neige qui bossent",

"La méchante reine aussi est utile".

Bref, hors contexte c'est encore plus drôle.

La conclusion est que l'on ne peut changer que soi même.

Je conseille de réaliser ce genre de jeux dans votre équipe.

Si cela vous intéresse, le jeux est disponnible en licence creative commons sur le site http://www.agilefairytales.com/

François Wauquier

Le coaching

Ce n'est pas de coaching agile dont il est question, mais de coaching individuel pour les professionnels. Luc Bizeul a invité Pierre Carnicelli , le père de l'école No Limit Coaching.

Le coaching traditionnel existe en effet depuis longtemps, nous apprennons qu'il se décline sous plusieurs formes:

• Psychanalyse
• Consultant
• Modèle
• Formateur
• Entraîneur
• Tuteur
• Coach
• Mentor

Les principaux enseignements de cette courte session sont que le coach ne doit pas forcement connaître le métier du coaché (Pierre coache dans le secteur du batiment), que seul le coaché peut trouver une solution à son problème, et que le coaching ne peut être qu'une étape transitoire.

François Wauquier

A Quand la première mise en production?

Le Duo Eric Mignot et Hervé Naudin a tenté de regrouper les préoccupations de communication PO/équipe, du niveau de créativité de l'équipe et de l'attente (ou pas) de la première mise en production.

Le lien ne vient qu'à la fin: l'équipe, si elle est impliquée, doit donner envie au Product Owner de mettre en poduction la "dernière story qui déchirre tout".

François Wauquier

Styles Sociaux en action

Jean François Helie  et Bernard Notariani nous présentent le modèle Herrmann, qui permet de nommer une préférence de fonctionnement d'une personne ou d'un groupe à un moment donné dans un contexte donné.

• Analytique
• Explorateur (imaginatif)
• Organisé (séquentiel)
• Emotif (interpersonnel)

Le jeu central se présentait sous la forme d'un débat sur une question (Comment être heureux au travail?, Comment faire de l'architecture dans un projet Agile?)

Les enseignements important nous sont faits:

Deux personnes qui ne sont pas dans la même position auront plus de mal à se comprendre.

La position dans laquelle nous pensons être à un moment n'est pas forcement celui qui est perçu par l'entourage.

Il est difficile de changer de position de manière volontaire.

François Wauquier

Le Planning game

L’objectif de François été de familiariser les quelques quarante personnes présentes au principe du travail en groupe pour l’estimation par l’utilisation de la technique du planning poker. Après une rapide présentation , les personnes se divise en trois groupes, chaque groupe doit mettre en pratique les quelques notions théoriques présentées pour réaliser le backlog d'un projet. Dans mon groupe on s’est vu assigné la tâche d’organiser un mariage, mon équipe été composée principalement de développeur et d’un scrum master, post-it en main, on décide très vite de crée des user stories puis de les estimer une à une.

 Abderrazac Bouadma 

Mon JavaScript est aussi Agile

L’objectif de cet atelier était la réalisation d’un mini langage de validation de formulaire sur la base de l’API JQuery, le mode opération été bien adapté aux besoins de la session « kata », la notion de DSL  (Domain Specific Language) a été exposée pendant la session.

Abderrazac Bouadma 

Dojo TDR

L’objectif été d’établir des spécifications fonctionnelles sur la base de tests fonctionnels. La session a commencé par une présentation rapide de la technique et l’ordre dans lequel se déroulera le Dojo, le choix du domaine fonctionnel s’est avéré intéressant « le black jack », deux personnes sensées représenter les référents fonctionnels se sont présenté volontaires, le présentateur a pris la casquette du scrum master, l’outil sur lequel on introduisait notre contenu été fitnesse, le processus se décompose d’une part par une discussion entre la personne qui veut rédiger la spécification exécutable ou au moins une partie car chaque personne été limité dans le temps « cinq minutes » maximum, et les référents fonctionnels, l’objectif est crée un test suivant le formalisme « Given, When, Then ».

A la fin de la session, on a procédés à une rétrospective qui nous a révélé que la rédaction de spécifications fonctionnelles est une tâches très ardue et stratégique et qui se base essentiellement sur la focalisation de l’ensemble des intervenant sur le cœur du métier en question.

Abderrazac Bouadma 

Le stand recrutement

Durant ces 2 jours, l'équipe de recrutement était présente sur un stand aux couleurs de SFEIR. Cela nous a permis d'être visible et de communiquer sur notre groupe et notre activité. Nous avons pu échanger avec une trentaine de personnes. En majorité, il s'agissait de personnes curieuses mais pas réellement à l'écoute du marché.

Nous avons bien conscience que la plupart des participants n'était pas là dans le cadre d'une démarche de recrutement.

En revanche, cela nous a permis de créer du réseau et de travailler sur du long terme. Nous réfléchissons déjà à  la prochaine édition pour mettre en place un stand un peu différent, et oui n'oublions pas : "amélioration continue"!

Myriam JOURDAIN

Chargée de recrutement.