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 : Waltzing with Bears, par Tom DeMarco & Timothy Lister

Note : 6 ; La continuité de Peopleware, mais décevant quand même

Ce nouvel opus du binôme DeMarco – Lister est dédié à la gestion du risque, la « gestion de projet pour les adultes » comme le disent si bien les auteurs. L’originalité de ce court opuscule est l’approche « probabilistique » du risque, au contraire de la plupart des approches qui voient la gestion des risques comme un phénomène binaire.

Malgré la petite taille de cet opuscule qui ne compte que 175 pages, les auteurs sont parvenus à découper celui-ci en 5 parties pour un total de 23 chapitres ! Il faut donc s’attendre à ce que ces derniers soient plutôt courts. Le propos est par ailleurs assez dense, on le verra. La première partie tente de répondre au « pourquoi » de la gestion des risques, sur un peu moins de 30 pages réparties sur 4 chapitres. Elle s’ouvre sur un chapitre abordant l’attitude des projets par rapport aux risques, dont les auteurs nous assènent qu’ils doivent être vus comme des opportunités. Cela se résume bien par la citation d’ouverture : si un projet n’a aucun risque, ne le faite pas ! Au second chapitre, on découvre quelles sont les activités de la gestion de risque. Cela nous amène à comprendre que, ainsi que les auteurs l’énonce dans le titre du chapitre, que la gestion de risque, c’est en définitive la gestion de projet pour les adultes.

Le 3ème chapitre est un interlude, où l’absence de gestion de risque est illustrée via la gestion des bagages du nouvel aéroport de Denver. Un propos précis, agréable à lire et mettant en évidence les lacunes de gestion des risques. C’est un plaidoyer pour la gestion des risques qui enfin conclut cette première partie. Il liste en une dizaine de points les avantages à tirer d’une gestion des risques sérieuse.

Lire la suite

Note de lecture : Joel on Software, par Joel Spolsky

Note : 8 ; Inclassable, instructif et passionnant.

Aussi surprenant que cela puisse paraitre, ce livre est simplement la compilation des « posts » de Joel Spolsky sur son blog « Joel on Software ». Les textes n’en ont pas été retouchés, ni rallongés pas plus qu’ils n’ont été agrémentés. Ils ont simplement été mis en page, rassemblés en un livre avec table des matières, index, couverture, relire et tout et tout.

Donc ce que vous pouvez acheter sous forme de livre, vous pouvez le lire gratuitement sur le net ! Le livre, justement, couvre 45 posts regroupés en 4 parties (la 5ème est consacrée aux annexes). Les posts sont ainsi regroupés de manière thématique et la taille de ces parties est en conséquence inégale. La première partie va aussi s’avérer la plus longue. Elle regroupe 19 posts et cible les pratiques de développement (au sens large). 3 sujets ont attisé ma curiosité ici. La série de 4 posts sur les spécifications, d’abord. Elles contiennent les germes de la définition du PO mais révèlent aussi un point de vue pour moi dépasser : écrire pour limiter la communication entre les intervenants, et gagner en efficacité ! Le second sujet a trait au craftsmanship. Il est la prémices du mouvement du même nom, même si l’auteur ignore encore (ou volontairement ?) la culture agile naissante. Le troisième sujet est marginal et évoque le « biculturalisme » chez Microsoft. Un sujet qui explique bien des choses sur la société.

La seconde partie est consacrée à la gestion des développeurs et est riche de 9 posts. Le plus célèbre, et très souvent référencé encore aujourd’hui est « The Law of Leaky Abstraction ». Cette loi stipule qu’une abstraction de haut niveau, destinée à masquer une réalité de plus bas niveau, montrera des failles ou des faiblesses dans certaines conditions. Le corolaire de cette loi est qu’on ne peut se contenter de connaitre cette abstraction de haut niveau, mais qu’il est nécessaire de connaitre voir de maitriser le niveau sous-jacent, car il expliquera certains comportements de cette « abstraction qui fuit ». Je conseille aussi deux posts consacrés au recrutement et à la rémunération. Vous n’êtes pas obligés d’être d’accord avec l’auteur, mais au moins donnent-ils à réfléchir.

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