Agile Playground #17 : En interlude…

Nous avons conservé ce mois-ci la formule du mois précédant : un démarrage en mode « place de marché » d’un forum ouvert ! Dans la pratique, nous n’avions pas de jeu « à expérimenter » ce mois-ci. Mais Alexis Nicolas avait amené un Kanbanzine. C’était fort à propos !

image

Finalement, deux « ice breakers » et 2 jeux furent retenus pour cette soirée. Outre le Kanbanzine et l’ice breaker dont j’ai oublié le nom, je me suis donc retrouvé mis à contribution sur un ice breaker que j’avais proposé … et un « remember the speed boat » pour satisfaire une demande de mettre en oeuvre des innovation games !

Cassons la glace des estimations agiles !

Pas tout à fait en estimations agiles, en fait. Il s’agissait plus d’expérimenter une approche d’estimation inspirée du Wide Band Delphi. Une version un peu simplifiée, en fait.

1 – On forme plusieurs groupes

2 – Je propose un sujet à estimer.

3 – Chaque groupe discute entre eux pour déterminer une estimation durant 2 minutes

4 – Les groupes partagent les éléments les ayant conduit à choisir cette valeur.

5 – On fait un nouveau tour de ré-estimation d’une minute.

Est-ce parce que nous avions un parterre d’agilistes « chevronnés » ? Aucun groupe n’a jugé nécessaire de réviser l’estimation au second tour (bien qu’avec quelques hésitations). A tord. La réévaluation les auraient fait converger vers la bonne direction !

Remember the Speed Boat

Mariage forcé entre le « Speed Boat » et le « Remember the future », il s’agit d’une combinaison qui me parait aujourd’hui naturelle. Par contre, cette animation était un peu improvisée et j’avoue ne pas avoir été excellent. Hélas. Le sujet, s’il était fun, n’était pas non plus évident à mener à bien : Organiser une visite privatisée au Taj Mahal, avec nuit sur place … mais à un prix raisonnable !

image

Nous avons pu mener notre projet fictif (plus ou moins) à bien. Nous avons terminé en discutant librement des apports de cette approche. Finalement, notre jeu aura atteint son but, car plusieurs des participants vont s’y essayer.

image

Pendant ce temps, le Kanbanzine

Nous avons terminé un peu plus tôt que le second groupe. C’était donc l’occasion pour moi d’entretenir une petite frustration réccurente : cela fait déjà un certain temsp que j’aimerai tester le Kanabanzine ! Chaque fois je rate l’occasion à pas grand chose ! Mais un jour, j’y arriverais…

image

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 » !

Note de lecture : Applied C++, par Philip Romanik & Amy Muntz

Note: 4 ; Tutorial pour C++

A l’origine, j’avais classé cet ouvrage dans la partie « C++ avancé », à l’image de la plupart des ouvrages de cette série. Toutefois, au final cet ouvrage s’adresse d’avantage aux développeurs peu expérimentés, ce qui justifie ce classement.

Le livre compte un peu plus de 300 pages et presque 20 pour les annexes. Il n’est découpé qu’en 8 chapitres. Passons rapidement sur l’introduction de 7 pages nous dispensant quelques rudiments de traitement d’image et de principes de conception de système. Le second chapitre est à peine plus long avec 11 pages. Mais on commence à écrire quelques classes simples et à aborder les conseils proposés par les auteurs, essentiellement concernant les questions de constructeur, destructeur et opérateur d’affectation.

Les choses sérieuses commencent au chapitre 3 qui comprend 48 pages. On commence par une idée curieuse : réécrire l’allocation mémoire ! Rapidement, on y mélange beaucoup d’aspects : les templates, les destructeurs virtuels, etc… Difficile de s’y retrouver. On finit même par perdre de vue l’étude de cas !

Le chapitre 4 est long de 45 pages. On commence par y parler convention de style (nommage, indentation, etc…) pour ensuite parler réutilisation. Car on va réimplémenter des classes telles que std ::string, eh oui ! Tout le propos sur le support de debuggage a le mérite d’être original et intéressant. Même si aujourd’hui on s’appuie d’avantage sur les tests unitaires.

55 pages sont consacrées aux considérations système au chapitre 5. La façon dont les sujets sont abordés me laisse dubitatif : est-on en train de construire un framework système, là où la librairie standard ou ACE font un excellent travail ? Par exemple, les auteurs s’efforcent de reconstruire une classe thread en s’appuyant sur Posix, sur Unix et Windows. Non seulement ACE fait déjà cela, mais cette approche n’est pas la bonne sous Windows ! De même les auteurs nous invitent-ils à avoir notre propre classe de base apException ou notre propre gestion de l’internationalisation, là où la librairie standard a ce qu’il faut ! Troublant…

