Dave Snowden au Scrumday 2015 : Making Sense through Action

Faire une bonne transcription de la keynote de l’auteur du modèle Cynefin n’est pas chose facile. Je ne pense pas y parvenir. Son accent n’est pas évident, pour commencer. Ensuite, suivre son propos s’est souvent avéré pour moi difficile. Je vais donc plutôt passer en mode « morceaux choisis ».

Adopter l’approche scientifique

Dave Snowden nous met en garde contre l’approche par l’exemple: on ne saurait proclamer une réussite basée sur un nombre limité de succès. En fait, la théorie s’avère alors un meilleur fondement que la technique.

image

Des entreprises montrent des succès spectaculaires en faisant des choses différentes, mais il est illusoire de chercher à les copier

All the path up are different, all the path down are the same

Le modèle Cynefin

C’est ce pourquoi Dave Snowden est connu. Il était normal que son auteur nous l’évoque. L’ayant déjà évoqué dans ce blog, je n’y reviendrais pourtant pas. Le billet de Nicolas Lochet développe très bien ce sujet également (de manière plus approfondie que moi pour être franc).

Mais le modèle Cynefin n’est pas statique mais dynamique. C’est pour décrire les transitions entre les états qu’il a été créé. Scrum transite ainsi entre « complexe » et « compliqué », il maintient même une cadence entre ces deux états. A la longue, il peut même revenir vers « évident » !

Simple or simplistic

Répéter les recettes est attrayant. Mais Snowden nous met en garde contre celles-ci. Et en particulier sur 3 effets :

Le « novelty effect » : Ce n’est pas parce qu’une approche est populaire qu’elle est bonne. Ce disant, Snowden vise SAFe sans aucun détour.

Le « cobra effect » : Il faut se méfier des solutions simples. Vous pensez à récompenser la correction de bugs ? Méditez sur cette histoire : Le gouvernement Britanique voulait réduire le nombre de Cobras pullulant certaines régions et a donc proposé des primes pour la capture des cobras. En retour, les paysans ont commencé a élever les cobras pour pouvoir toucher les primes…

Le « butterfly effect » : Ce n’est pas parce que quelque chose a marché une fois qu’elle continuera a marcher plus tard…

L’ethnographie scalable

Bien sûr, la scalabilité, c’était le thème de ce ScrumDay. L’ethnographie scalable, c’est le modèle que nous propose Dave Snowden. Hélas, je n’ai pas compris grand chose au propos, le point d’orgue étant le « human metadata ». C’est un peu trop pour moi. Je vous livre toutefois une pensée que j’aime bien :

Scale, not by aggregation, but by redistribution.

C’est une autre façon de dire que l’agile à l’échelle tant à la mode aujourd’hui doit se faire, non pas en « scalant », mais en « dé-scalant ».

Bref hélas une keynote que j’ai trouvé décevante. Mais pas par la pauvreté du propos, mais par son altitude stratosphérique et par la difficulté que j’ai eu à comprendre l’auteur à travers son accent.

Rendez-vous à l’Agile Vendée !

C’est toujours un grand plaisir d’assister à la naissance d’un mouvement local de notre communauté agile. En ce mois de Juin, c’est la vendée qui va poser la première pierre de sa communauté.

J’y serais, avec un plaisir d’autant plus grand que l’équipe organisatrice compte des personnes que j’apprécie vraiment beaucoup !

Pour vous inscrire ou vous régaler du programme, c’est ici !

Rendez-vous à l’Agile Vendée !

Note de lecture : Essential Business Process Modeling, par Michael Havey

Note : 7 ; Un titre trompeur, mais sinon un excellent tour d’horizon des langages de processware…

Commençons par clarifier un point important : ce livre ne traite pas de « business processes », pas plus qu’il n’aborde la modélisation métier. Hélas, ce terme a été kidnappé et est devenu depuis consacré, par les éditeurs d’infrastructures d’échanges et d’orchestration. Ce point traité, nous allons voir que ce livre, divisé en 3 parties, recèle beaucoup de bonnes surprises.

