Rien ne nous trompe autant que notre jugement.

Léonard de Vinci

Project Management. Sigh!

businesscraftsmanship:

“Let’s organize this thing and take all the fun out of it” — Ashleigh Brilliant

I’m aware that some folk think I like to dismiss project/program managers as unnecessary overhead in organizations, so I’ll start by saying I know some wonderful people who work under these titles. This post is not…

Project Management. Sigh!

Neo4J contre SAP Hana

Il y avait un petit moment que l’on n’avait pas eu de meetup Neo4J sur Paris ! C’est donc avec une façon un peu provocante d’aborder un sujet à connotation BI que nous avons été invités !

Nous étions environ 30 à nous rendre ainsi dans le showroom Zenika.

image

Introduction

Cédric Fauvet, toujours égal à lui-même nous fait son habituelle introduction sur les graphes. Presque habituelle, devrais-je dire, car il fait un peu évoluer son propos de meetup en meetup, tout comme son support.

image

Aujourd’hui, le spectre des problèmes couverts par les bases orientées graphes couvre :

  • La collaboration
  • Le SCM
  • L’analyse géo-spatiale
  • L’étude des interactions moléculaires
  • L’analyse d’impact
  • Le MDM
  • La gestion de lignes-produit
  • Et bien entendu la recommandation et les liens sociaux !

En Juin, Neo4J France devrait nous gratifier d’une présentation d’un projet « Dropbox-like » réalisé par des étudiants !

Cédric attire également notre attention sur le talk de Volker Pacher expliquant pourquoi Neo4J augmentait la capacité de delivery de Shutl (acquis depuis par eBay).

Il est l’heure de la pause pizza, nous allons bientôt attaquer la pièce maîtresse de la soirée !

image

Analyse des tickets de caisse avec Neo4J

Nicolas Mervaillies et Charles Besselièvre nous présentent le projet qu’ils ont développé pour « un grand client retail ». Il s’agit d’un petit projet, c’est à dire moins de 100 j/h, qui devait être développé rapidement. Sur les projets analytiques orientés « real time », cette enseigne s’appuie généralement sur SAP Hana. Mais ce projet tactique présente des échéances de temps incompatibles avec ce type de projet, plus adapté à des solutions légères menées en agile.

image

La problématique est essentiellement simple : trouver des corrélations d’achats. Vous savez, celles qui ont permit de déterminer que les couches culottes sont souvent achetées en même temps que le bière le samedi ou qui ont permit à une enseigne d’apprendre via des bons d’achat à une jeune fille qu’elle était enceinte avant qu’elle même ne le sache ! Ici les corrélations doivent être croisées entre magasins et entre régions. Pour chaque magasin, il faut compter une volumétrie de 300 millions de lignes de ticket par an.

Phase 0 : Prototypage

Pour cela on utilise simplement la console Neo4J ! En fait, on ne représente pas chaque ligne d’achat en liaison avec le ticket de caisse : on agrège ces lignes par sous-familles. Bien sûr, les tickets sont associés à une date, un client et un magasin.

Grâce à cela, on voit avec Cypher si l’on parvient à produire les analyses que l’on souhaite.

Phase 1 : Construction initiale

Premier fonctionnement en production : les données de ticket de caisse sont récupérés tous les mois et injectés avec Spring Batch. Le client peut agréger les données en live via des requêtes Cypher : dans le temps, par famille de produits, par magasin.

Les couplages repérés avec de forts pourcentages sont donc mis en exergue dans certains magasins, on compare les éléments différenciants des magasins ayant de moins bons taux de corrélation !

On a toutefois un problème : trop de lenteurs, dû aux fortes volumétries, mais aussi au déploiement de Neo4J sur des serveurs virtualisés. La virtualisation et les bases de données, ce n’est pas le grand amour, même si certains ingénieurs système essaient de se convaincre du contraire !

Phase 2 : Focus sur le « top 15 »

En analysant les données des différents magasins, on perçoit dans le temps des réccurrences d’association, notamment dans le « top 15 ». Nos artistes choisissent donc de précalculer les associations significatives, celles correspondant au « top 50 » de chaque magasin, mais sans Marc Toesca !

