Christian HOHMANN

Depuis 1998

  • Augmenter la taille
  • Taille par défaut
  • Diminuer la taille
Accueil Convergence Lean Software-Hardware Les gaspillages en développement informatique

Les gaspillages en développement informatique

Envoyer

Le développement informatique s’est inspiré d’approches, de méthodes et d’outils hors de son champ propre, notamment auprès de l’industrie et du corpus Lean Manufacturing / Lean Management. Ainsi s’est on avisé que les 7 types de gaspillages (muda) mis en évidence dans les ateliers d’usine trouvent leurs équivalent en développement informatique.

1- La surproduction

En production industrielle, la surproduction désigne la production excessive de produits finis ou de produits intermédiaires, excédant la demande client. Les biens en excès finissent dans les stocks, sans certitude de vente et exposés aux risques d’obsolescence, de dégradation, etc.

En développement informatique, la surproduction se trouve également et consiste notamment à développer des fonctionnalités non demandées, à lancer les développements trop tôt par rapport à la date de besoin ou à l’intégration, à raffiner des développements au-delà de ce qui est demandé. On retrouve ce dernier dans la catégorie “surqualité” également.

La surproduction peut également se trouver dans la production de données et d’informations dont on a pas besoin. Ces notions sont à préciser dans le contexte au risque de se lancer dans des débats sans fin sur le juste besoin de documentation, de reporting, de commentaires de codes, etc.

La saisie d’informations déjà existantes dans le système est également considéré comme de la surproduction. Il en va de même pour les étapes inutiles ou redondantes.

Attention cependant ! Une tâche redondante peut apparaître comme étant un gaspillage mais être requise pour des raisons de sécurité, normatives, réglementaires ou autres.

2 – Les stocks et encours excessifs

Les stocks et encours excessifs sont problématiques lorsqu’ils troublent la gestion des priorités, lorsqu’il n’est pas clair quelle tâche attaquer ensuite. Le lead time, ou temps de traversée d’un système est déterminé par le niveau des stocks et encours dans ce système, en vertu de la loi de Little. Plus les stocks et encours sont élevés, plus les délais s’allongent. Des délais qui s’allongent finissent par déclencher des actions coup de poing ou une mise sous pression des exécutants. Afin d’avancer un projet les priorités sont changées, au risque de rendre toute la planification du développement chaotique.

Les gaspillages par stocks et encours excessifs proviennent soit de la surproduction en amont, soit d’un lancement excessif de tâches à accomplir et/ou de la non limitation de l’encours.

Le travail en multitâche (on devrait plus précisément évoquer la commutation de tâches), laisse du travail inachevé en encours. Plus on commute parce que le chef de projet ou les circonstances l’imposent, plus les encours vont augmenter.

Les stocks et encours excessifs masquent les problèmes, tant dans le monde physique qu’en développement. Couplé aux délais qui s’allongent, la découverte d’un bug, d’une erreur peut ainsi être retardée au prix de conséquences plus importantes que si le défaut avait été vu et corrigé plus rapidement.

3 – Les temps d’attente

Les retards de livraison depuis les processus ou étapes en amont sont la cause la plus fréquemment citée pour expliquer les retards. Et parmi ces retards, ceux des clients qui tardent à fournir des spécifications, à valider des paramètres, à fixer leurs choix, etc. Les attentes peuvent aussi être imputables à des retards de tierces parties, d’équipes localisées ailleurs, dans des fuseaux horaires différents.

Pour éviter aux ressources mises en attente de rester sans charge, le chef de projet ou les ressources elles-mêmes commutent sur d’autres tâches. Cela augmente l’encours, ainsi que les risques d’erreurs.

4 – Transports inutiles

Ce type de gaspillages, aisément compréhensible dans un flux physique, est remplacé par le transfert ou de livraison des développements ; les handoffs. La commutation entre applications et la ressaisie d’information est également considéré comme un transport inutile, tout comme les allers-retours d’informations ou échanges de documents.

5 - Erreurs, bogues...

Les erreurs et bugs non décelés lors du développement, lors de tests, se propagent en aval dans le processus et risquent d’amplifier leurs conséquences ainsi que la durée et le coût à leur remédiation. Les erreurs sont des opportunités d’amélioration et la reproduction d’une même erreur et donc un gaspillage “pire” puisqu’en principe elle aurait pu être évitée.

6 - Raffinements excessifs, refaisage, reprogrammation

Le terme “raffinement” tente de restituer l’idée “d'over processing” ou “d'over engineering”, qui consiste à développer des fonctionnalités non demandées et/ou à raffiner à l’excès, ou tout du moins au-delà des attentes des clients, des développements ou des fonctionnalités. Ces raffinements sont éventuellement techniquement inutiles, mais surtout ils coûtent du temps et des ressources pour des fonctionnalités ou performances que les clients ne valoriseront pas, ne paieront pas. Cette catégorie est également fréquemment appelée "surqualité".

Le refaisage désigne toute tâche à reprendre, à refaire que ceci soit la conséquence de redondances, mauvaise planification ou d’erreurs à corriger.

7 - Les déplacements inutiles

Ces gaspillages sont le plus souvent relatifs à la recherche d’informations, la participation à des réunions dont l’utilité est très relative et pour lesquels des déplacements, des voyages sont requis. Peuvent figurer dans cette catégorie le temps passé en visioconférence, même si le déplacement physique peut être annulé par le recours à la technologie.

8 – Gaspillage d’opportunité d’apprentissage

Ce huitième type de gaspillage est plus particulier au monde du développement. La confrontation à des défauts ou à un problème technique particulier requérant un expert ou une recherche spécifique sont autant d’opportunités d’apprendre et de créer du savoir réutilisable. Manquer cette opportunité c’est s’exposer aux mêmes conséquences si une situation analogue se reproduit.

Conclusion

L’adoption du Lean et des méthodes agiles en développement informatique vise, entre autres, à éradiquer ces gaspillages et utiliser les ressources de manière efficiente, accélérer les développements et maîtriser les coûts.

La transposition ligne à ligne des gaspillages du Lean Manufacturing vers le développement informatique butte parfois sur des subtilités d’interprétation. Aussi ne faut-il pas chercher de coller à une quelconque “orthodoxie”, mais plutôt saisir l’esprit et transposer en fonction du contexte.


View Christian HOHMANN's profile on LinkedIn    

Mise à jour le Dimanche, 08 Octobre 2017 16:58  

Sujets similaires