La première partie est consacrée aux fondamentaux du « BPM », historique et fondements théoriques. En effet, les standards du BPM s’appuient globalement sur 3 principes théoriques (au choix ou de façon complémentaire) : les réseaux de Pétri, le Pi-calcul (je vous garanti que celui-ci n’est pas facile à capter) et les diagrammes d’état-transition.  Si les fondements théoriques permettent de comprendre les paradigmes développés par les moteurs de processware, les process patterns permettent de comprendre les briques de base de l’orchestration et aussi de classifier les normes d’orchestration de process en fonction de leur support des 24 process patterns présentés.

La seconde partie présente les principales nomes de process : BPEL, BPMN (mais aussi BPML), WfMC, les normes sur les chorégraphies de process (essentiellement WS-CDL) et autres normes de seconde zones (BPSS, XLANG, WSFL). L’auteur présente les différentes normes de façon simple et efficace, en s’appuyant sur des exemples. C’est une excellente façon de faire le tour de la question, sans aucun doute le meilleur ouvrage sur cet aspect. Deux points modèrent la qualité de cette partie. Le premier point à trait au manque de stabilité de ces normes : BPML a disparu, tandis que BPMN a été repris par l’OMG (qui travaille à son intégration dans le paysage MDA), de son coté WS-CDL a progressé. L’auteur n’y peux rien, seul une seconde édition pourrait remettre les pendules à l’heure. Le second point à trait au point de vue très subjectif de l’auteur qui présente BPEL comme le saint Graal et les autres normes comme des loosers, cela s’apparente régulièrement à de la mauvaise foi, et cela m’empêche souvent de considérer son point de vue…

La dernière partie est consacrée au développement complet de deux exemples complets, tous deux implémentés avec BPEL et le moteur de process d’Oracle. L’auteur présente précisément la marche à suivre pour mettre en place l’environnement adéquat. C’est certainement le point le plus positif de cette partie, car les exemples en eux-mêmes ne sont guère passionnants et pas extraordinairement bien expliqués.

En conclusion, le livre que nous avons ici est excellent pour avoir un tour d’horizon efficace des normes en présence, en connaitre leurs fondements théoriques et les comparer. Si tel est votre besoin, cet ouvrage est pour vous.

image

Référence complète : Essential Business Process Modeling – Michael Havey – O’Reilly 2005 – ISBN: 0-596-00843-0

Essential Business Process Modeling


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

Quand les users stories deviennent techniques…

Je ne suis pas un intégriste de la User Story. Il ne m’importe pas tellement qu’elles suivent le fameux template de Mike Cohn « en tant que… je veux… afin de… ». Même si ce template n’a rien de mauvais et peut guider vers l’écriture de meilleurs histoires, c’est aussi un bon moyen de devenir un « template zombie ». Je préfère les 3 questions de Jeff Patton : Qui ? Quoi ? Pourquoi ?

image

En fait, peu m’importe que vous parliez de User Story, d’item de backlog ou d’un autre terme inventé de toute pièce. Ce qui va m’importer, c’est que votre story ait un sens d’un point de vue externe au système que l’on construit. C’est là qu’intervient le « qui », un acteur externe aus système. Ce n’est pas par dogmatisme que j’y suis sensible, mais au contraire par pragmatisme. Une petite explication s’impose.

La liste des stories que nous réalisons durant le sprint doit être considéré comme notre contrat de fourniture : voilà ce que nous avons fait, voici où nous en sommes. L’un des mécanismes essentiels en contexte agile est le feedback. La simple déclaration énoncée ci-dessus est sans valeur si je suis dans l’incapacité de la constater et de donner du feedback dessus. Et pour donner ce feedback, il nous faut la connaissance de l’acteur concerné.

