Note de lecture : Change your Questions Change your Life 3rd edition, par Marilee Adams

Note : 9 ; Un très bon ouvrage de coaching centré sur le questionnement.

L’art du questionnement un aspect clé, non seulement en coaching agile, mais aussi dans des activité comme le product management, j’en suis convaincu depuis longtemps. Jusqu’ici je n’ai trouvé que des outils assez ponctuels comme les « powerful questions » de Debra Preuss. Avec cet ouvrage, c’est une véritable approche structurée, le « question storming » qui nous est proposée.

Le texte est fort de 12 chapitres complétant 180 pages et d’un petit workbook en annexe regroupant les 12 principaux outils mis en œuvre dans le corps du texte. Les 12 chapitres ne sont pas individuels, si chacun comporte un thème, il s’agit en fait d’une histoire, celle de Ben Knight, manager fraichement promu par Alexa, chez QTech. Ben est en situation d’échec et s’apprête à poser sa démission. Une situation qui rappelle celle du « Phoenix Project ». C’est ainsi que nous faisons la connaissance du coach, Joseph S. Edwards, qui nous introduit au Question Thinking. Le Question Thinking, c’est trouver de meilleurs questions, des questions qui ouvrent de multiples possibilités, pour obtenir de meilleurs résultats.

Le chapitre 3 introduit le « choice map » dont le trait principal est l’opposition du « judger minset » et du « learner mindset ». Notre premier reflexe est celui de juger et cette carte est là pour nous aider à réorienter notre approche, du jugeant vers l’apprenant. Toutefois, comme nous l’apprends le 4ème chapitre, nous sommes tous des jugeants qui cherchent à s’en sortir. Aussi faut-il l’accepter et savoir repérer nos moments de jugements pour nous réorienter. C’est sur ce dernier point que se focalise le chapitre 6 : les question permettant de « switcher » du jugeant vers l’apprenant. Le chapitre 7 y ajoute un outil, le « ABCD process » pour questionner nos postulats.

Lire la suite

Publicité

Note de lecture : CoreOS in Action, par Matt Bailey

Note 3 ; Malheureusement je ne suis pas un ops…

Je voulais vraiment en savoir plus sur CoreOS. Chemin faisant, je savais que je risquais une lecture qui pouvait s’avérer ennuyeuse pour moi, sinon hermétique. C’est surtout la brièveté de l’ouvrage qui m’aura permis de survivre, le texte n’étant vraiment pas fait pour moi.

Bref, le texte l’est avec seulement 175 pages et 10 chapitres (donc des chapitres assez courts en moyenne). L’ensemble est divisé en 3 parties. La première d’entre-elle « getting to know CoreOS » comprends 3 chapitres. Et on commence bien sûr par une introduction au système, d’une quinzaine de pages. Cette introduction doit nous donner une image de haut niveau de CoreOS, qui un OS « statique », dont les composants majeurs sont fleet et etcd. Mais pour moi, l’angle est déjà bien trop « système ».

Les 18 pages du chapitre 2 sont consacrées à faire fonctionner CoreOS sur une machine de dev, dans un environnement Vagrant, lui-même dans une machine virtuelle VirtualBox. En sachant que ce n’est pas un mais 3 CoreOs que l’on souhaite faire fonctionner, cela donne une idée de la configuration : pas vraiment une partie de plaisir pour moi. Je sombre encore un peu plus au chapitre 3 « expecting failure » qui rentre dans les arcanes d’etcd, le tout pimenté de configuration Ngnix !

Lire la suite

Note de lecture : Implementing Domain-Driven Design, par Vaughn Vernon

Note 3 ; Quand implémentation rime avec confusion.

