Lunch break

En gagnant en taille, l’Agile Tour Bruxelles gagne en standing ! Fini les sandwiches, bienvenue au buffet commerce équitable ! La qualité est au rendez-vous, mais l’attente est un petit peu longue. Difficile de d’être parfait en la matière.

De mon côté, je ne tiens pas réellement la forme. On sert aussi du potage en Belgique et je trouve en l’occurrence que c’est une très bonne idée. Surtout quand, comme ici, il est excellent.

Bref, l’ambiance est au beau fixe. On est bientôt d’attaque pour la seconde mi-temps !

Joanne Ho : Agile methodologies for research

Scrum nous enseigne que l’agilité s’applique bien au domaine des projets complexes, mais n’est pas conçue pour les domaines “chaotiques”. J’ai toujours (à tord ou à raison) classé la recherche dans cette catégorie. Joanne Ho nous donne l’occasion d’en savoir plus sur l’adéquation de l’approche agile pour les chercheurs.

L’un des points marquants du fonctionnement des chercheurs est qu’ils ne travaillent pas en équipe ! 

Pourtant la recherche est fondamentalement adaptée au mode itératif : étymologiquement cela ne signifie-t-il pas [Re]cherche ?
Pour Joanne Ho, chercheur environnementale, on peut faire une correspondance entre le travail de chercheur (du moins le sien) et Scrum:

• Le client : c’est la société (au sens large).
• Le produit : de nouvelles connaissances
• La Définition de terminé : la pertinence sociale

Enfin oui, Joanne utilise un backlog. 

Un backlog très mouvant, il faut bien le dire, car :

• Un item peut ne pas aboutir, nécessiter de nouvelles de nouvelles informations et donc être mis en suspens.
• Il peut générer d’autres items.
• Provoquer l’obsolescence d’items déjà présent dans le backlog.

Ce sont des choses qui existent déjà plus ou moins dans le fonctionnement des projets agiles. Sauf qu’il est très difficile d’avoir un plan de bataille fixe pour une itération. Donc la plupart du temps, Joanne dépile simplement l’item le plus prioritaire. Ce ne sont sont donc pas des sprints fixes et l’on est plus proche de XP que de Scrum, n’était-ce la présence du backlog…
Mais si on ne sait pas se fixer précisément d’horizon aux itérations, celles-ci gardent-elles un sens ? La réponse est : oui ! Les itérations aident à faire du bon boulot en gardant le rythme. Sans itération, la masse de travail devant soi devient vite déprimante. Les itérations permettent de se voir avancer, de délivrer de la connaissance grâce auxquelles il sera plus aisé de prendre des décisions en connaissance de cause.
Et les rétrospectives ? Mauvaise nouvelle : les chercheurs sont bien trop occupés pour se livrer à cela !

Joanne Ho nous donne ensuite en exemple un travail récent sur les biogaz. Comment cela s’est-il organisé ?
Traditionnellement, la structure d’une telle équipe serait :

• Le travail en silo est le standard.
• Beaucoup de compétition interne.
• Peu de transparence. Les revues de pair tournent vite aux critiques, voir aux insultes !
• Les stakeholders sont des personnes imaginaires.
• Une reconnaissance basée sur la quantité.

Pour cette étude, il a été constitué une équipe pluridisciplinaire, avec un mode de travail en pair et du test de groupe sur les hypothèses. Le processus était le suivant :

• D’abord comprendre le problème, définir ce que l’on veut tester. Et donc faire l’expérience du stakeholder en allant sur le terrain.
• Définir l’objectif, en définissant le critère de succès.
• Une réflexion en binôme, pour modéliser toutes les facettes du problème. Ce travail doit produire des hypothèses.
• Les tests unitaires, ce que Joanne appelle le “reality check”.
• L’intégration continue : la mise en commun des éléments.
• L’acceptance test : Une solution globale acceptable par le stakeholder.

En conclusion…

• On peut utiliser l’agilité littéralement partout !
• L’agilité est surtout une attitude.
• Sans dialogue, on n’aboutit à rien.
• Se déplacer pour aller réfléchir à différents endroits, sur le terrain.
• Mettre toutes ses tâches dans un backlog.
• Travailler en équipe est une chose nouvelle dans les université. ON n’a pas encore de modèle de fonctionnement pour cela.

En définitive, on fait émerger de meilleures questions, on prends d’avantage de plaisir !
La présentation de Joanne Ho reprends les thèmes développé dans son livre sur Leanpub.

Facile à bien utiliser, difficile à mal utiliser

C’était à mon tour, sur le créneau suivant. Pas de résumé de ma session, il ne faut pas pousser, mais la publication de ma présentation très bientôt, et celle-ci sous forme d’article lorsque je l’aurais complété !

La mesure de mon temps n’était pas non plus excellente. Je vais jouer le joker “état grippal” sur ce coup. Il faut dire que j’avais quand même prévu 20 exercice pour une heure. J’ai probablement été optimiste…

Domenico Musto : Event-Driven Architecture in Practice

Domenico est venu nous perler d’EDA. Il commence avec un point sur lequel j’achoppe : l’architecture doit être planifiée ! 

Enfin, surtout pour les gros projets d’après lui, et EDA n’est pas pour les petits projets.
Mais pourquoi EDA ? Parce que l’architecture doit être “business drivent” , suivre la structure des flux d’évènements métier. Au contraire, les architectures SOA favorisent l’intégration point à point, aboutissant à un réseau inextricable quand le nombre de composants augmente.

Les flux EDA ne sont pas nécessairement des messages d’un MOM, c’est surtout un concept logique qui peut se traduire en :

• Enregistrements d’une base de données.
• Fichiers
• Messages d’un MOM (quand même !)

Le support de ces messages, le canal, transmet différents types d’évènements qui peuvent être :

• Des évènements
• Des commandes
• Des doc-messages ; ce dernier type de message est auto-porteur. C’est un paradigme “push” dans lequel le message comporte tout ce qui est nécessaire au traitement par le composant cible. C’est le modèle vers lequel on souhaite se diriger.

L’architecture EDA implique aussi de nombreux corollaires :

• Le cas des données de référence : Elles doivent être embarquées en partie dans le doc-message. Cela me rappelle un certain nombre de considérations autour du MDM…
• La consistance (de l’ordre) des identifiants d’évènements : leur ordre est-il garanti ? S’il ne l’est pas, il peut y avoir nécessité de versionner les entités afin d’en reconsidérer l’historique depuis n’importe quel évènement.
• L’idempotence, ou la capacité à rejouer un évènement. Cette propriété va de pair avec le versionning.

L’architecture EDA se matérialise par un pattern publish-subscribe asynchrone au niveau de l’architecture. Cela n’est pas sans poser certains challenges en terme de tests. Mais dans cet ordre d’idée, une fois la capacité de test acquise, les composants sont relativement indépendants les uns des autres.
La communication à base d’évènements rend aussi possible le business monitoring (le fameux BAM). Par contre les “évènements avec états” sont un autre niveau de challenge. Il est (en partie) adressé du côté des Web Services avec les corrélations, mais surtout avec les moteurs de workflow type BPEL / BPMN 2.0
Terminons avec les infrastructures techniques. Domenico s’est appuyé sur les “reactive extensions” de Rabbit MQ pour implémenter EDA. De mon côté je pense aussi à Storm que nous mettons en oeuvre actuellement…

Clôture et dernier verre !

Il est l’heure de nous rassembler à nouveau pour conclure ce second Agile Tour Bruxelles.

C’est de nouveau Bruno qui nous donne rendez-vous aux prochains évènements Belges : XP Day Benelux (le seul, le vrai…), l’Agile Tour Namur … et bien entendu l’Agile Tour Bruxelles de l’an prochain !

Comme l’an dernier aussi, les conférenciers ont droit à un cadeau local. Au menu : bierre, confiserie, chocolat et Schtroumph, entre autres…

Pas questions de se barrer comme des voleurs à Bruxelles ! L’an dernier, on avait dégainé la bière locale. Cette année on est visiblement monté en gamme (comme je le disais au début).

J’avais prévu mon train de retour suffisamment tard pour discuter un peu. Et nous l’avons fait à propos de l’informatique et de l’éducation, de la représentation trop faible des femmes et des minorités dans notre métier en nous demandant pourquoi et en ne sachant toujours pas vraiment y répondre…

Il est temps de s’en retourner. Un grand merci à la très sympathique équipe organisatrice. Et à l’an prochain, si tout va bien…