Je n’ai pas écrit jusqu’ici à ce sujet, mais le moment est enfin venu de vous présenter le travail que nous avons réalisé dans le cadre de l’Agile Alliance Technical Debt Initiative.
J’attendais la publication de nos livrables, maintenant disponibles sur cette même page, pour écrire un post au sujet de ce programme et de notre groupe. Peut-être ne connaissez vous pas l’Agile Alliance, mais je suis sûr que vous au moins entendu parler du Manifesto Agile. Et bien, comme expliqué sur cette page, « L’Alliance Agile a été créée peu après cette rencontre afin d’encourager les professionnels à explorer et à partager idées et expériences » sur ces pratiques Agile.
Notre groupe s’est formé il y a un an, et nous avons eu notre première réunion en mai 2015, réunion de lancement afin d’organiser notre travail autour de différents objectifs, l’un d’entre eux consistant en la construction d’un modèle d’analyse de la dette technique. Nous collaborons principalement par Hangouts, puisque localisés dans différents pays des deux côtés de l’océan. Et ensuite, nous avons eu un workshop (atelier) à Washington, pour présenter et discuter de nos premiers résultats et partager opinions, suggestions et autres idées.
Il me faudra écrire un autre post dans le futur, au sujet de cet atelier, car c’est le meilleur auquel j’ai jamais participé. Je me souviens qu’au début, j’étais absolument et complètement persuadé qu’il serait impossible de couvrir tous les points à l’ordre du jour. Mais nous l’avons fait, sans nous précipiter ou bâcler le travail, notamment grâce à Declan, l’un des chairmen de notre groupe, mais aussi un consultant Agile et un directeur de l’Agile Alliance, ainsi qu’à Jean-Louis, également chairman et auteur reconnu de la méthode SQALE de la gestion de la dette technique.
Il me faudra également réaliser un autre post sur le ‘Dice of Debt’ que Tom nous a présenté lors de cet atelier. Tom est directeur au sein du Cutter Consortium, spécialisé dans les sujets Agile – il faisait partie du panel d’analystes lors de l’évènement Agile 2015 – et également un expert en Gamification. Je me souviens de ce que Tom nous a dit quand il nous a présenté ces ‘dés de la dette’ : « Si vous faites une présentation, les gens ne vous écoutent pas. Si vous leur demandez de participer à un jeu, ils seront prêts à apprendre. » Il avait complètement raison, et tout le monde a eu beaucoup de plaisir à pratiquer le ‘Dice of Debt’, un jeu éducatif sur les pratiques agiles pour gérer la dette technique.
Pas simplement une autre publication sur la Dette Technique
OK, je sais ce que vous pensez : « Oh, une autre publication à propos de la dette technique. Comme si on n’en avait pas déjà assez. » Mais Je crois que nos livrables se démarquent de la littérature habituelle sur le sujet, pour plusieurs raisons.
Tout d’abord, il est vrai qu’il existe beaucoup d’articles et de posts sur ‘la’ métaphore, et tous ne sont pas vraiment fidèles à l’idée de départ. J’en ai déjà parlé il y a quelques années à l’occasion d’un post sur l’utilisation que font les ‘marketeux’ de ce concept.
Dans l’introduction de notre programme, nous avons présenté notre vision de la Dette Technique, et comme nous avons compté avec Ward Cunningham pour examiner et reviewer notre travail, je pense que nous sommes restés près de la métaphore originale.
Autre raison, pour ne pas dire autre différence : notre objectif principal a toujours été, depuis le début, de proposer une liste prête à l’emploi et la plus accessible possible de « bonnes pratiques qui, lorsqu’elles ne sont pas respectées, génèrent de la dette technique. » Donc notre modèle ‘Agile Alliance Debt Analysis Model’ (A2DAM) comporte une trentaine de règles de base, et vous pouvez démarrer immédiatement, par exemple en les incluant dans un ‘Definition Of Done’ pour gérer la dette technique sur votre projet. Il vous suffit de télécharger un pdf d’une page avec cette liste, ou pour les plus vétérans d’entre vous, une feuille de calcul plus complète si vous souhaitez personnaliser le modèle A2DAM.
Notez que simple ne veut pas dire simpliste, et vous trouverez sur la même page une explication détaillée des différents paramètres : seuils, coûts et types de remédiation, périmètre (scope), attributs SOLID et Simple Design, etc.) Nous voulions également que ces règles soient facilement automatisables, donc nous avons demandé à différents fournisseurs d’outils d’analyse de code (Source Code Analysis) d’examiner cette liste et de nous faire part de leurs commentaires. Merci à eux : vous trouverez le nom des participants dans la section ‘Acknowledgments’ à la fin de cette page.
Il existe moins de littérature sur la gestion de la dette technique au sein des projets agiles, à part quelques généralités assez évidentes. A ma connaissance, c’est la première fois qu’est proposée une liste d’actions pour gérer la dette technique aux niveaux Release, Itération et Story du projet.
Vous pouvez laisser un commentaire sur toutes ces pages, ils seront les bienvenus.
Plus à venir en 2016. Je n’ai pas parlé de Thierry et de Dan, qui ont participé à ce travail, et nous promettent quelques nouveautés pour les douze prochains mois. Aussi permettez-moi d’en terminer avec une présentation complète de notre groupe, et une photo prise lors de notre atelier en 2015.
Agile Alliance Technical Debt Initiative – Washington 2015
Thierry Coq, Jean-Louis Letouzey, Jean-Pierre Fayolle, Dan Sturtevant, Tom Grant, Declan Whelan
Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.