Note de lecture : Agile Conversations, par Douglas Squirrel & Jeffrey Frederick

Note : 5 ; Des cadres de conversation essentiels, mais difficiles à appréhender !

Les transformations agiles ne sont pas seulement le fait d’adoption de pratiques, elles passent par des conversations qui favorisent le changement de culture. C’est tout l’objet de ce texte. Il ne s’agit pas de n’importe quelles conversations, mais d’un processus, d’une progression entre 5 types de conversation.

Avec moins de 190 pages et un format réduit, il a tout d’une lecture légère. Mais il n’en est rien, la prose ne s’avale pas d’un trait. L’ouvrage est composé de 2 parties très inégales. La première a une nature plutôt introductive et ne compte que 2 chapitres totalisant 50 pages. Le premier d’entre eux, escaping the software factory est une simple introduction à l’agilité, au lean et au devops. Il a le mérite de poser les principes de ces 3 courants de pensée, avec une mention spéciale aux principes du devops que l’on ne rencontre pas souvent écrits. Le second chapitre « improving your conversations » est une introduction à la seconde partie. Les types de conversation décrits dans cette seconde partie obéissent tous au cadre des « 4 Rs » décrit ici. C’est pour faciliter les deux premiers Rs (record & reflect) que les auteurs utilisent le format de conversation sur 2 colonnes utilisé par la suite et détaillé ici.

La seconde partie propose 5 types de conversations qui forment autant de chapitres. Ils sont à prendre dans l’ordre, car ils forment un édifice où une conversation sert de base à la suivante. Le chapitre 3 nous propose la conversation de la confiance, qui est bel est bien la fondation de l’édifice agile. Le cœur de cette conversation est le « TDD for people », un cycle délimité par l’action et l’observation, mêlant croyance, hypothèse est sens. C’est un concept plutôt difficile à appréhender et plus encore à adopter. Prévoyez de le relire deux ou trois fois.

Lire la suite

Note de lecture : Introduction to Apache Flink, par Ellen Friedman & Kostas Tzoumas

Note : 3 ; Apache Flink pour les executives.

Voici un petit traité qui promettait d’en savoir plus sur Flink en 6 chapitres et à peine une centaine de pages. Le texte me laisse quelque peu sur ma faim, me donnant plutôt l’impression d’un ouvrage dédié aux « executives ».
Le premier chapitre cherche à répondre à la question fondamentale « pourquoi Apache Flink » en 18 pages. On y répond surtout au « pourquoi le streaming processing » dans la première moitié, mais le chapitre se rattrape un peu en donnant les clés du positionnement de Flink par rapport aux autres frameworks de streaming. Bienvenu également, la vue aérienne des API et des librairies sus-jacentes qui expose les vues « batch » et « streaming » de Flink. Mais ce chapitre présente surtout les différents cas d’usages dans différents domaines.

Le second chapitre est d’avantage consacré aux aspects architecture, et met en lumière l’articulation transport / processing. Au moins le propos clarifie l’importance de Kafka dans ce contexte. Mais il manque quand même cruellement de précisions plus concrètes : le reste du texte donne quelques schémas de très haut niveau et d’autres cas d’usage. J’aurais préféré une vision dynamique des fonctionnements en mode stream et batch.

Au chapitre 3, nous allons voir ce que Flink fait. Le sujet est abordé sous l’angle des caractéristiques du framework : gestion des fenêtres glissantes, des états et des « checkpoints ». Littéralement, le chapitre répond bien à ce que fait Flink, mais sans laisser transparaître « comment » il le fait ce qui est quelque peu frustrant.

Lire la suite

Note de lecture : More Fearless Change, par Mary Lynn Manns & Linda Rising

Note : 4 ; Un pattern language organisationnel, qui nous aide à réflechir aux tactiques de changement mais s’avère bien aride à lire !

