Note de lecture : Agile Software Development with Distributed Teams, par Jutta Eckstein

Note : 3 ; Très loin de ce que j’espérais…

Sans jamais avoir lu aucun de ses livres, mais en ayant croisé son nom à de multiples reprises, j’avais mis beaucoup d’espoirs dans le texte de Jutta Eckstein. La caution « Dorset House » ajoutant encore un peu à cela. Une attente d’autant plus importante que la fameuse mode du « scaling agile » ne donne rien de réellement convainquant, la plupart des approches misant sur le processus plus que sur le savoir-être agile.

Hélas, ici encore, c’est surtout de processus qu’il est question ! Le corps du texte tient en 220 pages, constitué en 10 chapitres. On ouvre le bal avec « getting started » qui campe la structure du livre en 5 pages. Passons. Au chapitre 2 « assessing agility and distributed projects », l’auteur nous présente sur une quinzaine de pages des généralités sur les différentes catégories (structures) de développement distribué d’une part et les bases de l’agilité d’autre part. Certainement utile et bien écrit pour des débutants mais je n’y ai rien appris.

Le 3ème chapitre « building team » est plus conséquent avec 25 pages. On y fait la différence entre la feature team (équipe pluridisciplinaire à un seul endroit) et l’équipe dispersée où les compétences nécessaires à une réalisation sont réparties sur plusieurs localisations. Si l’auteur insiste à juste titre sur la nécessité de se connaître sur le plan individuel, j’ai été plus déçu par le focus important donné aux rôles qui occupe la dernière partie du chapitre.

Lire la suite

Publicités

Note de lecture : Re-Engineering Legacy Software, par Chris Birchall

Note : 3 ; Une expérience vécue solide pour l’auteur, mais un peu léger voir naïf pour un livre !

Dans l’ensemble, l’auteur s’est contenté d’évoquer ses quelques expériences (surtout une en fait) de travail sur du code Legacy. Certes, l’expérience est assez solide, mais présente aussi d’importantes lacunes dont je parlerai, je pense surtout aux tests.

L’ouvrage en lui-même n’est pas un jour sans fin : il compte 200 pages, réparties en 3 parties qui totalisent 10 chapitres. La première partie « getting started » comprend 2 chapitres qui comptent pour 45 pages. Au premier d’entre-eux, « understanding the challenges of legacy projects », on fait le point sur une douzaines de pages sur les problèmes rencontrés sur du legacy. Des problèmes que l’on connaît fort bien, ce ne sont donc pas des découvertes, le sujet est même traité un peu façon « tarte à la crème » !

Avec une trentaine de pages, le second chapitre « finding your starting point » est plus conséquent. La stratégie apparaît quand même étonnante et même peu pertinente : on y évoque de l’exploratory refactoring (donc du refactoring sans filet ) et l’usage des outils de métrique comme PMD. Mais point encore de tests qui justement me semble le bon point de départ !

Lire la suite

Note de lecture : Startup Growth Engines, par Sean Ellis & Morgan Brown

Note : 5 ; Il ne dit pas tout…

Sean Ellis est à l’origine du terme « growth hacker ». Cet ouvrage s’inscrit dans la continuité de cette approche. Ou plutôt, elle en est la déclinaison pratique par l’exemple : ce sont 10 entreprise dont les facteurs de croissance spectaculaire sont analysés, décortiqués ici. C’est en reconstituant l’histoire de ces startups que l’auteur nous montre précisément le ou les facteurs qui n’ont pas donnés les résultats escomptés et les changements qui ont provoqué le décollage et pourquoi.

On commence avec Yelp! Pour les auteurs, le site de recommandation a su démarrer au niveau local pour assurer son assise dans la baie de San Francisco jusqu’à y devenir incontournable. Yelp! A aussi su éviter la dérive pub : le focus a toujours été l’utilisateur, ne pas biaiser les avis en fonction des annonceurs, récompenser les bons comportements et promouvoir les « Yelp Elite » qui tractent le site par la qualité et la quantité de leurs notations. Un moment important fut le pivot des recommandations d’amis vers le partage de revues, en 2005. Yelp! A gagné son pari d’influer les commerces plutôt que l’inverse, mais s’est aussi embarqué très tôt sur la vague mobile.

