Akelaï

La maîtrise des projets de développement IT

Projets IT


Visitez notre site Web dédié à l'ingéniérie logicielle et aux projets IT : software.akelai.fr

logo Akelaï Visitez notre site WEB : www.akelai.fr

Aller au GEMBA

Le « Gemba » est un terme japonais qui nous vient du TQM : Total Quality Management.
C'est le lieu réel ou la valeur est créée, ce pour quoi le client paye.

Le Garage

Dans le premier essai « The Tar Pit », du « Mythical Man Month », F. Brooks présente le diagramme suivant :

image : multiplicateurs de couts

La case en haut à gauche du diagramme veut représenter un programme complet et fonctionnel, mais connu, utilisé (et utilisable) par son seul auteur. Il s'agit d'un programme développé par un individu « dans son garage » (les propres termes de F. Brooks).
Le diagramme décrit alors deux chemins pour passer de cet « objet » à un composant vraiment utile devant fonctionner dans un système plus large.
Ces chemins passent par deux étapes, qui chacune multiplie le coût par 3.

F. Brooks estime que chacune de ces transitions coûte 3 fois le coût du programme. Le chemin complet pour passer d'un programme à un composant d'un système complet coûte donc 9 fois plus que de faire un programme « dans son garage ».

Ce diagramme met évidence la distance entre le programme et le produit (et la multiplication du coût qui va avec): d'une façon ou d'une autre, il faut passer de la case « programme » à la case « système », et cela justifie tout ce que l'entreprise met autour du programmeur, en terme d'organisation, de procédure qualité, d'outil, de revues, de test, de contrôle ...

Le Lieu Réel

Le « garage » de F. Brooks fait écho au terme japonais « GEMBA ». Masaaki IMAI en donne une définition (« Gemba Kaizen » [2], glossaire page 312) :

Mot japonais qui signifie « lieu réel ». Dans la terminologie du management, il signifie le « lieu de travail ». C'est l'endroit où l'on crée de la plus-value. Dans la fabrication, il s'applique habituellement aux ouvriers.

L'utilisation du mot GEMBA en logiciel est tout aussi pertinente qu'en production de bien. En logiciel, le GEMBA est le « lieu réel » où le programmeur réalise à la fois la conception et la réalisation. Il mérite tout le respect et l'attention des managers.
On peut voir la case en haut à gauche du diagramme de Brooks (le « garage ») comme le « Gemba », là où se trouve la vérité de la création de valeur.

