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…

Nous arrivons à la troisième partie. Ce sont 3 chapitres sur 75 pages qui évoquent enfin le développement agile dans le monde du jeu vidéo. 26 pages sont dédiées au chapitre 7 sur la planification dans ce domaine particulier. Disons tout net que l’on va parler beaucoup de phase, mais la pré-production et la post-production sont incontournables en ce domaine. Voir comment accommoder ces deux approches est un des points forts de l’ouvrage.

Au niveau des équipes, il y a aussi de nouveaux rôles. Mais le chapitre 8 qui est dédié au sujet semble apporter peu de points de vue neufs sur le sujet, que ce soit à une ou à plusieurs équipes. Enfin, le chapitre 9 nous parle d’itérations. Ce chapitre se révèle plus intéressant que prévu car il évoque d’une part les différents cycles imbriqués et spécialement le cycle de « build ». Et aussi parce qu’il met particulièrement l’accent sur les différents types de tests.

La quatrième partie « agile discipline » regroupe 4 chapitres en une soixantaine de pages. Le chapitre 10 « technology » traite en fait de pratiques d’ingénierie. Il est donc logiquement question d’extreme programming. Mais on y évoque aussi dette technique, architecture up-front et gestion des bugs. Rien de transcendant, mais c’est fort bien venu pour ceux qui ne souhaiteront pas aller voir un autre ouvrage. Direction artistique et audio sont au menu du chapitre 11 et forcément on y apprend des choses. On y apprend surtout que l’idée promue par ces derniers que leur boulot ne peut être découpé en tranches est erronée, et qu’en fait ils bénéficieraient de cette pratique. Au passage on apprend 2/3 trucs sur Michel-Ange.

La conception de jeu et la « recherche du fun » qui sont l’objet du chapitre 12 ne diffèrent guère finalement de ce que l’on fait sur un projet de nature exploratoire. C’est bon à savoir mais surtout très bien développé. QA et production clôturent cette 4ème partie. Mais il s’agit surtout de la QA. Classiquement calée en fin de cycle de développement, lorsqu’il est trop tard, l’auteur ramène leur rôle de cette QA (qu’il conserve) tout au long du développement en revisitant leur mission. Et il conserve également le « test de fin » mais avec une finalité de finition différente. Intéressant.

La dernière partie « getting started » est forte d’une soixantaine de pages sur 3 chapitres. On ouvre le bal avec les mythes et challenges de Scrum au chapitre 14. Le propos n’est pas sans rappeler le « Scrum Shortcuts » bien que le format soit bien plus court. En tout état de cause, ces anti-patterns sont tout à fait pertinents. Travailler avec un éditeur est une question particulière au monde du jeu. Le chapitre 15 introduit le mode de pensée pas vraiment agile-compatible de cet acteur. Mais surtout il propose une démarche pour l’embarquer dans le fonctionnement agile. Le livre se referme sur un chapitre 16 dédié à l’adoption de Scrum en 3 étapes inspiré de « Karaté Kid » mais qui en fait reprend le Shu Ha Ri qui m’est si cher. C’est donc normal que le chapitre me plaise.

Eu égard au sujet du texte, le livre me semble bien trop gros. Mais en fait il se veut « autoporteur ». Cela implique de longues parties entièrement consacrées à Scrum. Mais pas assez longues pour concurrencer les ouvrages dédiés au sujet. Cela signifie aussi des parties spécifiquement dédiées au monde du jeu plus restreintes qu’espérées. Cela reste un bon texte, bien qu’il soit frustrant, car il est bien écrit.

Référence complète : Agile Game Development with Scrum – Clinton Keith – Addison Wesley / Signature Series 2010 – ISBN: 978 0 321 61852 8