Note de lecture : The Mikado Method, par Ola Ellnestam & Daniel Brolund

Note : 2 ; Que de remplissage !

Les auteurs ont découvert un bon truc pour refactorer du code legacy. Une technique à la fois simple et pratique, donc réellement bonne. Et ils ont voulu en faire un livre. Seulement voilà, parce qu’elle est simple, cette technique tient en 20 pages, guère plus !

2 parties totalisant 7 chapitres sur 140 pages constituent le corps de l’ouvrage. La première partie « The basics of the Mikado Method » se satisfait de 4 chapitres avec 65 pages environ. On ouvre le bal avec « meet the Mikado method ». En fait, tout est dit, ou presque, dans ce premier chapitre d’une quinzaine de pages. La démarche en fait très simple (c’est sa qualité première) est décortiquée pas à pas. La seule chose qui manque est un exemple. C’est ce que l’on escompte avec le chapitre 2 « hello, Mikado Method ». L’exemple est hélas un peu simpliste, mais la vingtaine de pages illustre un peu tout, y compris le « revert » à l’aide d’un petit exemple en Java. L’utilisation du gestionnaire de version, partie intégrante de l’approche, fait partie du lot. Il y a déjà pas mal de répétitions avec le chapitre précédant, mais cela reste intéressant.

Le chapitre 3, « goals, graphs and guidelines » est là pour nous donner un peu de recul sur ce qu’est un bon objectif de Mikado. C’est très abstrait et ne nous emmène pas très loin. Au chapitre 4, les auteurs explorent des variations de l’approche Mikado avec « Organizing your work ». En l’occurrence ils déclinent l’approche Mikado en isolation, en pair et en équipe. L’aspect « équipe » rappelle un peu le « Mob Programming », mais il ne m’apparait pas évident que la mise en œuvre ait été sérieusement expérimentée… Cela conclut la première partie du livre.

Lire la suite

Publicités

Note de lecture : Working Effectively with Legacy Code, par Michael C. Feathers

Note : 9 ; Le refactoring repensé pour le legacy. Book of the year 2018 !

Appréhender la remise sous contrôle du code legacy est à mon avis une discipline à part entière. C’est en partie de l’architecture, tout en empruntant au refactoring avec une démarche de tests bien à elle. Entre autres choses. Mais peu d’ouvrages sont dédiés à la question, il faut dire que celle-ci n’est pas la plus sexy qui soit. Le livre de Michael Feathers se tient au sommet de cet édifice depuis plus d’une douzaine d’années et pour de bonnes raisons.

Michael Feathers nous propose une approche dans la ligne de l’approche extrême programming, en s’appuyant sur une vision code adossé à des tests unitaires. D’ailleurs sa définition du code legacy s’en inspire directement : du code legacy, c’est du code sans tests !

Avec 420 pages, ce n’est pas un petit volume que nous avons entre les mains. Il se découpe en 3 parties. La première d’entre-elle « the mechanics of change » est aussi la plus courte avec une cinquantaine de pages en 5 chapitres. Il s’agit bien d’une introduction assez exhaustive à l’approche que propose l’auteur et que j’appelle le « inside out ». Elle répond aux questions suivantes :

Lire la suite

Note de lecture : Traité du Zen et de l’entretien des motocyclettes, par Robert M. Pirsig

Note : 8 ; Un road-trip qui associé aventure humaine, réflexions philosophique et réparation des motos !

Le plus curieux dans ce livre, c’est le titre ! En fait, il n’est guère question de Zen, mais on y évoque bien l’entretien des motocyclettes. Ce livre, c’est un road-trip, que l’auteur entreprends avec son fils, à moto. Ou plus exactement un Chautauqua ainsi que le qualifie l’auteur. Le livre en lui-même est difficile à décrire, et je vais faire de mon mieux.

La trame de fond est le road-trip que j’ai évoqué. C’est l’aventure que l’auteur a imaginée pour renouer le contact avec son fils, entreprise qui s’avérera ardue, et leur fera traverser la moitié des Etats-Unis. Très vite on y rencontre un 3ème personnage, Phèdre, dont on finit par comprendre qu’il s’agit de l’auteur lui-même, avant son internement en hôpital psychiatrique, mais qu’il dissocie de lui-même. Phèdre à une vie, une pensée propre et surtout sa propre quête, celle de la « Qualité ». C’est d’ailleurs à ce moment que cet autre moi s’empare de l’auteur.

