Note de lecture : The DevOps Handbook, par Gene Kim, Jez Humble, Patrick Debois & John Willis

Note : 5 ; De bonnes histoires et d’excellents principes mais un manque d’unité.

Le but inavoué de ce livre était d’être la référence sur le devops. J’en veux pour témoin l’impressionnante liste de noms à l’affiche. Les auteurs de « IT Rev » ont développé leur vision du Devops déjà ébauchée dans « The Phoenix Project », il s’agit des « 3 voies » dans la pure lignée de la pensée Lean. Ce livre est consacré au développement de cette idée.

Le livre lui-même est de format un peu plus réduit qu’à l’accoutumé, mais il atteint les 350 pages hors annexes (celles-ci en ajoutent 100 de plus), le volume de matière est donc conséquent. L’ensemble est découpé fin : on compte 23 chapitres rassemblés en 6 parties. La première d’entre-elle est consacré aux 3 voies. 4 chapitres sur 45 pages couvrent le sujet. L’introduction et le premier chapitre donnent les grandes lignes du devops, ce qui pourrait se résumer à la réduction du lead time.

Les 3 chapitres suivants de cette première partie sont chacun consacré à une des voies des fameuses 3 voies. Le second chapitre est ainsi consacré au « flow ». Sans surprise, on retrouve ici les principes du Lean appliqué au Kanban : taille des lots, élimination du gâchis, etc. Toutes choses permettant à la fois de réduire le temps de cycle et de donner de la fluidité au processus. Le second chapitre attaque le principe du feedback. Il est plus vague, évoquant le Andon et le déplacement de la qualité vers le développeur. Enfin le chapitre 4 nous parle d’amélioration continue, évoquant la culture « générative » au sens de Westrum. Les pratiques évoquées tournent autour de l’expérimentation et de la généralisation des découvertes locales.

Lire la suite

Publicités

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects

Robert Heinlein

Robert Heinlein

Note de lecture : The Agile Culture, par Pollyanna Pixton, Paul Gibson & Niel Nickolaisen

Note : 6 ; Un “trust-ownership model” intéressant, mais noyé dans d’autres considérations.

J’ai des sentiments mitigés concernant cet ouvrage. La base de celui-ci est le « trust-ownership » model, qui occupe le début du livre… Oui, mais le reste ? Eh bien pour le reste, c’est en partie du recyclage du purpose alignement model et d’autres considérations certes intéressantes mais qui ne se raccrochent pas forcément directement au sujet principal.

Le volume se présente sur 210 pages, auxquelles il faut rajouter une vingtaine de pages d’annexes (par ailleurs bien faites). L’ensemble est benoitement découpé en 9 chapitres. Le premier d’entre-eux introduit justement celui-ci sur une dizaine de pages. On en prend pour une trentaine au second chapitre. Ici, il s’agit de détailler les 4 quadrants du modèle. La tension entre l’appropriation de l’organisation par l’équipe et la confiance du manager est un équilibre délicat qui recèle des écueils. Ce chapitre est probablement l’un des plus riches de l’ouvrage.

Le chapitre 3 « building trust and ownership”, évoque à l’aide de questions, la manière d’échapper aux quadrants « failure », « contrôle » et « conflicts ». Il n’apporte pas réellement de réponses, mais propose des questions qui peuvent servir de cadre de réflexion. Disons que l’on est en « mode coaching » … Le chapitre 4 « trust tools » était l’une de mes plus fortes attentes du texte. Je reste sur ma faim, le texte apporte des voies qui sont connues depuis bien longtemps : ne pas décider à la place de l’équipe, donner le droit à l’erreur, etc.

Lire la suite

Note de lecture : Continuous delivery, par Jez Humble & David Farley

Note : 4 ; De l’intégration continue à devops ! Des points de vue de grande valeur, mais bien trop verbeux. Jolt Award 2011 !

Ce livre fait en quelque sorte suite au « continuous intégration » publié dans la même série. Ici, l’orientation est résolument « devops », ou comment aller du développement à la mise en production. Aussi le livre ne s’articule pas seulement autour des problématiques techniques, mais aussi de processus et des activités garantissant la mise en production : tests unitaires, tests d’acceptance, gestion des releases, gestion des environnements, etc…

La première partie appelée « fondations » évoque tous les prérequis à la déliverie continue. On y parle de tests, de gestion de versions, etc… Bref de toutes sortes de choses que l’on connaît déjà et déjà détaillées par ailleurs. C’est un peu long et verbeux. On en prend pour 100 pages. Au premier chapitre on s’évertue de mettre en lumière la vue « ancienne » du release management. Pas si ancienne d’ailleurs, avec ses « RC1 », « RC2 », etc. On le fait à l’aide d’antipatterns un peu tarte à la crème, pour au final introduire les qualités attendues d’un bon pipeline d’intégration. Le chapitre 2, « configuration management » traite de deux sujets : la gestion de version, où les auteurs sont opiniated sur le développement en banche principale, et les informations de configuration qui doivent être externalisées. Les deux sujets seront repris plus tard. Ces prises de position, même si elles piquent un peu sont plus que sensées.

Une grosse trentaine de pages est consacrée à l’intégration continue. Pas de révolution ici, on reprend des principes désormais bien connus : un build court, ne jamais laisser un build cassé, raccourcir la boucle de feedback en lançant le build d’intégration au plus tôt. C’est un peu long pour dire des choses que l’on connait déjà et qui ne sont pas le cœur du livre. Je ne m’attendais pas nécessairement à voir évoquer la stratégie de test, mais c’est bien le sujet du chapitre 4 qui clôt la première partie sur une quinzaine de pages. Ce sont des pages bien dépensées cette fois, car les auteurs font le tour du sujet assez efficacement en suivant le framework de Brian Marrick. Cela dit, on est cette fois encore, un poil en marge du sujet.

Lire la suite

Note de lecture : Coaching d’équipe, par Alain Cardon

Note : 4 ; Heureusement qu’il y a des exemples…

J’ai toujours une certaine appréhension à aborder un livre traitant de coaching, et plus encore quand il s’agit d’un livre en Français. Quand celui-ci se prétend « résolument pratique », cela veut dire qu’il sera juste un peu moins abscons que d’habitude. Et oui, c’est dans ce cadre que nous allons jouer.

Disons que ce livre est au standard des ouvrages de coaching, avec 250 pages. Seulement 10 chapitres en tout (en comptant introduction, conclusion et annexe). L’introduction tente de cadrer l’objet de ce livre, à savoir coacher les équipes. OK, c’est différent du coaching individuel, mais au-delà de cela, cela reste assez flou avec une description assez ésotérique du sujet. Hélas, cela va souvent être comme cela dans la suite du livre…

Le chapitre 1 « contexte d’intervention » nous précise 2/3 choses. Tout d’abord que le livre va être entièrement dédié aux réunions (avec en fait un focus plus fort sur les réunions de dirigeants) et que les relations entre les membres de l’équipe sont un élément important, spécialement la relation au leader, et qu’il faut faire attention à ne pas rentrer dans le jeu. Bref, ce n’est pas mal, mais ça ne vaut pas 30 pages. Éléments appréciables que l’on retrouvera tout au long du livre : les rubriques « exemple » et « pièges à éviter » : non seulement il donne vie au texte avec des éléments concrets (qui manquent cruellement par ailleurs), mais on perçoit aisément qu’ils viennent de la longue expérience de l’auteur.

Lire la suite