Note de lecture : Agile Game Development with Scrum, par Clinton Keith

Note : 5 ; Un texte honnête, finalement peu spécifique au domaine du jeu, mais qui accuse un peu son âge.

Pour une « simple » déclinaison de Scrum à l’univers du jeux, l’addition est un peu sévère avec ses 325 pages. Quand on regarde la date de publication, on voit qu’il date d’une époque où le sujet n’avait pas encore envahis chaque recoin de notre bibliothèque. Fort logiquement il reprend un certain nombre de basiques. Je pensais rentrer dans un univers très différent, mais c’est finalement peu le cas comme nous le verrons.

Le livre comprend 5 parties, pour un total de 16 chapitres. Belle bête, donc. La 1ère partie maigre d’une trentaine de pages sur deux chapitres est un avant-propos, au domaine du jeu et au développement agile. Le domaine du jeu est traité dans le chapitre introductif. L’auteur y aborde efficacement la course à l’armement des studios de développements conduisant à une crise du logiciel spécifique de ce secteur. La vingtaine de pages du second chapitre serait classique si l’auteur n’y avait introduit quelques concepts spécifiques du domaine du jeu : phases de pré-production / post-production et recherche du « fun », par exemple.

La seconde partie, avec ses 90 pages et ses 4 chapitres est plutôt indépendante du domaine concerné. Le chapitre 3 s’intitule sobrement « Scrum ». On y trouve sur ses 22 pages ce qu’on peut s’attendre à y trouver. Seuls les exemples sont empruntés au monde du jeu. La prose est bien écrite, avec quand même certains partis pris. Le déroulement du Sprint est au menu du chapitre 4. Là non plus nous ne trouverons une prose se démarquant réellement des grands classiques. Nous arrivons ainsi au chapitre 5 évoquant les user stories. Pas non plus beaucoup d’originalité ici également. On évoque longuement le « INVEST » comme à l’accoutumée. Plus original, le découpage hiérarchique des stories me laisse toutefois un peu perplexe. Enfin, l’agile planning n’est probablement pas mon sujet préféré, mais je dois avouer que le chapitre 6 qui lui est consacré est de bonne teneur. Il me rappelle quelque peu « agile estimating and planning » de Mike Cohn. C’est dire…

Lire la suite