Publié 10 ans après l’original, ce nouvel opus ne se présente pas comme une seconde édition. C’est pourtant ce qu’il est à mes yeux. Ce sont plusieurs dizaines de patterns organisationnaux qui peuplent les près de 300 pages de cet ouvrage. Car il s’agit bien d’un recueil der patterns, ou plus précisément d’un « langage de patterns » car ceux-ci sont liés les uns aux autre pour former une grande toile.
Je suis un afficionado des patterns de la première heure, mais je dois aussi avouer qu’ils engendrent des livres dont la lecture est plutôt austère. C’est l’objectif qui est aussi malheureusement atteint ici au long des 3 parties de cet ouvrage.

La première partie est aussi la seule à être explicitement découpée en chapitres, 5 en l’occurrence qui couvrent 25 pages. Point de patterns ici, mais les plus notables y sont référencés au sein de cette vue générale bien construite. N’hésitons pas à dire que c’est la partie la plus agréable de l’ouvrage. Chaque chapitre de cette partie adresse un aspect spécifique de la stratégie du changement : établir une stratégie, développer une vision, chercher de l’aide, cibler les résistances etc. Les quelques pages consacrées à chaque sujet sont autant de teasers.
La seconde partie ne compte que quelques pages au sein desquelles les auteurs développent deux histoires de changement. Cela faisait peut-être bien sur le tableau blanc mais tombe à plat une fois couché sur le papier. On aurait tout aussi bien pu s’en passer.

Lire la suite

Note de lecture : Apache Kafka, par Nishant Garg

Note : 3 ; Une introduction rapide (et hélas obsolète) mais qui ne vous conduira pas bien loin.

Si vous n’avez pas le temps, mais alors vraiment pas le temps, ce très court texte pourrait bien être pour vous. En quelques 88 pages et 6 chapitres, il vous met le pied à l’étrier sur la compréhension de base de Kafka. Ca, ce sont pour les bonnes nouvelles. Du côté moins glorieux, sachez que ce court texte est vraiment très mal noté un peu partout et qu’il y a de bonnes raisons à cela. J’ai obtenu cet ebook grâce à une offre promotionnelle de lot et je serais certainement allé dans le même sens si je l’avais payé plein tarif !

De plus l’ouvrage date maintenant terriblement. En 8 ans, Kafka est passé de la version 7 à la version 2.8, ce qui est énorme, sans compter l’écosystème qui s’est formé autour. Passons maintenant (rapidement) le contenu en revue. Le premier chapitre présente Kafka très rapidement. C’est fort succinct, mais au moins les concepts de base sont posés. Plus succinct encore, le chapitre 2 évoque l’installation de Kafka, mais seulement en version développeur / local. La compilation de l’outil est évoquée, mais cela ne parait pas spécialement pertinent, la même information est disponible en ligne.

Passons au chapitre 3 et à la configuration d’un cluster. Cette fois, c’est la version 0.8 qui nous sert de référence ! L’auteur passe en revue 3 configurations de complexité croissante et nous propose de les explorer en mode « hello world ». Bien sûr, on est très loin des informations nécessaires pour la production, ou même à un véritable développement, mais cela correspond au niveau d’information que je cherchais. Au chapitre 4, on nous promet de découvrir l’architecture de Kafka. Cela reste très haut niveau, du niveau décideur, mais là encore cela correspondait à mon besoin. On y évoque les partitions, le miroring et la réplication façon Powerpoint.

Lire la suite

Note de lecture : Conduire le changement, par John Kotter

Note : 8 ; La référence de la conduite du changement, et pour de bonnes raisons !

Les 8 étapes du changement de Kotter sont un grand classique. Cet ouvrage est en quelque sorte le guide de l’utilisateur de ces 8 étapes. La traduction française m’a fait un peu peur au début. Elle s’avère quelque peu laborieuse et franchement pas excellente, mais on échappe quand même aux problèmes de contresens qui peuplaient les traductions il y a 25 ans. C’est une lecture aisée, quoique moins rapide que ce à quoi je m’attendais, les nombreux exemples bien choisis aidant à rendre la lecture agréable.

Le volume est de taille raisonnable, avec 215 pages. Le découpage en douze chapitres regroupés en 3 parties aide à bien rythmer la lecture. La première partie est introductive, comme on peut s’y attendre. Il faut compter 40 pages et 2 chapitres pour celle-ci. Le premier d’entre-eux évoque les 8 erreurs conduisant à l’échec des transformations. Ces 8 erreurs, bien illustrées font directement écho aux 8 étapes du changement. Peut-être de manière trop flagrante. La véritable introduction est le chapitre suivant qui présente réellement les 8 étapes et justifie la nécessité de les suivre dans l’ordre prescrit.

Place à la seconde partie, le plat de résistance avec 8 chapitres sur plus de 140 pages. On s’en doutera, les 8 chapitres correspondent aux 8 étapes du changement du framework. C’est donc sans surprise que le chapitre 3 s’intitule « instaurer un sentiment d’urgence ». L’ennemi du sentiment d’urgence, c’est l’autosatisfaction, son allié : les crises ! L’auteur structure ce volet autour de 9 thèmes pour renforcer le sentiment d’urgence. L’ensemble est clair, concret et directement utilisable ! Au chapitre 4, c’est la formation de la coalition qui est au menu. Elle doit combiner management et leadership, avoir le bon niveau d’autorité et surtout être alignée sur un but commun.
Le chapitre 5 sur la création de la vision et de la stratégie nous apprend peu de choses. C’est un sujet assez récurrent et convergent pour qu’il y ait ici peu de surprise ou d’originalité. Toutefois, tout comme dans le reste du texte le propos est limpide et efficace. Moins galvaudé et pourtant fort utile, le chapitre 6 est là pour nous aider à éviter de rater le « dernier mètre ». J’ai particulièrement le volet « diriger par l’exemple ».

Lire la suite

Note de lecture : Turn Your Ship Around ! par L. David Marquet

Note : 7 ; Le management intentionnel en action, ou plutôt « en question ».

Ce petit opuscule est ce que l’on appelle parfois un « workbook », pour travailler et compléter à la maison ce que vous avez appris de la lecture de « Turn the Ship Around ». La similitude des titres donnait un indice sur le fait que ce titre venait compléter le précédent.

Le livre compte un total de 180 pages structurées en 29 chapitres très petits. L’ensemble est regroupé en 5 grandes parties. Il ne s’agit pas de 180 pages de texte. En fait il y en a même peu. Il s’agit pour beaucoup d’exercices introspectifs que l’auteur initie à partir de questions bien choisies. La plus grande partie de l’espace est donc en fait occupée par des lignes blanches ! Pour quelques exercices (peu en fait), l’auteur nous convie au visionnage de « Master & Commander » de Peter Weir. C’est sympa et original, l’auteur aurait pu le faire plus.

La première partie « mechanisms for starting over » regroupe 7 chapitres. Elle débute par un chapitre peuplé de questions destinées à identifier nos présupposés sur le leadership et à prendre du recul à ce sujet. C’est l’horizon de pensée et d’action du leadership qui est évoqué au chapitre suivant. La structure de récompenses / bonifications structure souvent celle-ci et l’auteur nous invite à considérer cet horizon comme allant au-delà du moment où l’on quitte l’organisation. « Care but don’t care » considère la manière dont nous aidons notre équipe à grandir tout en les laissant se débrouiller dans leurs tâches. Un point de vue qui me parle particulièrement.

Lire la suite

Note de lecture : Agile Game Development with Scrum, par Clinton Keith

Note : 5 ; Un texte honnête, finalement peu spécifique au domaine du jeu, mais qui accuse un peu son âge.

Pour une « simple » déclinaison de Scrum à l’univers du jeux, l’addition est un peu sévère avec ses 325 pages. Quand on regarde la date de publication, on voit qu’il date d’une époque où le sujet n’avait pas encore envahis chaque recoin de notre bibliothèque. Fort logiquement il reprend un certain nombre de basiques. Je pensais rentrer dans un univers très différent, mais c’est finalement peu le cas comme nous le verrons.