Les passages consacrés à Phèdre sont les plus ardus du livre, l’auteur y développe ses points de vue philosophiques, ou plutôt ceux de Phèdre. Nombre de réflexions sont toutefois réellement transposables, par exemple :

  • Les multiples évocations de la méthode scientifique et la manière dont elle peut être quotidiennement utilisée.
  • La dichotomie entre les modes « romantique » (inspiration, vision, intuition) et « classique » (structure de la pensée, approche scientifique).
  • Les divers écueils de nos modes de réflexion : blocages, freins et revers…

Lire la suite

Note de lecture : A Tour of C++, par Bjarne Stroustrup

Note : 5 ; Une introduction au C++ 2011, qui se lit mieux si on comprend déjà quelque peu le langage…

Une mise à jour de mes connaissances sur les dernières évolutions du langage : voilà ce qui étaient mes attentes concernant ce livre. Un livre fort court avec seulement 170 pages, ce qui me convenait parfaitement. D’ailleurs quand je dis « dernières évolutions du langage », c’est une façon de parler : j’ai bien attendu l’année de la norme 2017 pour lire un livre sur la norme 2011…

Le texte est bien découpé : les 170 pages sont réparties en 14 chapitres, chacun adressant un thème particulier du langage. Le premier couvre les « basics » sur 14 pages, j’y apprends quand même plusieurs nouveautés : le nullptr qui remplace null et la syntaxe for range permettant l’itération implicite sur des containers, comme en Java. Mais aussi l’inférence de types avec auto et l’initialisation des variables avec les accolades au lieu des parenthèses (on continue par ailleurs à utiliser celles-ci, tout n’est pas clair…). De petites (et moins petites) choses, mais de bonnes choses. Seulement 6 pages pour les « User defined types » du chapitre 2. Il faut dire que l’on n’a pas encore abordé les classes. Ici la nouveauté réside dans les class enums qui permet de typer ceux-ci. Là aussi on se rapproche du Java, mais sans pour autant pouvoir faire autant de choses avec. Dommage d’y consacrer moins d’une demi-page.

Lire la suite

Note de lecture : Understanding A3 Thinking, par Durward K. Sobek & Art Smalley

Note : 7 ; Pour donner du sens à la « pensée A3 », en conservant l’austérité du Lean !

Ne vous y trompez pas : le format de cet ouvrage est certes réduit, il ne prendra guère de place sur l’étagère… mais le contenu est consistant et demande à prendre son temps pour être consommé !

Ne vous y trompez pas : on y évoque le A3, mais ce n’est pas une explication de texte, en tout cas pas seulement. Comme le titre l’indique, il s’agit avant tout de comprendre la pensée A3, comment il s’inscrit dans une démarche et une logique PDCA. C’est d’ailleurs une trame récurrente du texte : superposer au A3 cette démarche PDCA.

160 pages et 8 chapitres, c’est tout ce qu’il faut pour venir à bout des objectifs énoncés ci-dessus. Le premier d’entre-eux est fort court avec 8, et c’est le PDCA qui nous est servi en guise d’introduction. C’est la philosophie Toyota que les auteurs tentent de nous faire toucher du doigt. Ils réussissent au minimum à nous donner l’envie de lire « The Toyota Way » ! Les 11 pages du second chapitre sont clés pour la suite, car il s’agit de la pensée A3 résumée en 7 éléments. Je ne vais pas les énoncer ici. Si je dois en retenir 3, je dirais : objectivité (résumé par l’approche scientifique), synthèse et vue systémique.

Lire la suite

Note de lecture : Le Mentoring Minute, par Ken Blanchard & Claire Diaz-Ortiz

Note 6 ; Les clés du mentoring, version succincte mais hélas un peu superficielle…

Dans la veine des autres « ouvrages minutes », celui-ci nous invite, par le truchement de deux personnages, à découvrir l’art du mentoring. C’est une bonne introduction au sujet. C’est un court opuscule d’environ 140 pages en petit format. L’approche « story telling » aide à en faire un texte qui s’avale très rapidement.

La relation de mentorat est différente de la relation de coaching, il s’agit d’une posture plus haute sans être infantilisante. Dans ce récit, le mentoré traverse une crise de doute qui l’empêche de dicerner le prochain pas à faire. Le mentor est quelqu’un de très expérimenté qui cherche à faire profiter de son expérience à de plus jeunes. Mentor et mentoré profitent tous deux de cette relation et c’est un des points qui est mis en relief ici. Alors qu’en coaching, le coaché doit lui-même trouver son chemin, le mentor peut proposer des possibilités, éclairer le mentoré de son expérience, mais il ne doit pas lui imposer une issue toute prête.