Avec 75 pages, le chapitre 6 « implémentation considérations » est le plus volumineux du livre ! Au moins a-t-il du sens, car les auteurs y développent un framework de gestion d’image. Si le propos est abondamment illustré, le fil un peu décousu ne facilite pas le suivi de celui-ci.

La chapitre 7 aborde les tests de performance. Mais disons le tout net : en 20 pages, on est surtout frustré par l’aspect superficiel du propos. Les auteurs en profitent pour nous présenter leur framework de tests unitaires. Aujourd’hui, cppUnit fait un meilleur travail.

Les sujets avancés traités en 35 pages dans le dernier chapitre vont un peu dans tous les sens : gestion mémoire, gestion du cache ou utilisation du mot clé « explicit »… Difficile de trouver un fil conducteur dans tout cela ! Et rien n’est vraiment traité de manière satisfaisante.

Il y a du bon et du moins bon dans ce livre.

Le bon, c’est que cet ouvrage décrit et adresse nombre de problématiques que l’on rencontre vraiment quand on développe du C++, plutôt que de s’appuyer simplement sur des cas d’école comme on le voit souvent. L’ensemble du livre s’appuie sur une véritable application, et son développement tire avantage des conseils dispensés par John Lakos dans son « Large scale C++ Design ».

Le moins bon, c’est nombre de conseils pour le moins curieux dispensés au long de l’ouvrage. On est même en droit parfois de se questionner sur le niveau de maîtrise du C++ des auteurs ! Pourquoi recommander l’usage des préfixes au lieu des namespaces ? Pourquoi s’évertuer d’utiliser un sous-ensemble de la STL et exhiber fièrement l’utilisation d’un conteneur inadapté ?

Ce livre est un « cas d’utilisation », mais l’étude de celui-ci occupe une place prépondérante dans le texte. Cela signifie que l’un des sujets principaux du livre est bel et bien le traitement d’images. Si ce n’est pas un sujet d’intérêt pour vous, vous risquez d’être carrément frustré ! Pour le moins, il faut bien savoir à quoi l’on a à faire.

Il n’en reste pas moins qu’un certain nombre d’idées et d’outils, pour les tests et les tests unitaires peuvent servir. Mais c’est quand même bien décevant…

image

Référence complète : Applied C++, Practical techniques for building better Software – Philip Romanik & Amy Muntz – Addison Wesley / C++ In depth series 2003 – ISBN: 0-321-10894-9

Applied C++: Practical Techniques for Building Better Software [With CDROM]

https://www.goodreads.com/book/add_to_books_widget_frame/0321108949?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Agile Tour Beirut 2014 : j’y serais !

Deux sessions pour moi au programme de cet Agile Tour Beirut !

image

Scrum Shu Ha Ri

En voici le teaser

Most of time, when we start agility, we think about « doing agile ». In truth, it’s rather about being agile. And being agile is becoming agile, again and again. Agile is not a destination, it’s a journey.

During this session, we will have a different look at Scrum. We will discover a framework that can help you in each and every step of your journey. Scrum owns the qualities to do it. This is why we should appreciate Scrum.

Together, we will engage the « Scrum Journey ». This is a 3 steps journey and there is no shortcuts ! We borrowed names from martial arts, we call them Shu, Ha and Ri.

Shu belongs to apprentices. It’s for people discovering Scrum. It’s about putting Scrum in practice right !

Ha is about improvement. Once you master the basic Scrum, it’s time to adapt the practices or use new ones.

Reaching Ri is reaching the master level. Here we innovate, we reinvente our own way to be agile, based on values and meaning of agility.

This session is a perspective on your next journey. We want to help you start peacefully, staying away from mistakes or misdirections. And enjoy rediscovering Scrum in a new way each time !

Un carpaccio, un !

Cette fois, il s’agit d’un atelier. En voici le teaser

All agile approaches focus on working on small pieces of features. But development teams as well as business-oriented peoples (like Product Owners in Scrum) struggle to split functionalities into small chunks. They claim that it doesn’t make sense. On the other side, we met teams that split features from a technical perspectives, a strategy that matter only for the development team.

Yet, the feature split is possible more often than not. It’s often a question of practice and discipline.