Le livre comprend 5 parties, pour un total de 16 chapitres. Belle bête, donc. La 1ère partie maigre d’une trentaine de pages sur deux chapitres est un avant-propos, au domaine du jeu et au développement agile. Le domaine du jeu est traité dans le chapitre introductif. L’auteur y aborde efficacement la course à l’armement des studios de développements conduisant à une crise du logiciel spécifique de ce secteur. La vingtaine de pages du second chapitre serait classique si l’auteur n’y avait introduit quelques concepts spécifiques du domaine du jeu : phases de pré-production / post-production et recherche du « fun », par exemple.

La seconde partie, avec ses 90 pages et ses 4 chapitres est plutôt indépendante du domaine concerné. Le chapitre 3 s’intitule sobrement « Scrum ». On y trouve sur ses 22 pages ce qu’on peut s’attendre à y trouver. Seuls les exemples sont empruntés au monde du jeu. La prose est bien écrite, avec quand même certains partis pris. Le déroulement du Sprint est au menu du chapitre 4. Là non plus nous ne trouverons une prose se démarquant réellement des grands classiques. Nous arrivons ainsi au chapitre 5 évoquant les user stories. Pas non plus beaucoup d’originalité ici également. On évoque longuement le « INVEST » comme à l’accoutumée. Plus original, le découpage hiérarchique des stories me laisse toutefois un peu perplexe. Enfin, l’agile planning n’est probablement pas mon sujet préféré, mais je dois avouer que le chapitre 6 qui lui est consacré est de bonne teneur. Il me rappelle quelque peu « agile estimating and planning » de Mike Cohn. C’est dire…

Lire la suite

Note de lecture : Refactoring to Patterns, par Joshua Kerievsky

Note : 6 ; Un grand sujet, traité avec acuité, mais parfois présenté de façon un peu fastidieuse !

Joshua Kerievsky est donc le premier à avoir franchi le fossé entre le refactoring et les patterns ! Nous devons lui en être reconnaissants. L’intérêt et l’expérience de l’auteur (notamment en tant que créateur du « new York patterns group ») l’ont conduit à aborder les patterns non pas comme des éléments initiaux de conception, mais comme des solutions à des problèmes, donc des éléments de conception émergentes, ce qui nous amène au refactoring ! La conception émergente via les patterns est le thème et l’intérêt central du livre et en font sa valeur.

Le sujet va nous occuper au long des 350 pages découpés en 11 chapitres que forme cet ouvrage. Au chapitre 1, l’auteur nous livre la démarche que l’a conduit à ce texte. En partant tout d’abord des patterns pour obliquer vers le refactoring et le cycle TDD, pour revenir enfin vers les patterns, pour améliorer la conception sans tomber dans l’over engineering. Le second chapitre est consacré au refactoring. Il ne s’agit pas là, en une douzaine de pages, de reprendre le propos de Martin Fowler, mais simplement de se focaliser sur l’intention et l’essence de cette démarche.

L’introduction aux patterns du chapitre 3 n’est ni vraiment utile, ni spécialement éclairante. Le chapitre est court mais assez vague sur la nature des patterns, le propos se concentrant plutôt sur l’histoire personnelle de l’auteur… Les Code Smells du chapitre 4 souffrent moins de ce défaut, Joshua Kerievsky nous gratifie ici des odeurs les plus rependues. Il s’agit plus d’un mini-catalogue que d’une introduction.

Lire la suite

Note de lecture : Modélisation de systèmes complexes avec SysML, par Pascal Roques

Note : 5 ; Succinct et fait le boulot, mais pas spécialement agréable à lire.