Coaching et mentoring partagent cependant des traits communs : dans les deux cas il est nécessaire de définir la mission. Un climat de confiance doit s’établir entre les deux parties, sans cela rien n’est possible. Enfin dans les deux cas l’accompagnement s’organise en terme de rythmicité et de mode opératoire.

Lire la suite

Note de lecture : Kanban pour l’IT 2nd édition, par Laurent Morisseau

Note 7 ; Toujours aussi (et même encore plus) complet avec une certaine austérité, mais un style en progrès.

J’avais trouvé la 1ère édition de ce livre excellente, quoique d’un style un peu rugueux. C’est avec un certain intérêt que je me suis lancé dans la lecture de cette nouvelle édition. Allait-elle montrer une amélioration ? Les habitués de mes notes de lecture savent que pour conserver la même note, un ouvrage doit se montrer un peu meilleur que son édition précédente. Et voilà que j’ai déjà cassé le suspens !
La précédente édition accusait 22 chapitres sur 215 pages, celle-ci prends de l’embonpoint avec 272 pages pour 31 chapitres ! On est donc très loin de la mise à jour cosmétique ! Voyons cela.

La première partie « les concepts de la méthode Kanban » est à peine plus longue que précédemment : 35 pages contre 27, mais on passe de 3 chapitres à 5, seuls les deux derniers étant repris. Le premier chapitre a lui-même changé, « les enjeux de Kanban » nous dresse les grands objectifs de l’approche de manière moins académique qu’avant. Le second chapitre « la méthode Kanban » est une sorte de teaser pour le reste du livre, nous proposant les éléments clés en version hyper-raccourcie. « Définir le flux tiré » est aussi extrait de l’ex-chapitre 1, même s’il ne fait que quelques pages, cet élément clé de Kanban méritait bien son propre chapitre.

La seconde partie change de titre dans cette nouvelle édition. « Concevoir et utiliser le système Kanban » compte 9 chapitre contre 17 précédemment, avec un chapitre 5 devenu chapitre 7 et chapitre 8. La troisième partie de la nouvelle édition « étudier et améliorer le système Kanban » poursuit l’ex-seconde partie à compter du chapitre 12. Il y ajoute un chapitre 19 « diminuer les délais par la résolution de blocages », court mais proposant une gestion pertinente des bloqueurs. Nouveau également, le chapitre 21 « évaluer son système Kanban » semble issu de l’expérience de l’auteur. Il nous propose un radar amputé de questions-clé permettant d’établir un niveau de maturité sur 6 axes. Le chapitre 23 (ex-chapitre 18) a droit à une évolution cosmétique passant de « résultat » à performance, ce qui change peu de choses pour moi. Le dernier chapitre de cette partie se voit alléger par rapport à la version d’avant : la partie consacrée au modèle Cynefin disparait !

Lire la suite

Note de lecture : Writing Great Specifications, par Kamil Nicieja

Note : 4 ; Dans la continuité du « specification by example » de Gojko Adzic, mais bien moins brillant.

Cet ouvrage est dédié à l’écriture de cas de test en Gherkin. Mais pas n’importe comment. Il s’inscrit dans la continuité du « specification by example » de Gojko Adzic qui a d’ailleurs préfacé le livre. En fait d’écriture de cas de test, l’auteur préfère évoquer l’écriture de spécifications (le livre a d’ailleurs changé de titre en cours de route), comme son devancier.

Il y a des variantes à la grammaire Gherkin, l’auteur a fait le choix de cibler celle supportée par Cucumber, bien qu’il fasse allusion à d’autres outils de temps à autre. De toute manière, l’outil n’est pas le propos du texte, ni même l’implémentation des scénarios. C’est bien de leur écriture dont il est question. Pour cet objectif, le texte accuse 250 pages structurées en 11 chapitres réparties sur 2 parties. La première d’entre-elle, regroupe les 6 qui suivent l’introduction et occupe 140 pages.
L’introduction justement, est là pour camper le décor. Il s’agit d’un chapitre plutôt dense, puisqu’il accapare à lui seul 30 pages. L’auteur y développe les définitions qui seront utiles par la suite, les anti-patterns de spécification et surtout sa démarche SBE. Mais que tout cela est verbeux ! Malheureusement, il en sera de même pour la suite.

