Planification Dimensionnelle en Agile

Ces dernières années, j'ai remarqué que je parle de plus en plus souvent du « Dimensional Planning ». J'ai découvert le Dimensional Planning grâce à Koen van Exem, l'un des premiers agilistes belges. Cette approche date des débuts du mouvement Agile (belge) et est malheureusement un peu tombée dans l'oubli.

Hier, j'en ai discuté avec JB (Rainsberger) et Alistair (Cockburn) et je me suis rendu compte que j'avais encore une belle histoire à raconter à ce sujet.

Avant de vous la partager, laissez-moi d'abord vous expliquer brièvement les bases du Dimensional Planning. L'idée est de décomposer nos Stories en différentes dimensions d'implémentation. Nous faisons cela parce que beaucoup de nos clients veulent une Lexus à la fin de la semaine. Mais nous n'y arriverons peut-être pas. En revanche, nous pouvons leur proposer une Toyota dès demain. La plupart des clients trouvent cette proposition géniale et peuvent patienter jusqu'à ce que nous puissions livrer la Lexus (autrement dit, un ROI obtenu rapidement).

J'aime beaucoup la façon dont Koen explique le Dimensional Planning

Imaginez que votre client souhaite une autoroute entre Amsterdam et Heusden. Vous êtes plutôt doué pour construire des autoroutes, alors vous vous lancez directement. Après quelques mois, vous avez terminé et vous laissez fièrement votre client emprunter l'autoroute pour la première fois. Il arrive à Heusden, mais n'a pas l'air particulièrement content. Vous lui demandez donc si les stations-service, les aires de repos et les sorties tous les quelques kilomètres lui conviennent. Bien que le client réponde oui à tout, vos questions semblent l'agacer encore plus. Finalement, il lâche le morceau : « Ce n'est pas l'endroit où je voulais aller ! »

Vous regardez le panneau de la ville : Heusden. Ne voulait-il pas aller à Heusden ? Si, c'était bien ça.

Mais il s'avère qu'il existe un autre endroit qui s'appelle également « Heusden ».

Vos avocats et ceux du client ont maintenant de longues discussions pour savoir à qui revient la faute et qui doit payer pour la mauvaise autoroute. (Si vous avez un bon avocat, votre client paiera et ne reviendra plus jamais…)

Dans ce cas, on pourrait bien travailler avec le Dimensional Planning. On commencerait alors par construire un chemin de gravier entre Amsterdam et Heusden.

En moins d'une semaine, vous auriez déjà terminé et constaté que vous aviez atteint le mauvais endroit. Pour vous, ce n'est pas un problème, car vous saviez qu'il y aurait l'un ou l'autre malentendu. Vous vous renseignez, trouvez l'autre Heusden et construisez un nouveau chemin de gravier. Après une semaine supplémentaire, cette route est également terminée et vous constatez avec votre client que c'est toujours le mauvais Heusden. Il y a en effet deux endroits portant ce nom en Belgique et encore un aux Pays-Bas. Qui aurait pu le deviner ?

Après une semaine de plus, votre client est content d'avoir enfin un chemin de gravier entre Amsterdam et le bon Heusden. (Et cela beaucoup plus rapidement qu'initialement prévu en plusieurs mois.)

Bien qu'il n'y ait pas encore toutes les fonctionnalités, on peut déjà constater un certain bénéfice, car le client peut maintenant faire la navette entre les deux sites de son entreprise. Ce n'est pas une route formidable et on ne peut pas rouler particulièrement vite, mais c'est nettement plus rapide qu'avec l'ancienne route et un détour de 100 km.

Le lendemain de l'achèvement du chemin de gravier, vous commencez à travailler sur une version pavée de la route, que vous terminez également après trois semaines. Vous pouvez tout aussi bien travailler sur une version asphaltée, goudronnée ou autoroutière. Dans la plupart des cas, les clients ne veulent plus l'autoroute dès qu'ils peuvent tirer profit des versions précédentes.

Nous savons tous qu'un client dira toujours « oui » si nous lui demandons s'il veut une autoroute, et que les développeurs adorent travailler sur toutes les fonctionnalités d'une autoroute.

Dans notre exemple automobile, la plupart des gens préféreraient aussi la Lexus à la Toyota – jusqu'au moment de payer, car là, soudainement, une Toyota suffit. Et de même, tous les développeurs ne veulent pas constamment penser à tous les détails que la Lexus exige.

N'est-il pas coûteux de construire trois routes en gravier, une route pavée, une route goudronnée et une autoroute ?

Bien sûr, c'est plus cher que de construire une seule autoroute. Mais nous savons tous que des erreurs se produisent et que c'est toujours moins cher que de devoir construire trois autoroutes, comme c'est souvent le cas dans le développement de produits.  

Avec ma méthode, nous nous préparons tellement bien que nous ne faisons jamais d'erreurs…

Si vous êtes sûr de vous et voulez prendre ce risque, vous pouvez bien sûr le faire. Et même si vous avez raison (je doute que ce soit toujours le cas), je suis relativement certain que la plupart des clients auront déjà changé d'avis au moment où vous commencerez à construire l'autoroute. Et des mois avant même que vous n'ayez commencé à construire, nos chemins de gravier génèrent déjà un retour sur investissement.

Ça semble bien en théorie. Mais est-ce que ça fonctionne vraiment en pratique ?

Bonne question ! J'ai failli oublier ; je voulais présenter dans cet article un bel exemple tiré de la vie réelle :

