Statistics are like bikinis. What they reveal is suggestive, but what they conceal is vital.
Aaron Levenstein
Auteur : addinquy
Software Freethinker
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 suiteNote 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 suiteDiscovering the unexpected is more important than confirming the known.
George Box
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 suiteNote 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 suiteNote 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 suiteYou cannot make informed decisions or create a quality product without first understanding why we are doing what we are doing. Lack of context creates waste.
Jim Benson
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 suiteNote 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
Software Freethinker 