Soirée « en finir avec… »

Cela faisait déjà un petit moment que je pensais à ma petite soirée mégalo à moi. Oh, surprise, elle a fini par avoir lieu ! Nous nous sommes donc retrouvé ce Jeudi 29 Janvier chez Zenika autour de ce thème. Cette fois, ce ne sont pas les intempéries, mais une grève inopinée des transports qui ont eu raison de l’enthousiasme de 2/3 des inscrits. Heureusement pour nous le format d’atelier que nous proposions se prêtait bien à un groupe plutôt restreint, une vingtaine de personnes.

Bon, c’est ma soirée, c’est donc à moi de faire l’ouverture !

Pas de répit pour les braves, on enchaines avec les propositions et les choix de sujets !

Lire la suite

Soirée « en finir avec… » organisée par le French SUG

Ca y est, je l’ai : Ma soirée mégalo à moi ! En effet, le 29 Janvier nous nous retrouverons sous l’égide du French Scrum User Group pour une soirée exceptionnelle « en finir avec… ».

Pourquoi une telle soirée ? Tout d’abord pour fair écho bien sûr à la série de post que je vous ai asséné depuis maintenant 3 étés, et que vous retrouverez encore quelque temps. Ensuite et surtout pour réfléchir ensemble à nos pratiques agiles : les comprendre et savoir les remettre en cause !

En effet, nous tenons pour acquis la nature agile des pratiques identifiées comme « bonnes pratiques ». Qu’en est-il réellement ? Quelle est la nature et l’objectif fondamental de chacune d’entre-elles ? S’inscrivent-elles vraiment dans notre système de valeur ou s’en éloignent-elles au contraire sous pretexte de compromis à un environnement aux antipodes de ce que nous voulons faire ? Notre acceptation inconditionnelle même de ces pratiques s’inscrit-elle dans un état d’esprit agile ? Mais là, je crois que nous avons déjà la réponse…

Si ma prose vous interpelle, rejoignez-nous le 29 Janvier ! Aucune promesse ne sera faite sur ce que vous pourrez en retirer, car cela dépendra largement de ce que vous saurez y apporter !

Soirée « en finir avec… » organisée par le French SUG

Formons-nous à Kanban avec le FKUG

Zenika accueillait cette nouvelle réunion mensuelle dans le zLocalHost. Une foule très nombreuse s’y était donné rendez-vous pour cet opus dédié à la formation au Kanban et aux techniques associées.

image

Un programme très chargé. Peut-être un peu trop, c’est vraiment tout ce que l’on pourrait reprocher à cette remarquable soirée !

Après le mot d’accueil du Sponsor soirée, Couthaier nous donne quelques nouvelles de l’association. Elle est très active il faut bien le dire. D’ailleurs la soirée suivante aura déjà eu lieu quand vous lirez ces lignes. Mais place à l’action.

Et l’action pour commencer, c’est avec Pascal Poussard et les essentiels de Kanban !

Initiation au Kanban avec Pascal Poussard

C’est toujours un plaisir pour moi d’entendre Pascal. Cette fois encore, il nous gratifie d’une session d’initation au Kanban clair et énergique, se concentrant sur les aspect importants de l’approche. On pourra juste lui reprocher de faire des infidélités au Scrum User Group (dont il est l’un des membres éminents du bureau) pour faire une pige au FKUG !

image

4 objectifs et 2 notions clé

La Kanban, c’est surtout 4 objectifs :

  • La qualité
  • Equilibrer le rapport demande / débit
  • Livrer souvent
  • Réduire la variabilité

Deux notions clé font de Kanban une approche radicalement différente.

  • La chaine de valeur : Ici, elle part de l’aval. C’est la demande qui contrôle la mise à disposition, d’où la fameuse notion de « flux tiré ».
  • Le temps de cycle : On ne parle plus de vélocité ou de capacité. Kanban se focalise sur le délai entre la demande et la mise à disposition au-delà de toute chose. Si cette notion n’est pas importante pour vous, sans doute n’êtes-vous pas un bon candidat au Kanban. Mais réfléchissez bien…

6 principes

Visualiser la chaine de valeur. C’est la première pierre du Kanban. Car visualiser cette chaine de valeur, c’est rendre compte de manière claire de ce qui se passe, créer une adhésion autour de celle-ci et permettre de « casser les silos ».

Limiter le travail encours (WIP limit). Ce principe est à la fois le moteur du flux tiré et de la réduction du temps de cycle.

Gérer le flux. Dans un système, le flux est limité par son goulot d’étranglement (théorie des contraintes). Cette dernière nous dit aussi qu’il y a nécessairement un goulot d’étranglement dans le système, qu’il faut décider (et non subir) où celle-ci se positionne et subordonner le système à cette contrainte.

Rendre les processus explicites. Comme les approches agiles, Kanaban est une école de rigueur : les règles de passages sont clairement définies, ainsi que les procédures exceptionnelles.

Amélioration continue. L’observation et la mesure de ce qui se passe nous permettent de déterminer ce qui peut faire l’objet d’amélioration.

Feedback : Celui-ci vient des mesures et de la voix du client.

Pour quel contexte ?

  • Si notre flux de travail n’est pas équilibré.
  • Si notre chaine de travail est surchargée.

Comment commencer ? Avec ce que l’on a, simplement en rendant notre processus explicite. Puis en enclenchant des cycles d’amélioration.

Retrouvez ici la prestation de Pascal.

Ainsi que le support de sa présentation.

Le management visuel et l’Obeya, par Christophe Keromen

Au commencement

On commence fort avec Christophe en se posant la question suivante : pourquoi faire un management visuel ? Pour nous pousser à l’action ! Si celui-ci n’atteint pas ce but, il faut le jeter !

Pourquoi doit-il être visuel ? La Programmation Neuro-Linguistique nous dit que des 5 sens, le VAKOG de la PNL, c’est le sens visuel qui est dominant, car notre cerveau est efficace pour reconnaitre les motifs.

La question suivante sera donc : qu’en fait-on ? On va s’en servir pour rendre visible les problèmes, et rendre aussi visible le lien entre le problème (que l’on refuse souvent de voir) et l’action.

image

Commençons avec un tableau Scrum…

Celui-ci nous permet de rendre visible la progression. Mais rend-t-il visible le challenge ? Permet-il de voir les « impediments », les boulets qui nous freinent ?

Christophe nous résume ainsi ce que le management visuel rend possible :

  • Voir ensemble
  • Agir ensemble
  • Apprendre ensemble

