Conf- Agile Open Sud–done

Cette fin de semaine se tenait la conférence Agile Open Sud, qui comme son nom l’indique s’est déroulée dans le sud de la france, près de Perpignan, à Banyuls plus exactement.

Cela a été une formidable occasion de rencontrer des gens à la fois sympathiques et à la pointe de l’état de l’art de leur métier, parmi les meilleurs agilistes français.

 

Le Déroulement

Pour commencer, le format déjà est un peut particulier, tout au moins changeant pour moi qui suis beaucoup plus habitué aux conférences classiques avec plein de monde, des speakers qui présentent leur sujet devant un public attentif, une grosse keynote et des horaires de bureau, sandwich le midi compris.

Pour le coup, là, nous étions une vingtaine, dans un hôtel au bord de la mer prévu pour accueillir des réunions d’entreprises (séminaires ou autres) et cela s’est déroulé de vendredi 16h à samedi 16h, très bon manger et boire compris ;-).

IMG_0962

Ceci implique une immersion complète, ce qui est plutôt une bonne chose.

Le deuxième point est le format de type Open Space. J’avais déjà beaucoup lu sur le sujet mais jamais encore participé à un évènement comme ça. Même si je ne doute jamais de l’intérêt d’un bon débat argumenté, j’avais des doutes sur le mode opératoire et ce que l’on pouvait en retirer.

Bref, je suis convaincu, le format Open Space est vraiment top et je pense que j’essaierai très rapidement de mettre ça en place dans le cadre d’Alt.Net fr. Le point crucial dans tout ça se trouve dans la rétrospective post session. Après chacune il y a en effet un résumé des idées émergentes ou conclusion des points importants des différentes discussions en parallèle.

J’ai été un peu pris au dépourvu en arrivant -oui on était pas à l’heure- car c’était le moment de présenter et choisir les sujets. Hop dans le bain en arrivant. Oui, tu participes et tu t’y mets, tu n’est pas là pour venir juste écouter passivement. Et ça c’est plutôt une bonne chose.

On a enchainer avec deux sessions avant le diner. Ce dernier est lui aussi l’occasion de faire plus ample connaissance ou encore de débattre d’autres sujets. Un point important pour le repas en lui-même qui était juste excellent. Le vin aussi d’ailleurs…

On a terminé avec un coding dojo, puis dodo.

 

Cela redémarre le matin à la cool (mais assez tôt quand même ;-)), petit dej, promenade puis petite séance musicale avec Pablo et Olivier avant de s’y remettre.

D’ailleurs pour revenir là dessus avec Pablo :

Commencer un accompagnement au banjo, c’est comme faire du pair programming

IMG_0965

S’en sont suivi plusieurs séances, déjeuner, puis une dernière session avant la rétrospective finale de l’évènement.

Bref, cela n’en a pas l’air, mais les contenus sont au final beaucoup plus denses que dans des conférences traditionnelles et surtout ce que l’on en retient est beaucoup plus conséquent.

Cela sans parler de la production émergeante en elle-même, car le contenu n’est ni fixé, ni définie à l’avance.

 

Les sujets

Je vous invite à parcourir les posts des autres personnes présentes (voir en bas du post), qui présentent chacun une vision des choses et surtout plus en détail les sessions auxquelles chacun a participé.

De mon coté, et même si c’est en train de changer un peu, je suis quand même aujourd’hui beaucoup plus technique que méthodologies. C’est donc assez naturellement que je me suis senti plus à l’aise sur les sujets à connotation plus technique ou pratique d’un point de vue développeur que sur des sujets de fond (comme Scrum vs Xp, Agilité effet de mode ou pas?, etc…)

 

Voici donc les quelques sujets des sessions auxquelles j’ai participé:

 

Les estimations sont-elles nécessaires?

Oui elles sont nécessaires, mais c’est surtout le processus des estimations qui est important. La quantification juste n’est pas aussi importante que le chemin ou l’arbitrage pour y arriver: cette tâche est plutôt courte ou longue, plutôt complexe ou plutôt facile.

L’estimation se fait d’ailleurs plus facilement dans le temps dès lors que l’on a les repaires de l’équipe: cette tâche estimée à X est-elle plus ou moins difficile/longue que cette tâche estimée à X que l’on a fait sur le sprint précédent?

La discussion des estimations permet en général de lever les ambigüités, de détecter les failles (si j’ai une estimation à 1 et lui à 3, peut-être qu’il y a un point que j’ai oublié). Cela permet aussi de s’obliger à découper les tâches (ok, cette tâche est noté 13 juste parce qu’elle est fastidieuse, tout comme cette autre tâche de 13 qui est complexe, essayons donc de la découper.

Bref, l’estimation valide la convergence. Le dernier point important est qu’elle doit servir de base de travail et d’organisation à l’équipe mais en aucun cas servir d’engagement et sortie du contexte.

 

Polyglot Data

Il s’agissait d’un sujet qui me tenait à coeur. Le sujet s’est croisé avec un autre qui était “faut-il enterrer Merise?”. Nous avons donc débattu des deux. L’idée principale est qu’il faut arrêter de penser modèle de data mais qu’il faut s’intéresser en priorité au modèle métier définissant l’application. Il faut voir le modèle de données uniquement comme un modèle de persistance.

Cette persistance est au final plus liée au type de données et à l’usage que l’on en fait (contraintes techniques, performances, sécurité,etc…). L’émergence de pratiques autour de DDD s’est bien faite sentir de même pour certains de même que le besoin de de se débarrasser des dbas (mais c’est un vieux débat ;-)).

 

Coding dojo