During this workshop, we’ll train ourselves to split features to the extreme with a hard constraint on realization duration. Because, we will not only talk and imagine slicing, we will also argue about it and put it in practice through a programming episode led into very small slices.

Agile Tour Beirut 2014 : j’y serais !

Le FKUG offre un tour de chauffe à Lean Kanban France !

Beau programme pour cette rentrée du FKUG ! En effet, cette soirée hébergée par Wemanity proposait pas moins de 4 sessions sur 2 tracks. Nous serons donc hélas frustrés de 2 sessions !

image

Un petit mot sur le FKUG tout d’abord :

  • Les choses avancent, avec maintenant un site pour l’association.
  • La taille de la communauté augmente aussi progressivement : elle compte 330 inscrits sur meetup ! La j’en suis sûr, nous étions moins nombreux chez notre hôte…
  • On est rentré et bien rentrés : le prochain meetup se profile déjà pour le mois de novembre…

Assez bavardé, place aux présentations !

Apprendre à apprendre pour le 21ème siècle, par Yannick Grenzinger

Cette session, seul Yannick pouvait nous en gratifier ! Sur la dernière année, Yannick a suivi 30 cours en ligne, les fameux MOOCs, il est en quelque sorte un « boulimique du savoir » !

Cette présentation, que Yannick propose par ailleurs au format Brown Bag Lunch s’articule sur 3 niveaux : l’individu, le produit, l’organisation.

image

Apprendre pour les individus

Ici, Yannick nous propose quelques « hacks » :

  • Déconstruire pour mieux reconstruire : faire des tranches d’une dizaine de minutes. Cette déconstruction est déjà une étape de l’acquisition de la connaissance !
  • Des répétitions fréquentes, mais espacées (!)
  • S’appuyer sur l’utilisation de modèles mentaux et de métaphores. Tiens ? Cela ne vous rappelle-t-il pas XP ?
  • Eliminer les bloquants.
  • Utiliser une boucle de feedback rapide. Nous autres agilistes sommes en terrain connu…

Bien sûr, pour faire bonne mesure, Yannick sait aussi nous proposer quelques bonnes lectures :

L’un des points majeurs est qu’il n’est pas besoin d’avoir une « connaissance parfaite ». Les fameux 80% sont largement suffisants et s’acquièrent comparativement rapidement !

Apprendre sur les produits

Et déjà, sur la construction de produits, quel est l’inverse de l’apprentissage ? Le « cycle en V » bien sûr ! Et bien entendu, notre objectif est bien d’apprendre en permanence. Notre attirail d’agiliste possède ce qu’il faut à ce égard : Rétro, A3, Kaizen, etc…

Apprendre, c’est aussi utiliser le pouvoir de la collaboration et les techniques de co-création.

Enfin, apprendre c’est aussi accepter l’échec et penser à « aller plus vite sur l’échec ». C’est ce que nous enseigne le Lean Startup.

Apprendre en tant qu’organisation

De nouveau la même question : quel est l’inverse de l’apprentissage ? C’est le Taylorisme : un travail codifié devant être exécuté sans reflexion par des executant dont réfléchir n’est pas le rôle !

image

Apprendre au sein d’organisation, c’est d’abord savoir organiser pour la complexité, plutôt que chercher à la maîtriser ou le réduire à tout prix. Le Stoos Network a pour but de faire progresser ce mode de pensée, bien que force soit de constater qu’il peine à prendre de l’ampleur.
Le rôle du management est à repenser dans une organisation apprenante. C’est ce que nous enseigne le Management 3.0, mais aussi les militaires dans le manuel Warfighting !

Ce que j’en ai pensé

Je sors un peu frustré par cette session. De l’aveu même de Yannick, la partie « organisation » nécessite d’être renforcée. Mais c’est surtout sur la partie « individu » que l’on attendait l’orateur, et malheureusement il ne développe pas assez ses « hacks ». Nous aurions aussi aimé une reflexion sur la nature (et l’objectif) différent de l’apprentissage au 21ème siècle, à l’ère de l’information à haute valeur disponible au bout des doigts !
Toutefois, je sors aussi avec quelques pointeurs de lecture (encore). Connaissant Yannick, ils valent sans aucun doute le détour !

Continuous Delivery : A Plug-in for Kanban, par Samuel Retière

Il s’agit en fait d’une présentation qui serait fait à 3 voix au LKF, ici il n’y avait que celle de Samuel. Je ne vais pas paraphraser la présentation de Samuel, car vous pouvez y accéder ici.

