L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

Il y a quelques jours semaines^[1], l'institut agile a publié la 1ère version du référentiel des concepts, pratiques et compétences agiles.

Par les temps qui courent, de plus en plus de monde s'intéresse aux méthodes agiles et le nombre d'experts de la chose s'adapte bien évidemment à la demande qui en résulte. Dans un tel contexte, un référentiel a un intérêt immédiat : clarifier les définitions du vocabulaire agile pour que tout le monde parle de la même chose avec les mêmes mots.

Et même en ayant une bonne expérience des méthodes agiles, je crois que l'on sous-estime le besoin de définitions partagées et non ambigües.
Un exemple. Récemment, lors d'une discussion sur la liste "xp-france", j'ai posé une question et j'ai eu la réponse suivante :

Les équipes que j'ai vu faire de l'agile utilisent le concept d'itération pour répondre à cette question. A intervalles réguliers, ils vérifient avec les clients (parfois nommés aussi "utilisateurs") que le produit correspond à ce qu'ils sont prêts à payés.

La réponse ne correspondait pas à ce que j'attendais^[2].
En temps normal, je n'aurais pas creusé plus loin mais, là, je suis allé voir la définition d'itération dans le référentiel :

Une itération au sens Agile est une "boite de temps" ou "timebox" dont la durée:
*varie d'un projet à l'autre, de 1 semaine à 4 semaines, rarement plus
*est en principe fixe sur la durée du projet

Une boîte de temps ou "timebox" est une période fixe pendant laquelle on cherche à exécuter le plus efficacement possible une ou plusieurs tâches.

Et il se trouve que, depuis quelques mois, mon équipe n'utilise plus de boites de temps^[3] ce qui ne nous empêche pas de demander très souvent à notre chef de produit si ce que l'on fait correspond bien à ce qu'il a en tête.
Cette possibilité de vérification n'est donc pas issue des boites de temps.
En fait, ce qui permet à un client de vérifier très souvent que le produit correspond à ses attentes, c'est le développement incrémental

Pour s'en convaincre, il suffit d'aller regarder la définition dans le référentiel :

Le développement incrémental consiste à réaliser successivement des éléments fonctionnels utilisables, plutôt que des composants techniques.

J'apprécie énormément cette précision sur les termes utilisés.

Le seul reproche que je pourrais faire au référentiel dans sa version actuelle, c'est la frontière qui me parait encore un peu ambigüe entre les "concepts" et les "pratiques".
Pour ma part, j'aurais plutôt vu "développement itératif" et "développement incrémental" dans les pratiques et non pas dans les concepts.

Ceci étant dit, le potentiel de ce référentiel me parait important.
Je ne sais pas si c'est un objectif souhaitable pour ce référentiel mais j'y verrais bien une plus grande articulation des pratiques entre elles, façon pattern language.

Le canevas de description des pratiques est ce que l'on attendrait classiquement d'une fiche de pattern^[4]
Par exemple, chaque pratique contient une section "bénéfices attendus" qui la met en perspective en tant que solution possible à un problème que l'on pourrait rencontrer.

Un exemple assez représentatif : intégration continue

* le principal intérêt de l'intégration continue est de réduire la durée, l'effort et la douleur provoquée par chaque intégration, l'expérience suggérant qu'il existe un "cercle vicieux" dans le sens inverse: plus les intégrations sont espacées, plus elles sont difficiles, et plus (en réaction à la douleur provoquée) on a tendance à les espacer
* l'intégration continue démultiplie le bénéfice d'une batterie étendue de tests unitaires: elle permet de détecter au plus tôt les défauts n'apparaissant qu'à l'intégration et par conséquent de minimiser leurs conséquences et les risques associés aux défauts d'intégration
* l'intégration continue permet de tirer le meilleur parti du développement incrémental: des questions comme l'installation et le déploiment du produit ne sont pas laissées de côté jusqu'à la fin du projet mais résolues dès le départ dans le cadre de la pratique

Le petit plus qui permettrait d'atteindre le niveau langage de patterns, c'est une formalisation des liens entre les différentes pratiques. Dans l'exemple précédent quelques filiations apparaissent : pour qui implémente déjà la pratique "tests unitaires automatisés" ou la pratique "développement incrémental", l'intégration continue est une suite logique.

Ce langage de pratiques agiles, que l'on peut également qualifier de "framework agile" me semble inévitable.
L'agilité en est arrivée à un point où tout le monde essaie d'adapter les méthodes existantes à des contextes très variés (avec plus ou moins de savoir faire).
Une bonne boite à outils serait certainement très utiles à tous les apprentis sorciers qui conçoivent des schemas d'organisation agile après deux jours de formation Scrum et la lecture d'un ou deux livres.
Et aux autres, aussi, bien sûr.