Note de lecture : User Acceptance Testing, par Brian Hambling & Pauline Van Goethem

Note : 1 ; Une approche des tests à l’ancienne pour un texte récent et une cible complètement ratée.

Tests d’acceptation et User Acceptance Tests n’adressent pas pour moi la même finalité : Le premier est destiné à valider la conformité de ce qui a été réalisé par rapport à la spécification, tandis que le second se doit d’évaluer dans quelle mesure ce qui a été spécifié puis réalisé adresse l’expression de besoin initiale de l’utilisateur. Bref, l’UAT est là pour tester (indirectement) la spécification.

Il y a vraiment très peu de livres consacrés aux UATs. Celui-ci est en fait pratiquement le seul que j’ai pu identifier à ce seul thème. J’avais deux craintes avant même d’avoir ouvert ce livre : avais-je la même vu sur les UATs que les auteurs ? Et , étant donné l’origine très « corporate » du texte, n’allais-je pas rencontrer une approche très processus à l’ancienne ? Comme nous allons le voir, la réponse est hélas « oui » aux deux questions.

L’ouvrage n’est guère long, moins de 180 pages si l’on ne compte pas les inénarrables check-lists ou templates. Le tout est découpé en 10 chapitres pour reprendre son souffle. Moins de 20 pages en moyenne par chapitre, il n’en faudrait pas plus, car le style d’écriture n’est pas pensé pour être une partie de plaisir. Le premier chapitre n’a que peu à offrir, mais je m’arrête quand même sur deux points : d’abord le contexte considéré est bel et bien du cycle en V. Ensuite la définition du rôle de l’UAT semble correspondre à la mienne. Le second chapitre « the importance of UAT » en rajoute une couche sans apporter grand chose : toujours plus de processus, la contribution des différents rôles… tout cela est un peu creux. On revient sur la définition des UATs et cela deviens moins clair, entre la validation des spécifications et la satisfaction du besoin utilisateur. A ce stade, je doute que la distinction soit même claire pour les auteurs.

Lire la suite

Publicités

Note de lecture : Scrum Mastery, par Geoff Watts

Note : 7 ; Les postures Scrum Master, illustrées par du story telling.