Ce que Samuel nous présente ici, ce sont les « patterns de transformation » appliqués à la SGIB et organisé en 3 niveaux. Les thèmes s’articulent beaucoup autour du Kanban Thinking de Karl Scotland : valeur, flux et potentiel

image

Le niveau 1 n’a peut-être l’air de rien, mais on y parle déjà cycle TDD et flux !

Le second niveau correspond déjà à une maturité acquise par bien peu d’équipe. On y trouve pèle mêle une pensée produit épaulée par du Lean Canvas, du BDD, du Flux « end to end », donc avec du devops à la clé !

Au niveau 3, on trouve des choses bien plus rares telles que la maximisation de la valeur « infrastructure as code ».Et le seul élément que j’ignorais de la présentation : le Black Swan Coaching ! Plus curieusement, on y trouve le DDD que j’aurais mis personnellement au niveau 2 au maximum. Peut-être même au niveau 1 !

Le programme inclut un cocktail de cours, de workshops et de katas. Le tout épaulé par 3 coaches qui permettent de couvrir le spectre de compétences évoqué. Impressionnant !

<

Fin

Hélas, il n’était pas possible de tout voir. J’aurais par exemple aimé assister au retour d’expérience sur SAFE chez JC Decaux. Il s’agit d’un buzzword qui monte et il faut que j’en sache plus sur le sujet. Celui-ci au demeurant me semble complexe, trop pour être honnêtement agile et j’y perçois des reminiscences d’Unified Process… Qu’importe, il me faudra bien appréhender correctement ce dont il s’agit.

ScrumBeer de Septembre : Histoire sans paroles…

Je rate rarement une Scrumbeer. Il faut vraiment qu’il y ait un empêchement pour cela. Cela a bien failli être le cas ce 25 Septembre, à cause d’une collision de date avec le meetup Product Tank, comme cela arrive bien trop souvent…

C’est donc tranquillement à 21h30 je me suis joins à notre petit groupe d’habitués. Auquel fort heureusement se joignent à chaque fois quelques nouveaux venus !

image

C’est Au Fut et à Mesure qui nous avions rendez-vous. Une idée originale, dans un lieu au concept très « tendance » ! Mais aussi hélas à la musique bien trop forte.

Mon arrivée tardive aidant, j’ai peu échangé avec les autres. Nous avons quand même pu le faire rapidement sur le sujet toujours délicat et d’actualité de la façon d’introduire et convaincre de mettre mettre en oeuvre de nouvelles pratiques.

Je suis de plus en plus sceptique, pour ne pas dire plus, sur la méthode consistant à « convaincre » de l’intérêt d’adopter telle ou telle pratique. Cela me parait une voie menant à des discussions sans fin ! Désormais j’essaie plutôt de faire accepter une petite expérimentation sans porter de jugement préalable, puis d’évaluer la pertinence de ce qui a été vécu sur la base de critères partagés. Bref, faire plutôt que discuter !

Avant de nous séparer, nous avons brièvement évoqué le prochain ScrumDay.

image

C’est vrai, c’est dans un bout de temps, mais il va bientôt y avoir un open-space pour amorcer sa co-création ! Malheureusement, j’aurais (encore) un autre meetup pile-poil à la même date ! Je ferais quand même mon possible  pour apporter mon gravier à l’édifice, à moins que je tente de nouveau le « double date »…

Note de lecture : Activity in Action, par Tijs Rademakers

Note : 7 ; Un bon ouvrage au standard « in action » pour accompagner une immersion dans Activity, malgré quelques frustrations.

Activity, c’est le « spin off » de JBPM par ses créateurs. Mais, ainsi qu’il est expliqué en introduction, ce n’est pas un fork mais une réécriture complète, avec les choix de conception que l’équipe aurait voulu prendre à l’époque !

Mais revenons au livre. L’auteur est un des comiters principaux du projet, ce n’est pas non plus un auteur débutant. Tout ce présente donc sous les meilleurs auspices pour commencer. La prose est conséquente : 400 pages sur 15 chapitres distribués en 4 parties inégales. Il est temps de rentrer plus en profondeur.

Les quelques 80 pages de la première partie regroupent 4 chapitres et sont une introduction à BPMN 2.0 et Activity. On commence par une présentation générale d’activity, de son architecture et l’incontournable « hello world » précédé d’une installation basique. C’est réussi. Le chapitre suivant a pour but de nous présenter BPMN 2.0. C’est fait avec pédagogie et bien illustré, mais aussi assez superficiel et on sort de là un peu frustré. La présentation de l’outillage Activity est un peu touffue, probablement parce que cet environnement l’est aussi un peu : il manque d’homogénéité et est un peu de pièces rapportées. Espérons que cela s’améliore à l’avenir.