Phase 3 : Optimisation de production

En dernière phase, il faut finalement réaliser des optimisations purement de production : gestion de l’infrastructure, mise en place de cache, etc…

En conclusion…

L’utilisation de Neo4J est parfaitement adaptée à ce type de projet tactique : on a la rapidité de de mise en place et la vitesse d’exécution de ce projet typique d’un projet agile ! Par rapport à SAP Hana, on gagne réellement en time to market !

L’équipe a aussi développé un front-end pour faciliter l’utilisation du système. Mais à la limite, cela aurait pu être omis !

Concernant l’infra : elle a été gérée complètement en interne pour des raisons de non exposition de données sensibles. Toutefois, on a une machine puissante qui ne sert que quelques heures, une fois par mois ! Ce type de configuration se marrie donc bien avec le Cloud.

Enfin, l’aspect communautaire de Neo4J permettant de trouver de l’aide sur les forum a été un plus important !

Faute de disposer du support de présentation, je vous propose ici l’enregistrement de la même session qui s’est déroulée au meetup Neo4J Lillois !

Ce que j’en ai pensé

C’est probablement le meetup Neo4J le plus interactif et le plus convivial auquel j’ai pu assister. Les interventions fort pertinentes d’un connaisseur SAP Hana ont été un gros plus dans la discussion, surtout quand, comme lui, on connait et sait reconnaitre les qualités de ce système. Il est là, juste derrière moi.

Pour clore ce compte-rendu et donner un avis éclairé sur cette confrontation, je le citerai :

« Remplaçons notre argent par notre intelligence ».

Cela me rappelle un peu un slogan des années 70 où il était question de pétrole…

Carnet de route : Agile France 2014 (4/4)

Nous voici arrivés au bout de notre périple. Les épisodes précédents sont disponibles ici et ici pour la journée du Jeudi, et ici pour le vendredi matin.

Au programme de cette dernière après-midi : des demi-sessions (dont la mienne) et une clôture de l’évènement toute particulière !

Matti Schneider : Petit board deviendra grand

Je ne connaissais pas Matti. Je dois dire qu’il m’a bluffé par son niveau de maturité en agilité et la qualité de ses analyses. Peut-être est-ce lié au fait qu’en plus d’être ingénieur, il est également étudiant en anthropologie ?

image

Matti évoque pour nous l’amélioration continue, avec une approche qui sort des très classiques rétrospective et est d’avantage « centrée artéfacts ».

Façonner nos outils

Le point essentiel de la présentation est l’utilisation d’un outil (oui !), en fait un tableau, qui va guider l’équipe d’une façon particulière : faire entrer en résonance le descriptif et le prescriptif par le biais de cet outil !

Quand un changement de workflow est pressenti : le tableau change et devient prescriptif. Et comme l’équipe suit ce tableau, il devient alors prescriptif. Le tableau évolue par le biais de l’équipe de production qui est elle-même une partie de l’outil de production ainsi décrit.

Le passage d’une étape à une autre fait l’objet d’un « point fixe » : un état que l’on sait parfaitement définir par lequel passe obligatoirement les items. En dehors de ces points fixes, la façon dont évoluent ces items peut varier !

Voilà qui rappelle une citation de McLuhan : nous façonnons nos outils et eux-même à leur tour nous façonnent ! Et la façon dont nous les façonnons passe au travers de nos interactions.

Reflection workshop

Cette approche, à la base une variante des classiques rétrospectives agiles, est issu de Crystal Clear d’Alistair Cockburn. L’incarnation qu’en fait Matti est au travers d’un board synthétisant les décisions prises au long des itérations ! On a donc une vue d’ensemble de la chose. Les règles sont d’abord simples (dans les premiers sprints) et deviennent de plus en plus pointues. Elles peuvent aussi être changées / abandonnées, on leur superposent alors un post-it bleu avec le numéro de l’itération à l’origine de ce changement.

Les tickets agissent comme des « reminders » évitant de réitérer une discussion sur laquelle il y a déjà eu un accord. Certains guides focalisent sur l’usage du board lui-même, une sorte de niveau méta…

