Note de lecture : Agile Metrics in Action, par Christopher W. H. Davis

Note : 3 ; L’agilité à mi-chemin.

Ce livre est une déception, je n’ai hélas pas d’hésitation à cet égard. Il est vrai que l’on manque souvent sur les projet agile à mesurer des choses alors que la collecte de faits tangibles est la base d’une démarche Lean ! L’origine de cet ouvrage est un système de collecte de mesures pensé et développé par l’auteur et déployé sur les équipes dont il était le manager. Ce système collecte des données depuis Jira, Github, Jenkins, la plateforme de déploiement et Google Analytics, pour ensuite consolider cela. Une idée tout à fait brillante. Malheureusement, comme nous allons le voir, le livre ne parvient pas à valoriser cela.

La structure de l’ouvrage suit en grande partie les 5 grandes « travées » que l’auteur voit dans le développement agile. Il est organisé en 10 chapitres format 3 parties, le tout totalisant 220 pages. A cela il faut ajouter les 2 annexes qui ajoutent près de 20 pages : celles-ci apportent quelques éclaircissements sur la chaine de collecte conçue par l’auteur. La première de ces parties ne compte qu’une trentaine de pages sur deux chapitres. Le premier d’entre-eux « Measuring Agile Performance » dresse sur près de 20 pages un tableau du problème que l’on s’efforce de résoudre. Je ne suis que partiellement d’accord avec l’auteur, par exemple quand il prétend que l’on a pas une vue claire de nombreux concepts comme celui de « bonne qualité » ou qu’il pointe du doigt le focus sur le produit plutôt que sur le projet comme un problème !

Le second chapitre « observing a live project » nous donne un éclairage sur le fonctionnement du projet s’appuyant sur les collectes de métriques. On y voit que les mesures de productivité ont une part prépondérante (vélocité, nombre de lignes modifiées). On voit aussi que la peinture agile du projet présente de nombreuses craquelures : l’utilisation des mesures ressemble à du contrôle en bonne partie, destiné à un « leadership team », joli contresens pour appeler ce qui n’est autre qu’une équipe pilotage (a.k.a. « papa-maman »). Une autre observation, qui sera récurrente, est que la plupart des diagrammes sont difficiles à interpréter. La plupart du temps, je ne suis pas parvenu à comprendre comment l’auteur parvenait à ses conclusions…

La seconde partie « collecting and analysing your team data » est nettement plus importante, avec 90 pages et 4 parties. Il débute avec la chapitre 3 « trends and data from project-tracking system » qui occupe 24 pages. On commence fort avec une orientation forte : abandonnez votre management visuel physique pour ne garder que l’outil électronique (ici Jira). La capacité de tracking semble avoir le pas sur le bien-être de l’équipe… C’est néanmoins l’un des chapitres les plus clairs. Mais les mesures tournent beaucoup autour de la productivité et des temps de développement.

Le chapitre 4 évoque sur 20 pages les métriques issues du système de versionning, en l’occurrence Github. Comprendre comment extraire des données de Github est réellement intéressant. Ici, c’est surtout le volume de lignes modifiées, l’activité de l’équipe autour des commits, le délai entre pull request et commits ou la présence de commentaires qui sont regardés. Je ne suis pas certain que le CLOC soit une mesure si pertinente, alors que la corrélation entre tâche et impact des changements dans l’espace (nombre de classes, nombre de packages) aurait donné un éclairage en terme de qualité. J’ai bien aimé l’idée de la mesure du « lagging pull », de l’interprétation des commentaires, et aussi la corrélation avec Jira, mais en fait guère plus.

Au chapitre 5, ce sont intégration continue et déploiement continu qui sont à l’honneur, et c’est Jenkins qui illustre cela. La chaine de build et les informations exploitables de Jenkins sont bien abordés, apparemment cet aspect est l’un des points forts de l’auteur. Malheureusement encore, l’auteur échoue à produire des diagrammes traduisant clairement son propos. J’imagine qu’ils sont moins hermétiques quand on est dans le projet, mais c’est assez douloureux pour le lecteur…

Cette seconde partie se referme sur la chapitre 6 qui se focalise sur la surveillance de la santé du système en production. C’est sur New Relic et StatsD que la collecte de ces informations repose. Un chapitre très intéressant aussi bien sur la finalité des mesures que sur quelques clés de mise en place. Dommage qu’il n’y ait pas de corrélation avec les autres mesures. Je pense que l’on aurait pu faire quelque chose, ne serait-ce que pour montrer l’évolution des tendances entre 2 mises en production…

La troisième partie agrège ce qui a été vu précédemment pour donner de l’information de plus haut niveau. Du moins est-ce l’idée. 4 chapitres sur 95 pages sont consacrées à cela. On commence par le chapitre 7 qui explore l’agrégation des données collectées sur 25 pages. Plutôt que donner des mesures standard, l’auteur y expose sa méthode pour créer des mesures agrégées. C’est un peu ennuyeux, à part l’utilisation de mind map pour explorer les questions. Le cas d’étude sur la « continuous release quality » n’est pas aussi passionnant qu’il devrait.

Le chapitre 8 traite de la qualité interne du logiciel, les fameuses « illités » au long de17 pages. Il s’agit surtout de métriques de maintenabilités, s’adossant essentiellement à des mesures de temps de cycle et de couverture de code, ce qui n’est pas génial, car il s’agit là d’indicateurs « proxy ». L’usability est abordée, mais de manière franchement superficielle.

Le chapitre 9 traite d’un sujet d’un peu plus haut niveau : la publication de métriques. La question occupe 23 pages qui rassemble des aspects tels que : quelles informations pour quels acteurs ? Comment publier ? Comment adapter le mode de publication et la fréquence aux acteurs ?

La 3ème partie se referme sur le chapitre 10 qui évoque les métriques par rapport aux principes agiles. Encore une fois l’auteur interprète les choses assez singulièrement. Par exemple, on utilise des informations de Jira pour mesurer le « face to face conversation ».

Au global, le livre est une déception. J’ai été aussi pugnace que possible, mais l’ennui m’avait déjà largement gagné au chapitre 7. Pourtant, on part de bonnes idées, celle de collecter des informations de différentes sources et de les corréler. Mais d’une part, ces idées prennent une direction qui n’est agile qu’à moitié. Et d’autre part la forme échoue à être intéressante. J’aurais d’avantage imaginé un découpage par domaine de pratique et des propositions de métriques sous la forme de patterns, ciblant à chaque fois une nature d’information actionnable et les corrélations de données nécessaires à sa construction.

Référence complète : Agile Metrics in Action – Christopher W. H. Davis – Manning 2015 – ISBN : 978 1 617292 48 4

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s