Gemba Kaizen -- L'art de manager avec bon sens, s'inscrit dans la lignée des écoles de Qualité Totale et des systèmes de production Juste à Temps.
Il décrit une démarche d'amélioration continue centrée sur le Gemba, où le manager se doit de rester en contact étroit avec le Gemba, et de le comprendre.
Les cinq règles d'or du management Gemba sont :

  1. Lorsqu'un problème se pose, aller au Gemba
  2. Vérifier le Gembutsu (le point dont il s'agit)
  3. Prendre des mesures provisoires sur place
  4. Découvrir la cause première
  5. Standardiser pour prévenir le retour du problème

Aller au GEMBA

Quarante ans après les balbutiements du « génie logiciel », comprend-on le Gemba ?
Deux questions méritent l'attention des managers :

Une troisième question n'est pas propre au Gemba: l'expression des besoins client et leur (in)stabilité. Il devra aussi être pris aussi en compte, tant dans la phase de développement d'un nouveau produit que dans sa maintenance (évolutive) ultérieure.

Qualité : une affaire de tests ?

L'écrasant problème de la qualité (présence de bugs) en logiciel a son origine au Gemba. Le TQM nous dit qu'il doit y avoir sa solution.

Le génie logiciel peine à produire des méthodologies « sûres » (dont le résultat soit prédictible et répétable) ; celles qui existent restent cantonnées à des domaines restreints pour système critiques (pouvant entraîner mort d'homme selon la classification SIL de la norme CEI 61508).

On peut voir une méthode comme le passage d'un gué. On peut passer de façon sûre de l'autre coté de la rivière sans se mouiller si, en travers du gué, sont disposées quelques grosses pierres, bien fermes, qui sont autant de pas qu'il suffit de faire. Le respect de chacune de ces étapes garantit le résultat, de manière prédictible et répétable.

En logiciel, il n'existe pas, ou très peu, (la normalisation de table pour créer une base de données relationnelle ?) de telle méthode « sûre », qui empêche par leur nature même d'introduire des erreurs.
A titre de (contre) exemple, UML est plus un ensemble de notations qu'une méthode. Ces notations peuvent participer, en tant qu'outils, à l'obtention de produit de meilleure qualité. Elles ne garantissent en aucun cas cette qualité -- ni de façon prédictible, ni de façon répétable.

Devant le constat de la qualité (insuffisante) obtenue, l'entreprise doit traiter le problème. A défaut d'être traité (sur le plan technique) par des méthodes et outils, il a été traité (sur le plan projet) par le management.
Le remède est simple, peut-être simpliste : le projet se termine par une phase de tests, censée découvrir et traiter tous les « bugs ». Cette phase est le talon d'Achille du projet, mal maîtrisable en coût et délai. Il n'est pas rare que le coût global des activités de tests soit de 50% du coût du projet.
C'est l'approche par le contrôle (ou curative). Elle dénoterait dans les industries manufacturières une entreprise centrée sur le produit.

L'alternative, l'approche préventive, attache plus d'importance à corriger la cause du défaut qu'à corriger le défaut lui-même. Cette approche est le fait d'entreprise centrée sur le processus. Elle permet d'améliorer petit à petit le processus de production, et ainsi fabriquer des produits de meilleure qualité, à moindre coût : sans les surcoûts du contrôle ni de la reprise ou du rebut des produits défectueux.

Chaque industrie est différente. Le constat actuel sur la présence en aval du processus logiciel d'une interminable phase de test/contrôle du logiciel n'est pas en soi critiquable -- il faut bien pallier le plus pressé (voir l'article: « Qualité et Délai » qui tempère la critique, sans diminuer le constat).

Il est par contre critiquable de s'habituer à payer 50% des coûts dans des phases de tests en finissant par considérer cette situation comme normale.

Il est depuis longtemps établi que le coût de correction est très dépendant du délai de détection : un défaut trouvé en tests unitaires coûtant 10 fois moins à détecter/corriger que le même défaut trouvé en test de sous-système, le même facteur 10 se répétant à chaque étape (tests d'ensemble, tests de recette ...).

Si l'on fait le constat que peu d'entreprises suivent une statistique des bugs logiciels en croisant les trois paramètres :

... on peut s'interroger sur :

Conception et codage : séquentiel ou itératif ?

Les critiques justes et répétées contre le modèle séquentiel (amendé et pratiqué sous le nom de « cycle en V ») n'ont toujours pas reçu de réponse satisfaisante.
Les modèles séquentiels (« modèle en cascade », « modèle en V » ...) décrivent le déroulement séquentiel de phases bien distinctes sans retour arrière (l'eau de remonte pas à sa source dans une cascade ...).
Ils ne correspondent pas à la réalité (le lieu « réel » ...) du travail de développement logiciel.
De façon étonnante, l'article de Royce [3] à qui on attribut la paternité du modèle en cascade le décrit pour en souligner la faille : l'existence de retour arrière (l'article propose des palliatifs, dont un « do it twice » on ne peut plus explicite). Malgré cela, et l'apparition encore trop timide de méthodes incrémentales, les projets logiciels sont encore majoritairement construits sur le « cycle en V » : Dans [4], une étude auprès de 200 praticiens cumulant des milliers de projets rapporte que le modèle dominant reste encore en toujours le cycle en V.

L'inadéquation d'un modèle qui sépare conception et codage peut être aussi reconnue par tout un chacun lorsqu'il doit exprimer par écrit ses idées. Le modèle séquentiel veut distinguer la conception (la réflexion sur l'organisation future du code) du codage (la réalisation). Pourtant lorsqu'il s'agit d'écrire un texte ne serait-ce que de quelques pages, on passe de façon naturelle par des cycles d'écriture / réflexion / écriture / réflexion / amélioration ... etc. Plus encore, c'est la phase d'écriture qui, en détaillant la pensée, permet souvent d'en corriger les erreurs.
Le processus de « réflexion / rédaction » est extrêmement proche des activités de « conception / codage » en logiciel. Je ne connais pas de meilleur exemple qui puisse faire partager ce vécu à un non-informaticien.

Bien sûr les développeurs s'adaptent au moule qui leur est imposé. Les développeurs censés rédiger un document -- décrivant la conception -- avant de passer au codage, le font à minima, se gardant le maximum de liberté, puis mettent sérieusement à jour la spécification après codage.
Il n'en reste pas moins que beaucoup de bugs trouvent leur origine dans une conception supposée figée avant codage, dont les défauts apparaîtront en phase de tests... où la correction se fait toujours à coût et délai minimum: Les phases de conception/codage sont des phases où l'ordre du programme est construit, où son « entropie » est maîtrisée. Dans la phase de test, l'ordre du programme commence à être détruit.

Pourquoi les cycles « séquentiels » persistent-ils ? Sans doute pour les raisons suivantes :

  1. Le management a imposé le « cycle en V », non pour ses mérites intrinsèques (voir plus haut le malentendu sur l'article de Royce !), mais pour sa compatibilité avec une une approche planifiée, où l'on peut suivre les tâches avec début et fin. Et où l'avancement du projet est mesurable de façon non ambiguë.
  2. Les méthodologies cycliques, itératives ou autres... ont l'odeur du souffre pour le management : comment s'assurer de ce qui est réellement accompli et de ce qui reste à faire ? Le problème n'est pas de faire de l'itératif, mais de le faire de manière contrôlée.
  3. N'importe quelle méthode est toujours meilleure que pas de méthode du tout.

Faut-il continuer à imposer le cycle séquentiel, en laissant le développeur faire « comme si » ?
Abandonner un cycle de développement « séquentiel » -- pour aller vers de l'itératif ou conception et codage peuvent interagir plus finement -- pose quasiment la question du cadre « projet planifié » avec tâches séquentielles et suivi du réalisé par rapport à une référence. Pour une direction, c'est presque tabou.
Pourtant :

  1. La valeur d'un logiciel est de plus en plus dépendante de sa capacité à évoluer et s'adapter. Elle réside au moins autant dans son adaptabilité que dans les fonctions qu'elle fournit aujourd'hui, mais qu'il faudra modifier demain.
  2. La conception est synonyme de structure du logiciel, donc de son ordre ou son désordre (son entropie). L'adaptabilité du logiciel dépend directement de la qualité de sa conception. Cette dernière doit prendre en compte de manière optimale les contraintes et lignes de force que la phase de code met en évidence ; la conception se cristallise en même temps que le code.

Le débat entre Séquentiel et Itératif est affaire de contrôle et de visibilité.
Mais le contrôle que permet une approche planifiée n'est-il pas illusoire quand on considère les dérives du projet ? Ne faudrait-il pas plutôt s'assurer du bon fonctionnement du projet, de sa capacité à produire des résultats, et de sa « vitesse de convergence » vers le but ?

C'est sans doute l'enjeu pour le Gemba : trouver son chemin entre méthode itérative et contrôle. Il doit encore prouver sa capacité à fournir des produits logiciels évolutifs qui préservent leur valeur au cours du temps.

Références

[1] Fred. P. Brooks, The Mythical Man Month -- anniversary edition, Addison-Wesley 1995
[2] Masaaki Imai, Gemba Kaizen, Kaizen Institute 2000
[3] Dr Winston Royce, Managing the development of large software systems: concepts and techniques, Proceedings WESCON, Aug. 1970
[4] Neill C. J., Laplante P. A., Requirements engineering: the state of the practice, IEEE Software Volume 20, Issue 6 (Nov./Dec. 2003), p 40-45


© Akelaï Conseil 2006-2018. Akelaï Conseil encourage l'usage de navigateurs internet respectueux des normes : Google Chrome, Firefox, Opera, Safari.

Valid CSS Valid XHTML 1.0