Ce que j’en ai pensé

Une présentation remarquable qui traduit une maturité tout aussi remarquable. Ce fut ma présentation préférée de cette après-midi là.

Géry Derbier : Les jeux de langage de Ludwig Wittgenstein

Ce n’est pas souvent que Géry nous gratifie d’une session qui n’est pas un atelier. En fait, c’est la première fois que j’y assiste ! Géry avait envie de partager depuis longtemps ce qui l’attire sur la pensée de Ludwig Wittgenstein. Une session pas très facile à suivre et encore moins facile à retranscrire !

image

Le plus simple est problement de ne pas faire de retranscription. Je vais simplement relever certains éléments que j’ai noté au fur et à mesure de la présentation de Géry.

  • La primauté de l’acte sur la pensée.
  • La théorisation est vaine. Il est préférable de voir et décrire ou « déconstruire » précisément.
  • Comprendre n’est pas l’intellectualisation de quelque chose, mais l’aptitude à le faire.
  • Nous utilisons un langage : regardons comment il fonctionne.

Cette façon de pensée amène Géry, en tant que coach, à demander au coaché de « déconstruire » les constats par une question : comment le savez-vous ?

C’est aussi ce mode de pensée qui a amené Gery vers le solution focus qu’il voit comme une incarnation de la pensée de Wittgenstein.

Ce que j’en ai pensé

Une session difficile à suivre qui nous amène vers les sentiers d’une philosophie à contre-courant. Je ne suis certainement pas rompu à cet exercice (je n’ai même pas d’épreuve de philo dans mon bac technique !). Bref, je passe pour l’instant…

Pierre Hervouet : Manipulé à l’insu de mon plein gré

Hélas, j’ai assez peu suivi la session de Pierre. Il faut dire qu’elle précédait juste la mienne. Au minimum pour commencer, je peux vous en livrer le teaser.

Pourtant cette session s’articule autour d’un de mes sujets préférés : les biais cognitifs ! Pierre évoque ainsi quelques mécanismes :

L’ancrage

Le cerveau humain juge souvent en relatif. Si on fournit une référence, elle biaise les résultats obtenus, par le haut ou par le bas, suivant que le référence d’origine est haute ou basse respectivement !

Le planning poker, en exigeant que les cartes soient montrées en même temps cherchent à éradiquer ce biais.

image

L’identification

S’identifier à une personne est plus fort que s’adosser à des statistiques ! Le mécanisme des persona s’appuie sur cela (en lieu et place des rôles, plus abstraits).

Ce que j’en ai pensé

Essentiellement que je suis frustré de n’avoir pas mieux suivi cette session. Damnation ! Car le sujet m’intéresse au plus haut point. Mais je ne peux en vouloir qu’à moi-même. J’espère que le support ou mieux l’enregistrement sera bientôt disponible…

Christophe Addinquy : User Stories, what else ?

C’est mon tour ! Au programme une version plus dense, en partie raccourcie et en partie modifiée de ma présentation faite à Agile Grenoble 2013. J’ai dans ma liste de tâches, la rédaction de cette présentation sous forme d’article, comme je l’ai fait pour Scrum Shu Ha Ri.

Je publierai aussi sous peu la nouvelle version correspondante du support.

Les 10 buzzwords du hipster agile

Cette dernière demi-session ne fut pas ma préférée de l’après-midi, bien au contraire. Le but était en principe de démystifier certains de ces buzzwords, de les dégonfler. En fait, je me suis trouvé en désaccord avec nombre des assertions de Christopher et Hervé !