Régulièrement, hélas, je vois arriver ces fameuses « user stories techniques ». La justification que j’obtiens alors est : non mais là c’est technique, on a besoin de le faire ! J’ai alors droit à des merveilles du genre :

  • Stocker les donner fournisseur.

Ne souriez pas, c’est très fréquent. Mon exemple est d’ailleurs loin d’être le pire. Je vous épargne le classique « développer la couche de persistance »…

Un second effet de ces user stories techniques peut aussi se constater en planning meeting

La user story technique et le planning meeting

C’est donc conjointement à des user stories plus classiques que ces « stories techniques » se présentent en planning meeting.

image

Mais si les user stories classiques sont traitées assez efficacement, leurs homologues techniques necessitent environ 4 fois plus de temps (bien que je ne l’ai pas mesuré précisément).  Sont en cause :

  • Une difficulté à cadrer la solution, car la finalité n’est pas claire. Il manque le contexte.
  • Impuissance à déterminer le périmètre de la story. Quand celle-ci sera-t-elle terminée ? Quels sont les tests d’acceptation ?

Même avec 4 fois plus de temps, le découpage en tâches et l’estimation s’avèrent moins satisfaisants. Même si vous n’êtes pas fan du découpage en tâches et des estimations, il n’en reste pas moins que ceux-ci s’avèrent symptomatiques de la compréhension de l’item.

Mais voilà : c’est du travail technique, ce n’est pas fonctionnel. Est-ce vraiment le cas ?

Remettre la story technique dans son contexte

Basculer de la user story technique à leurs équivalents fonctionnels est moins difficile qu’il n’y parait de prime abord. Il s’agit surtout de se poser les bonnes questions :

  • Pourquoi a-t-on besoin de faire cela ? Que se passe-t-il, ou qu’est-ce qui se passe mal, si on ne fait pas cela ?
  • Dans quel contexte cela sera-t-il utilisé ?
  • D’un point de vue externe, comment saurais-je que le système possède cette propriété ou cette capacité supplémentaire ?
image

Cette liste n’est pas exhaustive, et vous pourrez facilement imaginer d’autres questions de la même eau. Le but est simple : remettre l’item technique dans un contexte fonctionnel. Dans le cas que nous avons énoncé plus haut (stocker les données fournisseur), à la question « qu’est-ce qui se passe mal si on ne fait pas cela », la réponse est : on ne peut pas communiquer ces informations si le système s’arrête entre leur acquisition et la transmission. Je pourrais vous le souffler à l’oreille, mais cette réponse nous permet assez facilement d’en déduire une user story fonctionnelle…

Et mon refactoring, alors ?

Eh bien c’est vrai, le refactoring, ce n’est pas fonctionnel (apparemment).  Doit-on le rejetter, l’ignorer ? Bref, le développeur doit-il se débrouiller et caser ça à l’heure du déjeuner ?

Bien sûr que non ! Mais ce n’est pas non plus une raison pour produire une « user story technique ».

N’oubliez pas que le mainteneur du système (donc le développeur) est aussi un utilisateur du système. Tout comme le sont les ops et les exploitants chargés de déployer et d’assurer le bon fonctionnement du système en production, soit dit en passant. En tant que mainteneur, vous pouvez demander à rendre un type d’évolution plus facile, de pouvoir prendre en charge de nouveaux périphériques ou de nouveaux algorithmes plus efficacement. Vous pouvez souhaiter que les évolutions ou les corrections soient localisées à un seul composant.

image

Bref, vous pouvez exprimer des besoins qui une fois remis dans le contexte d’un objectif, peuvent être discutés avec le Product Owner. Et vous pouvez même produire des critères d’acceptation ! Certes, ce ne seront pas des tests d’acceptation (on reste iso-fonctionnel, n’est-ce pas ?), mais on peut évaluer l’atteinte de ces critères ne serait-ce que qualitativement. N’oubliez-pas :

