Mois : février 2020

Note de lecture : L’art de devenir une équipe agile, par Claude Aubry, illustré par Etienne Appert

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Une réussite !

Je pense qu’à un moment donné, Claude Aubry en a eu marre d’être enfermé dans Scrum. Au bout de 5 éditions de son best-seller, on le serait à moins. Ici c’est de culture agile dont il est question (bien que le cadre s’appuie très fortement sur Scrum).

Le format de l’ouvrage est atypique : la taille est large mais ne compte que 170 pages, bien que le grammage du papier laisse penser qu’il en contient 250. L’impression est bichromique, mais surtout les illustrations d’Etienne Appert se taillent la part du Lion. On aurait presque l’impression de lire « Martine s’essaie à l’agilité ». Si le texte de Claude forme la portion congrue (bon j’exagère un peu), il a en fait déployé tout son talent, car on savait déjà qu’il savait écrire, pour condenser son propos en peu de mots sans qu’il en coûte en fluidité de lecture. Un magnifique tour de force !

Le texte compte 7 chapitres et débute par une question cruciale : pourquoi devenir agile ? On y parle valeurs et principes, raison d’être et sens, le tout saupoudré d’un peu d’historique. Mais on y évoque aussi le faux-agile et une démarche pour réellement devenir agile s’appuyant sur l’agile fluency. Le tout est abondamment illustré, d’images mais aussi d’exemples, avec les « lapins agiles ». C’est excellent.
Le second chapitre aborde la question cruciale de l’équipe. Et l’auteur de nous proposer l’acronyme TAPIS pour résumer les propriétés d’une équipe agile. Claude Aubry aura été très créatif en acronymes tout au long du livre et ils sont très bons. Claude, c’est un peu notre Mike Cohn français. L’auteur s’appuie sur Scrum pour aborder les rôles dans l’équipe, alors même qu’il nous avait dit qu’il serait agnostique. L’angle se défend car l’alternative serait d’être trop abstrait. J’aurais aimé deux mots sur « compétences versus rôles », mais j’accorde un bon point à la section consacrée à la confiance. Encore une fois le chapitre est remarquable de clarté et d’efficacité, mais c’est vrai pour tout le livre.

Lire la suite →

Note de lecture : Production-Ready Microservices, par Susan J. Fowler

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Une vue bien trop généraliste des microservices depuis un point de vue « ops ».

J’étais impatient d’entamer la lecture de ce petit volume (il compte 130 pages pour sa partie principale). En effet bien qu’il s’agisse d’un texte de plus sur les microservices, il le fait avec une optique « ops » sous la plume de Susan Fowler, à l’époque SRE chez Uber. Dès l’avant-propos, l’auteur nous prévient : on ne rentrera pas dans les détails ici qui nous conduiraient trop loin. Il s’agit de poser les principes généraux et génériques qui permettent l’opérabilité d’une architecture microservices.

Pour mener à bien cette mission, le livre est découpé en 7 chapitres plus 2 annexes. L’entrée en matière s’intitule sobrement « microservices » et pèse 25 pages. Elle ne détaille pas les principes d’un microservice à la Sam Newman. Ici, il est plutôt question de scaling et surtout de présenter le modèle en 4 couches de l’écosystème microservices, qui servira de trame aux différents chapitres. Le chapitre 2 construit pour sa part la structure des chapitres restant, en évoquant la notion de « production ready ». Pour Susan Fowler, cela regroupe un ensemble de propriétés : stabilité, fiabilité, scalabilité, tolérance aux pannes, performance, monitoring et documentation. C’est déjà ici que l’on perçoit le regard du SRE : l’auteur prône la standardisation en toute chose ! Certes, elle évoque la promesse d’hétérogénéité prônée par l’approche microservices mais préfère refermer celle-ci au nom de l’opérabilité !

Le chapitre 3 s’attaque à la stabilité et à la fiabilité, les deux premières propriétés évoquées au chapitre précédent. La cible du propos est d’abord la standardisation des cycles de développements et du pipeline de déploiement. Bien que le terme « standardisation » me donne des frissons, j’appuie le propos développé ici. Un bon point pour le développement des environnements de stagging, partiel ou complet que je trouve pour la première fois bien évoquées ici. Scalabilité et performance sont au menu du chapitre 4. Le propos reste très général sur la notion de scaling, abordant les aspects qualitatifs et quantitatifs, ainsi que la gestion des ressources contraintes. Le capacity planning est brièvement abordé, j’attendais mieux d’un livre labellisé ops. L’efficience du modèle de tâches, du choix du langage ou des caractéristiques des bases de données sont tout autant mentionnées. Un chapitre décevant et frustrant.