image
  • Lean Startup = XP + Product Management ! Bien sûr, Eric Rie est un ancien de XP. Un peu léger pour affirmer que Lean Startup est un réhabillage d’XP avec les idées de Steve Blank ! Il ya mieux et plus à dire d’autant que l’inspiration initiale est beaucoup plus « lean ». Dehors !
  • Le MVP n’est pas la réalisation minimale de mon produit. Je suis d’accord !
  • Le devops n’est pas un process ou un outil, mais la collaboration entre ops et dev : d’accord aussi !
  • Continuous deployment, ce n’est pas mettre en production des bug fixes tous les jours. Certainement, mais d’ou vient cette idée ?
  • Le Kanban, il doit suivre la définition d’Anderson ! Ce n’est pas lui qui a inventé le Kanban, et on peut aussi faire des proto-Kanban sans mettre en place de WIP initialement !
  • Le Proxy PO : Bon, nous sommes d’accord sur l’absurdité du concept !
  • La transformation agile d’entreprise. Une foutaise pour les orateurs. Certainement, si on mène cela comme un nouveau process et non comme un changement culturel et organisationnel !
  • La feature team : Désolé, je ne suis pas prêt à considérer comme un « nouveau buzz » quelque chose décrit par Ken Schwaber en 2004…
  • Le Design Thinking. Bien, là aussi je doute que les orateurs ait fait l’effort de rentrer dans le concept…
  • Agile. Oui c’est vrai le « on fait ça depuis longtemps mais on appelait pas ça comme ça », on l’entend réellement tous les jours.

Bref, pas enthousiasmé par cette session. Mais alors, pas du tout…

Fresque Finale

Le scribing était notre grand fil rouge de la conférence. Pour clore en beauté celui-ci, Romain nous a invité à élaborer en commun une grande fresque faisant le tour de la salle Belvédère. Un bel exercice !

image

Keynote de clôture ?

L’organisation d’Agile France nous réservait une petite surprise pour clore ces deux jours : une fausse session proposée avec talent par la compagnie des Z’Humbles.

image

Drôle et bien enlevé. C’est une façon originale de terminer cet Agile France !

Alors, cet Agile France 2014…

image

Une formule en grand changement pour cette nouvelle édition, avec deux après-midi à caractère spécifique, sans oublier le fil rouge de Romain. Toujours une grande qualité dans les sessions et la magie du Chalet de Porte Jaune ! Les organisateurs ont réellement redoublé d’efforts pour réussir cette nouvelle édition.

Carnet de route : Agile France 2014 (3/4)

Suite du compte rendu d’Agile France, après la journée de Jeudi disponible ici et ici.

De bon matin…

De bon matin, ce n’est pas moi. J’arrive à temps pour le café et discuter un peu avec les autres. Mais quand j’arrive, un petit groupe se livre déjà à des exercices de Qi Gong.

image

Je retrouve les autres dans la salle commune. On discute, Alex Tweet. Business as usual…

image

Assez plaisanté ! La journée va commencer, place à la keynote !

Coaching Teams Through Change

Rachel Davies nous avait déjà gratifié d’une session il y a peu lors du ScrumDay. Fort heureusement, ce ne fut pas la même. J’ai d’ailleurs préféré cette keynote.

Rachel travail pour Unruly, une société spécialisée dans le « social media advertising ». C’est un domaine où les spécifications changent véritablement tous les jours. L’objectif est ainsi de déployer effectivement tous les jours !

image

Le début d’un changement

Au début les départements produit et développement étaient deux directions séparées. C’est le départ du directeur produit qui a permit d’enclencher un changement de structure.

Ce changement, c’est l’organisation en équipes de 3 à 5 personnes pour développer le produit. Et pas seulement développer : ces équipes prennent en charge la totalité des activités entourant le développement : l’écriture des user stories, les tests, etc. Ce sont eux qui vont solliciter les différents interlocuteurs (produit, marketing, commercial) quand cela s’avère nécessaire. Pas de product Owner qui est la seule voix du client, l’équipe va parler directement à tous les interlocuteurs ! Parmi ces interlocuteurs, nombre d’entre-eux ne sont accéssibles qu’à distance : l’équipe utilise Google Hangout pour communiquer. La conversation s’engage avec les interlocuteurs pour trouver la plus petite chose utile à construire, ce qui nécessite de prendre en compte tous les point de vue.

Lone rangers et development owners

Tout le développement est réalisé en binômes. Mais les équipes sont constituées d’un nombre impair de personnes ! En fait, par rotation, l’une d’entre-elle est le « lone ranger ». Elles s’occupe de diverse choses dans l’équipe, mais pas du code de production. C’est aussi à cette personne que les intervenants extérieurs à l’équipe s’adressent, afin de ne pas perturber les binômes en train de travailler.

