Note de lecture : Sooner Safer Happier, par Jonathan Smart

Note : 8 ; Passionnant et frustrant tout à la fois.

Jonathan Smart nous propose sa vue à 360° de la pensée Lean / Agile sur le développement de produit. Sa boussole est dans le titre : il faut délivrer plus tôt, de manière plus sécurisée en cultivant la joie (OK ma formulation n’est pas très heureuse. En fait l’auteur nous assène cette phrase jusqu’à la nausée (et en gras dans le texte pour faire bonne mesure) et au-delà. Et cela lui coûte 1 point d’un livre par ailleurs excellent, comme nous allons le voir.

L’ouvrage compte près de 400 pages pour 9 chapitres, ou plutôt 10 car il me faut y ajouter le chapitre 0 ! Le corps du texte est composé des chapitres 1 à 8 qui sont autant de thèmes où sont développés des anti-patterns puis des patterns. Revenons au chapitre 0 « how we get here », qui nous dispense un peu de perspective sur l’agile, le Lean et le devops en se focalisant sur leur raison d’être. C’est une introduction classique mais réellement bien faite.

Le chapitre 1 est consacré à « l’outcome ». C’est surtout pour l’auteur l’occasion de développer ce fameux « business value sooner, safer & happier ». Les anti-patterns présentent peu d’intérêt et le pattern se résume assez bien par le « focus on why, empower the how ». Un chapitre qui est surtout une déclaration d’intention. Le second chapitre « achieve big through small » attaque un thème qui m’est cher : découper un (gros) problème en petits morceaux. Il s’attaque également au super-gorille à la mode : l’agilité à l’échelle… en proposant le dé-scaling. Quand on y rajoute la « règle du 1 », j’ai l’impression de retrouver mes recettes personnelles !

On retrouve le combat contre l’agilité « à taille unique » au chapitre 3. Le propos y a moins de force et j’y retiens surtout les 3 types culturels de Westrum, mais la référence au « Shu Ha Ri » me plait aussi, bien sûr. Le chapitre 4 est dédié au leadership. Je classerais le propos dans les modernes / classiques. Si l’auteur centre bien le sujet sur la complexité, la posture promue reste celle du « servant leader », alors que nous sommes plutôt dans l’ère du leader créateur de leaders ou du host leader. Cela reste toutefois un bon chapitre.

Si le titre du chapitre 5 « construire les bonnes choses » est plutôt abscons, le contenu va retenir notre attention. Tout d’abord en abordant avec pertinence les value stream mapping, sujet souvent abstrait pour ne pas dire mal compris, puis la question du portefeuille, dans la continuité. Ensuite en promulguant le « triumvirat des rôles » à chaque niveau de l’organisation. L’idée peut être critiquable, mais elle se défend. On pourrait s’en doute, le chapitre 6 évoque le « bien construire les choses ». L’auteur y développe le concept de « safety team » qui peine à se démarquer de la désormais traditionnelle équipe pluridisciplinaire. Il est aussi question d’aligner l’équipe sur des values streams, un sujet mieux développer dans Team Topologies. Un chapitre honorable malgré tout.

Lire la suite

Note de lecture : Operations Anti-Patterns, par Jeffrey D. Smith

Note : 3 ; Verbeux et ennuyeux

La juxtaposition de « patterns » (ou anti-patterns) et devops avait tout pour attiser ma curiosité, bien que j’avoue avoir quelque peu foncé en aveugle sur ce livre. Comme nous le verrons, cela ne fut pas une très bonne idée car le texte prétend parfois avoir inventé l’eau chaude…

Avec 290 pages structurées en 12 chapitres, ce volume se situe dans la moyenne, la taille des chapitres aussi et ceux-ci ne sont pas trop longs. Le livre s’ouvre sur un premier chapitre « what is devops » plutôt sympathique à lire qui évoque le CAMS (culture, automation, metrics et sharing) comme les piliers du devops. C’est original par rapport à mes autres lectures, mais l’éclairage en vaut un autre. Le second chapitre est plus représentatif des chapitres suivants, c’est-à-dire un thème accompagné de patterns et d’anti-patterns. Ici il est question de « paternalisme ». Derrière cela il faut voir le mode guichet et les délais que cela occasionne. La solution promue est évidemment l’automatisation embarquant les vérifications automatisant « l’approbation ». Rien de bien nouveau.

Le thème du 3ème chapitre est la cécité opérationnelle : c’est-à-dire qu’opération et développement vivent chacun dans leur silo et que le développement ignore tout du comportement du produit en production. La solution est ici, cher captain obvious, les métriques et les logs ! Le développement part un peu dans tous les sens et reste hélas assez superficiel. Le chapitre 4 s’intitule « des données plutôt que de l’information ». Ce chapitre se démarque un peu des précédents en ne suivant pas la recette désormais habituelle. Il s’inscrit plutôt dans la continuité du chapitre 3 en évoquant la présentation des données de monitoring. C’est un peu inutile ou plutôt mieux traité ailleurs.

Lire la suite

Note de lecture : The Art of Agile Development, par James Shore & Shane Warden

Note : 4 ; Une prétention encyclopédique qui tombe un peu à plat.

Ce n’est certainement pas le premier ouvrage à nous parler de développement agile. Vu son âge vénérable, nous lui concèderons aussi de faire partie de la première génération de livres consacrés à l’agilité. Nous ne nous étonnerons pas non plus que la pratique se consacre à Extreme Programming, mais sans aucune velléité dogmatique pour autant.

Avec près de 400 pages presqu’exclusivement couvert de texte, l’ouvrage est particulièrement dense. Il a des prétentions bibliographiques, car en grande partie consacré à des descriptions de pratiques qui sont loin d’extreme programming en grande partie. En cela ce titre est particulier. Il est structuré en 3 parties et totalise 15 chapitres. La première partie, « getting started » regroupe les 4 premiers sur environ 65 pages. Elle débute par un chapitre nous aidant à répondre au « pourquoi » de l’agilité. Il n’y a guère de surprise ici. Il est intéressant toutefois de voir l’auteur articuler son propos à la croisée des succès techniques, individuels et organisationnels.

Le « comment » devenir agile ne réserve guère plus de surprises, moins même. Les quelques pages qui lui sont dévolues se concentrent sur le manifeste agile : les valeurs et les principes, sans entrer dans les détails. Les détails, ils sont pour le chapitre 3 qui couvre XP, ou plus exactement l’interprétation par l’auteur de XP. La description est déjà colorée de pratiques et de rôles qui n’appartiennent pas au corpus d’extreme programming. La méthode originale en est difficile à reconnaitre. Le chapitre 4 « adopting XP » permet mieux de reconnaitre la méthode et ses vecteurs d’adoption. A une différence de taille : la recommandation d’adopter XP pour les projets « page blanche » qui me semble à la fois réducteur et en décalage avec le monde réel.

Lire la suite

Note de lecture : Liespotting, par Pamela Meyer

Note : 5 ; Un tour d’horizon de la détection des menteurs qui est plutôt une introduction au sujet.

L’auteure est connue pour sa prestation TED sur la détection des mensonges. C’est d’ailleurs cette vidéo qui m’a conduit vers cet ouvrage. Mon objectif était de voir si je pouvais trouver là une compétence à développer à mettre dans la boite à outil du Product Owner. Ici, en fait, ce serait plutôt la boite à outils du manager qui serait visée.

Le livre est de taille raisonnable avec 250 pages dans sa version papier. J’avoue qu’il m’a paru plus court dans sa version numérique, je dirais dans les 200 pages équivalentes, voir un peu moins. Le texte est découpé en deux parties très inégales. La première « détecter la tromperie » est en fait le cœur du sujet et compte 6 chapitres. Le premier chapitre « une épidémie de tromperie » nous campe le décor : nous mentons quotidiennement, avec des conséquences plus ou moins importantes, alors que notre capacité de détecter la tromperie n’est ni plus ni moins celle des singes ! Le chapitre est clairement introductif et nous présente de nombreux exemples (bonjour Mr Kerviel) et nombreux faits pour étayer l’importance du sujet. Au second chapitre, nous abordons les bases de la tromperie. Il parait que cela commence tôt, dès la petite enfance ! On y voit aussi que les hommes ne s’en sortent pas grandis par rapport aux femmes, mais le chapitre nous donne aussi quelques informations sur les raisons pour lesquelles nous mentons, et envers qui. Bref, c’est instructif, mais pas encore ne mesure de nous alimenter sur le fond du sujet.

Au chapitre 3, il devient réellement question de détecter les menteurs en lisant les visages ! Et si le sujet remonte à Darwin lui-même, c’est à Paul Ekman que l’auteur va se référer sur le sujet. Partant des 7 émotions de base, l’auteur nous invite à rechercher les asymétries pour détecter les émotions feintes : micro-expressions, clignement de yeux, etc. Aux expressions du visage s’ajoutent les expressions du corps, sujet du chapitre 4. Ce sont les « big 3 » que nous allons chercher ici : les « emblèmes » qui peuvent contredire l’expression verbale, les « illustrations » qui tendent à se raréfier avec le mensonge et l’effet miroir, expression inconsciente de l’empathie, qui peut disparaitre dans le cas qui nous intéresse.

Lire la suite

Note de lecture : Lean Analytics, par Alistair Croll & Benjamin Yoskovitz

Note : 7 ; Un contrepoint au Lean Startup, pour suivre et piloter la croissance avec des métriques.

Le moteur de la Startup, c’est la croissance. Pour accomplir celle-ci, elle passe par plusieurs phases, mais aussi des ajustements, voir des virages radicaux de son positionnement de marché, de son business plan ou de son offre de service. Dans Lean Startup, il y a « Lean » et qui dit Lean dit amélioration et mesure. C’est de mesure dont il est question ici. Le livre évoque les métriques actionnables pour différents contextes et différentes phases des startups.

Ce volume fait partie de la « Lean Series » d’Éric Ries. C’est même un membre en bonne chair de cette série, avec près de 400 pages totalisant 31 chapitres ! Fort heureusement, le tout est rythmé en 4 parties. La première d’entre-elles « Stop lying to yourself » n’accuse qu’une quarantaine de pages pour 4 chapitres. Les deux premiers chapitres rentrent assez vite dans le vif du sujet en abordant les types de métriques (avec l’habituelle mise en garde contre les « vanity metrics ») et les différents tests permettant d’établir celles-ci. Les deux chapitres suivants de cette première partie se focalisent sur les décisions subordonnées à ces métriques. Mention spéciale aux 10 antipatterns sur l’usage des métriques en fin de cette première partie.

Avec 220 pages sur 15 chapitres, la seconde partie « finding the right metric for right now » est de loin la plus conséquente de l’ouvrage. Les deux premiers chapitres s’intéressent au quoi mesurer. D’abord, c’est en passant en revue les frameworks tels que les pirates metrics de McClure ou le « engine of growth ». Mais c’est surtout en ciblant le « One measure That Matters » ou OMTM, un concept qui sera récurent durant le reste de l’ouvrage.

Lire la suite

Note de lecture : The Passionate Programmer, par Chad Fowler

Note : 6 ; Juste une nouvelle édition actualisée et améliorée dans les idées développées dans le précédant ouvrage

J’ai une habitude, probablement détestable : je pénalise d’un point les secondes éditions qui sont justes aussi bonnes que les premières éditions ! Cette seconde édition de « My Job Went to India », car c’est bien de cela qu’il s’agit même si le titre a changé, subit cette règle de plein fouet. Comme nous allons le voir, si l’évolution du texte va au-delà du cosmétique, c’est surtout le changement de titre qui reflète mieux l’intention première du propos.

A format équivalent, cette nouvelle version, avec près de 200 pages en accuse 20 de plus que l’opus précédent. 5 nouveaux items sont apparus et 4 ont disparus (ceux du dernier chapitre), un bilan qui passe donc de 52 à 53 items. On retrouve les mêmes chapitres que précédemment, à l’exception du dernier qui a disparu. Donc, c’est 5 chapitres au lieu de 6. La première partie « choose your market » comporte 10 items au lieu de 9 précédemment, mais avec quelques changements. Mon item « à emporter » est le n° 4 : Be the worst ! Comme le disait Miles Davis, pour progresser, il faut choisir le groupe où l’on sera le moins bon joueur !

Lire la suite

Note de lecture : Practical Monitoring, par Mike Julian

Note : 7 ; Une brève et excellente introduction à l’univers du monitoring !

Quand il est question de monitoring, il est bien difficile de trouver un ouvrage ciblant d’autres publics que les ingénieurs systèmes. Pourtant, partie intégrante de nos systèmes d’information, il est bien utile sinon indispensable de comprendre ce que ce domaine recouvre, ces composantes, ces possibilités, les différentes composantes, etc. Non, ce que la plupart des ouvrages nous proposent, c’est de plonger directement dans les fichiers de configuration, nous laissant à nous autres, pauvres mortels, la difficile tâche de comprendre de quoi il en retourne. Ce livre comble exactement cette lacune. Attention, il reste technique, mais à peu près agnostique quant aux outils.

Le livre est bref également, avec à peine 140 pages. C’est à la fois dû à l’efficacité de la prose (qui est par ailleurs très agréable à lire) et au caractère introductif du texte. L’ensemble se décompose en deux parties, pour un total de 11 chapitres. La première partie se contente de 4 chapitres pour un total de 55 pages et couvre les principes du monitoring. Elle débute de manière originale par un premier chapitre sur les anti-patterns, ici au nombre de 5. La plupart d’entre-eux nous alerte sur un focus trop porté sur l’outillage en premier lieu, alors que sa mise en place doit être guidé par l’usage et les feedbacks escomptés. On commence bien ! Fort logiquement, le second chapitre est consacré aux patterns. Ils sont au nombre de 4 et le plus important d’entre-eux, régulièrement rappelé dans la suite du texte, est de débuter par la perspective utilisateur. Voilà qui nous change des ouvrages purement techniques sur le monitoring.

Le 3ème chapitre a une perspective résolument processus, on n’y parle presque pas de monitoring : il s’agit de la gestion des incidents et des alertes. La coloration de ce que nous propose l’auteur ici est d’avantage ITIL qu’agile, mais un ITIL un peu agilifié quand même. Enfin, et c’est une surprise, le chapitre 4 nous propose une courte introduction au minimum vital des concepts mathématiques et statistiques nécessaires pour comprendre les indicateurs. Bien vu.

Lire la suite

Note de lecture : Prometheus: Up & Running, par Brian Brazil

Note : 4 ; Une approche “culture système” avec des allures de manuel de référence qui ne facilite pas la compréhension globale.

La littérature sur Prometheus est fort maigre, malgré le poids qu’a pris ce système de monitoring, porté entre autres par le cloud en général et par la percée de Kubernetes avec lequel il s’intègre parfaitement, en particulier. Cet ouvrage vient combler cette lacune. Comme nous le verrons, il s’adresse avant tout à un public orienté « opérations », qui manque singulièrement d’une vue en grand.

Pourtant l’auteur n’a pas été avare : l’ouvrage compte 350 pages an 20 chapitres structurés en 4 parties. La première d’entre elles, l’introduction ne compte que 2 chapitres sur 35 pages. Cela débute par une présentation de l’outil. On y dresse le paysage du monitoring, les fonctionnalités attendues pour arriver sur l’architecture de l’outil lui-même. Un chapitre très instructif. On plonge directement dans l’exercice préféré de l’auteur dans les premiers pas proposés au chapitre 2. Certes on voit comment installer le produit et commencer à l’utiliser, mais en alignant les commandes, sans perspective ni contexte. C’est assez frustrant.

La seconde partie traite du monitoring des applications. Elle compte 4 chapitres sur environ 55 pages. Il est d’abord question d’instrumenter les programmes au chapitre 3. Via de courts exemples en Python, on voit comment mettre en place les différents instruments (compteur, gauge, buckets, etc.) et comment configurer Prometheus pour les récupérer. C’est super-basique mais cela fait le boulot. C’est toujours côté client que le chapitre 5 se situe en passant en revue les modes d’exposition et ce en différents langages. Le texte est à mi-chemin entre le guide d’utilisation et le manuel de référence, il lui manque une vue de haut niveau des cinématiques de scrapping.

Lire la suite

Note de lecture : Monitoring Taxonomy, par Dave Josephsen

Note : 3 ; Plutôt qu’un livre, un catalogue pour éveiller votre curiosité.

Le monde du monitoring est plus complexe qu’il n’y parait de prime abord. Non seulement il adresse des finalités très différentes allant des ressources systèmes, infrastructure et réseau jusqu’à l’expérience utilisateur, mais il prend en compte des aspects et des fonctionnalités variés : indicateurs, évènements, découvertes de services, tableau de bord et reporting, pour citer les principaux.

L’objectif de court opuscule d’une soixantaine de pages est d’organiser ce paysage en proposant une taxonomie (d’où le titre) où l’auteur va classer les outils de marché. Bref il s’agit d’un catalogue. Pour être précis, il s’agit de la mise en forme rédigée d’un catalogue disponible et mis à jour sur GitHub. Cela explique d’une part le côté un peu rugueux du texte sur lequel je reviendrais et le fait que ce catalogue soit promis à l’obsolescence. Hélas pas de mise à jour publiée ni en vue à ce jour, pour ce texte.

L’explication de la taxonomie, c’est le sujet du premier chapitre qui tente de l’expliquer en 6 pages. Il utilise 3 axes de classification que je ne développerais pas ici, mais qu’il est bien difficile de comprendre (à part l’axe « modèle de pricing » qui est classique) quand on débarque juste de sa campagne et que l’on n’est pas bien au fait du domaine du monitoring. Car en fait le texte est bel et bien fait pour ceux qui nagent déjà dedans. Rugueux, je vous dis.

Lire la suite

Note de lecture : Kubernetes: Scheduling the Future at Cloud Scale, par David K. Rensin

Note : 1 ; Plaquette commerciale Kubernetes

Vous allez dire que j’aurais dû me méfier vu la maigreur de l’opuscule (38 pages) ? C’est vrai. Pour autant, cela peut suffire pour avoir une vue aérienne et une première approche de l’outil. La vue aérienne est assez bien couverte par le premier chapitre, « go big or go home ». Sauf qu’en fait, ce n’est pas le premier chapitre. Le premier est une introduction où l’auteur parle essentiellement de lui : une totale perte d’espace pour un opuscule qui n’en a déjà pas de trop. Revenons à ce premier chapitre qui est en fait le second. Il introduit correctement les concepts de base : conteneurs, nodes, pods… C’est quand même bien succinct et on ne voit pas très bien comment tout cela fonctionne et communique ensemble !

Le second chapitre traite d’un aspect important : les labels et les annotations. L’auteur nous en parle mais en omettant complètement de nous dire comment cela était assigné, comment cela fonctionnait. Bref on sait juste que cela existe et que cela peut être requêté, même si on ne sait pas comment ni dans quel but. Il faudra raccrocher cela avec l’idée évoquée qu’il faut traiter les serveurs comme du bétail et qu’ils peuvent être détruits et créés à la volée. On voit confusément la relation et l’auteur nous laisse nous débrouiller avec cela. On saute du coq à l’âne avec le réplication contrôler, les services, le scheduling des pods, etc. Cela aurait mérité un autre chapitre, car il n’y a pas vraiment de rapport. En fin de compte, beaucoup de concepts sont effectivement évoqués, mais fort mal introduits et sans aspects concrets pour bien comprendre chacun d’entre eux.

Le dernier chapitre évoque les différents modes de déploiements : sur machine virtuelle, sur serveurs dédiés ou en service managé sur le cloud. L’auteur travaille chez Google, aussi est-il à l’aise pour dire que cela marche bien sur GKE. C’est sans aucun doute vrai, même si en 2021, les 3 grands clouds n’ont plus de problèmes là-dessus.

Lire la suite