Développement logiciel Lean en 2017 ou Régime-Santé TI

Voir la version AMP

Le Développement logiciel Lean est l’extension des principes Lean au Développement et à la Gestion de Produits et Services TI; plus particulièrement, on voudra éliminer tout travail qui n’apporte pas de valeur audit produit ou service TI.[1]

Lean Six Sigma est une méthodologie qui s’appuie sur un effort collaboratif d’équipe pour améliorer la performance en éradiquant de façon systématique le gaspillage (pertes )[1]et ce, sur huit plans : Transport, Inventaire, Mouvement, Attente, Surproduction, Sur-processus, Défectuosités et Talents (abréviation : ‘TIMWOODS’).

On ne saurait sous-estimer le rôle de plus en plus crucial de la fonction TI dans un contexte eBusiness et eCommerce où livrer de la qualité et de la valeur aux consommateurs est devenue la principale activité des entreprises. Les services et produits TI permettent souvent aux consommateurs de découvrir, commander et payer ainsi qu’aux employés et fournisseurs de communiquer, collaborer, gérer et exécuter / produire, etc.

Tous les Consultants et Évangélistes du Lean IT vous le diront, il y a un gaspillage énorme (pertes) en développement logiciel dû aux infrastructures TI héritées et aux processus dispersés ou non-performants qui sont souvent à l’origine de mauvais service à la clientèle, perte de clients, perte de productivité des employés, coûts trop élevés, etc.

Le Développement logiciel Lean cible huit sources de gaspillage en Gestion et Développement TI :

lean-it-waste-examples-1158-x-574Source image : Wikipedia

Ne pas confondre « Lean » avec « Cheap »

Étonnamment, malgré cet environnement de plus en plus concurrentiel ne laissant plus aucune place à l’erreur, nous avons perdu ces dernières années en tant que consultant plusieurs projets de développement d’applications au profit de stagiaires ou de développeurs juniors en entreprise. Ainsi, plusieurs entreprises croient encore pouvoir sauver temps et argent en confiant des mandats à l’interne à des taux horaires plus bas.

Habituellement, il ne faut pas beaucoup de temps avant que la réalité ne rattrape ces entreprises et que quelqu’un lève un « flag », comme on dit si bien. Heureusement pour nous, au fil des ans, nous avons réussi à récupérer plusieurs mandats de développement d’application pour lesquels nous avions été initialement sollicités mais dont le développement avait finalement été confié à l’interne.

Une règle d’or émerge de notre expérience en ce sens : si le développement est complexe et / ou doit s’intégrer à d’autres systèmes en place, l’utilisation d’une ressource junior n’est pratiquement jamais gagnante.

Et comment se traduit l’expérience du Développement d’Applications dans la réalité d’Analystik ?

Développement logiciel Lean « à la Analystik »

Analystik a mis en place un processus exhaustif et très rigoureux de contrôle de qualité du développement logiciel au cours des 15 dernières années, à saveur « Développement logiciel Lean. »

Et aujourd’hui, chaque projet de développement logiciel se fait selon notre propre processus de développement logiciel qui se base sur les principes du Développement Agile.

Ainsi, il nous a été facile de mettre en lumière que les principales causes d’échec des projets de développement confiés à des juniors ou stagiaires à l’interne étaient l’absence d’expérience combinée à des lacunes au niveau de la Méthodologie de Développement d’Applications utilisée par le / la / les ressource(s) dans les projets.

Et voici comment se traduit dans la réalité d’un nouveau projet, les leçons tirées de notre expérience du Développement d’Applications TI et notre expertise des Méthodologies de Développement logiciel :

  • Prendre le temps qu’il faut pour BIEN comprendre les besoins d’affaires du client (souvent non exprimés clairement) et en distinguer l’important du superflu (priorisation et hiérarchisation des fonctionnalités suggérées)
  • Prendre le temps qu’il faut pour BIEN architecturer la solution AVANT de commencer à coder
  • Prendre le temps qu’il faut pour BIEN designer chaque fonctionnalité à livrer
  • Définir comment la fonctionnalité à livrer sera testée AVANT de commencer à coder
  • S’assurer que chaque fonctionnalité développée CORRESPOND vraiment à un besoin ainsi qu’aux attentes tout au long du développement de l’application
  • Utiliser une Méthodologie de Développement AGILE
  • TESTER, tester et encore tester avant de livrer

Autres Méthodologies de Référence en Développement logiciel 

Et pour votre information, voici les différentes sources auxquelles Analystik s’abreuve en permanence depuis des années.

 

Bon projet de développement et au plaisir de collaborer avec vous,

Denis Paul & Michel

 

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *