Se fixer un but pour garder le cap

Après quelques décennies passées à suivre des procédures formelles et lourdes, l'heure est aux méthodes agiles qui prônent la supériorité du pragmatisme sur le dogmatisme.

Je suis personnellement convaincu du bien-fondé des approches agiles. Plutôt que de viser un idéal impossible à atteindre, elles préconisent de constamment revoir sa copie et de s'adapter au mieux aux circonstances afin que le projet colle le plus possible au besoin réel et non au besoin exprimé ou pire encore : au besoin imaginé.

Il arrive que les nouveaux pratiquants pensent à tort que les méthodes agiles s'apparentent à la trop célèbre méthode La Rache. Même si elles sont moins contraignantes que les méthodes dites traditionnelles, les méthodes agiles proposent chacune un formalisme.

Au-delà de la méthode choisie, il me semble important de ne jamais perdre de vue le but du projet. Pour cela Tom Preston-Werner a imaginé une méthode originale et tout à fait intéressante : le Readme Driven Development. Il préconise de toujours commencer un projet par la rédaction de son fichier README. Ce fichier est traditionnellement inclus dans la distribution d'un programme afin d'en expliquer l'usage.

Rédiger ce document avant toute autre chose permet d'éviter de se jeter tête baissée dans le développement avec le risque que ce soit lui qui induise la direction que prendra le projet. Il faut au contraire que le code ne soit qu'un instrument destiné à atteindre un but. En se mettant à la place de l'utilisateur final dès le début, on privilégie l'usage et non le développement du produit.

Par ailleurs, si de nouveaux développeurs viennent étoffer l'équipe ou s'il faut expliquer le but de l'application à quelqu'un d'extérieur, ce document sera une bonne base de travail.

Parfois, le produit n'est pas vraiment une application destinée à un utilisateur final mais plutôt une librairie qu'utiliseront d'autres développeurs pour construire une application. Dans ce cas là, j'ai pris pour habitude de commencer par concevoir les exemples d'utilisation.

Ainsi, je peux voir si l'usage est simple et logique. Généralement, je fais plusieurs modifications radicales avant d'arriver à quelque chose qui me satisfasse pleinement. L'avantage de cette approche est que les classes n'étant pas encore implémentées, le coût de refactorisation du code à ce stade est quasiment nul.

Cette approche très simple à mettre en œuvre permet de concevoir une librairie idéale sans se laisser influencer par d'éventuels raccourcis que l'on utilise parfois pour se faciliter la programmation mais qui vont compliquer l'usage ultérieur de la librairie.

Cela se rapproche de la philosophie du Test Driven Development mais sans s'encombrer, pour le moment, du framework de tests unitaires. Le but est de prototyper l'usage de la future libraire de la manière la plus souple possible.

Et vous, utilisez-vous une méthode personnelle pour conserver le cap lors de vos développements ?