Note de lecture : Clean Agile, par Robert C. Martin

Note : 7 ; Un « back to basics » très bien écrit et malheureusement aujourd’hui nécessaire… mais par moments trop empreint de dogmatisme XP !

Quand on ouvre un livre de Robert Martin, on est presque toujours sûr de passer un bon moment. C’est bien le cas ici, et c’est sans doute pourquoi j’ai avalé ce court opuscule en à peine 2 jours. Le sous-titre « back to basic » traduit bien la volonté de l’auteur, revenir aux sources de ce qu’est l’agilité, de pourquoi et comment la met-on en œuvre. Le retour aux sources, c’est le retour à la véritable agilité, et pour l’auteur ce ne peut être rien d’autre que Extreme Programming. Nous verrons que cela induit quand même quelques biais qui peuvent aller de légèrement irritant à franchement embarrassant.

Place au texte ! Comme énoncé, c’est une lecture fort digeste : 185 pages réparties sur 8 chapitres. C’est d’histoire dont nous parle Robert Martin dans ce premier chapitre. L’histoire telle qu’il la connait et qu’il l’a vécue. Cela couvre des éléments bien antérieurs aux années 89/90, que les non-férus d’histoire découvriront, et bien sûr l’écriture du manifeste à Snowbird. Un régal. Le chapitre se termine sur le « circle of life » d’extreme programming, car pour l’auteur agile est synonyme d’extreme programming, et en fait rien d’autre.

Le chapitre 2 couvre les raisons de faire de l’agile (oui, j’ai dit « faire »). Le chapitre incarne assez bien l’aspect « retour aux bases » avec un éclairage résolument XP et ingénierie du développement. Ce n’est pas vraiment une découverte bien sûr, ni une redécouverte pour moi, mais il pourra éclairer des nouveaux venus qui n’ont que le prisme facilitation en tête. Le plus curieux dans le chapitre 3 est le titre « business practices » qui pour moi correspond peu au contenu (pour ne pas dire pas du tout). Peut-être que selon le prisme XP, le business est tout ce qui n’est pas strictement l’ingénierie de développement ? On y aborde de manière conséquente les estimations et la vélocité ce qui, même si c’est bien et clairement abordé est tout à fait ennuyeux. La fin du chapitre sur les tests et la QA parvient tout de même à me sortir de ma torpeur.

Lire la suite

Note de lecture : Coacher une équipe agile, par Véronique Messager

Note : 7 ; Une boite à outil plutôt qu’un cadre de coaching

Faire une note de lecture d’un livre dont j’ai été l’un des relecteurs principaux n’est pas une tâche facile. De plus, j’avoue n’avoir que peu goûté les ouvrages que j’ai pu croiser sur le coaching agile. Peut-être bien est-ce au fond un manqué d’intérêt de ma part sur ce sujet ? Voyons ce qu’il en est.

Tout d’abord l’ouvrage : avec 273 pages découpés en 21 chapitres plus une conclusion il est de taille moyenne. Moi qui apprécie les chapitres de taille raisonnable, je serais plutôt satisfait, toutefois il y a une forte disparité de longueur des différents chapitres, mais rien de bien gênant.

Enfin, il faudra noter le découpage en 5 parties qui reflète une progression dans la démarche de coaching.
La première partie campe le contexte. Il faut compter 3 chapitres sur 40 pages pour cela. Si le premier d’ntre-eux parle d’agilité, ce sont bien les « comportements attendus » figurant en dernière page qui constituent le point dominant du propos. Le second chapitre forme un contrepoint mettant en relief au travers d’exemples fictifs mais inspirés de la réalité, la différence entre ce qui devrait être un acquis et l’observation du terrain. Le contraste est saisissant. L’explication arrive au 3ème chapitre avec, entre autres, l’homéostasie et le poids de nos émotions que l’auteur compare à un GPS interne.

Lire la suite

Note de lecture : Software Requirements 3rd edition, par Karl E. Wiegers & Joy Beatty

Note : 6 ; Il échoue à se mettre au goût du jour et déçoit sur sa prise en compte de l’agilité

J’avais adoré la 1ère et la seconde édition, c’est avec un plaisir par anticipation que j’abordais ce 3ème opus. J’ai l’habitude de faire perdre un point de note à une édition qui ne fait que se maintenir par rapport à l’édition précédente. Las, ce n’est pas 1 mais 3 points qu’a perdu cette édition-là ! J’avais gardé un excellent souvenir de la seconde édition et m’attendais à une modernisation conséquente du texte, plus particulièrement sur la convergence avec le mouvement et les pratiques agiles. Sur ce dernier point plus particulièrement les auteurs ne sont pas dans le coup et la déception est grande. Le texte reste un ouvrage majeur toutefois dans l’ingénierie des exigences. Voyons cela.

