Du gaspillage en développement informatique

Publié par Martin dans Ayeba

Je souhaite approfondir avec vous la conférence que Régis Médina lors du 4ème séminaire Lean et SI (http://www.regismedina.com/) sur le gaspillage en développement informatique car le sujet abordé se positionne à mon sens sur une évolution à surveiller : les méthodes agiles enrichies au Lean.

Régis souligne tout d’abord les apports des méthodes agiles dans l’amélioration de l’adéquation au besoin des solutions logicielles, dans la suppression de l’effet tunnel et dans l’amélioration de la qualité.

Valeur

La valeur est avec le flux et le gaspillage un élément central du lean.

Régis propose une signification à la notion de valeur en développement logiciel en lui donnant une définition double :

• faire de nouvelles choses que l’utilisateur ne faisait pas avant
• faire plus simplement des choses existantes

De là il introduit la notion de gaspillage en expliquant qu’il existe trois types de taches

• les tâches qui produisent de la valeur
• les taches auxiliaires, ex : la saisie des temps qui est nécessaire à l’entreprise mais qui n’apporte pas de valeur au logiciel
• et enfin, le gaspillage

On notera que le lean préconise la mise en place d’un flux tiré. Cela est déjà traité par les méthodes agiles qui mettent en place un flux tiré (on va chercher des fonctionnalités à développer dans une backlog et on les mets en production à la fin du sprint) et non plus un flux poussé (on développe toute la spécification avant la mise en production).

Gaspillage

Le lean identifie 7 types de gaspillages (on en identifie parfois deux supplémentaires, cela fera l’objet d’un autre papier). Le conférencier propose des exemples pour ces 7 catégories :

• la surproduction : ex :réalisation d’une fonctionnalité qui ne sera jamais utilisée, ou réalisation d’une fonctionnalité produite trop tôt.
• l’attente : ex : attendre une décision de l’utilisateur
• le transport : le transport d’information, ex un analyste qui fait une spec très lourde
• le traitement : traitements excessifs, changement de contexte, reprogrammation d’un traitement déjà existant
• le stock : travail en cours en attente, spécifications écrites mais pas en cours de développement
• le déplacement : déplacement d’un groupe pour une réunion sur un site distant
• la correction : retouches et corrections du code, le développeur retourne voir l’utilisateur apres une premiere explication car il lui manque des informations.

Réduction des gaspillages

Régis Médina identifie deux familles de problèmes

• les problèmes de qualité (adéquation, correction, retour arrière …)
• les problèmes de délais (stocks/attente, traitements, …)

Qualité

Concernant la qualité, Il introduit la notion de build-in quality ou « bon du 1er coup ».

L’idée qu’il présente est de marquer d’une pastille rouge les tâches sur lesquelles on constate du rework (retour sur spécifications, retour sur recette, retour sur conception) afin de pouvoir les étudier ensuite pour identifier ce qui n’a pas fonctionné correctement et chercher à améliorer le processus (avec une démarche type 5 why’s par exemple).

Délais

Concernant les délais, Régis Médina introduit la notion de structure de délais. Le temps passé sur une tâche se divise en trois

• le lead time : le temps projet total
• le touch time : le temps pendant lequel la fonctionnalité est traitée sans création de valeur
• le value added time : le temps pendant lequel on apporte de la valeur ajoutée à la fonctionnalité

Le frottement

Régis Médina appelle frottement la différence entre le touch time et le value added time, c’est à dire la différence entre l’ajout de valeur et la recherche.

Expérience

Afin de mesurer ce frottement, Régis réalise une expérience, il s’agit d’une session de pair programming pendant laquelle les 2 développeurs doivent réaliser une tâche a priori complexe qui correspond en fait à une simple modification d’une ligne dans un fichier de paramètrage.

On demande aux deux développeurs d’exprimer à haute voix toutes les hypothèses qu’ils formulent.

Une équipe d’observateur note toutes les actions qui vont être tentées.

On peut dès lors identifier le touch time du value added time

• Le touch time est de l’ordre de 20mn
• Le value added time est de 15s
• On a donc un rendement de 1,25%

D’où vient ce frottement ?

Les causes de ce frottement sont multiples, mais on peut identifier globalement les problèmes suivants :

• recherche : dans le code, dans les fichiers, dans les milliers de lignes de code
• interprétation/traduction : code complexe pour faire une chose simple, plusieurs variables pour une donnée
• changement de contexte : code imbriqué qui dans un meme fichier va concerner une fonctionnalité puis une autre, l’ihm puis l’accès aux données, ce qui fait perdre de vue la tâche initiale
• actions redondantes : variable qu’il faut mettre à jour à plusieurs endroits différents

Solutions à explorer

Tout d’abord un constat : quand on découvre le phénomène, il est trop tard. Ce qui signifie qu’on est dans l’action préventive plutot que dans le curatif.

D’ailleurs XP a bien identifié ce phénomène en imposant dans son cycle projet des séances de refactoring de code.

Régis propose de former nouvelle race de développeurs. Il compare ce nouveau développeur à un poisson nettoyeur qui maintient son environnement propre par un effort de nettoyage continu.

Le nouveau développeur doit savoir identifier les frottement et les éliminer, Régis reprend là deux principes clef du lean, le travail sur la durée et la formation des équipes à l’identification des gaspillages.

Selon Régis Médina, les développeurs sont actuellement trop focalisés sur la technologie pure. Le nouveau développeur doit être formé pour comprendre ce qu’est le flux de production de valeur (pour l’utilisateur).

Il insiste aussi sur l’importance de la conception qui permet de faire vivre le code sans ajouter de complexité.

Enfin, le conférencier ajoute que l’utilisation d’offshore ne fait qu’accentuer le phénomène : plus on ajoute de force plus il y a de frottement or la méthode de résolution type d’un centre de service offshore est d’ajouter plus de ressource pour résoudre un problème.

Bénéfices

Les bénéfices à tirer de la mise en oeuvre des préconisations de Régis sont

• une réduction des délais et des coûts (ce qui permet aussi de limiter les frottements),
• une fiabilisation des estimations puisqu’on ne risque plus de tomber sur une mauvaise surprise (et donc de la prédictabilité des équipes),
• une meilleure flexibilité du système puisqu’on ne risque plus d’être limité dans l’évolution du système par du code instable qu’on ne peut toucher.

Par ailleurs le fait de sensibiliser et de former les développeurs au flux de production de valeur va leur permettre d’aider l’utilisateur dans l’expression de son besoin en proposant des solutions pertinentes.

Conclusion

Le développeur classique traite l’information en séquence (en cascade, spécifications, conception, developpement, recette …), le développeur agile se tourne vers le service client, le développeur lean cherche à travailler plus vite pour le client et pour créer un produit pérenne.

Merci à Regis Medina pour sa conférence très instructive.