Note : 4 ; Une prétention encyclopédique qui tombe un peu à plat.

Ce n’est certainement pas le premier ouvrage à nous parler de développement agile. Vu son âge vénérable, nous lui concèderons aussi de faire partie de la première génération de livres consacrés à l’agilité. Nous ne nous étonnerons pas non plus que la pratique se consacre à Extreme Programming, mais sans aucune velléité dogmatique pour autant.

Avec près de 400 pages presqu’exclusivement couvert de texte, l’ouvrage est particulièrement dense. Il a des prétentions bibliographiques, car en grande partie consacré à des descriptions de pratiques qui sont loin d’extreme programming en grande partie. En cela ce titre est particulier. Il est structuré en 3 parties et totalise 15 chapitres. La première partie, « getting started » regroupe les 4 premiers sur environ 65 pages. Elle débute par un chapitre nous aidant à répondre au « pourquoi » de l’agilité. Il n’y a guère de surprise ici. Il est intéressant toutefois de voir l’auteur articuler son propos à la croisée des succès techniques, individuels et organisationnels.

Le « comment » devenir agile ne réserve guère plus de surprises, moins même. Les quelques pages qui lui sont dévolues se concentrent sur le manifeste agile : les valeurs et les principes, sans entrer dans les détails. Les détails, ils sont pour le chapitre 3 qui couvre XP, ou plus exactement l’interprétation par l’auteur de XP. La description est déjà colorée de pratiques et de rôles qui n’appartiennent pas au corpus d’extreme programming. La méthode originale en est difficile à reconnaitre. Le chapitre 4 « adopting XP » permet mieux de reconnaitre la méthode et ses vecteurs d’adoption. A une différence de taille : la recommandation d’adopter XP pour les projets « page blanche » qui me semble à la fois réducteur et en décalage avec le monde réel.

La seconde partie couvre un peu plus de 280 pages, donc bien plus de la moitié du texte. Ce sont 5 chapitres qui figurent ici, autant dire qu’ils sont plutôt volumineux. Le chapitre 5 « thinking » ouvre le bal. On y trouve un assemblage assez hétéroclite de pratiques telles que le pair programming et les rétrospectives. Peu d’entre elles sont en fait strictement relatives à XP. Le format retenu pour décrire chaque pratique n’est pas des plus attractifs non plus, et cela on le retrouvera dans tous les chapitres.

Le chapitre 6 nous parle de collaboration, peu de pratiques sont en provenance d’XP mais finalement peu importe. Une section importante est consacrée à la confiance, avec 4 stratégies d’équipe et 6 stratégies organisationnelles. C’est ma partie préférée du chapitre. Petite surprise aussi de trouver une pratique issue du Domain Driven Design, apparemment un des centres d’intérêt des auteurs !
« releasing », au chapitre 7 est certainement avec le chapitre 9, le plus proche de XP. Bien que la définition de terminé soit un de mes thèmes, le concept de « done done » me donne des boutons. A quoi ressemble donc le « done not done » ? La plupart des autres pratiques gravitent autour de l’intégration continue, on est plutôt en terrain connu. Au chapitre 8, il est question de planification. Nous nous éloignons pas mal d’extreme programming, mais les auteurs proposent une trame intéressante bien que moins extrême partant de la Vision au planning game en passant par le release planning. Des concepts tels que le cône d’incertitude et la gestion des risques sont aussi abordés. Mais je ne suis guère les auteurs sur le « slack », en tout cas tel qu’abordé. Le chapitre 9 qui clôt cette partie est volumineux, essentiellement parce que le refactoring y prend beaucoup de place, expliqué et illustré avec du code pas à pas. Je ne trouve pas que cela soit une bonne idée pour un ouvrage généraliste. C’est à la fois trop et trop peu.

La 3ème partie « mastering agility » couvre 45 pages mais comprend 6 chapitres qui seront donc petits. Les quelques pages du chapitre 10 « values and principles » me semblent superflues car abordées au chapitre 2. D’accord il s’agit ici des valeurs et principes d’XP… Le chapitre 11 sur l’amélioration du processus semble alléchant de prime abord, mais il nous laisse finalement sur notre faim en s’arrêtant sur le « pourquoi » et en l’illustrant d’une anecdote personnelle ! Le chapitre 12 « rely on people est peut-être le plus intéressant, qui nous invite à construire le processus pour les personnes, même si une fois encore, on reste sur la déclaration d’intention.

Éliminer le déchet, au chapitre 13, sonne très « lean ». Les concepts évoqués ici sont parmi les plus importants : travailler en petits lots et maximiser le travail non fait. Des idées que l’on retrouve dans d’autres livres, mais à ne pas rater. Délivrer de la valeur, au chapitre 14, est alléchant car définir la valeur est un peu le serpent de mer du développement logiciel. En lieu et place, le texte évoque les livraisons fréquentes et la boucle de feedback. C’est bien mais c’est un peu l’arnaque. L’ouvrage se referme sur un chapitre 15 dédié à l’excellence technique. Les thèmes mis en exergue nous rappelleront le « clean code » de Robert Martin, mais pas seulement. Une bonne façon de refermer l’ouvrage.

J’étais assez content d’avoir terminé cette lecture. Certes, les sujets m’étant déjà largement connus, je ne suis pas le public cible, mais l’auteur semble vouloir aborder absolument toutes les facettes du développement logiciel. Comme dit le proverbe : « qui trop étreint mal embrasse », et c’est bien le cas ici, et au final le texte est trop lourd.

Référence complète : The Art of Agile Development – James Shore & Shane Warden – O’Reilly 2008 – ISBN : 978 0 596 52767 9