Lire la suite →

Note de lecture : The Cathedral & The Bazaar, par Eric S. Raymond

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Un texte historique, mais qui a mal résisté à l’assaut du temps

Voici un livre assez court : environ 200 pages en petit format. Il tire son titre du premier essai de ce volume qui en compte 4. J’ai parié l’avoir fini rapidement, j’aurais perdu !

Le premier essai est une sorte de mise en bouche : « a brief history of hackerdom » compte seulement 19 pages. Ce prologue retrace l’histoire des hackers ou des « real programmers » auxquels l’auteur les assimile. Le vrai hacker refuse de se laisser enfermer dans une logique de vendeurs. Ainsi Eric Raymond ancre cette culture au début des années 60 au MIT avec le rejet du PDP-1. A la fin des années 60, puis au début des années 70, ce sont Arpanet et Unix qui seront le vecteur de cette culture. Cette première vague sera émoussée par les Unix propriétaires (et Microsoft, l’incarnation de Satan pour l’auteur), pour renaitre avec Linux et l’explosion du Web.

La cathédrale et le bazar est un article long de 42 pages consacré à l’open-source. Il ne se lit pas aisément. C’est la révolution Linux qui a inspiré cette métaphore à l’auteur, une révolution sociale plutôt qu’une révolution technique qui permit d’amener l’open-source à un niveau d’échelle qui ne semblait pas imaginable. Mais les deux tiers de cet article sont consacrés à l’un des projets open-source majeur de l’auteur et des enseignements de son histoire : Fetchmail. Ce sont 19 enseignements qui nous sont distillés au fil des pages, concernant aussi bien l’implication de la communauté, la manière de penser le design et de réutiliser le code que sur la manière de de faire émerger la roadmap. Finalement l’auteur analyse les conditions nécessaires au succès.

Lire la suite →

Note de lecture : Building Evolutionary Architecture, par Neal Ford, Rebecca Parsons & Patrick Kua

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; De bons moments mais des considérations bien trop générales la plupart du temps.

Je suis en grand fan d’architecture émergentes. Je n’avais pas de doute sur le fait que ce texte allait alimenter mon enthousiasme. Finalement, le livre refermé, le sentiment est mitigé. Nous allons voir pourquoi.

L’ouvrage est un format court, il ne compte que 164 pages sur 8 chapitres. Le premier chapitre compte une quinzaine de pages et couvre surtout des généralités. D’une part on y évoque les « ilités » et de l’autre la question de la conception émergente et pourquoi les auteurs préfèrent le terme « évolutionnaire ». Bref, il s’agit surtout de généralités. Le second chapitre aborde une notion très conceptuelle, celle de « fitness function », une notion que l’on retrouvera au fil des pages. L’idée est intéressante, à savoir établir une formule combinant les différentes propriétés attendues de l’architecture dans des proportions correspondant à nos attentes. La pratique est beaucoup plus floue, avec des concepts tels que « holistique » versus « atomique » …

Le chapitre 3 est bien plus conséquent, car il compte une vingtaine de pages pour évoquer la question des changements incrémentaux. Le cas d’utilisation choisi « penultimate widget » est bien abstrait, je n’ai pas compris ce que cela faisait (apparemment, ce n’est pas le sujet). Évidemment, il est question ici de pratiques devops et de déploiement continu, mais pas seulement. On évoque aussi la testabilité et de nouveau les fameuses fitness functions. Ce n’est pas mon chapitre préféré. On arrive aux choses sérieuses avec le chapitre 4 traite de « couplage architectural ». D’ailleurs le chapitre compte 35 pages. Tout d’abord la notion de « quanta architectural » définit la plus petite unité déployable indépendamment. Autant dire qu’il est gros pour le monolithe dont les auteurs se moquent à loisir. Le « monolithe modulaire » abordé ensuite (et rarement évoqué) mérite nettement moins de risées. Suivent : Micro-kernel, EDA, SOA, Microservice et serverless !

Lire la suite →