Pour permettre cela, il faut non seulement faire attention à l’information que l’on montre (et qui conditionnera tout le reste), mais faire en sorte que l’information représentée sur ce tableau soit :

  • Univoque
  • Visible
  • Interactive

Un tableau soigné

Cela commence en soignant ce tableau au niveau du contenu. Ce sont les « 3 U » :

  • Utile (ce qui n’est pas utile constitue une pollution)
  • Utilisable
  • Utilisé (quelle est la dernière chose que vous avez apprise avec le tableau ?)

Cela signifie aussi un tableau soigné du point de vue esthétique. Eh oui je confirme : personne ne va aller voir un tableau moche !

Du manangement visuel à l’Obeya

Que doit montrer d’autre notre management visuel ?

  • Les objectifs (le challenge)
  • Les règles
  • La vision

C’est de tout cela dont on parle quand on évoque l’Obeya. Mais l’Obeya, c’est aussi un espace, l’Obeya Room, à l’agencement très spécifique. Le but ? Se mettre en position de faire du Kaizen !

Retrouvez ici la présentation de Christophe Keromen en vidéo.

Ainsi que les slides de sa présentation.

La résolution de problèmes avec le A3, par Laurene Vol

Le A3, c’était probablement la présentation que j’attendais avec le plus d’impatience. Mais ce fut aussi probablement la présentation la plus faible, hélas. Non pas qu’elle fut mauvaise, mais elle est restée très « by the book ».

Un A3 pour traiter des problèmes

Et ces problèmes, comment sont-ils identifiés ?

  • De manière spontanée, durant l’itération, quand on tombe dessus !
  • En rétrospective
  • Via des indicateurs

Ces problèmes, Laurene nous propose de les collecter au sein d’un tableau, plus précisément dans une matrice de Merill-Covey. Vous connaissez déjà certainement.

image

A partir de là, des règles nous permettront de déterminer la manière dont nous traiterons ces problèmes. Pour certains d’entre-eux, ce sera le A3 !

Du contexte à l’analyse

Le A3 débute avec une partie « contexte ». Elle répond à la question : Pourquoi en est-on là ?

Vient ensuite le « current state » : un état initial quantifié et si possible illustré avec un schéma. Si des contournements sont déjà mis en oeuvre, ils sont exposés.

image

L’objectif, c’est l’état final désiré. Il est lui-même quantifié.

La partie délicate, c’est bien l’analyse. On privilégie l’analyse causale à l’aide de différentes techniques : les 5 pourquoi, les diagrammes de cause-effets ou les diagrammes en arêtes de poissons.

Vous avez trouvé mon compte-rendu trop succinct ? Regardez la vidéo de l’intervention de Laurene.

Son support de présentation est également disponible.

Kaizen & PDCA avec Julien Karoubi

Je dois avouer que Julien affronte des challenges que je n’oserai pas, même dans mes jours les plus téméraires.

Ainsi, pour illustrer le principe de l’amélioration continue, Julien a proposé un jeu !

image

Ce jeu, Julien l’a imaginé spécialement pour cette soirée. Il s’agit d’effectuer des itérations et de consacrer un peu de temps pour trouver des améliorations de fonctionnement, à l’image du Ball Point. Ici, Julien s’évertue également de perturber le système en intervenant au milieu des itérations, histoire de casser de rythme et voir comment l’équipe réagit !

image

Résultat moyennement concluant. On arrive à la même productivité avec ou sans temps consacré à l’amélioration. Mais on doit pendre en compte que du temps de travail est alors consacré aux rétrospectives. Il faut dire que les tranches de temps sont réellement très courtes, surtout pour les rétrospectives. Voyons en video ce que cela donne.

Il était aussi audacieux de la part de Julien de faire ce jeu dans une configuration de soirée « plénière » : Il y avait 80 personnes dans le showroom Zenika, probablement moins de 10 pouvaient voir et suivre réellement ce qui se passait.

Quoi qu’il en soit, cette cassure était bienvenue dans ce marathon de présentations !

Key Performance Indicators pour Kanban, par Yannick Quennec’hdu

Yannick est très, très affuté (et expérimenté) sur les mises en place de Kanban et les mesures associées dans des contextes multi-équipes. On pouvait s’attendre à une présentation de haute qualité, nous l’avons eu !

Parlons pré-requis

Toutes nos présentations s’articulent bien ensemble, car pour Yannick, un pré-requis important est … la mise en place d’un management visuel ! Bon, il n’y a pas que cela. Il faut aussi que notre Kanban soit « stabilisé » également. Nous ne devons pas non plus perdre de vue notre objectif : rendre factuel notre Kanban !

image

Les indicateurs

Ils sont classiques, mais ça ne fait pas de mal de les reprendre :

Le Lead Time : combien de temps entre une « commande » et un client servi.

Le temps de cycle : Le temps séparant deux évènements identiques. C’est donc l’inverse de la fréquence et vice-versa.

Le débit : Le nombre d’items livrés dans un laps de temps donné. Là on ne parle plus d’étape du processus, mais de ce qui sort du Kanban !

Le travail en cours : combien d’éléments sont en élaboration aux différentes étapes du processus !

Le diagramme de flux cumulé est l’outil de prédilection permettant de mesurer et voir évaluer la plupart de ces indicateurs. Ca, c’étaient les bases. Et maintenant, voici…

Le grand Mix

Ces indicateurs se combinent pour voir les corrélations entre ces indicateurs.

La loi de Little : Elle indique que le temps pour terminer est inversement proportionnel à l’en cours. Donc réduire l’en-cours augmente le débit !

La prédictibilité : Un indicateur compliqué, basé sur le débit et la taille des tickets.

L’efficience : Pour mesurer dans notre processus, le temps qui ajoute de la valeur au produit. En pratique, on isole les zones tampon et l’on mesure le temps que le ticket y passe.

La qualité : C’est le coût de la non-qualité qui est mesurée, via des « tâches rework », par exemple. Yannick utilise cela pour mesurer la valeur économique de l’accroissement d’une équipe de tests !

Variabilité : Ces variabilités peuvent être locales ou globales.
Je vous recommande la vidéo de l’intervention très riche de Yannick

Et aussi, bien sûr, le support de sa présentation.

Mesure de la maturité par Nicolas Lochet

La soirée n’est pas encore tout à fait finie ! Nicolas nous expose à la vitesse de la lumière une grille d’audit de maturité Kanban, basée sur les éléments du livre de Laurent Morrisseau.

image

Il n’y a pas de support de présentation, car Nicolas nous présentait directement sa feuille Excel (que je n’ai pas non plus). Hélas, nous n’avons pas également de captation vidéo de cette intervention.

Enfin, un petit « preview » ne fera de mal à personne : voilà !

image

On a soif !

Il est plus que temps d’aller au ravitaillement. Vider le frigo rempli de bières et les petits fours et autres provisions de bouche laissées à disposition, telle était notre dernière tâche !

image

Ce que j’en ai pensé

Ce Meetup était vraiment très riche. La mission était d’initier le plus grand nombre aux éléments de base de Kanban. Les diverses présentations ont réellement rempli ce rôle. En fait l’agenda était même trop ambitieux. Nous aurions eu de la matière pour deux soirées ici.

Second point, bien que mineur : je n’ai pas compris la nécessité de rendre cette soirée payante. D’autant qu’étant hébergée chez Zenika, tous les coûts étaient assurés par l’hôte ! Cela n’a pas freiné les ardeurs (et la contribution demandée était minime) et cela a certinement alimentée la caisse de l’association.

Le FKUG montre une fois de plus son dynamisme, non seulement à organiser une soirée par mois, mais à varier les formules de ces soirées. Un rythme et une variété que j’avais escomptée pour le Scrum User Group il n’y a pas si longtemps que cela, et qui reste à retrouver.

L’association organisait aussi en décembre une soirée jeux, je n’ai malheureusement pas pu y participer. J’attends avec impatience l’année prochaine !

Waiting for the Storm…

Le Storm User Group, c’est une initiative de quelques collègues autour du « big data temps réel ». Aujourd’hui, nous parlons de Storm et quelques infrastructures qui peuvent s’y connecter. Demain, il s’agira peut-être de Spark ou d’autres…

Halte là ! Je vais peut-être un peu vite ? Et d’abord, Storm, qu’est-ce que c’est ? Voilà une question à laquelle une partie de cette première rencontre va être consacrée.

Oui, Storm, qu’est-ce que c’est ?

C’est Florian Hussonois qui va répondre à cette question. Nous pourrions résumer la chose en déclarant simplement qu’il s’agit d’un Hadoop « temps réel ». Il s’agit en quelque sorte d’un middleware permettant le traitement d’évènements en mode flux.

Un (petit) peu d’historique

Storm a été développé par Nathan Marz chez BackType en 2011. La société est rachetée ensuite par Twitter qui promeut le projet et le passe en Open-Source. La première release officielle date de 2011. En Septembre 2014, le projet devient officiellement « Apache Top Level Project » alors même qu’il n’a pas encore atteint la release 1.0 !

Ecrit principalement en Clojure et en Java, ce « processeur d’évènements » est conçu pour traiter un flux de très nombreux évènements (des tuples dans la terminologie Storm), à savoir 1 millions de tuples par seconde et par noeud (1 seul coeur processeur), avec tolérance aux fautes, gestion de la scalabilité et garantie de traitement !

image

Les concepts clés

Pour bien comprendre Storm, il faut en saisir les concepts de base.

  • Le Tuple : Nous en avons parlé, il s’agit de l’unité d’information à traiter. C’est l’évènement.
  • Le Stream : c’est une séquence illimitée de tuples.
  • Le Spout : C’est un connecteur producteur de tuples. En pratiques, ce sont des composants source de données. Il en existe de nombreux types (dans le projet officiel et en dehors) pour se connecter à différentes infrastructures.
  • Le Bolt : Il s’agit du composant de traitement élémentaire. Il consomme bien entendu des tupples et peut en produire (mais pas obligatoirement). Il peut aussi se connecter à une base de données, par exemple.
  • La Topologie : il s’agit de la structure de déploiement de votre configuration Storm. Dans la pratique, il s’agit d’un graphe acyclique (DAG).
  • Groupements de streams : Si les bolts peuvent « splitter » des streams (façon CBR) ou les multicaster, ils peuvent aussi les regrouper. Il existe 7 types de regroupements.

Le parallélisme est intrinsèque à Storm. Chaque Bolt peut être instancié plusieurs fois (on les appellent « task »). Chaque tâche est prise en charge par un Executor qui correspond dans la pratique à un thread. Storm prend en charge la répartition des Executors sur des Workers (qui correspondent à une JVM). Chaque Worker devant être géré par un Supervisor. Ce dernier point est important, car les Workers peuvent tomber ! Un petit dessin vaut parfois mieux qu’un long discours…

image

Pour gérer et faire tourner l’ensemble, Storm met à notre disposition 3 briques importantes :

  • Le Supervisor : nous en avons parlé, il gère un Worker, le relançant si nécessaire, et permet de surveiller sa charge.
  • Zookeeper, qui a en charge de gérer une topologie
  • Nimbus, qui gère les masters des topologies. Il doit lui-même tourner sous supervision.

Traiter en toute quiétude

Les graphes de traitement de Storm peuvent devenir des arbres très complexes ! Toutefois Storm s’y entend pour reconnaitre si un Tuple entrant a été traité sur la totalité de son arbre. Tout d’abord chaque Tuple a son id (sur 64 bits). Nathan Marz a développé un algorithme très complexe, basé sur le XOR pour identifier si un arbre a été complètement traité. Bien entendu, chaque Bolt opère son acquittement local, c’est le « Ack ».

image

Florian passe rapidement sur Trident qui permet d’assurer une sémantique « exactement 1 » aux traitements. J’avoue que le sujet est passé trop rapidement pour moi. Peut-être une occasion de creuser le sujet ultérieurement ? Il en va de même pour la fonctionnalité DRPC.

Si vous avez raté le live et que ma prose vous laisse de marbre, voici l’enregistrement de l’intervention de Florian lui-même !

Storm et Redis chez Twitter Foot

Ce retour nous était proposé par Benjamin Houdu. Cette présentation m’intéressait d’autant plus que j’ai participé au début de ce projet. Et je dois dire que ce dont Benjamin nous a gratifié est probablement le meilleur retour d’expérience auquel j’ai pu assister !

Le projet

Comme son nom l’indique, Twitter Foot traite des flux Twitter, suivant des comptes identifiés par l’AFP (7000 comptes sur 5 ligues), pour fabriquer des timelines spécialisées et toute sortes de statistiques, comme des tendances, la détection de viralité ou de popularité.