L’équipe a aussi développé l’idée de « owner of the development area » : un développeur plus expert au sein d’un sous-ensemble fonctionnel. C’est lui qui élabore une proposition par rapport à un besoin exprimé.
Les propositions sont traitées en planning meeting. Celui-ci n’est pas un planning meeting classique XP : seule la priorisation des propositions y est traitée, il n’y a pas d’engagement de charge. Ces planning sont donc très courts : ils n’excèdent pas 30 minutes !

Gold card

A l’image de ce que Kniberg décrit pour Spotify, Unruly fait des efforts particuliers par rapport au bien être des équipes. Outre divers évènements sociaux, la société applique la politique du 20% free time inspirée de Google (bien qu’elle disparaisse progressivement de Google, justement). Ici elle s’appelle « gold card day » et sert de sources d’inspiration pour creuser de nouvelles idées.

Ce que j’en ai pensé

Sans être exceptionnelle, cette présentation nous offre l’opportunité d’avoir un retour sur une organisation d’équipe différente de ce que l’on voit aujourd’hui :

  • Les itérations s’estompent au profit de la déliverie continue, mais des points de priorités réguliers contrebalancent l’effet « court terme » du flux.
  • Pas de « product owner » ici : c’est l’équipe qui fait le lien avec les divers interlocuteurs. Le périmètre de responsabilité de l’équipe s’accroit, mais on évite ainsi l’effet paravent du PO !

Je change mon programme à la dernière minute. Je choisis en 15 secondes d’aller à une présentation résolument technique. Grand bien m’en a pris !

Le mythe du framework agile

Jean-Baptiste Dusseault vient mettre fin à quelques idées reçues concernant ces frameworks qui doivent nous agilifier / faciliter la vie. Au départ de ce « ras le bol » un titre de livre : Agile Web Developement with Rails ! Même co-écrit par l’un des signataires du manifeste agile (et par l’auteur de Rails), ll y a un problème ici. Probablement plusieurs même. Le premier est la taille du livre : près de 500 pages !

Le framework maison

Mais commençons par le commencement. Et le commencement, puisque nous parlons ici de frameworks « full stack », c’est le fameux framework d’entreprise. Un bon point : nous n’avons que trop rencontré ces pantalonnades. Lâchons-nous, ça va faire du bien !

image

Le but de ces frameworks, c’est d’avoir le « meilleur du moment », tout bien branché ensemble. On met les pantoufles, on débranche le cerveau, et l’on peut tranquillement produire plein d’applications en un tournemain !
Sauf que ça ne se passe pas comme ça. Ces braves frameworks transforment notre vie en enfer !

Citons dans le désordre :

  • Prévus pour être simples, ils s’avèrent en fait ultra-compliqués ! Peut-être leur conception et leur réalisation par des « équipes transverses » explique-t-elle quelque chose ?
  • Ils sont difficiles à tester et très bugués. Là encore, leur réalisation détachée des projets n’a pas contribué à leur testabilité. Utilisés uniquement par quelques projets de l’entreprise (au mieux) le « durcissement » du framework n’a jamais vraiment eu lieu…
  • pas de support : souvent les équipes ayant réalisé le framework sont parties depuis longtemps…

Qu’en est-il des « full stack » reconnus ?

Ici on parle des rails, Play, etc… Ils nous font la même promesse d’accélérer les développement du sol au plafond. En vérité, ils prennent des décisions d’architecture pour nous ! Jean-Baptiste va plus loin : en déléguant les choix d’architecture au framework, on laisse celui-ci nous utiliser !

Nous n’utilisons pas les frameworks “full stack” : ce sont eux qui nous utilisent.

Ce biais a des conséquences, on va le voir bientôt.

D’où vient leur succès ? Ils permettent de faire très vite 80% de l’application. Mais on galère sur les 20% restant ! Généralement, la réalisation en suivant le tutorial va vraiment vite.

Hélas, ils encouragent certains comportement. La partie « basse » entité et persistance est plus ou moins câblée. Il n’est pas possible d’y intervenir facilement. Et les entités ressemblent beaucoup aux tables de la base de données (ça rappelle les outils RAD client/serveur). On hérite donc d’un couplage vertical sur la base de données.

En fait, le seul endroit où l’on peut réellement raccrocher du code, c’est le contrôleur ! On l’accroche comme on peut. Et si des comportements communs apparaissent dans le code tartiné sur deux contrôleurs, le seul moyen efficace de le partager est le copié-coller ! Beurk !

Bref nous obtenons :

  • Des architectures monolithiques.
  • Des frameworks optimisés pour l’écriture de code … mais pas pour sa maintenance !
  • Des couplages forts avec la représentation et la base de données.
  • De grosses difficultés pour sortir des clous via des « plugins » et autres joyeusetés du genre qui ont de grosses courbes d’apprentissage.
  • Une testabilité rarement au rendez-vous.

Mais alors, c’est quoi un framework agile ?

Plutôt que de framework agile, parlons d’architecture agile, et des propriétés qu’elle devrait avoir.

  • Elle doit nous permettre de retarder les décisions
  • Elle minimise les couplages.
  • Elle est facile à changer.Elle est testable (via TDD et ATDD)

Une proposition et des inspirations

Pour Jean-Baptiste Dusseault, une telle architecture c’est :

  • Au centre un véritable modèle du domaine d’inspiration DDD, comme les proposent l’architecture hexagonale d’Alistair Cockburn ou la Clean Architecture de Bob Martin. Ce modèle ne dépend de rien et ne connait pas la persistence ni aucun système tiers, mais expose une API métier.
  • Une couche « commandes » implémentant les cas d’utilisation du modèle du domaine. Des idées que l’on retrouve dans la Lean Architecture de Jim Coplien.
  • Au-dessus un couche d’accès type CQRS dialoguant en asynchrone avec la couche commande et routant différemment les évènements commande (vers la couche commande) des requêtes qui sont adressées directement à la couche d’accès à la base de données.

Bien sûr le postulat de cette architecture, c’est que le métier est au centre des préoccupations. On n’évoque pas non plus l’architecture en micro-services qui me semble pourtant adaptée mais peut-être pas facile à concilier avec une architecture hexagonale…

La présentation de Jean-Baptiste est évidemment en HTML5 et elle est accessible en ligne ici.

Ce que j’en ai pensé

Cette session est une agréable surprise. Si le bashing des « frameworks agile » ne fait que confirmer ce que je pensais, les idées développées sur l’architecture agile me font beaucoup plus réfléchir, pour ne pas dire qu’elles soulèvent mon enthousiasme !

Comment j’ai développé mon muscle de l’amélioration continue en faisant mes courses

Ayant décidé de bouleverser mon programme, je n’ai de nouveau que 2 minutes pour changer mon programme. De nouveau, c’est une bonne pioche avec la session de Cyrille Deruelle !

Tout d’abord : pourquoi faire des exercices d’amélioration ? Pour que cela devienne une habitude, rendre cela naturel. Et Cyrille s’est livré à cet exercice en faisant ses courses du Samedi : c’est drôle et instructif !

image

Bien sûr tout ça n’a pas très bien marché du premier coup (d’où la nécessité de s’améliorer). Au départ, Cyrille a essayé d’impliquer son épouse (Product Owner des courses) dans la résolution des problèmes qu’il rencontrait. C’est une première leçon :

Les gens se foutent de la manière dont nous résolvons les problèmes.

Au hasard des améliorations, on va trouver :

  • « t’as rien oublié » … où comment suivre que l’on a tout acheté ? A l’aide d’une liste de courses et d’un gros feutre noir (le stylo fin ne convient pas).
  • Grouper les courses par catégorie : afin d’optimiser le parcours dans le magasin.
  • Prendre une photo des rayonnages pour les produits compliqués … afin de permettre à son épouse d’indiquer le produit souhaité. Le choix de la lessive a été vaincu ainsi !
  • Gérer les dates limites de consommation en les pré-calculant par rapport aux courses suivantes : afin d’éviter les erreurs pendant les courses.
  • Sortir des éléments du process : Les packs d’eau, c’est ingérable ! Alors on ne les sort du processus standard et on fait de temps en temps des ravitaillements en eau (en grande quantité) !

