samedi 10 décembre 2011

Agile Tour Paris 2011 : "Le bout du Tunnel par Pierrick Thibault d'Agile Garden"

Description donnée sur le site de l'Agile Tour : "Nous connaissons tous l'effet tunnel pour avoir travaillé sur des projets au long cours pilotés par les spécifications. Pourtant, de nombreux projets continuent à fonctionner de cette manière en suivant le bon vieil adage "c'est sûr, on fera mieux cette fois-ci". Il est en effet difficile dans la multiplicité des paramètres de la conduite de projet informatique de faire ressortir que le mode spécifications écrites, développement long, livraison est en lui-même une cause importante d'échec. Cet atelier ludique propose de montrer de manière simple les limites des spécifications écrites et de faire apparaître l'intérêt de miser sur les interactions entre le porteur de la vision et l'entité en charge de sa réalisation. Le corps de l'atelier est constitué de 2 sessions totalisant 30mn, le reste du temps étant réservé à la présentation et mise en place de l'atelier, au dépouillement des résultats et à la discussion."

L'atelier consistait à former des équipes de 2 personnes :
- un client avec sa vision d'un produit (un dessin géométrique en l'occurence);
- un développeur en charge d'exécuter ce dessin.

Session 1 : Le développeur de chaque équipe sort de la salle. Puis uniquement par écrit (aucun dessin ni symbole), le client doit mettre sur une feuille les informations qui permettront à son développeur de reproduire le dessin. Au bout des 10 minutes, le client sort de la salle avec le dessin qui a servi de modèle et le développeur entre. Ce dernier a 10 minutes à son tour pour faire un dessin en se basant sur les écrits que lui a laissés le client.

Session 2 : distribution d'un nouveau dessin mais cette fois-ci, le client et le développeur ont le droit de rester dans la salle. Le client cache le dessin au regard du développeur et lui donne des instructions uniquement à l'oral (pas de signe des mains) pour reproduire le dessin qu'il voit. Le développeur peut poser des questions à son client.

Résultat : le dessin produit à la session 2 est plus fidèle (voir complètement fidèle) au modèle, alors qu'il y avait beaucoup de décalages sur le dessin de la session 1. Et pour plusieurs groupes, le travail a été plus court lors de la session 2 : 5 minutes pour finir au lieu des 10 allouées.

Cet atelier a fait ressortir en pratique les travers de la gestion de projet en cycle en V. Les spécifications écrites, malgré les efforts du client, ne seront pas assez claires ni assez exhaustives pour permettre au développeur de sortir un produit qui collera à la vision client. La différence de culture et de vécu de chacune des parties amènera forcément des interprétations différentes des écrits. De plus, même un temps important consacré à l'écriture ne permettra pas d'avoir une communication aussi bonne qu'une discussion avec des échanges. La session 2 l'a bien prouvé : sur un mode de feedbacks fréquents et d'interactions entre le réalisateur et son client, le résultat est bien plus proche de l'attente de ce dernier.

Qu'ai-je appris au cours de ces deux sessions de jeu ? Finalement, des choses que je savais déjà. MAIS la grande force est d'avoir, au travers d'un jeu simple de 30 minutes, de quoi faire réfléchir les participants et aussi donner des arguments pour convaincre les gens de passer à l'Agile.

Vous pouvez le faire avec vos collègues : ça ne dure que 30 minutes et c'est facile à mettre en place !

ROTI : 5/5

2 commentaires:

  1. Ce p'tit test est très connu en communication ... et est toujours très intéressant ... on peut aussi le faire avec des cure-dents pour une vision 3D des choses. Mais finalement est ce la méthodologie qui est à mettre en cause ou juste la non capacité de chaque individu de comprendre les non-dit et d'en déduire par conséquent sa propre image qui sera forcément erronée .. le mode feedback permettera à l’individu de corriger progressivement sa vision afin d'arriver à une vision "égale" à celle du demandeur ... c'est notre principe de cognition qui fonctionne comme cela ;) ... donc en plus d'être Agile c'est juste naturel.

    RépondreSupprimer
  2. Merci pour ce commentaire.

    Conclusion : les spécifications écrites ne sont pas naturels... Ceci explique pas mal de choses maintenant que j'y pense :P

    RépondreSupprimer