Agile

En attendant de finaliser mes articles techniques (au nombre de 3) que j'ai du mal à terminer par manque de temps, intéressons-nous aux méthodes dites agiles. C'est le billet sur TDW qui me pousse à avancer la rédaction de ce billet, un peu agacé (mais gentiment hein) par de tels propos qui mélangent dans un amalgame à peine voilé bataille technologique et savoir-faire et méthodes appliquées par l'humain.

Cela fait maintenant 2 ans que je m'intéresse aux grands principes de l'agilité en appliquant tout ou partie des règles de bon sens (et pragmatiques) qu'apportent les méthodes agiles. La révélation fut à l'issue d'une formation sur la gestion de projets informatiques, le formateur (et ce ne fut pas le premier) était très orienté agile, son discours me parlait et faisait référence à mon vécue : "mais oui mais c'est bien sûr" me suis-je dit, cela me correspond presque parfaitement et c'est très adaptée à l'organisation dans laquelle je travaille.

J'ai pour habitude de répéter souvent cette phrase :

Think big, start small

Avoir des ambitions, des besoins géniaux à réaliser, c'est bien, être raisonnable dans leur réalisation, c'est mieux et surtout moins risqué (prendre des risques oui, mais calculés). Nous avons des apprentis en permanence, le cycle est de 2 mois en entreprise, 2 mois à l'école, rien de mieux pour appliquer un cycle itératif et incrémental sur nos chantiers ou projets.

Alors comment et pourquoi j'essaie (j'essaie, j'essaie, ...) d'être agile, que je résumerais de la façon suivante :

• itératif et incrémental : cycle court entre 2 versions (spécs, conception, codage, recette sont compris dans cette courte itération), on s'éloigne ainsi notamment de l'effet tunnel, propre aux vieilles méthodes traditionnelles, mais également permet de réduire le taux de bugs (courte itération = moins de fonctionnalités = moins de lignes de code = moins de bugs)
• être à l'écoute du feedback utilisateur : on met son égo dans sa poche, on écoute, on argumente s'il faut le pour et contre (j'admets qu'avec certains, c'est dur ;)), d'une manière générale, j'essaie de ne pas avoir d'apriori ou de préjugés sur les remarques, et de ne pas partir du principe que la solution est parfaite et sans partir dans des spéculations / conjectures à n'en plus finir,
• innover et prendre des risques mesurés, afin de ne pas tomber dans une 'inertie,
• collaborer pour aller de l'avant et trouver des solutions et non se retrancher voire se couvrir derrière une irresponsabilité des parties prenantes ("c'est pas ma faute, c'est celle du stagiaire"),
• peu de documents papiers/électroniques mais un bon code, documenté (dans le code, ou un wiki pour les principes généraux), simple (si cela existe...;)) et souvent refactoré pour une meilleure maintenabilité : diminution du risque d'entropie du système ou simplement, du degré d'installabilité de celui-ci qui le rendrait alors non évolutif, ceci est rendu possible grâce aux courtes itérations,
• accepter le droit à l'erreur (pour peu qu'on ait le sens des responsabilités) et réagir pour corriger,
• appréhender de façon positive le changement (de direction, de méthodes, de besoins, ...), en gros, inscrire dans le marbre des besoins qui sont suceptibles de mûrir dans l'esprit (ie : et éventuellement qui in fine ne seront pas utilisés par ex. ) semble vain, cela évite l'inertie et le manque d'innovation, sans quoi la concurrence guette, également, essayer, expérimenter, changer de méthode, de direction si besoin, si cela permet d'arriver à l'objectif, pourquoi pas : droit à l'erreur, accepter l'imperfection, pour cela, mettre son égo de côté, faire de courtes itérations, écouter,

Tout ceci n'est bien sûr pas exaustif, cela correspod à des bonnes pratiques, comme on pourrait en avoir en développement logiciel, c'est une habitude à prendre et à avoir, et surtout, se faire souffrance parfois, mais c'est tellement mieux au bout du compte !

Tout ça c'est bien mais encore faut-il se doter d'outils, choisis, les outils les plus sont les meilleurs et non des outils imposés et supposés meilleurs, quelques exemples :

• mind mapping,
• cas d'utilisation,
• excel ou tout autre logiciel permettant de lister des tâches (de recette, de choses à faire, de bugs, ...),
• procédures simples de déploiement (un script, des fichiers textes de todo/tasks list, ...),
• ...

Tous ces points ne sont pas le fait d'une technologie mais bien du bon sens, et du pragmatisme inhérent à l'agilité, indépendemment à toute technologie.

Architectes, développeurs, chefs de projets, utilisateurs, oeuvrons pour mettre au point le meilleur système, ou du moins une première version du système qui le deviendra...meilleur à termes, cela passe par la qualité et les méthodes ou moyens pour y parvenir.

Communautés .NET, affirmons-nous, assez de ces a priori ou idées reçues issus des anciennes technos. MS qui étaient certainement par le passé mauvaises, cela a bien changé depuis bientôt 7 ans, il est temps d'ouvrir les yeux chers lamers.

Sur ce, je vais me coucher, et ça, c'est du concret.