Techniquement, les particularités de cette mise en oeuvre de Storm repose d’une part sur la connexion Twitter via la streaming API en utilisant le connecteur Hosebird, et d’autre part sur la mise en oeuvre conjointe de Redis, un base NoSQL de type clé-valeur fonctionnant en mémoire. Redis est d’ailleurs très exploité ici, car on en fait un triple usage :

  • Pour bufferiser le flux Twitter et alimenter le stream Storm. Incidemment, cela rend l’architecture plus testable, car les tests peuvent être faits simplement en peuplant Redis, sans connexion à Twitter, avec en prime la maitrise sur les données injectées !
  • Pour sauvegarder les données de référence : aussi bien la topologie que l’on va injecter dans Zookeeper que les comptes sur lesquels on a des abonnements.
  • En frontal, pour exposer les timelines résultantes et les données statistiques !

En pratique, la topologie est constituée de 3 machines abritant chacun un worker, auxquelles il faut rajouter le serveur frontal abritant le serveur Rest qui expose les services ainsi construits.

image

Et bien sûr, il y a le serveur hébergeant Redis !

Justement Redis, qu’est-ce que c’est ?

Nous l’avons dit, il s’agit d’une base NoSQL de type clé-valeur fonctionnant en mémoire. On devinera que ces choix l’orientent vers la performance, ce qui explique les autres choix techniques : elle est écrite en C et est … monothreadée ! Ce dernier choix peut paraitre curieux, mais de fait, il évite de devoir gérer les problèmes de contention. Il se justifie aussi par les excellentes performances de la base dont les requêtes sont non seulement traitées rapidement, mais aussi peu sensibles à l’augmentation de volume : la plupart des fonctions proposées ont des indices de performance en O (Log (n)) !

Parmi les fonctionnalités intéressantes de cette base, on pourra noter dans le désordre :

  • La présence d’une API de type « publish / subscribe » bien pratique entre autre pour le débug !
  • La présence de connecteurs pour un grand nombre de langages.
  • La mise à disposition de structures intelligentes : sorted sets, Z sets, etc. qui permettent non seulement de retrouver un élément, mais de sélectionner un « range » d’éléments. Une fonctionnalité qui s’avérera particulièrement précieuse dans le cas d’utilisation de Twitter Foot !
  • La présence d’un langage de script basé sur Lua qui permet d’écrire l’équivalent de procédures stockées dont l’atomicité d’opération est garantie par l’architecture monothreadée de la base !
  • L’accès en mode interactif en ligne de commande, via redis-cli pour travailler sur la base en mode non programmatique.

Storm, au coeur de Twitter Foot !

Nous n’allons pas revenir sur le descriptif général de Storm que Florian a fort bien abordé. Benjamin attire toutefois notre attention sur les changements importants survenus entre les versions 0.8.x et 0.9.x, la première dépendait fortement de Zero MQ, ce qui n’est plus le cas des versions ultérieures. Il met aussi l’accent sur l’intérêt de Storm UI d’un point de vue opérationnel, surtout pour savoir quel tâche tourne sur quel worker ! En effet, il faudra abandonner l’idée que l’on traite l’affinité des tâches sur les workers / machines, c’est Storm qui gère cela.

En fait, l’un des enseignements que tire Twitter Foot, c’est que l’administration est un volet du projet aussi important que le développement, et il faut y faire face le plus tôt possible dans le projet ! Autre difficulté, la configuration dont les changements imposent des redémarrages de topologies. C’était une contrainte trop forte pour Twitter Foot, aussi l’équipe a-t-elle traité la configuration comme un Stream traversant les Bolts !

Des fenêtres bien glissantes…

Un concept est rapidement apparu sur Twitter Foot : la nécessité de faire des statistiques sur une durée fixe, mais relative au temps présent. Ce que l’on a appelé des « fenêtres glissantes », c’est à dire entre T0 et T-n minutes (ou heures, ou jours), avec un échantillonnage représentant la résolution de ces statistiques en x minutes ! Vous pouvez aussi dire « sliding windows » pour briller dans les salons, mais ne cherchez pas sur Google, c’est un concept maison !

image

Plusieurs essais d’implémentations en ont été faites. Benjamin nous parle de deux d’entre-elles.

Tout d’abord, on peut s’appuyer sur un concept Storm : les Rolling Buffers. Ils sont plutôt complexes à mettre en oeuvre, mais ils présentent entre autre l’avantage de gérer automatiquement l’éviction des échantillons quittant la fenêtre glissante !

Autre possibilité : s’appuyer sur les ZSets de Redis. Redis permet même d’opérer des aggrégations par x minutes et donc de gérer pratiquement automatiquement l’échantillonnage ! Par contre l’éviction des vieux échantillons doit se faire programmatiquement.

Quelques mots sur la testabilité

J’ai été agréablement surpris de voir Benjamin aborder ce point finalement assez déconnecté des problématiques purement techniques de Storm (bien qu’il y ait bien sûr des corolaires techniques). Le projet a en effet mis en oeuvre tôt dans ses premières phases une approche ATDD impliquant le client et s’appuyant sur le paradigme « Given When Then » outillé avec Cucumber JVM. Cette approche a réellement permit une convergence et appréhension fine des fonctionnements attendus.

D’un point de vue technique, il a été possible de se servir de l’alimentation par Redis pour effectuer ces tests déconnecté de Twitter en injectant dans Redis des Tweets « forgés ». Autre point délicat, la nécessité de ne pas redémarrer la topologie entre chaque tests afin de garder des temps d’exécution raisonnables.

Et le monitoring ?

Nous l’avons dit, avec Storm on fait beaucoup d’administration, ce qui a quelques implications.

D’abord, plus encore qu’ailleurs, les opérations réalisées fréquemment doivent être en « push button ». Jenkins est d’une aide appréciable à ce niveau.

Le Storm Supervisor : il est indispensable, et il en faut un par machine.

L’équipe a aussi utilisé avec bénéfice Monit, un watchdog qui s’est avéré d’une grande utilité. Notre orateur est dithyrambique à ce sujet !

Du côté de Redis, c’est redis-rdb-tools qui s’est avéré indispensable. Le gros avantage est le parse des logs offline, donc sans impacter la machine de production. Dans la pratique, beaucoup d’investigations peuvent être menées à bien en différé.

Si on a réellement besoin de connaitre l’état de santé de l’instance en live, il y a … Redis Live !

Quelques mots sur le débug et les best practices

L’investigation de problèmes sur une architecture Storm peut très facilement se transformer en chemin de croix ! Il faut anticiper cela au niveau de la conception et penser les Bolts avec des responsabilités bien séparées (principe SRP de Bob Martin). En fait, Benjamin nous suggère de séparer les Bolts de contrôle des Bolts d’action !