Ce sont 550 pages que compte ce 3ème opus, structurées sur 5 parties pour un total de 32 chapitres, hors annexes. Et ces dernières sont conséquentes. Ce n’est pas ce que l’on peut appeler une lecture légère, ni par le volume ni hélas non plus par le style. La première partie est forte de 4 chapitres sur 75 pages et va nous camper le décor de l’ingénierie des exigences. Le premier chapitre est fort bien fait, il donne la big picture des exigences, avec les différents types (dont les fameux NFR, Non functional Requirements), et comment ils s’articulent sur 3 niveaux. On y a un aperçu quoique superficiel du cycle de vie des exigences et des enjeux de leur bonne gestion. Le second chapitre est consacré aux exigences du point de vue des utilisateurs. On apprend donc à les distinguer et à identifier le décisionnaire. Le point réellement intéressant de ce chapitre sont les « bill of rights / bill of responsibilities » des utilisateurs.

Le chapitre 3 nous sert les « bonnes pratiques » du développement et de la gestion des exigences. Il y en a vraiment beaucoup. De fait, c’est un peu la table des matières de la seconde partie de l’ouvrage. Un chapitre pas spécialement sympathique à lire. Cette première partie se referme sur l’analyste : sa vie, son œuvre et ses compétences. Un chapitre bien fait, très clair sur ce qu’on attend d’un bon analyste.

Lire la suite

Note de lecture : Seriously Good Software, par Marco Faella

Note : 4 ; Le “seriously” est à prendre très au sérieux !

Ce texte n’est pas très facile à classer entre Java et Craftsmanship. S’il est résolument orienté sur la plateforme Java, c’est tout de même sur les principes d’implémentation (et un peu de conception) que l’auteur met l’accent. L’auteur, parlons-en, est professeur d’informatique à l’université de Naples. De fait, sans en avoir l’austérité, le texte a quelques ressemblances avec un support de cours.

Voyons un peu ce qu’il en est. L’ouvrage compte 9 chapitres répartis sur 2 parties très inégales, pour un total de 280 pages. On le voit, ce sont des chapitres relativement conséquents, en moyenne supérieur aux 20 pages par chapitre qui m’a toujours semblé un bon compromis. La première partie compte deux chapitres, couvrant 45 pages. Le chapitre introductif traite de la qualité ou plus exactement des qualités attendues d’un logiciel. Ce seront les points successivement développés dans les chapitres suivant, puis l’étude de cas qui nous suivra tout au long de l’ouvrage est introduite.

Le second chapitre introduit l’implémentation de référence. Une implémentation qui ne cherche à optimiser ni la performance ni l’emprunte mémoire. Toutefois l’approche adoptée pour analyser l’un et l’autre est présentée ici, grâce à cette version facilement appréhendable. Bien sûr c’est la notation O popularisée par la STL qui est utilisée pour les performances. On sent déjà le côté « support de cours » dans ce chapitre par ailleurs pas désagréable à lire.

Lire la suite

Note de lecture : Pomodoro Technique Illustrated, par Staffan Nöteberg

Note : 7 ; Pragmatique, simple et rafraichissant.

Les auteurs scandinaves se suivent … et sans se ressembler, ils semblent tous faire preuve d’une redoutable efficacité dans la rédaction de leurs textes ! Après avoir dégusté Kniberg, Staffan Nöteberg nous offre le texte de référence sur le Pomodoro.

En soit, le Pomodoro est une technique simple, qui en fait peut se décrire complètement en 2/3 pages. Bien sûr, ici il est question de mieux que cela, et l’auteur développe au long des 7 chapitres de cet ouvrage toutes les facettes de la mise en pratique de cette technique, s’appuyant pour cela sur sa propre expérience et nous la faisant partager.

Je l’ai dit, le Pomodoro est une technique simple (c’est bien sûr l’une de ses qualités essentielles), il n’était donc pas nécessaire de nous asséner un pavé pour l’expliquer. Le texte n’est long que de 137 pages. En fait, il est même plus court, car comme l’indique le titre, le livre est « illustrated » au sens le plus littéral : chaque page fait l’objet d’une illustration (naïve, mais amusante et réussie), faite de la main de l’auteur, sur du papier quadrillé et en couleur (crayon à papier et gouache, si vous voulez tout savoir). C’est une première pour un livre d’informatique, mais cela se marie curieusement bien au texte. Du fait de ces illustrations, la taille réelle de ce texte ne couvre qu’environ 2/3 des pages, soit environ 90 pages.

Lire la suite

Note de lecture : Agile Software Requirements, par Dean Leffingwell

Note : 3 ; L’ancien testament de SAFe, sous un titre bien trompeur !

C’est vrai que je n’avais pas regardé de très près. Mais au vu du titre, je pensais avoir entre les mains la 3ème édition du « Managing Software Requirements », cette fois à sauce agile, avec la couche de peinture qui va bien. Il n’en est rien et ce n’est pas une bonne nouvelle.

Le livre est une belle bête, avec sa couverture dure et ses 470 pages (500 pages tout mouillé). L’ensemble est subdivisé en 4 parties totalisant 24 chapitres. Une belle bête, vous dis-je ! La première partie « the big picture » regroupe les 5 premiers et chiffre près d’une centaine de pages. A ce stade, cela reste encore mystérieux, l’objet de cette grande fresque. Toutefois le schéma qui figure en-dessous pourrait nous éclairer car il ressemble furieusement au poster SAFe. Les 26 pages du premier chapitre ont comme objet l’histoire de la gestion des exigences. Il s’agit en fait de l’histoire de la transition vers les approches agiles. Un chapitre agréable, néanmoins.

Avec le chapitre 2 et la grande représentation des spécifications agiles, les choses se précisent. Il ne s’agit pas des spécifications, mais de la vision « par étages » de la réalisation agile à grande échelle, celle qui deviendra SAFe et n’a déjà plus grand-chose d’agile. Ne nous vous inquiétez pas, le pire est à venir. Au chapitre 3, il est question des spécifications au niveau de l’équipe, ou du moins il devrait l’être. Il s’agit des User Stories, mais en fait le chapitre expose le fonctionnement de Scrum. Pour en savoir plus sur les US, n’importe quel autre texte vous en dira plus.

Lire la suite

Note de lecture : Practices for Scaling Lean & Agile Development, par Craig Larman & Bas Vodde

Note : 7 ; Une déclinaison en pratiques pas si pratique que ça du « book of the year 2010 » mais qui reste très enrichissant.

Cet ouvrage va de pair avec « Scaling Lean & Agile Development » des mêmes auteurs. Il se veut le guide de mise en pratique de ce précédent ouvrage. Nous verrons que ce n’est pas tout à fait vrai, ce qui ne signifie nullement que le texte ne vaille pas le détour.

S’agissant du volet « pratiques », on ne devra guère s’étonner du volumes substantiel de l’ouvrage : 560 pages ! L’ensemble tient en 15 chapitres, beaucoup d’entre-eux sont tout à fait conséquents en taille ! Ce n’est pas le cas de l’introduction qui ne compte que 6 pages. Il s’agit plutôt de deux mises en gardes qui seront des thèmes récurrents des chapitres suivants : pas de fausses dichotomies (beaucoup de choix ne sont pas exclusifs) et il n’y a pas de « best practices » mais plutôt des pratiques bien adaptées à certains contextes. Le second chapitre est aussi une introduction en quelque sorte, celle du « large scale Scrum » ici appelé FW2, qui deviendra LeSS plus tard.

Les choses sérieuses, vraiment sérieuses commencent au chapitre 3 qui évoque les tests et compte 75 pages ! Le chapitre couvre beaucoup de sujets, depuis la cartographie des tests jusqu’aux pratiques elles-mêmes. Les quelques messages essentiels sont : l’activité de test est indissociable du développement et doit se passer au sein de l’itération elle-même. C’est dense et c’est que du bon !

Lire la suite

Note de lecture : SAFe 4.5 Distilled, par Richard Knaster & Dean Leffingwell

Note 4 ; Un tour d’horizon à haute altitude bien écrit, mais manquant de consistance, de SAFe l’ERP de l’agilité.

SAFe est réellement le raz de marée de la seconde moitié des années 2010. Il serait vain de l’ignorer. Avec quand même un certain bagage sur le framework, j’aborde ce livre dans le but de mieux appréhender comment l’ensemble des briques s’articulent. Un objectif qui, nous le verrons, est malheureusement loin d’être atteint.

C’est un livre de taille moyen, avec ses 300 pages environ, qui surprend par son poids quand on le prend en main. Et pour cause : il est imprimé sur papier glacé, et même imprimé totalement en quadrichromie ! Un peu comme une plaquette publicitaire, ce qu’il est en partie. Le contenu est divisé en 6 parties et ne compte pas moins de 22 chapitres. La première partie nous invite à une vue générale, sur 25 pages comptant deux chapitres. Le premier est à peine un tour de chauffe, avec le « business case » de SAFe mâtiné de perspectives historiques. C’est bien écrit, mais on n’y apprend rien. C’est un peu plus concret au chapitre 2 qui nous explique clairement les différentes déclinaisons de SAFe et les rôles utiles. C’est une introduction comme il faut.

La seconde partie dédiée au mindset et principes compte 3 chapitres et couvre une cinquantaine de pages. On commence au chapitre 3 par parler mindset avec le manifeste agile et avec la « SAFe House of Lean », un peu librement adapté de l’original. A part cette nouveauté, la seule originalité est la déclinaison du manifeste à l’échelle, tout à fait sensée. Les principes SAFe sont détaillés au chapitre 4. Franchement ils sont bien et sont clairement évoqués. D’inspiration très largement Lean, j’ai quand même un peu de mal à les raccorder à ce que j’ai compris du framework. J’ai hâte d’en savoir plus. J’adhère aussi au propos sur le « Lean-Agile leader ». Du focus sur le développement des personnes au recrutement ciblé sur les soft-skills, nous sommes clairement dans la bonne direction !

Lire la suite