Tout ce qui a besoin d’être mesuré peut être mesuré d’une manière qui est de toute manière supérieure à pas de mesure du tout !

Maintenant, c’est trop gros !

Vous avez basculé dans l’usage ? Bien. Et maintenant vous vous rendez compte que votre story a pris de l’embonpoint, car elle intègre maintenant le contexte d’usage ! Je vous entend : c’est justement pour cela que vous aviez fait une story technique, pour que ce ne soit pas trop gros.

Il faut alors passer à la cure d’amaigrissement. Mais pas en réalisant un morceau du mécanisme après l’autre, en faisant des tranches plus fines de ce mécanisme.

image

Faire des tranches fines dépasse le cadre de ce post. Cela reste une compétence clef à acquerir pour le développement agile, en particulier pour le Product Owner. Je vous recommande à ce titre l’exercice du Carpaccio pour aiguiser votre savoir-faire.

A emporter

Peut-être un jour devrais-je faire face à une story technique que je ne saurais pas mettre dans un contexte d’utilisation. Pour l’instant tout va bien. Si vous faites face à cette difficulté, tentez l’exercice !

Reprenez les questions évoquées dans ce post. Au besoin, enrichissez-les des vôtres. Reprenez vos User Stories techniques et mettez-vous à 2 ou 3 autour d’une table et basculez votre story technique dans l’usage qui en est fait.

Note de lecture : Convergent Architecture, par Richard Hubert

Note: 1 ; Pas convaincant et ennuyeux!

Mais pourquoi donc ai-je acheté ce bouquin? Tout simplement parce que l’excellent « enterprise patterns and MDA » y fait référence. Mais force est de constater que c’est l’échec complet. Voyons donc comment les 260 pages et les 8 chapitres de cet ouvrage pourtant estampillé « OMG press » ont pu nous amener là.

Le chapitre 1 « IT Architectural style » couvre 30 pages. Il s’agit, du moins pour les 15 premières pages d’une discussion philosophique sur la nature d’une architecture, son caractère évolutif, ses niveaux d’expression et l’équilibre entre innovation et couverture du risque. Rien de bien concret. Je ne me retrouve guère non plus dans les 4 propriétés énoncées concernant cette architecture, sujet des 15 pages suivantes :

  • Le métamodèle architectural, bref la nécessité de suivre un style prédéfinit.
  • Le cycle de vie du développement du modèle.
  • Une suite d’outils complète.
  • Une « projection technologique » formalisée.

On va même jusqu’à évoquer le template IEEE 1471-2000 pour documenter cette architecture. Bref, un chapitre qui n’a guère de sens pour moi.

Le chapitre suivant s’attaque à la roadmap de la Convergent Architecture sur une vingtaine de pages. Il s’agit du plan d’ensemble. Sans grande surprise, on apprend que celle-ci s’articule sur les 4 points énoncés précédemment. Il est juste de penser que l’on va voir ici comment ils se déclinent pour la « Convergent Architecture ». C’est bien ce qu’on y fait, mais cela reste très abstrait, même si chaque point est décomposer en plusieurs concepts. Leur description ne permet pas de se faire une idée du fonctionnement réel de l’ensemble. Ni même de ce qu’est cette Convergent Architecture, d’ailleurs. On a quand même droit à un beau tableau résumant les gain de productivité et de qualité que cette approche donne sur les 4 axes. Pour autant que l’on suive cette approche en 4 axes, bien sûr. Bref, je n’ai pas encore l’impression d’avoir mordu dans le dur.

Le dur vient peut-être au chapitre 3 : ses 18 pages sont consacrées au premier pilier, le Convergent Architecture Metamodel. Celui-ci est basé sur un modèle dit holistique s’appuyant sur 3 facettes : le « business design », le « project design » et le « system design ». Il s’agit là d’une vue conceptuelle inspirée du Convergent Engineering de David Taylor. Le couplage sémantique entre objet métier et objet IT rappelle le PIM/PSM du MDA, mais à part nous dire que c’est compliqué et évoquer un parallèle avec une « machine shop », on ne va pas loin. Le chapitre se poursuit avec d’autres concepts, évoqués plus qu’abordés le RASC (qui fait écho au concept des processeurs RISC), l’isomorphisme conceptuel et le « component metamorphosis ». Me voilà frustré de nouveau. L’espoir s’amenuise.