Les conclusions de Cyrille

  • Mes problèmes sont mes problèmes : Il n’est pas possible de s’en décharger sur d’autres personnes.
  • Il n’y a pas de choses simples : l’amélioration continue est une quête !
  • Les actions d’amélioration sont fragiles et difficiles ; c’est une discipline de tous les jours.
  • Mesurer l’impact d’un problème, c’est déjà 50% de la résolution

Enfin parfois, les améliorations ne sont pas possible, c’est le CCMCCC : C’est Con Mais C’est Comme Ca !

Grâce aux actions d’amélioration, Cyrille n’a pas seulement rendu son processus de meilleure qualité et plus efficace, il l’a aussi rendu fun !

Ce que j’en ai pensé

Une très bonne session : amusante et instructive. Bravo !

Refactorer du Legacy

Pas besoin de changer de salle pour la session de Johan Martisson. J’ai rencontré Johan lors du ScrumDay 2014. Ou plus exactement, Jean-Laurent de Morlhon me l’avait présenté. D’ailleurs Jean-Laurent était là à cette session résolument intimiste orientée craftmanship, avec des vrais morceaux de « live coding ».

image

Johan nous parle et nous démontre son approche de la reprise en main du code legacy, à l’aide de la librairie ApprovalTests. Pour résumer l’approche en quelques points :

  • On construit un harnais de tests résolument temporaires de manière rustique mais rapide.
  • On construit de manière assez brutale des combinaisons de conditions d’entrée pour couvrir une combinatoire de cas couvrant l’espace du problème.
  • On exécute une première fois les tests pour constituer la référence, sans se soucier de la justesse des résultats : il s’agit juste du comportement courant de la librairie.
  • On vérifie la stabilité du comportement du soft en comparant les résultats par rapport à la référence.
  • Au fur et à mesure du refactoring, on construit des tests unitaires définitifs. On peut envisager de se débarrasser définitivement des tests temporaires, de manière progressive.
image

Ce que j’en ai pensé

Au début de la présentation, je mes suis demandé où Johan essayait de nous emmener et j’ai pris conscience avec un peu de retard de l’efficacité et de la rapidité avec laquelle Johan mettait en place son harnais de tests ! Je dois dire que c’est très convainquant. Une petite vidéo pour vous en convaincre.

J’avais prévu d’être un peu plus long sur le descriptif de ce que Johan nous a montré avec l’outil, mais il le fait mieux que moi sur son blog. Je vous invite donc à le lire.

Pause déjeuner

Par une curieuse coïncidence, c’est de nouveau avec Jean-Luc Lambert que j’ai échangé lors de cette pause. Et nous avons parlé éducation et « génération Y ». Jean-Luc évoque avec enthousiasme le challenge que représente l’enseignement avec cette population.

  • Elle ne prend pas pour acquis les propos de l’enseignant. Le cours magistral a une vertu pour le moins limitée.
  • Ils sont « multi-tâches ». C’est assez déroutant, mais il faut faire avec !
  • Ils sont réceptifs aux jeux et aux exercices libres. Les techniques type « from the back of the room » leur sont bien adapté.
  • Ils ont beaucoup d’autonomie et sont entreprenant.
  • Ils ne se sentent pas beaucoup d’attache ni de fidélité pour la société pour laquelle ils travaillent.

Voilà pour cette dernière matinée. Je vous retrouve très bientôt pour la dernière partie de cet Agile France 2014 !

Ma galerie de photo du Printemps Agile 2014

Je vous avais asséné il y a quelques temps deux posts (ici et ici) sur le Printemps Agile qui s’est déroulé à Caen le 20 Mars. Voici la galerie de toute les photos que j’ai prises durant cette journée. Ce n’est hélas pas la couverture photos dont je suis le plus satisfait, loin s’en faut.

Présentation Marshmallow Challenge (2/2)

Les équipes Marshmallow challenge (1/7)

Les équipes Marshmallow challenge (3/7)

Mon équipe !

printemps agile 2014, un album sur Flickr.