En ouverture de la 1ère partie « Writing executable specifications with examples », le chapitre 2 évoque sur un peu plus de 20 pages l’articulation entre la couche de spécification et la couche d’automatisation. L’objectif du propos n’est pas franchement clair. J’ai l’impression que l’auteur tente de faire une introduction au ralenti. La véritable introduction est au chapitre 3, elle nécessite 25 pages et introduit tout à fait convenablement la syntaxe et les règles d’écriture qu’y surimpose l’auteur. C’est bien, juste trop volubile par rapport à la quantité d’information délivrée.

Lire la suite

Note de lecture : Training from the BACK of the Room ! par Sharon L. Bowman

Note : 7 ; Pour penser la formation autrement. Mais un format pas spécialement plaisant à lire.

On apprend mieux quand on est actif, quand le stagiaire est aussi acteur de la formation et quand l’animateur se tient en retrait. C’est le message principal de cet ouvrage majeur dans le monde de la formation. Sharon Bowman nous propose de structurer notre agenda de formation en cycles composés de 3 éléments : la connexion, les concepts et la mise en pratique. Cela ne semble pas disruptif, mais c’est dans la mise en pratique que les choses commencent à diverger. D’où les 65 propositions d’atelier.

L’ouvrage est ainsi divisé en 3 parties principales, auxquelles il faut ajouter une partie introductive, et deux « follow up ». Le tout compte environ 280 pages. Autant le dire tout de suite, c’est la structuration du livre qui m’a le plus dérangé dans ma lecture.

Pour entamer la lecture, la partie introductive « need to know » introduit les concepts qui seront par la suite développés. La table des matières nous indique que les 70 pages de cette partie sont décomposés en 3 morceaux (je n’ose dire « chapitres »), mais on a bien du mal à les différencier. En fait, il y a deux thèmes principaux. Le premier à traits aux concepts issus des neurosciences et qui seront ici exploités : on apprend mieux quand on est soi-même acteur de son apprentissage ! Le second, qui structurera l’approche de l’auteur et en fait, la construction même du livre sont les « 4 Cs » : connexion (avec les autres, avec le sujet), concepts (qui est l’apport de nouvelles connaissances), concrete practices (pour ancrer cette connaissance) et enfin conclusion (pour débriefer et prendre du recul sur le sujet). L’auteur nous propose d’ailleurs aide-mémoires et exercices pour mettre en pratique in situ l’approche avec le contenu même du livre !

Lire la suite

Note de lecture : Sprint, par Jake Knapp, avec John Zeratsky & Braden Kowitz

Note : 7 ; Une approche du prototypage inspérée du Design Thinking et du Lean Startup, clairement illustrée.

« Sprint », cela fait penser à Scrum. Pourtant, ce n’est pas du tout ce dont il s’agit. Il s’agit ici de tester rapidement et réellement des hypothèses, et ce en 5 jours, le dernier étant consacré aux tests d’idées formulées le lundi même ! C’est Google Venture qui a énoncé cette approche, à cheval entre le Lean Startup et le Design Thinking, pour faire converger plus rapidement et efficacement les startups qu’elle incube.

Cet opuscule de 280 pages couvre le déroulement de ces fameux sprints d’une semaine. En fait, 5 des 6 parties que constitue le texte couvrent les 5 jours du Sprint. Seule la première partie « plantez le décors » et ses 3 chapitres totalisant 60 pages sert de préambule. Passé l’introduction, le premier chapitre « le défi » réponds au « pourquoi » de cette démarche : il s’agit bel et bien de tester des hypothèses par le biais de prototypes passés au crible d’un vrai test utilisateur ! A ce titre, l’histoire du robot de Savioke s’avère particulièrement éloquente. Le second chapitre évoque l’équipe : elle doit être pluridisciplinaire et surtout intégrer LE décideur, doté d’un superpouvoir de vote. A quelques détails près on retrouve l’esprit du Design Thinking. Enfin, « le temps et le lieu » fixent les règles du jeu de l’exercice, y compris quelques petites règles destinées à ne pas s’enliser dans la non-décision, car le temps va filer très vite !

La seconde partie est consacrée au lundi ! Ce jour-là doit répondre à quelques questions : quel est l’objectif ? Une question que l’on traitera façon « remember the future ». Ensuite ce sont les questions pour lesquelles on désire des réponses. Cette journée du lundi est vouée à l’exploration et les outils pour cela sont les diagrammes de flux, les notes « HMW » et l’interview d’experts. Tout cela mis à plat, le lundi se conclura par le choix d’une cible. Même enrobé différemment, on reconnait ici nombre d’outils agiles.

Lire la suite