Le thème du chapitre 4 est le « component metamodel ». Cela semble sérieux, d’ailleurs 34 pages lui sont consacrées. Et là, en effet, on nous parle des couches architecturales (il y en a 4), avec la manière dont elles s’articulent entre elles et même la façon dont tout cela est outillé. On passe du très abstrait au tellement concret qu’il s’agit même d’une obsolescence programmée. On y parle : JSP, servlet, HTML, EJB, etc… Le « technology projection component » est un élément clé (qui n’est guère décrit) et les composants eux-mêmes ont des « personnalités » telles que « client » ou « serveur ». Nous voici rentré dans une sorte de pensée unique de l’architecture.

Le chapitre 5 aborde la question du modèle d’organisation IT. Il est long de 35 pages. Il s’articule autour de l’abstraction OPR (Organization, Process & Resource). On parle bien là d’une vue projet, d’inspiration UP, avec même une inspiration Tayloriste plus marquée encore. On parle donc de responsabilisation avec le fantasme habituel qu’en disant aux membres des équipes ce qu’ils doivent faire et comment ils devront le faire, ils se sentiront responsabilisés. Passons, voulez-vous ?

Après l’organisation, c’est au tour du processus de développement d’être abordé au chapitre 6. Ce doit être important, car on lui accorde 46 pages ! Le processus se revendique d’inspiration UP et Catalysis. J’y retrouve en effet l’aspect directif de ce dernier sur ce qu’est et la manière de concevoir un composant. Le chapitre est une suite de description de workflows et des activités attenantes :

  • IT-Environnement
  • IT-Bar Business Modeling and Requirements
  • Project Management
  • Development Environnement
  • Configuration and Change Management
  • Analyse by Design
  • Implementation (enfin)
  • Test
  • Documentation
  • Deployment

Il y a donc à la fois plus de workflows et moins de sens que dans UP !

Le chapitre 7 est dédié à »l’architectural IDE ». Je ne vais guère m’étendre là-dessus. Il s’agit de 20 pages de pub pour l’outil développé au sein de la société dans laquelle travaille l’auteur.

Les 47 pages du dernier chapitre font suite au précédent : il s’agit d’un tutoriel mettant en œuvre l’outil pour suivre la démarche. Il n’y a pas trop à lire, car il y a pour l’essentiel beaucoup de copies d’écran. Pour moi, ce chapitre met surtout en avant que la démarche est extrêmement rigide.

L’auteur « réinvente » des concepts vieux comme Hérode (comme le « 3 tiers » !), avec son propre vocabulaire, tout en se désespérant que le reste du monde n’utilise pas le sien ! Les idées et les concepts sont expliqués de façon très floue. Difficile de comprendre ainsi le propos de l’auteur. Les quelques idées originales paraissent ubuesques, comme l’intégration gestion de projet / architecture métier / architecture technique, ou la métaphore de la shopping machine. Quand à la « convergent architecture », elle semble se réduire à l’utilisation des assistants de l’outil ArcStyler, même si les explications de l’auteur à cet égard sont également vagues.

L’auteur aurait mieux fait de consacrer 100 pages à développer les concepts et l’utilisation de arc styler, plutôt que de nous fatiguer avec des concepts vides de sens. Mon conseil ? Passez votre chemin !

image

Référence complète : Convergent Architecture, Building Model-Driven J2EE Systems with UML – Richard Hubert – John Wiley & sons 2002 – ISBN: 0-471-10560-0

Convergent Architecture: Building Model Driven J2ee Systems with UML

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