Cela faisait déjà un moment que j’entendais parler de ce livre, il était temps de lui faire un sort. Comme son titre l’indique bien, ce volume traite du boulot et de la posture du Scrum Master, le texte n’explique pas Scrum (il y a bien 3 pages là-dessus en annexe, mais bon…). Le texte part du principe que la connaissance de Scrum est acquise. La démarche (car il y a une démarche de Scrum Mastery) sur laquelle s’appuie l’auteur emprunte l’acronyme RE-TRAINED. C’est sur cet acronyme que s’articule le livre. Il compte 270 pages, mais compte tenu du format et de la mise en page très aérée (sans compter la qualité de la prose, cela se lit très bien.

R, comme « Respected ». Cette partie compte 3 « patterns », ainsi que je les appelleraient. Je retiens principalement de cette partie la notion de confiance, et plus particulièrement de faire confiance à l’équipe. Je retiens aussi l’acronyme AID (qui nous vient du « Tao of Coaching ») : Action, Impact et Desired Outcomes.
Le E est pour « Enabling ». 3 patterns également ici. De cette partie, mon take-away sera le modèle de maturité proposé par l’auteur. Il aborde aussi le sérieux problème du proxy : l’auteur n’aime pas le concept.

Le T signifie « Tactful ». La « fable des 2 Scrums » en début de partie va servir de point d’ancrage à d’autres parties. L’auteur nous conduit également à utiliser les silences à bon escient, un art plus difficile qu’il n’y paraît et de poser les bonnes questions pour que l’équipe prenne elle-même conscience de ses travers.

Lire la suite

Note de lecture : Le Mini-Book Cynefin, par Greg Brougham

Note : 3 ; Malheureusement, introduit plus de confusion qu’il n’éclaire.

J’utilise beaucoup le modèle Cynefin pour introduire la notion de complexité lors de mes introduction à l’agilité. Ce mini-book était pour moi l’occasion de découvrir une manière de l’aborder et de comprendre le framework plus en profondeur. Au final il s’agit d’avantage pour l’auteur de promouvoir les outils de cognitive edge que de développer le propos de Dave Snowden. Malheureusement également, la traduction française m’est apparu très poussive. Heureusement que je possède aussi la version originale !

Le livre est plutôt court, avec 58 pages (un mini-book comme stipulé dans le titre), découpé en 5 parties. Le framework Cynefin expliqué en occupe une dizaine de pages. C’est probablement la partie la plus intéressante. Elle développe la différence entre systèmes ordonnés et désordonnés. Mais il termine toutefois avec des concepts dont je ne comprends pas tellement comment ils se raccrochent au framework comme « l’obliquité » (toutefois intéressant) et le résolution de conflits !
La seconde partie est consacrée au narratif. Il y est question du narrative inquiry. Là aussi je ne parviens pas à raccrocher cela au Cynefin, mais je note le concept, qu’il me faudra creuser.

En troisième partie, on parle de « sense making ». L’auteur y développe la notion de contextualisation à l’aide de logique abductives (si, si). Sur ce principe, il développe la contextualisation qu’il préfère au VSM (value stream mapping). On y propose aussi un exercice de contexte partagé à l’aide narratif. C’est en quelque sorte du teasing pour Cognitive Edge car on n’y comprends pas grand chose…

Lire la suite

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

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

Note de lecture : A Little Riak Book 2.0, par Eric Redmond & John Daily

Note : 2 ; Un livre à décoder plutôt qu’à lire !

Edité à compte d’auteur par un (gros) contributeur Riak, ce livre est assurément petit car il dépasse à peine la centaine de pages. Il n’a pas non plus d’ISBN ce qui est hélas un premier indice sur sa qualité éditoriale. Autant le dire tout de suite : elle est médiocre.

Je m’attendais à un petit tutorial pour mettre le pied à l’étrier. Si c’est effectivement la cible de ce texte, l’objectif est quand à lui bien raté. La prose fait de nombreux raccourcis qui nous font rater une bonne compréhension. Ainsi l’articulation entre bucket et bucket-type reste-t-elle nébuleuse. L’auteur semble parler de clés hiérarchiques mais … finalement non. Quand aux « rings » on en est encore à se demander comment cela fonctionne. L’ouvrage n’est pas dénué d’illustration ou d’extraits de code ou de configuration, mais c’est plutôt du matériel brut ne soulignant pas ce qu’il y a à voir. Bref : encore raté.

Le chapitre 1 est une courte introduction. Il liste les fonctionnalité de Riak 1 et met en évidence les nouveautés de Riak 2 avec des concepts qui ne sont pas expliqués, donc incompréhensibles. On est bien avancés. Le chapitre 2 aborde les concepts : ce devrait être le chapitre le plus intéressant. Mais là aussi les auteurs parviennent à introduire de la confusion. Il reste toutefois le chapitre le plus instructif.

Lire la suite

Note de lecture : Designing for Growth, par Jeanne Liedtka & Tim Ogilvie

Note 6 ; Bon sur le framework et le mindset design thinking. Mais le propos se perd parfois un peu en route.

Il y a finalement assez peu de littérature sur le Design Thinking. J’ai profité du MOOC avec le Pr Liedtka pour me plonger parallèlement dans cette lecture. C’est un beau livre, à l’impression bi chromique et comptant environ 200 pages auxquelles il faut ajouter les annexes. Découpé en 5 sections, il suit la logique des 4 questions qui structurent l’approche des auteurs..

Le texte s’ouvre sur une partie introductive de 2 chapitres totalisant 40 pages. Les 20 pages du premier chapitre tentent de répondre à la question « pourquoi le design ». Ce sont avec des histoires et des témoignages que des réponses sont apportées. C’est bien vu, même si cela n’apporte qu’une réponse partielle à la question. Le second chapitre de cette introduction est la « big picture » du framework : 4 questions et 10 outils. Aussi émaillé de témoignages, même s’ils sont moins percutants, le chapitre permet de s’approprier la logique de la démarche, mais pas l’essence.

La seconde partie du livre est consacré à la première question : « what is ? » sur 55 pages et 4 chapitres. Cette partie s’ouvre sur un chapitre consacré à la visualisation. Il manque cruellement de contenu concret, on reste dans la déclaration d’intention et les bénéfices attendu. Difficile d’y décerner une matière concrète avec laquelle rentrer chez soi ! Le chapitre 4 est tout l’inverse : s’il est succinct, il décrit parfaitement l’approche et le tout est brillamment illustré. Le value chain analysis est expédié à toute vitesse et c’est le « mind mapping » qui conclut cette partie. Ce mind-mapping n’est pas à confondre avec les cartes heuristiques. Il s’agirait plutôt de safaris pour partager et brain-stormer.

Lire la suite

Note de lecture : Kotlin in Action, par Dmitry Jemerov & Svetlana Isakova

Note : 5 ; Fait le boulot.

Kotlin est un langage de la JVM que je classe dans la catégorie des « better Java », aux côtés de Ceylon (qui hélas n’a pas encore d’ouvrage). Le parti-pris du langage est celui d’une très bonne intégration avec Java (le langage), la manière dont chaque concept se traduit et peut être utilisé de ce côté est un fil rouge du livre. Ce n’est pas celui qui m’intéresse le plus, mais c’est une fonctionnalité forte (et limitante) du langage, donc… L’autre parti-pris est de s’adosser à une version déjà ancienne de la JVM : Java 6, mais ce dernier point n’a pas d’influence sur le texte.

Il y a fort peu à dire de ce texte, ni en bien ni en mal. Il est plutôt sans surprise. Le texte est raisonnablement clair et les extraits de code font le boulot. D’un autre côté, pas de « waouh effect ». Avec 310 pages sur 11 chapitres regroupés en deux parties, on reste également dans le standard, bien que dans la partie haute.

La première partie « introducing Kotlin » compte 6 chapitres et couvre 170 pages. Le premier d’entre-eux se contente d’une quinzaine d’entre-elles. Il a pour but de faire le tour des caractéristiques principales du langage et de son positionnement. C’est bien écrit, mais on n’est en réalité pas tellement avancé. Par contraste, le chapitre 2 « Kotlin basics » et ses un peu plus de 25 pages font un bon boulot pour couvrir les bases du langage : déclaration de classes et de méthodes, les propriétés (et leurs petites particularités) ainsi que des structures de contrôle : boucles, switches, énumérations, etc. On couvre bien les base et c’est bien écrit.

Lire la suite