C’est un beau pavé de presque 600 pages que nous a produit l’auteur. J’avais pas mal d’espoirs sur celui-ci, en effet malgré l’ampleur du mouvement DDD suscité par Eric Evans, j’ai toujours eu pas mal de difficultés avec le niveau stratosphérique de son propos. Avec ce volume orienté implémentation, je pensais régler ce problème. Nous n’y sommes pas et il s’en faut de beaucoup. Certes il y a du code, quoique souvent avec des « leaky abstractions » : pourquoi donc le choix de la stratégie de persistance devrait-il influer le modèle du domaine ? On arrive au pire avec les « values object » où l’on dit à demi-mot qu’il s’agit d’un choix technique ! L’étude de cas n’aide malheureusement pas beaucoup : elle manque de vie, son propos est trop abstrait et bien que le choix du sujet soit très pertinent pour moi, j’ai eu toutes les difficultés à le suivre. J’oublie encore les interludes « cow-boy logic » sensés donner de la légèreté au texte, mais incompréhensibles pour les non-américains.

Le premier chapitre est en quelque sorte le « business case » du DDD. On n’y apprends pas grand chose mais au moins le texte est compréhensible ainsi que les extraits de code. Tout de même, 42 pages pour cela… C’est d’ailleurs la taille du second chapitre « domain, sub-domain & bounded-context ». Les 3 niveaux de structuration rendent le propos difficile à suivre et à mon avis d’une complexité non-nécessaire. De plus l’exemple choisi (identity & access control) n’est guère pertinent. Il en résulte que l’on sort du chapitre avec peu d’éléments pour déterminer la granularité du bounded context mais avec un gros mal de tête sur les notions avancées.

Le chapitre 3, context map est un court interlude qui évoque la projection d’un bounded context sur un autre. C’est intéressant sans être mortel. Polluer le propos avec du http ou du rest est non seulement inutile mais hors de propos. Malheureusement, c’est récurrent dans tout le livre. Contrastant avec cela, le chapitre 4 « architecture », c’est du sérieux avec ses 56 pages ! On y évoque différents types architecturaux comme le modèle en couche et l’architecture hexagonale d’Alistair Cockburn. Il évoque aussi le DIP qui n’est jamais que la même intention que l’Adapteur au centre de l’architecture hexagonale, ce qui ne semble pas effleurer l’auteur. Le CQRS est à peu près compréhensible, ce qui n’est pas le cas de l’Event-driven architecture, bien qu’il faille concéder une représentation intéressante intégrant l’architecture hexagonale. Le pipe and filter est juste évoqué et les « sagas » c’est à dire les transactions applicatives sont plus à décoder qu’à lire. L’Event-sourcing et les data frabric ont aussi doit à quelques mots. Dans l’ensemble le chapitre est bien trop long pour son contenu ?

Lire la suite

Note de lecture : Rupture Douce, saison 01, par Laurent Sarrazin edt.

Note : 3 ; Hétéroclite.

Laurent a invité de nombreux coaches à contribuer à cet ouvrage collectif. Il m’avait d’ailleurs invité également, je me suis contenté du rôle de relecteur. L’objectif était de constituer une grande fresque d’histoire de transitions agiles ou les propos des différents auteurs s’entremêleraient et se répondraient. Cela faisait d’ailleurs partie des contraintes de l’exercice : 3 références vers d’autres histoires.

En pratique, ce fut l’occasion pour nombre de ces coaches de se donner de la visibilité en inscrivant leur nom sur un livre. En soi rien de choquant : se rendre visible fait partie du business, je le fais aussi ! Malheureusement la fresque n’est pas si cohérente qu’on pourrait l’espérer : les histoires n’en sont pas toujours, le propos tourne assez régulièrement à l’auto-publicité dans des textes employant abondamment la première personne. Fort heureusement, la plupart de ces textes font moins de 10 pages, mais certains d’entre eux paraissent beaucoup, beaucoup plus longs ! Il faut dire que certaines productions, et malgré les relectures, manquent franchement de qualité rédactionnelle. C’est même parfois carrément pompeux, Claude Aubry a d’ailleurs haussé la voix lors des relectures à ce sujet.

N’allez pas croire que tout est à jeter. Il y a beaucoup de contributeurs à ce livre, des contributions courtes, je l’ai dit. C’est la bonne nouvelle : on a droit à beaucoup de variété et quelques pépites dans le tas. Je pense à Jean-Claude Grosjean et Damien Thouvenin, par exemple. Mais aussi à Axel Villechalane. Véronique Messager est égale à elle-même, mais Claude Aubry est un peu décevant lorsque l’on connaît ses qualités rédactionnelles.

Lire la suite