Même chose sur Redis : bien séparer les actions d’insertion des actions de nettoyage.

Enfin, même les topologies peuvent être décomposées, une leçon qui est arrivée hélas bien tardivement sur Twitter Foot ! De plus petites topologies se testent plus facilement et sont plus robustes. Mais attention, ne pensez pas mutualiser les workers : un worker ne peut appartenir qu’à une topologie.

Autre problème bien connu, celui de l’auditabilité : comment retrouver l’origine du problème ? L’équipe Twitter Foot nous propose la technique du « Carbon dating » : injecter dans les Tuples des informations de trace des Bolts traversés !

Du côté Redis enfin, si l’aspect « sans schéma » est apparemment une liberté bienvenue, on touche vite les limites de ce manque de typage. Ici, c’est l’emploi de json-schema que vient nous recommander l’équipe.

Si vous préféreez la présentation de benjamin in extenso, ne pleurez plus, la voici !

Ce que j’en ai pensé

Je l’ai dit au début : l’orateur nous a gratifié là d’un retour d’expérience d’un niveau de qualité que j’ai rarement (jamais ?) vu !

La mise en oeuvre d’un projet avec Storm est réellement quelque chose de complexe. On perçoit cette impression rapidement, mais les dimensions de cette complexité apparaissent clairement dans cette présentation !

Mais on va plus loin ici : les voies à explorer, les points d’attention dans le projet, les outils indispensables et leur utilité, tout nous est clairement exposé. Un grand bravo !

Quand Tom Baeyens inaugure le BPM Professional Group

Quand on pense BPM et Open-Source, on pense toute de suite à jBPM ou Activiti ! Derrière ces 2 projets, un même homme : Tom Baeyens ! On ne pouvait rêver mieux pour inaugurer le BPM Professional Group au zLocalHost de Zenika ! Ce ne sera pas le seul intervenant de cette soirée, car Fayçal Mehrez viendra nous parler d’indicateurs de performance en entreprise et de l’usage de BPM dans ce cadre !

A la découverte d’Effektif, avec Tom Baeyens !

Effektif, c’est la nouvelle structure de Tom Baeyens, qui s’éloigne maintenant d’Activiti et Alfresco pour une nouvelle aventure. Mais ce n’est pas pour faire la promotion de son outil qu’il sera là ce soir, mais bien pour nous parler de BPM.

image

Pourquoi BPM ?

C’est une question essentielle, car il serait irréaliste de penser que BPM est une évidence pour les entreprises. Il s’en faut de beaucoup. Nous ne sommes que 40 ce soir, et non des centaines !

Le BPM, c’est avant tout voir les processus de l’entreprise comme des activités répétables. Un outil BPM modélise non pas des processus, mais des templates de processus ! les processus eux-mêmes en sont les instances.

Par rapport à ces processus, et oserais-je dire par rapport à la « normalisation de ces processus », BPM permet une agilification avec une réelle facilité d’amélioration et de déploiement de ces nouvelles versions de processus. Nous aurons l’occasion de revenir sur cette conjonction entre agilité et BPM qui est en fait bien plus complexe, lors d’une prochaine rencontre. Pour Tom Baeyens, cela s’articule en 4 éléments principaux.

1 – L’organisation des tâches

Un modèle BPM permet non seulement de définir, mais surtout d’implémenter « qui fait quoi », et d’éviter ainsi les incompréhensions entre acteurs.

2 – Le bon niveau de contrôle

Un moteur BPM permet de garantir le respect des règles telles qu’elles sont définies et appliquées. Hum ! Voici une déclaration qui a bien plus des relents de Taylorisme que d’agilité ! Toutefois, le BPM permet aussi de laisser libre le fonctionnement au niveau ui est décidé ! D’ailleurs l’un des apports les plus intéressants d’Effektif est l’intégration d’une notion de « case management » au sein de l’outil !

3 – Transparence sur ce qui se passe

Un moteur BPM permet de centraliser les informations sur l’activité, permettant de savoir qui fait quoi, mais aussi de remonter aux causes racine d’un problème en s’appuyant sur un audit trail.

4 – Coordination de grand volumes de processus

Un moteur BPM permet de monitorer ce qui se passe sur plusieurs milliers (millions ?) d’instance de processus simultanément, et d’assurer la consistence de leur traitement. Comme le dit Tom, cela permet aussi de surveiller les « employés distraits ». Quand je vous parlais de Taylorisme…

image

Qu’est-ce qui a changé ?

Le BPM n’est pas un nouveau-né ! C’était déjà un sujet d’actualité au début ou au milieu des années 90 quand la modélisation était l’une de mes activités principales ! Mais le paysage a incontestablement changé ces dernières années. Tom Baeyens concentre son propos sur 3 points

1 – Le cloud dans l’entreprise

L’utilisation des services est aujourd’hui une évidence, que les DSI le veulent ou non. Et dans ce cas, elles se font tout simplement contourner ! Toutefois les reservoirs d’information n’ont pas disparu des entreprises, et il faut savoir fonctionner en environnements hybride !

2 – Focus sur l’expérience utilisateur

Les applications d’entreprise sont traditionnellement mauvaises sur cet aspect. Et au sein des applications d’entreprises, les applications BPM seraient plutôt les pires ! Pourtant, être incapable de proposer une expérience utilisateur de qualité dans ce domaine n’est pas une fatalité : IFTT fait un excellent travail à cet égard, avec ses « recettes » !

Autre problème dans ce domaine : la surcharge d’emails ! Hélas, s’en passer semble illusoire, car l’email reste le plus petit dénominateur commun ! Mais les outils de case management tels que Yammer, Jive, Huddle ou Asana permettent d’entretenir des « discussions riches » auxquelles on peut ajouter du contexte et garder tout le monde dans le même échange !

3 – Le point de souffrance du BPM

Le BPM est une problématique métier. Hélas, il ne faut pas longtemps pour que cela devienne un projet IT ! Et avec cette transition arrive les questions de management « lourd », les temps de cycle long… Il est nécessaire de séparer la partie « expérience utilisateur » de la partie « projet IT ». Car ne rêvons pas : la customisation nécessitant de faire des développements restera vrai !

Voici Effektif

Effektif permet de laisser entre les mains des utilisateur métier la modélisation des processus, tant que celle-ci reste simple. Et l’on s’inspire ici de ce que fait IFTTT ! Puis l’outil dispose d’API pour permettre d’y adjoindre des traitements « custom »!

