Une expérience intéressante

Dans la section Informatique

Une Image...

Top Articles

Joomla Templates

Une expérience intéressante

Informatique - Méthodes

Écrit par Vincent MARTIN

Les méthodes de développement classiques demandent de spécifier en détail avant de se lancer dans un développement. A l’inverse, pour les méthodes agiles, une liste d’items, décrits sous la forme de simples user stories, peut suffire à constituer un backog de produit et démarrer un projet. Sur cette différence, et grâce à un exercice proche de l’esprit des « serious games », voici une expérience intéressante.

Lors d’une formation, un animateur divise son groupe de stagiaires en deux groupes d’à peu près six personnes. A chaque groupe, il donne une feuille de papier, autant de feutres rouges, verts et bleus qu’il y a de participants et leur donne une minute pour réaliser un dessin suivant un Cahier des Charges.

La mission du premier groupe est de dessiner « une belle prairie d’été avec des fleurs bleues et rouges dans de l’herbe verte, des vaches et des oiseaux sous un soleil éclatant ».

Le deuxième groupe doit répondre aux exigences suivantes :

« 10 fleurs bleues avec 5 pétales chacune,
5 fleurs bleues avec 6 pétales chacune,
13 fleurs rouges avec 6 pétales chacune,
2 vaches avec 3 taches noires,
1 vache avec 5 taches noires,
2 vaches avec 4 taches noires,
2 oiseaux dans le coin supérieur gauche,
3 oiseaux au milieu,
un soleil à droite avec 5 rayons. »

Le résultat est le suivant :

Le dessin du haut est celui qui a été réalisé par le groupe avec le Cahier des Charges le moins précis et celui du bas par le groupe qui avait les spécifications les plus détaillées.

Au-delà de l’aspect artistique (même si c’est sans doute le dessin du haut qui est le plus réussi), on constate que le dessin du bas est, non seulement incohérent (les vaches sont sens dessus-dessous), mais aussi incomplet (il n’y a ni prairie ni soleil).

Cette expérience n’a pas valeur de preuve, évidemment, et tout est affaire d’interprétation. Personnellement, l’enseignement que j’en tire est qu’une vision globale mais ouverte du produit est suffisante pour en avoir une première version cohérente, quitte à l’enrichir progressivement pour satisfaire les exigences de départ.

Plus intéressant encore, il semble que des spécifications sur-détaillées focalisent l’attention sur les détails et empêchent d’avoir une vision d’ensemble. Attaquer le développement avec des spécifications encore fragmentaires n’empêche pas d’en avoir une vision globale, bien au contraire !

Dans tous les cas, l’important est d’avoir, non pas un, mais plusieurs niveaux d’abstraction, suffisamment ouverts pour ne pas occulter les autres, qu’ils soient plus globaux ou, à l’inverse, plus détaillés.

Ce billet reprend une expérience de David Barnholdt. Elle est consultable dans son intégralité dans sa version originale (en anglais) ici : http://blog.crisp.se/davidbarnholdt/2009/02/18/1234986060000.html.

Computurellement vôtre

Retrouvez tous nos articles sur www.computure.net.

Pour tout savoir de Scrum :

L’essentiel de SCRUM. SCRUM est aujourd’hui la méthode agile la plus utilisée et la plus riche en termes de retour sur investissement. Voici, en quelques billets, l’essentiel de la méthode. lire la suite…
L’essentiel de SCRUM (suite). Un deuxième billet sur l’essentiel de la méthode, plus orienté cette fois sur les « cérémonies » (les réunions). lire la suite…
Tutorial Scrum : l'agilité et la priorisation par la valeur. Comme dans le tutorial sur les niveaux de maturité de CMMI, une petite analogie pour aborder quelques-uns des principes de l’agilité et de la méthode Scrum. lire la suite...
Le mineur, le missile et le marin, ou l'agilité par l'exemple. Derrière ce titre aux allures de fable, trois exemples parmi ceux que j’utilise parfois à propos de l’agilité et de ses principes. lire la suite...
Computure lance le projet DSA : Les dictionnaires sont à la mode. Les éditions Plon confient depuis quelques années un « Dictionnaire amoureux de ... » à des pointures du monde de la culture. A l'exception du format, évidemment imposé (le lexique classé alphabétiquement), le procédé laisse à son auteur toute liberté quant au choix de ses entrées et de ses textes. lire la suite...

Et dans la catégorie « Méthodes », retrouvez également les articles suivants :

Aider le client à prioriser ses exigences. Comment prioriser son besoin à l'aide du modèle de Kano. lire la suite...
Les exigences : définition et classification. La gestion des exigences est aujourd’hui une activité majeure de l’ingénierie du logiciel. Elle est couverte dans CMMI par deux domaines de processus : REQM (Requirements Management : niveau 2) et RD (Requirements Development : niveau 3). Voici le premier de quelques billets consacrés à l’essentiel de l’ingénierie des exigences… lire la suite…
Tutorial : les niveaux de maturité de CMMI. Tout le monde le sait : rien ne vaut une analogie pour comprendre un concept un peu abstrait. Lorsque j’explique les niveaux de maturité du CMMI (Capability Maturity Model Integration), j’utilise souvent une analogie, disons... domestique. lire la suite...
sans oublier le très populaire Petit lexique du chef de projet informatique.