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. J’espère confronté nos points de vue avec Babozor un jour autour d’une bière afin de lui retirer de l’esprit tant d’idées reçues sur .NET.
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, pragmatiques et réalistes 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écu : “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) ,
- avoir des objectifs raisonnables, cela ne sert à rien d’essayer de prévoir 125 000 fonctionnalités nouvelles si on sait qu’on ne tiendra pas les objectifs avant même de commencer,
- ê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 éviter de partir dans des spéculations / conjectures à n’en plus finir, présumer que est une mauvaise direction,
- savoir innover et prendre des risques mesurés, afin de ne pas tomber dans une inertie, accepter l’incertitude,
- 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. Egalement, 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, faire de courtes itérations, écouter, expliquer.
Tout ceci n’est bien sûr pas exhaustif, cela correspond à 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, issu du retour d’expérience, et du pragmatisme inhérent à l’agilité, indépendamment à 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.
NB : bon nombre des points énumérés sont applicables pour une réunion, notamment avoir un délai fixe (débute à l’heure, finit à l’heure) et court (max 1h30), des objectifs / points du jour raisonnables (sinon cela ne tient pas dans le délai imposé, alors faire plusieurs réunions, tiens, ça me fait penser à itérations), des réunions à périodes et fréquences fixes (décidemment…), comprendra qui veut.
