Note : 3 ; Du Scrum de base sans surprise, à part celle de décevoir sur son titre !

Bien entendu, c’est l’aspect « spécifications exécutables » qui m’a conduit vers ce livre ! Le fait qu’il soit plutôt bref, avec ses 150 pages était un bonus. Au final, c’est une déception, la note est peut-être sévère à cet égard mais c’est ainsi, car il s’agit plutôt d’un nième « Scrum Shū ». L’ouvrage manque dans ses grandes largeurs d’originalité et le peu qu’il y en a ne m’a guère convaincu. Heureusement, il faut avouer qu’il est bien écrit. Voyons donc ce que nous réservent ses 9 chapitres.

Le premier d’entre eux couvre une douzaine de pages au sein desquelles on retrouve les poncifs habituels sur la justification des projets en agile : incertitude, complexité etc. En fait, j’ai même l’impression de relire l’introduction du premier bouquin sur Scrum, celui du début des années 2000. Le second chapitre, lui aussi fort d’une douzaine de pages, est un peu moins bateau. Il évoque les prérequis au démarrage de projet. Rien de neuf sous le soleil si ce n’est une bonne vue synthétique et l’usage de l’euristique de nommage de Gause et Weinberg.

Le chapitre 3 ne compte que 10 pages et sert principalement d’introduction à l’un des concepts originaux de l’auteur, celui de « desirement », contraction de « desire » et « requirements ». L’aspect « desire » étant inspiré de nouveau par Gerald Weinberg (are you ligh on ?). Disons le tout net : c’est très peu convainquant. Le tarif est d’une dizaine de pages également pour le chapitre 4 « expressing desirements through user stories ». On nous ressasse une nouvelle fois le template de Mike Cohn et le INVEST. La partie sur les rôles et bénéfices parvient à être intéressante, tandis que l’introduction au backlog reprenant la prose de Mike Cohn est parfaitement insipide.

Justement, c’est de backlog grooming qu’il est question au chapitre 5, un sujet qui nécessite apparemment 27 pages. De fait, il y a pas mal de choses dans ce chapitre, un melting pot de techniques, en fait :

• Le « dot voting » pour prioriser les stories. A oublier.
• Le « storyboard » pour illustrer les stories : une bonne idée, mais appréhendée un peu naïvement par l’auteur.
• L’estimation des stories en point de complexité : rien de neuf sous le soleil.
• Le split des user stories : c’est un sujet important mais traité de manière très superficielle.
• Le « collaboration board », c’est à dire le Scrum board : ce n’est guère que la répétition de ce que l’on peut lire depuis des années…

Le chapitre 6 « confirming User Stories with scenario » aborde ce qui m’a fait m’intéresser à ce livre, à savoir les tests d’acceptation. De fait, ce chapitre est assez conséquent avec 23 pages. Mais une fois encore le propos est assez léger. Je retiens juste le processus de rédaction en 2 étapes, qui sépare la rédaction des scénarios clés des différentes variantes. Ce n’est pas ce que je fais, mais c’est intéressant.

L’auteur sépare la notion de scénario (l’objet du chapitre précédent), de celui de test d’acceptation (qui est le propos du chapitre 7). Une distinction un peu confuse, comme l’est globalement le propos des 25 pages fort peu convaincantes de ce chapitre. En grande partie, il s’agit d’aborder la question de l’implémentation de ces tests et de partager un contexte entre les méthodes ainsi chainées.

Le chapitre 9 est, je pense, l’une des fiertés de l’auteur car il aborde les exigences non-fonctionnelles à l’aide d’un concept qu’il a créé : les restrictions. Ces restrictions n’étant pas fonctionnelles car « trop vagues sur le Quoi ». L’auteur s’évertue ensuite à nous faire saisir le concept de restriction qui doit s’attacher non pas à une User Story, mais à un scénario ! Bref, une grosse prise de tête pour un résultat bien peu convainquant.

C’est à la conclusion du livre qu’est consacré le chapitre 10. Elle n’occupe que 5 pages, reprenant la « big picture » du livre et… les rôles de Scrum, augmentés de 2 rôles qu’il pense indispensable de distinguer. Une affaire de goût, mais qui n’est pas le mien.

Peu d’enthousiasme pour cette lecture qui est clairement pour moi consacrée au nouveau venu, ce sur quoi le titre est trompeur. Si on peut picorer quelques bonnes idées, la plupart des points originaux me paraissent plutôt bons à jeter. Passez vôtre chemin.

Référence complète : Executable Specifications with Scrum, a practical guide to agile requirements discovery – Mario Cardinal – Addison Wesley 2013 : ISBN : 978 0 321 78413 1