Il est temps de passer à la démo. Plutôt que de la décrire, je vous propose cette vidéo, hélas d’assez mauvaise qualité : je n’étais pas très bien placé et tenir un appareil photo à bout de bras pour filmer pendant 20 minutes … eh bien il y a mieux ! Désolé donc pour l’effet « mal de mer » si vous avez le courage de la regarder !

Techniquement, Effektif s’appuie sur des choses assez simples : Tomcat et MongoDB ! Et encore, seul le moteur de servlet de Tomcat est réellement utilisé. Pour Tom Baeyens, le début de l’aventure commence bien, avec le reconnaissance de la validité de son modèle par le Gartner ou Tech Crunch. Et bien d’autres choses dans la roadmap…

Vous avez raté la performance de Tom et ma prose vous laisse de marbre ? Voici la vidéo !

BPM dans un contexte industriel, par Fayçal Mehrez

C’est d’analyse de la performance d’entreprise avec le PLM dont Fayçal va parler. Pas évident d’évoquer ce sujet qui n’est pas réellement attendu par le public !

Quand on parle PLM, on pense souvent « outil de PLM ». Mais le PLM c’est avant tout un processus, un concept structurant de gestion de produit pour dire à une société comment elle doit fonctionner. Décidément, je suis verni ce soir : après le Taylorisme, voici venir l’ERP dans son habit de lumière !

Trêve de plaisanterie : ce dernier point fait la jonction avec l’univers du BPM, car la démarche PLM passe par la mesure de la performance, une chose que permet justement les moteurs de BPM !

Il y a 3 axes à cette démarche :

  • Une méthodologie de performances
  • Une démarche de transformation
  • Une approche BPM
image

Parlons de performances

Attention, quand on parle « performances », on pense souvent à la performance financière uniquement. C’est une erreur. Par exemple, dans un processus RH, la performance ne concerne pas le coût du processus d’embauche, un aspect qui est en fait souvent marginal, mais bien l’adéquation par rapport aux besoins futurs de l’entreprise, la réduction du turn-over, etc.

Par ailleurs, la performance ne se décrète pas, mais se construit.

Mais aussi, dans un cadre PLM, on peut avoir un objectif stratégique de réduction du « time to market ». Cet objectif se décline en objectifs opérationnels, comme par exemple réduire le délai de développement.

Pour ce faire, on développera plusieurs axes :

  • Améliorer la conception
  • Réduire les volumes de développement
  • Multiplier les ressources

Quels outils pour mettre en oeuvre cela ?

C’est également une démarche de transformation

Il n’y a pas d’outil unique dans cette démarche. L’un des classiques est le Balanced Scorecard. Fayçal préfère la « feuille de route stratégique ». On parle bien de feuille de route, et non de carte ! Si j’ai bien compris, elle aide à partir des objectifs stratégiques à décliner les objectifs opérationnels à l’aide d’une approche type « 5 pourquoi ». Mais en vérité, je ne pense pas avoir tout suivi correctement.

L’autre volet de cette transformation, ce sont les hommes ! 80% de la performance vient de l’humain. Aussi est-il important de donner du sens à ces changements. Enfin un point commun avec l’agile ! Et n’oublions pas que la première étape d’une transformation est une baisse de performance !

L’apport du BPM

Le BPM permet de donner de la cohérence aux processus. La finalité du PLM est intrusive : obtenir des processus répétitifs et contrôlables. De nombreux aspects de l’intérêt du BPM dans une démarche PLM me rappellent les finalités de l’urbanisation des systèmes d’information (décidément, je boirais la coupe jusqu’à la lie) : partir de standard de processus, permettre l’alignement sur les processus (alignement d’un peu tout).

Petites reflexions personnelles

Ne nous voilons pas la face : nous étions venus pour Tom Baeyens ! Il ne nous a pas déçu, autant par la clarté de sa perception du BPM que par sa démonstration d’Effektif !

Le thème abordé en seconde partie est assez éloigné de mes préoccupations. Mais il met en relief certains éléments que je percevais quelque peu : le monde du BPM reste fondamentalement assez éloigné de celui de l’agilité. Un avis à tempérer toutefois avec la flexibilité qu’il permet d’une part, et l’ajout de dimensions « non prédictives » d’autre part !

Bref, cette session m’aura aussi alimenté en reflexions sur le BPM et l’agilité, bien plus que je ne l’espérais. Et cela nous donnera du grain à moudre pour une future rencontre « BPM Pro » !

La rentrée en open space !

Il n’aura pas fallu attendre longtemps pour voir notre premier rendez-vous agile de la rentrée. C’est d’ailleurs un agenda assez rythmé qui nous attend dans les semaines qui viennent !

Mais en ce 4 Septembre, c’est un open-space auquel Yannick nous a convié dans les locaux de Zenika. Beaucoup d’inscrits, peu de venus (environ une quinzaine), mais comme on dit dans les open spaces : les personnes qui sont là sont les bonnes personnes. Petit avantage : l’achalandage de notre place de marché va plutôt vite. C’est bien car ce sont 3 créneaux qui sont prévus pour ce soir !

image

1er round : où il est question de (non) estimations…

3 sujets sont proposés dans chaque tranche de temps, avec 45 minutes consacrées à chacune q’entre-elle ! Voilà, c’est parti.

image

Chaque groupe prend possession de son espace. J’avoue apprécier d’avantage les petits groupes de 5 comme c’est le cas ici.

Il faut faire des choix, parfois difficiles. Ce groupe a choisi d’aborder la définition de « done », un sujet pour lequel j’éprouve un certain intérêt … 

image

Je me décide finalement à rejoindre le groupe de Dov pour débattre du « no estimates ». Je me suis dit que cela faisait une bonne suite à ma rubrique de l’été : en finir avec les estimations !

image

J’ai été rapidement déçu par la direction qu’a prise la discussion, ou plutôt l’exposé que nous a fait Dov de son contexte. Outre que je suis plus intéressé par la discussion que par écouter une seule personne discourir, il ne nous parlait pas de « no estimates », mais plutôt de « diluate estimate » !

Supprimer les estimations « parce qu’elles font durer le planning meeting trop longtemps » sans changer la logique de travail entre le PO et l’équipe, c’est un peu mettre un sparadra sur un bobo. Certes, cela fait diminuer la pression … mais ce n’est pas du « no estimates ». Où plutôt cela l’est au sens littéral, comme quoi le terme n’est pas bon, du moins à mon avis.

