First you learn the value of abstraction, then you learn the cost of abstraction, then you’re ready to engineer.
Kent Beck
Publicités
Auteur : addinquy
Software Freethinker
Note de lecture : Comment leur dire … La Process Communication 2nd édition, par Gérard Collignon
Note : 4 ; Un tour assez honnête de la Process Com, mais qui en garde sous le pied.
La process com est un des outils fortement médiatisés du coaching. Il m’apparaissait important d’attaquer ce domaine par un ouvrage adéquat. Mais la process com, c’est aussi un business model, et c’est là que cela se gâte. Voyons cela.
Le texte compte 260 sur 13 chapitres, le tout structuré en 2 parties. La première d’entre-elles, consacrée aux fondements couvre 150 pages sur 8 chapitres. Les types de personnalité, abordés au premier chapitre est un élément primordial de la Process Com. C’est bien illustré ici, via le fil rouge de l’ouvrage. Le style est un peu ampoulé, mais ça passe. C’est assez logiquement que le second chapitre est là pour expliquer la structure de personnalité, la fameuse pyramide de la Process Com, en expliquant les concepts de phase et de base, par exemple. C’est clair mais cela donne une impression de superficialité, en étant trop descriptif et pas assez explicatif. Le biais « plaquette publicitaire » commence à apparaitre.
Le chapitre 3 revient sur les types de personnalité en détaillant leurs besoins. Étrange d’avoir placé ce chapitre ici et non dans la continuité du premier. Cela apporte certes quelques éclaircissements, mais sans être éblouissant pour autant. On rentre dans des considérations un peu complexes au chapitre 4 avec les canaux de communication : différents types de canaux de communication (nourricier, informatif, émotif, etc.) fonctionnant ou ne fonctionnant pas avec des « parties de personnalité (directeur, ordinateur, protecteur, etc.) et bien sûr… Chaque type de personnalité a une partie de personnalité prédominante. Intéressant, mais bien complexe à utiliser dans la réalité.
Note de lecture : Rupture Douce saison 02, par Laurent Sarrazin edt.
Note : 3 ; Toujours hétéroclite mais quelques petites choses à garder
Ce second volume a suivi de peu le précédant, toujours avec la même recette. Comme pour le premier volume, je trouve celui-ci inégal. J’y vois d’abord le même biais que dans le premier volume : beaucoup d’histoires racontées à la première personne, qui sont d’autant de propos autocentrés plutôt que des récits du point de vue de l’observateur. Malheureusement, ce type d’ouvrage sert avant tout de tribune aux coaches en recherche de publication.
Voilà pour l’aspect déception. Mais il y a aussi des choses à en retirer.
Le « osons jouer » d’Alexandre Boutin, plein d’énergie, de réflexions profonde doublé d’une véritable démarche de gamification.
Alexis et Isabel Monville racontent quant à eux une véritable de changement où se lit une chronologie et une démarche, le tout centré sur le client. Bravo d’avoir joué le jeu !
Dans la lignée de ce que j’ai apprécié dans le texte d’Alexandre, l’éloge de la lenteur productive de Dimitri Baeli a attiré mon attention. Bien sûr, connaissant Dimitri, le propos est centré sur Kanban à l’exclusion de tout autre chose. Même si ce n’est pas mon point de vue, le texte présente assez substance pour se faire apprécier. Et le style est avenant.
It is therefore not unreasonable to suppose that some portion of the neglect of science in England, may be attributed to the system of education we pursue.
Charles Babbage
Note de lecture : Exploring Scrum, The fundamentals, par Dan Rawsthorne with Doug Shimp
Note : 3 ; De la « soupe au Shu » … Et encore, celle de l’auteur !
J’en suis encore à me demander ce qui m’a pris lorsque j’ai acquis ce bouquin ! Car autant le dire tout de suite : il est très dogmatique. Pire encore, il y bien peu de choses avec lesquelles je sois d’accord. Pour couroner le tout, il ne s’agit pas d’une lecture légère. Voyons cela.
L’ouvrage est fort de 4 sections de longueurs très inégales totalisant 27 chapitres. La première d’entre-elles est introductive et se satisfait de 2 chapitres. Le premier est d’avantage un avant-propos que l’introduction du livre lui-même car il se focalise sur le « pourquoi » du texte. Celui-ci débute réellement au second chapitre qui propose un « tour du propriétaire ». Celui-ci est assez conforme au Scrum guide même si l’on voit poindre en filigrane les interprétations des auteurs. J’aurais l’occasion d’y revenir.
La seconde partie « people » compte 6 chapitres. On débute assez logiquement au chapitre 3 par l’équipe. Les auteurs commettent leur premier coup de canif en évoquant 6 rôles (Business Owner, Stakehold et Subject Matter Expert). C’est un chapitre assez long qui remet au clair nombre de principe mais verrouille aussi tout autant des principes d’articulation entre rôles qui n’ont pas besoin de l’être autant. Le chapitre 4 qui vient se focaliser sur le PO donne le ton dès la première page « le PO priorise le travail de l’équipe et en échange reçoit le blâme pour le résultat ». Autant pour la collaboration ! J’ai trouvé le point de vue quelque peu tordu, voir schizophrène entre un discours sur la collaboration et des directives de fonctionnement induisant des comportements à l’inverse.
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.
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
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.
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.
Dans les situations critiques, quand on parle avec un calibre bien en pogne, personne ne conteste plus. Y’a des statistiques là-dessus.
Michel Audiard