J'ai modifié quelques détails de l'histoire pour protéger le client.

Il s'agit du site web d'une entreprise. Celui-ci se trouvait cependant dans une zone complètement démilitarisée du réseau de l'entreprise. On y avait créé un petit produit qui devait être commercialisé via Internet. Le Chief Financial Officer (directeur financier) était un grand partisan de ce produit et voulait recevoir régulièrement les chiffres de vente. Pour cela, il aurait toutefois fallu franchir des zones de sécurité et intégrer les données de vente dans le système SAP.

Dans une grande entreprise, c'est un projet assez conséquent qui nécessite certainement six mois de travail de développement. Les préparatifs ont commencé par des réunions avec au moins 20 personnes (experts en sécurité, experts SAP, développeurs web et une foule de managers jusqu'au niveau juste en dessous du CFO).

Lors d'une réunion suivante, le CFO s'est plaint du manque de visibilité sur l'évolution des ventes du produit pendant les six premiers mois cruciaux. J'ai donc recommandé des projets parallèles temporaires en utilisant le Dimensional Planning (comme dans l'exemple de l'autoroute).

La version chemin de gravier :

Chaque jour, nous générions un rapport PDF sur le serveur web et le sauvegardions sur une disquette. (Rappelons qu'une grande partie du réseau n'était pas connectée au serveur.) Chaque jour, nous imprimions ce rapport et apportions une copie des chiffres de vente au bureau du CFO, où un stagiaire saisissait toutes les données dans notre système SAP. Le rapport PDF avait été créé par l'un de nos développeurs le jour même où le produit était mis en ligne. À la fin de la journée, nous avions déjà les données pour le CFO.

Premier problème : le CFO voulait quelque chose en plus ; quelque chose qui devait être demandé au client sur le site web. Le développeur avait fièrement montré le rapport au CFO et retournait maintenant à son poste de travail. Une demi-heure plus tard, l'information supplémentaire était demandée sur le site web et le nouveau rapport était généré (sans les données du premier jour). Dès le lendemain, un article de journal paraissait et de nombreux clients achetaient le produit. Le jour suivant, les premiers chiffres arrivaient déjà et notre stagiaire essayait de transférer les données dans le système SAP. C'est là que nous avons découvert notre deuxième problème. Il s'est avéré que nous utilisions la mauvaise table SAP. Il a fallu plusieurs jours pour corriger cette erreur. Le CFO continuait à recevoir son rapport, mais pendant la première semaine, cela ne pouvait pas encore se faire via SAP. Le vendredi de la première semaine, le stagiaire était en mesure de télécharger les données. Cependant, c'était un travail plutôt ennuyeux et absolument pas scalable. (Nous avions plusieurs milliers de ventes la première semaine.) Il était maintenant temps pour notre :

Version pavés :

Cette fois, nous avons créé le rapport au format CVS. (Rappelez-vous, c'était avant XML.) Chaque matin, le développeur qui arrivait le premier au bureau allait sur le serveur web, générait le rapport et le copiait sur une disquette. Ensuite, il prenait la disquette et téléchargeait les données dans notre système SAP. Cette version était plus évolutive ; peu importe combien nous avions vendu la veille, le travail pour notre développeur restait le même. Mais cette version avait aussi un petit problème. L'un des champs était formaté en texte au lieu d'un nombre. (Un bug tout à fait classique.)

Le travail devait être effectué personnellement par quelqu'un chaque jour. Il n'était pas automatisé et la mise à jour n'était effectuée qu'une fois par jour (pour la veille).

Puis les réunions pour la version autoroute ont commencé. À la fin d'une de ces réunions, j'ai demandé à un collaborateur du directeur financier comment ils utilisaient les données et s'ils étaient satisfaits des chiffres. Par hasard, j'ai remarqué que le directeur financier ne consultait les données que le vendredi. (Donc pas quotidiennement.) Cela ne le dérangeait même pas de ne pas connaître les chiffres de vente complets du jour ou de la semaine.

La version autoroute :

Heureusement, j'avais de toute façon une réunion avec le CFO et son collaborateur le lendemain. Nous avons parlé de l'avancement du projet Autoroute et du fait qu'il empêchait les gens de travailler sur un autre projet important. J'ai poliment suggéré de rester avec la version pavée et de mettre le projet Autoroute en pause pour le moment. Beaucoup de gens dans l'entreprise n'étaient pas particulièrement ravis, car ils voulaient vraiment travailler sur ce projet super cool. Le responsable sécurité, en revanche, était très content, car le serveur web pouvait ainsi rester dans la zone sécurisée. Au final, l'entreprise a économisé six mois de travail de développement pour une autoroute qui aurait mis le réseau en danger et qui n'aurait pas vraiment été nécessaire.

Quelques années plus tard, j'ai revu le CFO. Il a admis que le projet Autoroute aurait probablement été excessif, car le produit n'avait jamais rapporté ne serait-ce qu'une fraction de ce qu'il aurait fallu dépenser pour le projet Autoroute. Grâce au projet Route de gravier, ils ont pu découvrir assez tôt que les adresses e-mail des clients manquaient encore, et c'était la meilleure chose qui pouvait leur arriver. Avec cette liste d'e-mails, ils ont pu vendre plusieurs autres services aux clients au cours des années suivantes, ce qui a sauvé l'entreprise de la faillite.

Le texte suivant provient du blog d'Yves Hanoulle et a été traduit par nos soins en allemand.