Le mineur, le missile et le marin, ou l'agilité par l'exemple

Dans la section Informatique

Une Image...

Top Articles

Joomla Templates

Le mineur, le missile et le marin, ou l'agilité par l'exemple

Informatique - Méthodes

Écrit par Vincent MARTIN

Derrière ce titre aux allures de fable (« fabuleux » donc, selon la première acceptation du terme

), trois exemples parmi ceux que j’utilise parfois à propos de l’agilité et de ses principes.

Ils illustrent l’intérêt de l’itérativité et de la priorisation par la valeur, de la réévaluation périodique du besoin et de la nécessité de valoriser le changement au lieu de le refuser. Trois exemples en un, ou une « analogie des 3M » (comme le fabricant des Post-it™, Scrum jusqu’au bout).

photo d'entête Idec – Francis Joyon © AFP - http://www.infobateau.com/francis-joyon-idec-deuxieme-route-du-rhum

Le mineur

L’exemple du mineur illustre les avantages de l’itérativité. J’en ai déjà parlé sur ce site : http://www.computure.net/fr/methodes/122-tutorial-scrum-lagilite-et-la-priorisation-par-la-valeur. J’y reviendrai donc juste en quelques mots : imaginons un processus de transformation de minerai minier, capable de transformer du minerai directement extrait de la mine, en un certain nombre de lingots. On comprend facilement qu’en traitant le minerai petit tas par petit tas, on est capable de livrer des lingots plus vite qu’en appliquant chaque phase de la transformation à l’ensemble du minerai. Le traitement itératif produit donc de la valeur plus vite que le même traitement, appliqué étape par étape sur le tout.

On voit bien aussi que, si on est par ailleurs capable d’attribuer une valeur à chaque lot de minerai – par exemple en fonction de la mine ou du filon dont il est extrait – on a tout intérêt à transformer d’abord les lots les plus « riches », ceux qui sont porteurs de la plus grande valeur. Prioriser le projet par la valeur permet donc de produire le plus de valeur le plus rapidement, donc d’optimiser la production de valeur.

Le missile

Dans l’exemple du missile, j’évoque le cas d’un missile qui doit régulièrement, au cours de son vol, se livrer à de nouvelles acquisitions de sa cible. Ces acquisitions périodiques sont particulièrement profitables dans deux cas :

soit la cible est mobile, et le nombre d’acquisitions devra être d’autant plus important que l’amplitude de ce déplacement sera important – par rapport au temps de vol du missile – et, bien sûr, imprévisible ;
soit les conditions de vol sont changeantes, et de façon imprévisible ; typiquement, les conditions météo, complexes, combinées avec des paramètres de vol eux aussi changeants (charge diminuant avec la combustion de carburant).

L’analogie avec l’agilité est simple : plus on collabore avec le client, plus on fait le point (l’acquisition) sur son besoin et les exigences du produit (la cible), plus le résultat du processus de développement aura des chances d’être proche du besoin de ce besoin, d’être en adéquation (pour reprendre un mot à la mode) avec lui, et d’améliorer la satisfaction du client.

Les bénéfices vont au-delà de la simple réussite d’un projet donné. Si les utilisateurs sont satisfaits, le client aura confiance en vous, et il vous fera certainement confiance pour un autre projet.

Le cas de la météo est presque un cas d’école : du fait de son caractère changeant et de la complexité du modèle à établir, la fiabilité des prévisions météo est inversement proportionnelle à leur durée. Dans le monde du développement logiciel, c’est un peu la même chose : il est plus difficile de faire des prévisions et des plannings à long terme que sur les trois ou quatre prochaines semaines, grosso modo le prochain sprint. Etonnamment, si personne ne prend plus désormais au sérieux une prévision météo à long terme (tout au plus évoquera-t-on le « bon sens paysan », ce qui au passage en dit long sur le sérieux qu’on lui accorde), personne ne remet en cause l’idée d’un planning détaillé sur un projet complexe de plusieurs mois !

Le marin

Ces quelques réflexions préliminaires pour nous amener à notre troisième exemple, celui du marin, ou plus précisément celui qui pratique la voile. Le moteur du voilier, c’est le vent, autrement dit – avec la girouette – l’image même du changement.

L’équipage d’un voilier ne peut pas éviter le vent. L’intérêt de la démarche consiste justement à accepter le vent, quelles soient sa nature, sa force et sa direction. Mieux, à l’utiliser, à adapter et modifier son allure pour le valoriser et atteindre malgré tout son objectif – on serait presque tenté de dire : « contre vents et marées ».

Le marin ne peut pas se passer de prévisions météo. Mais il sait qu’un bulletin météo précis ne sera valable que pour la nuit prochaine, éventuellement le lendemain ; s’il veut traverser l’Atlantique, il ne prendra pour estimer sa date d’arrivée que les paramètres « macro », ceux qui ont peu de chances de bouger : les performances de son bateau et de son équipage, les conditions météo « habituelles » en cette période de l’année. Et il prévoira une marge d’erreur qui sera fonction de la durée de la traversée et des inconnues du modèle.

Au passage, on notera que le marin avisé cherchera plus à amener son bateau et son équipage à bon port plutôt que de respecter à tout prix une route et un horaire donnés. Une petite pique pour les adeptes de la planification détaillée...

Aujourd’hui, le changement, pour une équipe projet, comme le vent pour le marin, est omniprésent – il est technique, métier, organisationnel. Dans un contexte fortement concurrentiel, il ne peut pas être ignoré. A minima, il doit pouvoir être utilisé pour maintenir le projet à flot, au mieux on saura le valoriser pour construire un produit qui correspond aux priorités des utilisateurs et aux contraintes du sponsor.

A l’arrivée au port, de l’autre côté de l’Atlantique, l’itinéraire parcouru n’a souvent pas grand-chose à voir avec la route que le marin ou son staff aurait pu imaginer au départ de la course. Un coup d’œil sur les routes parcourues par les concurrents d’une épreuve comme la Route du Rhum (2010) suffit à s’en persuader.

Route du Rhum 2010
(© BretagneNet - http://flash45f.free.fr/)

Agilement et computurellement vôtre.

Retrouvez tous nos articles sur www.computure.net.

Pour tout savoir de Scrum et de l'agilité :

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...
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...
Une expérience intéressante. Les méthodes de développement classiques demandent de spécifier en détail. A l’inverse, pour les méthodes agiles, une liste d’items peut suffire démarrer un projet. Sur ce sujet, voici une expérience intéressante. 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.