Avec 35 pages, le chapitre 4 est le gros morceau de cette première partie, on y débute l’implémentation de l’étude de cas, avec configuration Maven, définition de processus, implémentation de tâches en Java et tests unitaires. Honnêtement, ça fait un peu trop de chose pour être vraiment clair.

La seconde partie est consacrée à l’implémentation de processus avec Activiti, c’est donc le cœur du livre. On y compte 150 pages et 5 chapitres, ce qui le met à égalité avec la 3ème partie. Là où le chapitre 4 était un peu brouillon, le chapitre 5 reprends les choses calmement et implémente un BPM simple mais non trivial, avec une implémentation d’un script task et de différents service tasks. On va même jusqu’au déploiement. C’est bien fait et clair. Le chapitre 6 nous permet de faire des choses plus avancées (sous-processus, points de décision) et couvre aussi l’accès à JPA depuis Activity et la mise en place de listeners sur les tâches. La gestion des erreurs (en Java ou en définition de processus) est traitée avec sérieux au chapitre 7, un bon point ! C’est aussi le cas sur les options de déploiement abordées au chapitre 8, bien que je reste sur ma faim sur la façon dont l’utilisation de l’interfaçage ReST est abordé. Le chapitre 9 qui clos cette partie n’est pas mon préféré. Seul la partie OSGi m’aurait intéressée si elle avait été abordée clairement !

La troisième partie se focalise sur les aspects avancés d’Activity. Le chapitre 10 fait un peu pot-pourri entre des aspects avancés de modélisation (sous-tâches, délégation), la connexion au LDAP ou les tâches multi-instances, ça manque un peu de cohérence. Le chapitre 12 est plus « focus » car il traite d’un aspect important : l’intégration. L’utilisation d’Apache Camel et de Mule ESB font le gros de ce chapitre. C’est une bonne idée, car cela donne un exemple avec ESB et un autre avec « ESB light ». L’intégration d’un moteur de règle n’est pas nécessairement l’aspect qui m’aurait intéressé de prime abord, mais le chapitre 13 qui le traite et clair, bien écrit et même source d’inspiration. Je ne dirais pas la même chose du chapitre 14 qui traite de l’intégration avec Alfresco.

Alfresco est le principal comiter Activity et parler de cette intégration sonne comme un passage obligé, mais personnellement j’en retire peu de choses. Ca fait plutôt plaquette publicitaire. Cette partie se conclut par un passage par le monitoring de production e l’intégration avec Esper : utile, intéressant et bien fait.

La quatrième partie ne compte qu’un seul chapitre et 25 pages. L’objectif est de nous permettre de monitorer les processus en production. Concrètement on entre dans le modèle de données d’Activity et on fait un petit tour dans le Job Executor. Pas grandiose mais nécessaire.

Activity in Action fait bien le boulot, il est à la hauteur du standard « in action » de Manning. Le texte est bien écrit et les illustrations aident. Les exemples par contre sont plus problématiques : ils sont souvent non seulement complexes et volumineux, mais insuffisants tels qu’ils figurent dans le texte. Il est nécessaire d’avoir recours au code source complet.

Personnellement, mon regret est une approche très « Activity centric », où les fonctions du logiciel sont subordonnées aux hooks qu’offre le framework. Etant essentiellement conçu en ce sens, l’approche est compréhensible. Toutefois Activity possède aussi un ensemble d’API ReST permettant de l’utiliser de l’extérieur à la façon d’une appliance. Je suis d’avantage intéressé par cette architecture et je soupçonne que de nombreuses personnes le sont également. Très peu de contenu est orienté en ce sens. A mon avis, l’ouvrage aurait bénéficié d’un ou deux chapitres en ce sens, même si cela avait dû être au détriment d’autres sujets.

Malgré ces quelques frustrations, le contrat est bien rempli. Pour qui veut s’initier à Activity, voilà un excellent compagnon.

image

Référence complète : Activity in Action, Executable business processes in BPMN 2.0 – Tijs Rademakers – Manning 2012 – ISBN : 978 1 617290 12 1

Activiti in Action

https://www.goodreads.com/book/add_to_books_widget_frame/1617290122?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on