Github a été créé en 2008, et est devenu depuis le Mammouth de l’open-source (provoquant même la disparition de certains acteurs historiques). Au départ, Github se veut une solution au problème de collaboration que Git adresse mal. Il devient une plateforme de choix pour cloner des repo, proposer des évolutions, bref collaborer, justement. Grâce à cela, Github a très tôt formé une communauté d’ingénieurs chevronnés, noyau d’un « effet réseau ». L’un des facteurs déterminant fut le modèle « freemium » qui n’a pas cannibalisé le modèle payant. Au final, le produit devient très addictif et les utilisateurs fidèles.

Lire la suite

Note de lecture : The Thin Book of Appreciative Inquiry, par Sue Annis Hammond

Note : 6 ; Fin, il l’est. Clair aussi, et également frustrant.

L’appréciative inquiry est en quelque sorte le petit frère du Solution Focus. L’objectif était bien pour moi une lecture rapide sur le sujet. Avec 49 pages, ce volume m’a semblé tenir ses promesses. Passé l’introduction (qu’est-ce que l’appréciative inquiry ?) le reste du livre (environ 35 pages) est divisé en 3 grandes parties. Chacun est tout à fait clair sur son objectif et son contenu.

La première partie est consacré aux 4 suppositions qui forment la base de l’approche.

  • Dans chaque organisation, société ou groupe, il y a quelque chose qui marche.
  • Ce sur quoi nous nous focalisons devient notre réalité. C’est le langage que nous utilisons qui façonne notre réalité.
  • La réalité est créée sur le moment, et il y a de multiples réalités.
  • L’acte de poser une question sur un groupe ou une organisation influence celle-ci d’une certaine façon.
  • Les individus ont d’avantage confiance dans le futur quand ils embarquent une partie de leur passé. Donc, il est préférable que ces parties soient les meilleures de notre passé.
  • Il est important de valoriser les différences.

Lire la suite

Note de lecture : The Leader’s Guide to Adopting Lean Startup At Scale, par Eric Ries

Note : 5 ; Des outils pour le Lean Startup

Après la publication de « The Lean Startup », Eric Ries cherchait un second souffle, une nouvelle étape de maturité dans la mise en œuvre du Lean Startup. Ce livre s’en veut l’incarnation. Le livre lui-même est une expérimentation : disponible uniquement via kickstarter, je fais partie des heureux élus à en posséder un exemplaire.

