Survivre en mode projet

Ce projet consistait à développer un outil permettant d'automatiser des tests de logiciels développés séparément, pour s'assurer qu'ils fonctionnent bien indépendamment mais surtout que les combinaisons de versions des outils fonctionnent elles aussi correctement.

Le besoin était donc relativement précis en terme de résultat. Mon affectation était limitée dans le temps, même si la limite n'était pas connue à l'avance, on partait sur une période d'un an renouvelable. Enfin, le sujet n'était pas le plus excitant du monde mais comportait une bonne part de réflexion pour modéliser les éléments à manipuler (outils, versions, branches, chaînes de traitement, exécutions de référence, ...), leurs liens et leurs représentations.

Pour ce projet, comme dans d'autres dans le même contexte, ma "méthode", si on peut ainsi la nommer, est la suivante:

1. Comprendre les besoins,
2. Trouver une solution, si possible élégante,
3. Proposer la solution,
4. Développer la solution;
   • si une question surgit, discuter, en faisant éventuellement un cycle depuis l'étape 1,
   • montrer le résultat, recueillir les retours, revenir en 1.

Rien de très original, on retrouve les cycles habituels de méthodes dites "agiles"¹. Une étape capitale n'apparaît cependant pas: Trouver un intérêt à développer le logiciel en question. Etape dont le point 2. ci-dessus dépend directement.

J'ai déjà écrit sur le fait que le développement d'un logiciel nécessite de regarder loin, de se projeter², seule façon de garantir un potentiel d'évolution du logiciel.

Il ne suffit cependant pas de viser un horizon éloigné au début du développement, il faut également que l'horizon visé s'éloigne, c'est-à-dire que le projet et la vision associée évoluent en même temps que le logiciel est développé. On pourrait dire que le projet doit déborder la mission qui est confiée au développeur.

Je considère donc qu'une partie de mon travail, consistant à développer des logiciels, inclut l'entretien de cette motivation et cette vision à plus long terme.

Développer l'outil en question seulement pour cette équipe posait évidemment un problème quant à l'avenir même de ce logiciel: serait-il maintenu ? utile ? utilisé ? Autant d'interrogations propres à empêcher une vision à long terme, m'interdisant de projeter le développement au-delà de la fin de mission.

La "solution" a donc été de concevoir dès le départ le logiciel pour qu'il puisse être utilisé par d'autres équipes de développement avec des problématiques similaires. Cette réponse est évidente et l'approche choisie est relativement naturelle. Il n'empêche que c'est à cette condition qu'il est possible de conserver des possibilités d'évolution très larges au logiciel développé.

J'ai trouvé d'autres sources de motivation sur ce projet: apprendre sur le web sémantique, utiliser des graphes RDF et enfin développer une bibliothèque de manipulation de graphes RDF pour OCaml. Ce développement me sert pour d'autres projets personnels. Je me suis donc servi de mes intérêts personnels pour le développement d'une partie du logiciel pour lequel j'étais "missionné".

Une troisième source de motivation qui est intervenue dans ce projet est l'envie de "faire du beau", de s'appliquer, d'avoir une conception élégante, etc.

Un ami m'avait fait remarquer que l'étymologie du mot "méthode" inclut la notion de chemin:

Le développement d'un logiciel s'apparente au parcours d'un chemin, un chemin inconnu³, que l'on découvre au fur et à mesure. Un chemin que parfois d'autres ont déjà parcouru et dont on perçoit les traces dans d'autres logiciels⁴.

Le chemin à parcourir n'est pas tout plat, certaines sections sont plus faciles que d'autres. En descente et à découvert, on déroule le code sans perdre de vue le point de l'horizon visé, la hauteur par rapport à la destination permet de repérer bien à l'avance les obstacles, de les anticiper et d'avoir une trajectoire fluide et courte.

Dans d'autres endroits, la pente est rude et nous cache l'horizon, il convient alors de rester concentrer sur son seul objectif, arriver en haut, à son rythme⁵, ne pas s'arrêter en chemin. Le sommet atteint, un autre horizon s'ouvre, riche de directions à choisir. Il arrive aussi qu'on débouche au bord d'un précipice infranchissable et qu'il faille revenir en arrière. En se retournant au sommet, on peut voir le chemin parcouru et s'apercevoir qu'il est bien sinueux, c'est le moment de simplifier le code avec ce nouveau point de vue.

On prendra parfois des chemins que l'on a déjà empruntés, parce que l'on sait où ils vont: La voie de la bibliothèque existante, même si elle fait un détour, est parfois préférable au défrichage d'un éventuel raccourci.

Souvent plusieurs chemins sont possibles et on préférera par moments en ouvrir un qui pourra être suivi à nouveau plus tard, même s'il est peut-être un peu plus long. Alors on développe une bibliothèque réutilisable plutôt qu'un composant ad-hoc pour le projet en cours.

C'est que la marche du développement logiciel ne prend pas seulement en compte le point visé, mais également le plaisir de la marche, les marches passées et celles à venir.

Si j'emploie l'expression "ouvrir un chemin", c'est qu'il s'agit aussi, en cheminant, de tracer des routes, qui pourront être suivies par d'autres, y compris par le développeur lui-même quand il refera le chemin jusqu'au point où il s'arrête, ou pour le quitter vers une autre direction. J'employais déjà cette image par ici. Il arrive que pour gagner du temps et parce qu'une difficulté n'est pas le sujet d'intérêt du jour, on se soucie peu d'ouvrir un chemin, seul passer l'obstacle compte, comme si on traversait une haie et que celle-ci se refermait derrière soi.

Les directions que je prends lors de mon cheminement ne dépendent donc pas seulement d'un état actuel du code et de l'objectif visé, mais aussi de mes expériences et surtout de mes motivations, de mes intérêts, comme on choisit une route plutôt qu'une autre "pour la vue", ou pour en profiter pour s'arrêter visiter un lieu.

C'est comme pour partir en vacances: on peut prendre l'autoroute pour un voyage ennuyeux dont les seules surprises seront les bouchons et autres perturbations. On peut aussi choisir de prendre les petites routes, faire un crochet pour visiter un bel endroit que l'on connaît déjà ou découvrir de nouveaux lieux en guise de repérage. Dans ce cas, le voyage fait partie des vacances.

Si je devais décrire "ma" méthode, en reprenant l'étymologie, il s'agirait donc d'une attitude, d'une façon de faire mon chemin vers l'horizon visé, en m'inscrivant toujours entre le passé et l'avenir, mon passé et mon avenir, mes expériences et mes aspirations.

Loin des prescriptions de méthodes, "agiles" ou non, ma méthode m'est donc personnelle et mes développements logiciels contiendront une partie de ce que j'étais à ce moment.

Elle est également ma façon de survivre dans un environnement de plus en plus contraint et qui place les développeurs comme des ressources dans des processus de production qu'ils ne maîtrisent pas. Face à une stratégie de mise en compétition et visant une illusoire compétitivité économique fondée sur de pseudo-innovations, il s'agit en quelque sorte de braconner pour conserver un intérêt au travail.

Je laisse l'autoroute aux fondus de performance et de compétition.