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

Publicités

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