Le livre est de belle facture : couverture dure, et 360 pages imprimées en 2 couleurs. Le texte lui-même est découpé en 2 parties, chacune comptant 4 chapitres. La première partie s’intitule « process ». Elle débute par un rappel sur ce qu’est le Lean Startup. Le propos s’entrecroise de sections « tools », « coach guide » et d’histoires issues des coachings de l’auteur (General Electric y tiens une place importante. Mais j’y reviendrais.

Le second chapitre nous rapproche de l’utilisateur, à la recherche de preuves et d’observations plutôt que de leurs assertions. On touche bien là l’esprit Lean et le contenu de ce chapitre nous rapproche aussi du « Running Lean » d’Ash Maurya. Au troisième chapitre, on procède à un gros coup de zoom sur le MVP. L’auteur veut rattraper l’incompréhension sur ce concept issu de son précédent ouvrage. Pour se faire, il développe deux idées principales qui y sont subordonnées :

  • Retirer du MVP tout ce qui ne contribue pas à l’apprentissage que l’on recherche.
  • Associer le MVP à le démarche de construction et de validation d’hypothèses. Là encore une démarche qui nous rapproche du propos d’Ash Maurya.

Lire la suite

Note de lecture : The Phoenix Project, par Gene Kim, Kevin Behr & George Spafford

Note : 7 ; Une histoire autour des principes Lean et Devops, dans la veine de « The Goal » d’Eli Goldratt.

Un hasard bienheureux m’a fait lire ce livre dans la foulée de « Turn The Ship Around ! ». Ce livre, c’est l’histoire de Bill. Bill hérite d’un poste de manager dont il ne veut pas, celui de VP des opérations. Ce livre est donc un roman, plutôt bien écrit qui plus est. Il amène Bill d’un poste de manager dont il n’a pas voulu à celui de « chief operation officier », conseillé en pointillé par Erik, qui deviendra son mentor.

Le style narratif, les personnages et le fil de l’histoire ne sont pas sans rappeler « The Goal » d’Eli Goldrath. Les auteurs ne s’en cachent guère, et le texte n’est pas un plagiat pour autant, car ce sont d’autres savoirs et d’autres découvertes vers lesquelles veulent nous emporter les auteurs.

Parmi les idées fortes du livre, il y a les « 3 voies » :

  1. Comment créer un flux de travail rapide.
  2. Raccourcir et amplifier la boucle de feedback, pour fixer la qualité à la source.
  3. Créer une culture de l’expérimentation et de l’apprentissage.

Lire la suite

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

Note 10 ; Eclairé, passionnant et inspirant ! Book of the year 2016 !

Encore un livre qui prenait benoitement la poussière sur une de mes étagères, attendant de propices vacances pour être enfin lu. Eh oui, j’ai attendu 3 ans pour un livre qui méritait d’être dévoré aussitôt ! Cet ouvrage est assez atypique, non seulement parce qu’il a été écrit par un militaire, un commandant de sous-marin nucléaire, mais parce qu’il associe le narratif de la préparation au déploiement du sous marin avec les principes de leadership que veut promouvoir l’auteur.

David Marquet nous invite à découvrir un nouveau type de Leadership : celui dont l’objectif est de faire émerger d’autres leaders, plutôt que de conduire des suiveurs. Pour David Marquet, tout a commencé à bord de l’USS Sunfish quand son commandant lui a suggéré d’exprimer son intension et l’a laissé l’expérimenter. C’est cette demi-heure qui deviendra la source de son inspiration pour une nouvelle aventure : une façon radicalement nouvelle d’appréhender le commandement de son sous-marin, l’USS Santa Fé.

Ce livre est une histoire, celle de la préparation au déploiement du Santa Fé, sur une période de 6 mois. Un commandement qu’il n’était pas préparé à prendre et un sous-marin très mal noté. Je ne vais pas développer ici les 29 chapitres qui constituent les 220 pages de ce livre. Il se compose de 4 parties, mais ce sont les parties 2 à 4 qui forment essentiellement le précis de coaching qu’est également ce texte.

Lire la suite

Note de lecture : Mesos in Action, par Roger Ignazio

Note : 3 ; Un focus quasi-exclusif sur l’aspect « opérations » qui rend la lecture bien ennuyeuse pour moi…

Le volet « opérations » n’est pas ma tasse de Thé. Pourtant les frameworks qui gravitent autour de cette problématique simplifiant le déploiement, le clustering et permettant l’infrastructure as code sont probablement les plus actifs et les plus novateurs des projets open source aujourd’hui. C’est à ce titre que je me suis intéressé à Mesos, non pour être capable de l’opérer, mais pour le comprendre et en saisir les concepts et la manière de l’utiliser.

Hélas pour moi, c’est bien autour de la problématique des opérations que s’articule ce texte. Et même sous cet angle, il ne paraît pas des plus didactiques. Voyons justement comment il se structure. L’ouvrage est long de 235 pages, découpé en 3 parties pour un total de 10 chapitres. La première d’entre-elles, « Hello Mesos » fait une trentaine de pages et compte 2 chapitres. Il s’ouvre sur « Introducing Mesos » qui compte lui-même une quinzaine de pages. Ce chapitre donne une vue de haut niveau sur les fonctionnalités que délivre le framework et sa place dans la stack système. Il s’agit là d’une bonne introduction et l’on comprends ce qu’adresse Mesos, bien que la façon dont il l’adresse reste fort abstraite.

Au chapitre 2, « Managing Datacenters with Mesos », compte également une quinzaine de pages. Il se concentre d’avantage sur l’usage et la dynamique de fonctionnement de Mesos, toujours à haut niveau. Illustré par le déploiement de Spark dans différentes configurations, le chapitre est très bien illustré mais on reste toujours sur sa faim : comment diable Mesos interagit-il avec les applications sus-jacentes ?

Lire la suite

Note de lecture : Docker in Action, par Jeff Nickoloff

Note : 4 ; Assez clair, mais pourrait être plus pédagogique…

Docker est une des technologies qui monte, Manning ne pouvait laisser un vide dans son catalogue à ce sujet. C’est chose faite avec cet ouvrage de 270 pages. L’auteur maîtrise très bien son sujet et nous propose donc ce volume structuré en 12 chapitres regroupés en 3 parties.

La première partie est dédiée à la découverte de la containerisation. C’est la plus importante du livre, elle couvre 125 pages et occupe 6 chapitres. Le premier d’entre-eux est court d’une dizaine de pages. Il a pour but de présenter les principes généraux de Docker, son « pourquoi » ainsi que les principes généraux de la conteneurisation. C’est bien emballé. Le second chapitre nous projette côté utilisation de Docker, afin de faire tourner des softs dans des conteneurs, un peu dans tous les sens. On y utilise beaucoup la ligne de commande et l’on découvre les transitions d’états des conteneurs, le lancement d’un conteneur depuis un conteneur, etc.

Après le run, c’est à l’installation que l’on s’intéresse au chapitre 3. Sur 15 pages, on y découvre l’installation depuis un repository ou depuis un dockerfile et bien sûr les principes de base des layers. Les choses se complexifient au chapitre 4 avec la gestion du stockage (persistant ou non) et l’attachement de volumes dédiés ou partagés. Heureusement le propos est largement illustré.

Lire la suite

Note de lecture : Netty in Action, Norman Maurer & Marvin Allen Wolfthal

Note : 3 ; A peine mieux que la doc d’API !

C’est un livre qui a été long à sortir et le sujet même laissait à penser que le propos serait de bas niveau. Mais tout de même, que d’ennui ! En lui-même l’ouvrage compte presque 250 pages découpées en 15 chapitres, eux-mêmes répartis sur 4 parties. La première d’entre-elle couvre plus de la moitie du texte, avec 130 pages sur 9 chapitres. Le chapitre d’ouverture se propose de nous exposer l’architecture orientée évènements de Netty sur une douzaine de pages. Les auteurs auraient pu rendre la chose moins abstraite avec des diagrammes adaptés, mais disons que le boulot est fait.

Ce sont 16 pages qui sont consacrées au chapitre 2, le « hello world » de Netty. Au moins on a le code, plutôt beaucoup de code, si on compte le build et les listings de console. On a réussi à rendre aride ce qui en principe doit être une partie plutôt passionnante. Mais au moins, on a le code. On rentre dans le dur du sujet avec le chapitre 3 « components and design » qui sert en quelque sorte de table des matières aux chapitres qui suivent. Cela ne prends que 10 pages, mais on a déjà le goût de l’austérité d’une doc d’API !

Les 3 chapitres suivants : Transport, ByteBuf et ChannelHandler partagent le même aspect très peu passionnant, c’est à dire une description des APIs par le menu (avec quelques tableaux récapitulatifs imposés par les règles éditoriales manning. Très peu passionnant, cela va sans dire ? Seul OIO versus NIO au chapitre 4 relève un peu le niveau…

Lire la suite