Un avis apparemment partagé par Arturo ! Du coup, nous réorientons la discussion sur le changement de focus : la valeur et la définition de succès, du projet ou du rôle du product owner. Dans le cas du projet de Dov, on parle d’implémenter ce qui est dans le backlog : tant que l’on en est là, il n’y a pas de changement de logique et cesser d’estimer est futile, peut-être même malhonnête par rapport au client ?

J’aurais aimé avoir plus de temps pour creuser la question du changement de logique avec Arturo, mais le gong nous a rattrapé. Nous avons à mon goût passé bien trop de temps dans une direction qui ne m’intéressait pas. Oui, je sais j’aurais dû appliquer la loi des deux pieds. Mais le sujet m’intéressait et je préférais le rediriger dans une voie qui me convenait plus.

2nd round : Trop d’agile tue l’agile ?

Pour faire 3 round, Yannick nous a proposé un timing assez rythmé, pour ne pas dire serré. Ca ne laisse pas beaucoup de temps au partage ni au « slack », c’est un peu dommage.

image

Pour ce second round, je me suis joins à Renaud. Je ne suis pas fan de la manière dont il a exprimé le sujet. Peut-être même pas fan du sujet, d’ailleurs. Mais je me dis qu’au pire, il se prête assez bien au hacking !

Renaud s’étonne d’un certain nombre de sujets abordés dans le cadre de Scrum qui sont justement incompatibles avec Scrum. Sans aucun doute, il a raison. Renaud profite de l’occasion pour nous parler de Shu Ha Ri, cela vous rappelle-t-il quelque chose ?

Je ne vois pas trop où le « trop d’agile » intervient dans cette discussion, car on en arrive à évoquer le « Scrum by the book », ce qui est un peu normal quand on parle de Shu, mais pour le seconde fois de la soirée, je m’aperçois que ce n’est pas une direction de la discussion qui m’intéresse !

image

Le « trop d’agile », c’est pour moi trop se focaliser sur le fait de faire effectivement de l’agile au travers de telle ou telle pratique. Et s’intéresser à l’orthodoxie des pratiques (comme nous le faisons là), c’est se focaliser sur les choses qui sont au final inintéressantes. L’agilité est un moyen, c’est aujourd’hui devenu une fin ! On est d’ailleurs en train de parler « d’audit agile » dans cet ordre d’idée, une perspective que je trouve déplaisante.

Merci une fois encore à Arturo pour m’avoir épaulé pour chercher à explorer cette voie. Une fois encore je me trouve un peu frustré par le gong qui raisonne…

3ème round : Convaincre sur l’agile

Rapide partage avant le dernier round. Trop rapide encore. Hélas encore !

image

Nous commençons à nous dépeupler. Ce dernier round ne comptera que 2 sujets, le 3ème passera à la trappe : c’était le mien ! Mais il semble n’intéresser que peu de monde. Peut-être même personne.

Un débat plus intéressant cette fois autour d’un cas réel : quelle prise pour convaincre un management par ailleurs dans l’échec !

image

On a beaucoup parlé de construire un argumentaire, enquêter, chercher des éléments… Tout cela ne vas pas me convaincre. Plutôt que d’argumenter avec de grands mouvements de manche, pourquoi ne pas faire ? Quelle expérimentation mener pour prouver ? Quel investissement semble assez raisonnable pour essayer quelque chose ? Après tout si la situation actuelle ne marche pas …

image

Conclusions

Ce n’était pas la grande forme pour moi, ce jour-là. Mais je souligne 4 éléments à l’issu de cette soirée.

Un petit groupe pour l’open space et des petits groupes de 5 pour discuter, c’est plus convivial et plus interactif !

Le timing était un peu serré du fait de la contrainte que l’on se donnait sur les 3 tranches de temps. C’est dommage ! Je pense que j’aurais préféré deux créneaux de qualité avec un peu de mou et un temps de partage prolongé.

Un peu frustré par la direction prises par les deux premiers sujets. C’est nécessairement un point de vue personnel, je ne peux escompter que tout le monde partage la direction que j’aimerais faire prendre à la discussion.

Enfin, mon sujet n’a finalement pas été abordé. En soi, cela n’a aucune importance. Mais il s’agissait du seul sujet traitant de conception, de craftmanship. Lors des rendez-vous agiles, j’entends toujours des participants parler du TDD « il n’y a que ça de vrai » … mais traiter vraiment du coeur du sujet, en l’occurrence de la conception émergente, cela finalement n’intéresse personne. Est-ce la différence entre l’intention et la réalité ?

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 : Le ScrumDay 2014 (4/4), Bonus track !

Après avoir couvert mon parcours de ces 2 jours de ScrumDays (ici, ici et ici), une question reste en suspens : et les autres sessions ? J’ai donc été rechercher du mieux que j’ai pu les supports de présentation des sessions auxquelles je n’ai pu assister. Il en manque encore hélas beaucoup, sans compter la mise en ligne des vidéos. Si vous avez des liens vers les supports manquants, faites m’en part, je les rajouteraient.

Pour commencer, voici le livret des sessions, en mode présentation

La transformation numérique de France Télévision

France Télévision fut le premier sponsor « client final » du French SUG ! Ils nous partagent leur retour d’expérience.

Vous retrouverez aussi cette présentation via le blog d’Alain Buzzacaro.

Le Lean Startup au service du Product Owner, par Jérôme Guenver

J’ai entendu dire beaucoup de bien de cet atelier animé par Jérôme. Un atelier que Jérôme a imaginé suite à une discussion que nous avons eu ensemble chez Zenika. Je suis donc plutôt heureux d’avoir eu un petit rôle pour inspirer un collègue !

Des outils du monde de la psychologie… par Bruno Sbille

On ne présente plus Bruno, en tout cas on ne devrait plus ! Bruno est l’un des piliers de l’imposante communauté agile Belge. Il est aussi l’organisateur de l’Agile Tour Bruxelles auquel je participe depuis sa création (et j’espère continuer). Lors de ce ScrumDay, il proposait cet atelier en plus de son rôle dans la « coach clinic » !

Dans cet atelier, Bruno présentait et permettait d’expérimenter divers outils tels que la PNL, le VAK, etc. Je me souviens encore que Bruno avait fait le déplacement depuis Bruxelles pour la soirée de création du French SUG il y a 6 ans de cela. C’était justeent pour nous parler de PNL !

Let’s Sketch together, par Alvin Berthelot

L’atelier d’Alvin était articulé autour de la création visuelle de produits. Je sais qu’il le produit régulièrement, j’aimerais bien avoir l’opportunité d’y participer…

The big payoff, par Alexandre Boutin

J’avais eu l’occasion de pratiquer ce jeu lors des premiers Agile Game France. Alex remet le couvert pour ce très bon agile game. Vous pouvez en trouver le descriptif en anglais ici. Et mieux encore le descriptif en Français ainsi que le matériel de jeu sur le blog d’Alex.

Faites Revivre vos spécifications

Un autre sujet orienté BDD issu d’une expérience récente de Yannick. Il m’en avais parlé lors d’un déjeuner, plus tôt dans l’année. Une optique de l’acceptance testing qui diffère un peu de la mienne, mais sans être incompatible (si, si !).

Open Agile Adoption, par Pablo Pernot et Oana Juncu

Encore une session à laquelle j’aurais aimé pouvoir assister si j’avais pu me dédoubler. Too many sessions, so little time…

Ici, Oana et Pablo nous dévoilent (en partie) le framework de Dan Mezik.

Créer le bon produit avec le Lean Canvas, par Romain Couturier

Romain a vécu un ScrumDay mouvementé, avec une panne de sonorisation suivi d’un changement de salle. Ici Romain nous parle du Lean Startup et plus précisément de l’outil de référence développé par Ash Maurya .

Les nouveaux outils du Product Owner

Story Mapping, Impact Mapping, Lean Canvas et Kanban : ce sont les « nouveaux » éléments que nous propose Claude pour le Product Owner.

Agilité : la fin du middle management ? Par Kevin Maccioni et Fabien Barbaud

Avec le passage à Scrum, le retour d’expérience des deux orateurs les amènent à répondre oui !

Introduction to Visual Management, par Natalie Yadrentseva

Je ne suis pas certain de joindre ici le bon support, je l’avoue…

Certains éléments de cette présentation me rapellent furieusement le Lightning Talk d’Igor Sviridenko à l’Agile France 2013…

Devops Game, par Vincent Daviet

Le troisième atelier Zenika de ce ScrumDay nous était proposé par notre nouveau venu Lyonnais avec ce Devops Game que je n’ai hélas pas pu expérimenter.

Podojo : PO, viens t’améliorer par la pratique avec nous ! Par Guillaume Duquesnay et Nicolas Verdot

A défaut d’un support de présentation, voici une petite vidéo avec une interview de Dominique Lequepeys sur cet atelier

Le Product Owner est-il un Product Manager agile ? Par Sébastien Saccard

Sébastien Saccard n’est pas un inconnu pour moi : tout d’abord il fut à l’initiative du workshop d’Ash Maurya à Paris, ensuite en tant que président de l’association We Do Product Management, il fut à l’instigation de la rencontre avec Gojko Adzic hébergée chez Zenika.

Sébastien cherche à développer le métier de Product Manager en France. Sa présentation va dans ce sens.

Vous pouvez aussi retrouver la présentation de Sébastien sur son Blog.

Agile-Lean-Kanban : Le guide du routard 2014, par Christophe Keromen

Bien rodée, j’avais eu l’occasion d’assister à cette très vivante présentation de Christophe à l’Agile Tour Rennes 2013. Mais était-ce réellement la même ?

My Product is a James Bond Movie – part V, par Pierre Neis

Les présentations de Pierre ne ressemblent à rien de connu ! Elles sont difficile à raconter, et je doute que le support ci-dessous lui rende justice. J’avais assisté à la « part I » de cette série « James Bond Movie » lors de l’Agile Tour Bruxelles 2013 … nous voici rendu au 5ème opus !

Développer en mode Kick-Ass, par Samuel Le Berrigaud

Le Kick-Ass de Samuel, cela me fait penser au « programming motherfucker » ! D’ailleurs en fait, il en parle dans sa présentation. Je vous recommande ce support pas mal du tout … en attendant la vidéo !

De la culture projet à la culture produit, par Céline Stauder et Gregory Alexandre

La présentation de Céline et Grégory est tout à fait dans le thème de ce ScrumDay. Par contre le support ne vous permettra guère de saisir la substance de la présentation !

Le prétotyping, avec Elalami Lafkih

Le prétotyping, c’est du prototypage « low cost », plus tôt donc avec un feedback anticipé. Elalami nous en expose un certain nombre de techniques. J’ai repris le support de l’orateur utilisé durant l’Agile Tour. Je suis parti du principe qu’il s’agissait du même…

Kapla Challenge, avec Dragos Dreptate

Construire un pont par itération (avec des Kapla), c’est le challenge que nous propose Dragos durant cet atelier

Faire Agile, c’est bien…, par Aurélien Morvant et Simon Jallais

Simon et l’homme aux chaussures de couleurs différentes nous proposent de découvrir ce qu’est « vivre agile ». Une session plutôt décalée !

DSL et refactoring pour les tests d’acceptation, par Laurent Py

Laurent nous fait partager son expérience ATDD / Devops chez Smatesting. En fait, la session ressemble terriblement à une promotion de l’outil Zest’ qui est, oh surprise, développé par la société dont Laurent Py est CEO !

Bon, voici quand même cette présentation…

Les reportages du ScrumDay

Une petite séquence « fun », tournée en bonne partie durant la pause déjeuner du second jour.

Et le reportage du ScrumDay, avec quelques interviews et des interventions de Xavier Warzee et Alistair Cockburn

Ils en parlent aussi…

Quelques liens vers des articles de blog que j’ai peu glaner à droite et à gauche. Si vous avez d’autres liens, n’hésitez pas à m’en faire part.

Il y avait une Coach Clinic, mise sur pied par Fabrice Aimetti et Bruno Sbille. Côté Zenika, Géry Derbier y participait ainsi que Laurent Sarrazin pour Rupture 21. Un compte-rendu est disponible sur le site d’Ayeba.

Alex Boutin nous livre sur son Blog la manière dont il a vécu ce ScrumDay.

Un retour de Laurent Sorin sur la table ronde menée par Véronique Messager

Autre retour également en provenance d’Ippon, un feedback sur la session de Rachel Davies par Victoria Pedron.

Dominique Lequepeys nous adresse les points forts des sessions auxquelles il a participé. Youpi, ceci inclut la mienne !

Christophe Deniaud fait aussi son billet de Blog sur les sessions qu’il a vu, ainsi que sur l’open-space. Lui aussi donne son feedback sur mon atelier. Pas sûr que mon message principal sur l’écriture collaborative des tests soit bien passé…

Coactiv nous livre aussi ses retours.