J’ai passé l’époque où j’avalais les bouquins de modélisation au kilomètre. Mais la modélisation système, domaine dont j’ignore tout attisait ma curiosité. SysML, c’était pour moi l’occasion d’assouvir celle-ci, car maîtrisant parfaitement UML, j’étais à peu près sûr de ne pas être largué. Objectif rempli de ce côté. Je connais les livres de Pascal Roques sur UML (j’en ai même lu plusieurs éditions successives), je suis donc aussi parti confiant sur la qualité de la prose.

Le livre en lui-même est court : 136 pages hors annexes (et presque 170 en les comptant. Le tout est structuré sur 10 chapitres en 4 parties. J’ajoute que les illustrations abondent (ce qui est normal pour un livre traitant de modélisation), autant dire qu’il s’agit d’une lecture rapide. Là aussi, cela me convient dans le principe. Avant même d’aborder la première partie, le premier chapitre introduit le sujet sur une quinzaine de pages. On y évoque les normes et organismes liés à la modélisation système et une ébauche très abstraite de SysML. C’est assez aride et finalement peu instructif, à part si on aime les normes.

La première partie comprend 3 chapitres sur un peu moins de 30 pages et a pour objet la modélisation des exigences. Elle s’ouvre sur un chapitre 2 qui adresse, tambour battant, les cas d’utilisation en moins de 10 pages ! La prose est claire mais ne peut couvrir le sujet en profondeur. Elle aborde néanmoins les relations d’inclusion et d’extension et même la généralisation qui est à peu près inutile à mon avis. Mais les explications sont vraiment succinctes. L’auteur insiste sur son dogme favori : la limitation de la modélisation à 20 cas d’utilisation, quitte à transformer les UC en sorte de thèmes. Une approche que je ne partage pas, tout comme la plupart des auteurs. Je trouve cavalier de présenter cela comme une vérité.

Le diagramme de séquence est traité encore plus rapidement en 7 pages. L’auteur parvient à bien illustrer et expliquer les subtilités de ce diagramme qui ne sont ni plus ni moins que celles d’UML 2.0 dans cet espace réduit. Je retrouve l’angle du cours Valtech et de « UML en Action » consistant à positionner le diagramme de séquence au niveau de l’expression des besoins, alors qu’il s’agit d’un usage particulier, voir détourné. Mais ce n’est pas grave. 7 pages encore pour le diagramme d’exigences qui est lui bien spécifique de SysML. Là aussi c’est efficacement expliqué et illustré, mais je suis un peu frustré par la brièveté du chapitre qui faisait partie de mes grandes attentes, certaines subtilités me semblant même passées sous silence.

Ce sont 3 chapitres également qui sont compris dans la seconde partie, consacrée à la modélisation d’architecture. Le diagramme de définition de blocs (BDD) a droit à une quinzaine de pages. Sans le nommer il fait le pendant au diagramme de classes d’UML. Là encore la prose est claire, le boulot est bien fait.

Près de 20 pages sont dédiées au diagramme de bloc internes (IBD) au chapitre 6. Il s’agit d’un sujet complexe avec des subtilités assez compliquées au niveau du concept de ports. L’auteur s’en sort plutôt très bien sauf quand on arrive sur les nouveaux types de ports de SysML 1.3 où le propos devient trop abstrait. Autre problème plus embêtant : ces diagrammes font apparaitre des subtilités au niveau de la notation graphique qui sont mal rendues au niveau de l’impression. Pour un aussi petit ouvrage vendu 35 €, c’est inacceptable. Le diagramme de package est couvert en 5 pages, mais il y a peu à en dire. Petit regret quand même sur les stéréotypes « model », « view » et « viewpoint » qui, à l’exception de ce dernier, sont mal expliqués.

Sans surprise, c’est la modélisation dynamique qui est au menu de la 3ème partie. Une quinzaine de pages sont dédiées au diagramme d’état. A l’échelle de cet ouvrage, c’est un gros chapitre. Je retrouve l’angle du cours Valtech (qui s’étendait sur 2 chapitres sur ce sujet) consistant à rentrer dans les plus petits détails de cette notation, jusqu’aux extraordinairement peu usités « deep history ». Il en est de même ici. Peut-être que SysML fait-il plus usage de diagrammes d’états que moi avec UML ? Disons simplement que tous les aspects de la notation ne sont pas logés à la même enseigne. Le chapitre 8 est un exemple du genre : il couvre sur 15 pages aussi les subtilités du diagramme d’activité en les introduisant progressivement. Beau boulot ! Tout comme au chapitre 6, la notation qui devient fouillée avec les concepts de flux est rendue difficilement lisible du fait de la médiocrité de l’impression.
La dernière partie traite de « modélisation transverse » sur 2 chapitres. Il s’agit d’aspects qui sont particuliers à SysML. Le chapitre 9 nous invité à découvrir le diagramme paramétrique sur 5 pages. C’est bien et clairement fait, même si je ne peux m’empêcher d’être frustré par la brièveté du chapitre : n’y a-t-il rien d’autre à dire ? C’est ce genre de sujets que j’étais venu découvrir. Le dernier chapitre est dédié aux concepts d’allocation et traçabilité. Il a droit à 8 pages, ce qui est plus qu’assez pour couvrir le sujet.

J’ai eu ce pour quoi j’étais venu. Je trouve toutefois le texte un peu court sur un certain nombre de sujets, mais l’efficacité du propos fait partie des qualités que je recherche : le plus gros investissement dans un livre, c’est le temps passé à le lire. Pascal Roques m’a habitué à une prose de grande qualité et je l’ai trouvé ici plus austère qu’à son habitude. Peut-être est-ce ma perception qui a changé ? Je connaissais les biais de modélisation de l’auteur, entre autres sur les cas d’utilisation. Nous avions déjà des « discussions de clans » sur ce sujet chez Valtech. Je vois que cette ligne n’a pas changé. Bref, un texte qui sans être enthousiasmant fait le boulot. Sauf pour le rendu des diagrammes.

Référence complète : Modélisation de systèmes complexes avec SysML – Pascal Roques – Eyrolles 2013 – ISBN : 978 2 212 13641 8

Note de lecture : The Professional Product Owner, par Don McGreal & Ralph Jocham

Note : 6 ; Une solide lecture pour le Product Owner, qui ne reste pas figée dans le dogme Scrum mais s’égare parfois un peu.

La Scrum.org s’est impliqué dans l’écriture de son corpus de connaissances et de pratiques. Le présent volume consacre celui dévolu au Product Owners. Comme nous allons le voir, c’est globalement une bonne surprise, même s’il nous embarque dans quelques hors sujets.

Les 320 pages du présent ouvrage sont découpées en seulement 9 chapitres structurés en 3 parties. Nous voilà donc embarqués dans des chapitres plutôt conséquents. La première partie « strategy » couvre 4 chapitres, soit un peu plus de 100 pages. Le premier chapitre est lui consacré à la gestion de produit agile. On y retrouve quelques poncifs habituels tels que le triangle de fer. Plus intéressant sont les propos sur les boucles de valeur et surtout les « roles type » qui offre une vue originale des profils de maturité du product ownership.

La vingtaine de pages du second chapitre va aborder la Vision. Le propos tourne autour de quelques pratiques désormais bien connues : le business model canvas, la product box et l’elevator statement. Le propos est bien ficelé, mais les habitués n’y découvriront pas grand-chose. Arrive le chapitre 3 et un sujet tout à fait épineux : la valeur ! Les auteurs lui accordent un peu moins de 40 pages. Les auteurs ont quelque peu du mal à trouver un angle, aussi commence-t-on avec « l’évidence-based management », ce qui a au moins le mérité d’introduire le sujet pour évoquer ensuite la satisfaction des employés et des utilisateurs (avec l’inévitable NPS). Après cela, ça part un peu n’importe comment en parlant budget, taux d’innovation, etc. Un chapitre qui n’est pas mémorable, sur un thème particulièrement difficile.

Lire la suite