Triabulle

Bernard demande à Ronald d’analyser un nouveau projet pour un client important. Ronald passe de nombreux jours à analyser, à tenter d’estimer le temps total de développement, à produire des documents expliquant les principaux modules, à tenter de tout prévoir. Ronald pense qu’il sera en mesure de dompter son projet Web de façon à ce qu’il se conduise comme il l’entend. Erreur, mon pauvre Ronald, tu aurais dû savoir qu’un projet Web est une bête sauvage, une bête qui peut détaler dans n’importe quelle direction à tout instant. Tu ne peux contrôler la bête, tu ne peux que faire de ton mieux pour la guider vers la terre promise.

Ce à quoi ressemble votre projet Web.

Ce n’est pas un secret : développer un projet Web relativement complexe n’est pas comme tracer une ligne droite entre le départ et l’arrivée. Il y a des surprises, des changements de direction, des modifications majeures qui viennent compromettre le plan que l’on croyait pourtant infaillible au départ.

Mieux vaut réagir que prévenir

Plutôt que de tracer le chemin exact que la bête sauvage devrait suivre, je crois qu’il est préférable de donner un peu de liberté à ce pauvre animal attachant. En terme de développeur, cela revient à dire de développer de façon minimaliste et attendre les commentaires et les demandes en provenance des utilisateurs.

Supposons que je développe une application de e-business (quelle originalité) et que je me questionne sur l’utilité d’avoir un petit résumé du produit qui pourrait être affiché à certains endroits dans l’application. Eh bien… je ne devrais pas ajouter cette fonctionnalité en me disant que’elle va sûrement me servir. Je devrais plutôt attendre que la bête me le demande par elle-même. Je devrais faire un Pierre Lalonde de moi-même et regarder Alf droit dans les yeux en lui disant : “Hé la bête! Action? Réaction!”

Tout ça n’est pas sans rappeler le principe YAGNI (You Aren’t Gonna Need It). En effet, je pense qu’il faut absolument arrêter de développer des fonctionnalités au cas où. Si nous n’en n’avons pas besoin maintenant, laissons la fonctionnalité de côté. Si Alf nous le demande (dans ce cas-ci, Alf peut également faire référence au client), ce sera le moment de passer à l’action.

J’ai essayé de trouver un nom pour définir cette approche que je m’efforce de suivre et celui que j’ai trouvé n’est pas très valorisant… mais je vous en fait part quand même. J’ai appelé ça : L’analyse du paresseux. Certains me diront que ce n’est pas applicable pour les projets plus complexes et plus volumineux, mais je demande tout de même à être convaincu. En faisant le strict minimum dès le départ, toutes les portes demeurent ouvertes, l’application est plus flexible et rien n’est coulé dans le béton. De plus, cette méthode a l’avantage de laisser la possibilité aux utilisateurs de trouver eux-mêmes la façon dont ils souhaitent utiliser l’application.

Cette voie mène à la réussite, n’est-ce pas Pierre?

Pierre Lalonde sait comment parler à la bête