Après manger, nous sommes parti sur un coding dojo un peu improvisé entre gens qui aiment encore pratiquer cette basse besogne de produire du code, mais nous ne sommes pas allé très loin au final, le serveur de l’hôtel sonnant le gong final, nous demandant de plier les gaules.

Note pour plus tard: improviser un coding dojo à 23h après un bon repas, sur un langage maitrisé suffisamment ou presque par un seul des participants, c’est un peu tendu ;-).

 

Agilité et Code Legacy

C’est une question que je me pose toujours, que peut-on faire dans ces cas-là? Il en est ressorti déjà qu’il y a plusieurs niveau de légacy, qu’il y a le problème du code mais aussi celui des équipes, qu’il est difficile dans un cas comme dans l’autre de faire évoluer les choses si il n’y a pas les deux qui convergent.

La mission critique passe en général par du refactoring en douceur (bravo à Jérôme pour son abnégation dans sa mission actuelle où il est en plein dedans) mais en gardant bien en tête que la base de tout est la mise en place au fur et à mesure de tests. Puis il y a le passage de témoin, le souci étant plus souvent dans la manière de travailler des équipes en places que dans le code lui-même. On trouve toujours des solutions techniques à un problème mais il est plus difficile de faire évoluer les mentalités ou les manières de travailler. Pour cela nous avons pu voir qu’une des meilleures solutions était de mettre en place du pair programming.

De la même manière au niveau de l’entreprise en elle-même, on se rend compte que la rupture avec du code legacy se fait souvent quand celle-ci se trouve au pied du mur, qu’elle n’a plus le choix. C’est dommage, mais c’est une certaine réalité, tant que l’entreprise a les moyens d’entretenir son code legacy elle du mal à se remettre en question.

Jean-Baptiste nous a d’ailleurs présenté un modèle de migration legacy qu’il a pratiqué avec succès:

  1. Société au pied du mur avec code legacy
  2. mise en place d’une nouvelle équipe externe agile
  3. Prise en main de l’existant par cette équipe
  4. Stabilisation avec le métier
  5. tests, refactoring
  6. intégration des membres de l’ancienne équipe au fur et a mesure
  7. Fin du projet avec un code à jour, testable, des process en place et une équipe à jour.

Jérôme nous a fait aussi une belle démonstration à partir d’un plan d’attaque de rugby.

 

AvancerEnsemble

Si dans une équipe Legacy (ou autre, c’est vrai aussi), il y a quelqu’un qui avance très vite, plus que les autres (il a bien intégré les principes de l’agilité et du TDD par exemple), si il avance tout seul, il va se faire manger, et il va perdre le ballon (le fil du projet, le courage, la motivation dans notre cas ;-)).

Ce qui compte c’est de consolider ses positions. Si quelqu’un avance plus vite, alors doit tirer les autres vers le haut, par une séance de pair programing par exemple.

Création coding dojo Solid

L’idée était de commencer à mettre en place les éléments de réflexion pour la création d’un coding dojo sur les bases du principe SOLID.

Guillaume avait déjà commencé à mettre en place un début d’implémentation en C# et nous avons discuté autour de ça, principalement autour de ISP et SRP pour commencer.

Nous avons donc un début de process sur lequel nous allons essayer de revenir dans les semaines à venir. J’espère pouvoir partager ça avec vous, peut-être dans le cadre d’une session alt.net si il y en a que cela peut intéresser.

 

L’agilité par le jeu du développeur.

Nous avons pu jouer avec Kodu, une plateforme pour apprendre aux enfants à développer des jeux. Le but était de voir comment on pouvait se servir de cette plateforme –lors d’un dojo par exemple- pour montrer aux participants les principes du développement agile.

Le principe serait de se servir de cette plateforme, qui nous permet donc de faire une abstraction totale du langage de développement tout en produisant quelque chose de concret, pour comparer le travail réalisé par deux équipes, l’une en mode cycle en V, l’autre en mode agile.

Sur le principe c’est un bon concept, il faudra que l’on creuse sa mise en place.

En tout cas, je note bien ce formidable projet de Microsoft FUSE labs pour jouer plus tard avec mes enfants ;-).

 

 

Aller plus loin

Il y a eut aussi plein de découvertes (Sociocratie, Jugement majoritaire, etc…) et de discutions animées pendant les repas qui encore une fois étaient tout simplement excellents.

Bref, c’était une formidable expérience, très dense quand on y pense et que je renouvèlerai dès que possible. Merci encore aux gentils organisateurs pour tout et à tous les participants, dont je pense que la plupart vont être visibles au Scrum Day le 27 mars.

Vous pouvez retrouver sur twitter la plupart des participants à partir de la liste faite par Romain ici:

https://twitter.com/#!/rvignes/agile-open-sud-2012/members

 

Et pour continuer les autres posts sur l’évènement des autres participants:

Tagged with: , , , ,
Posted in Event
2 comments on “Conf- Agile Open Sud–done
  1. C’était effectivement excellent ! Merci pour ce retour !
    Promis, le 26/03, c’est le retour de Genba (aka mon blog) !
    Ravi de t’avoir rencontré !

    A bientôt ! :)

    • Anonymous says:

      Tout pareil, c’était top de t’avoir vu en vrai ainsi que tous les autres!

      Oui, recommence à écrire, les billets précédents étaient très interessants, tu as beaucoup de bonnes choses à partager ;-)
      +

3 Pings/Trackbacks for "Conf- Agile Open Sud–done"
  1. [...] Claude Thierry Pablo Des photos La liste twitter de (presque) tous les présents Alexis Rui Tweet [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>