Aujourd'hui, nous cherchions une métaphore pour comparer le cycle en V à un cycle itératif et incrémental.LE PARCOURS PRÉDICTIF
Il nous a semblé que conduire un cycle en V revient à prendre le temps de visualiser où on souhaite se rendre, à prévoir la trajectoire à suivre pour atteindre ce lieu, à estimer le temps qu'il faut pour parcourir le chemin, puis à fermer les yeux et se diriger sans voir vers cette destination. Quand la durée estimée du trajet est atteinte, on ouvre les yeux.
LE PARCOURS ADAPTATIF
Conduire un cycle itératif et incrémental revient à répéter en boucle la démarche suivante: jeter un coup d'œil rapide vers sa destination, fermer les yeux, faire quelques pas sans voir vers cet objectif et ouvrir les yeux. Plus le nombre de pas entre deux coups d'œil est réduit, et plus le pilotage est fin.
LA MÉTAPHORE CONCRÉTISÉE PAR UN ATELIER
Cette métaphore peut être jouée en atelier. Deux volontaires côte à côte se voient attribuer une même destination. Le premier doit se rendre à ce lieu en suivant la première démarche. Le second adopte la deuxième démarche.
Pour pimenter l'atelier, le parcours peut être initialement perturbé par un obstacle, comme une chaise ou une personne. Il est également intéressant d'ajouter un obstacle supplémentaire (une autre chaise ou une autre personne) en cours de parcours.
Ensuite, il peut être intéressant de rejouer le même atelier, mais cette fois avec deux volontaires adoptant la deuxième démarche. Le premier ouvre les yeux tous les pas. Le deuxième n'ouvre les yeux que tous les trois pas.
A EXPÉRIMENTER
J'utiliserai cette métaphore et j'essayerai ces petits ateliers avec les étudiants lors de mes prochains cours de génie logiciel pragmatique.
EN CONCLUSION
Cette métaphore ne suffit pas à illustrer les différences entre les deux démarches. Aussi, cette comparaison est caricaturale. Personne ne mène un cycle en V aussi aveuglément (rassurez-moi). En cours de développement, il y a bien sûr des réajustements (tardifs certes, mais il y en a toujours). Néanmoins, cette métaphore me semble être une bonne vulgarisation.
Une alternative pour éviter que les participants se fassent mal dans les obstacles (c'est un risque avec les yeux fermés) est de demander à une équipe d'écrire le parcours sur un papier pour aller d'un point de départ à un point d'arrivée (avec des ordres simples, Pas, Droite 90, Gauche 90, Recul ...). L'équipe peut changer le plan prévu, mais doit absolument réécrire l'ensemble du trajet (en partant toujours du début). Cette approche reprend le mécanisme du cycle en V, avec les mêmes défauts.
RépondreSupprimerTu peux donc rajouter des obstacles sans risque de blessures. Pour l'approche agile, il suffit de demander à l'équipe de prévoir 3 mouvements (ou 1 comme tu le proposes) et de replanifier tous les 3 mouvements.
Pour donner un objectif à l'équipe, tu peux demander d'aller ramasser une balle qui est au point d'arrivée, et pour donner plus de réalité au jeu, rien ne t'empêche de déplacer la balle en cours de jeu (pour bien montrer que le client change d'avis).
je pourrais ajouter un petit détail: N'oublie pas que en tant qu'inexpérimentés, les étudiants ont d'abord besoin, avant de savoir les avantages et inconvénients de chacune des approches, de comprendre l'utilité d'avoir justement une approche (quelle qu'elle soit).
RépondreSupprimerMoi je rajouterais à cette métaphore un parcours sans aucune méthode. Genre "va là bas, débrouille toi".
Parce que peut être que ça vous paraît fou, mais quand on n'a jamais vu de projet logiciel, on peut s'imaginer que ce n'est pas utile de se formaliser à un "cycle". Enfin en ce qui me concerne j'ai eu besoin de preuves ! (je les ai maintenant, mais c'était pas immédiat).
N'oublie pas que certaines boîtes (peu recommandables peut être mais...) ne savent pas répondre sur "vous êtes plutôt cycle en v ? itératif ? ...?" Et que des étudiants pourraient s'y retrouver et ne pas savoir que faire ;°)
Je réagis avec un peu de retard, mais c'est marrant Emmanuel, parce que je planche justement depuis qq temps sur la question.
RépondreSupprimerCe que tu suggères comme atelier, c'est le même genre de problèmes rencontrés en IA pour la navigation de robots : l'approche prédictive montre très vite ses limites, dès que l'on dépasse les problèmes triviaux...
Je suis d'ailleurs en train de rédiger une présentation où je pousse plus loin la métaphore de l'orientation.
En orienteur aimant courir dans les bois, j'essaie de transposer les techniques avancées d'orientation au design/dev adaptatif et incrémental.
Ca t'intéresserai de relire un draft ? =;]