Agile Scrum plus Six Sigma

DFSS veut dire Design For Six Sigma. Il s’agit donc d’un acronyme en deux parties. La partie Design et la partie Six Sigma. Design est un mot Anglo-Saxon qui exprime l’idée de développement de produits ou de processus(1), Hardware (produit physique tangible) ou Software (programme informatique) ; et Six Sigma qui fait écho : d’une part à la manière scientifique de décider sur le fait que des mesures mettent en évidence un changement significatif(2) de comportement d’un processus comme  par exemple une augmentation de performance revendiquée par son auteur, d’autre part d’évaluer par un indicateur la capacité d’un processus à délivrer les effets attendus (on parlera d’un niveau de Capabilité par exemple 6 Sigma ce qui veut dire qu’on peut s’attendre en moyenne à 3.4 ppm ou problèmes par million d’occurrences) et finalement de la méthode de travail lancée en 1987 par Motorola pour améliorer de façon continue les processus n’ayant pas les rendements suffisants (ici le mot processus doit être pris dans son sens habituel ; c’est-à-dire, dans le milieu de l’entreprise, une séquence de tâches programmées pour obtenir la transformation désirée).  On parlera du DMAIC pour invoquer la méthode Motorola du nom de l’acronyme qui veut dire : Define, Measure, Analyse, Improve, Control. Cet acronyme représente la feuille de route qu’il faut suivre pour appliquer la méthode. Le DFSS quant à lui suit une autre feuille de route et répond donc à un autre acronyme (cf. IDDOV).

La méthode DMAIC a été un immense succès surtout après que les deux géants industriels que sont General Electric et Honeywell aient décidé de l’utiliser pour améliorer leurs propres processus. Aujourd’hui la plupart des grandes entreprises dans le monde l’utilise.

Le DFSS Hardware même s’il est utilisé depuis une dizaine d’années par quelques grands groupes industriels n’en est encore qu’à ses débuts. En comparaison du DMAIC, il est plus complexe car il est multidimensionnel(3).  L’utilisation d’outils mathématiques comme le sont les matrices qu’on appellera pour l’occasion Maison de la Qualité (House of Quality) ou Matrice Causes/Effets (Causes and Effects Matrix ou encore Matrice X/Y) deviennent incontournables et du fait de leur complexité limitent le nombre d’adeptes et donc d’ « évangélistes » technologiques de la méthode.

Cela dit, la méthode a tout de même le vent en poupe et intéresse de plus en plus de directeurs R&D et autres responsables développement en tout genre qui sont, du fait de la globalisation, acculés au rendement et ce qu’il s’agisse de la productivité, de la fiabilité, de la sécurité ou de la performance au sens large.

Pour ce qui est du DFSS Software il n’est pas encore réellement mis en œuvre. Cela vient certainement du fait que les informaticiens restent en retard en ce qui concerne les méthodes Qualité par rapport au monde industriel. Certainement parce que l’informatique est un métier encore relativement jeune comparé au monde manufacturier. Dans l’informatique l’accent est avant tout mis sur la capacité à faire fonctionner le programme et moins sur sa performance. Dans ce cadre, l’utilisation d’indicateurs de Capabilité qui mesurent surtout la qualité est chose rare pour ne pas dire exceptionnelle. Il faut également prendre en compte l’aspect difficile de la mesure en informatique car il s’agit le plus souvent de mesures attributs. Ça fonctionne ou ça ne fonctionne pas. Souvent l’unique mesure continue possible est celle de la quantité d’heures pour écrire le code. Mais comme cette quantité est souvent mal estimée, sa mesure ne répond pas à un comportement normal (cf Loi Normale dans note bas de page point(1)) car peu fiable et ne peut pas vraiment être utilisée pour déclencher des actions d’améliorations.  Cependant les outils existent comme les points de fonction mais ils ont mauvaise réputation. Peut-être à cause du fait qu’ils ont été mal utilisés dans le passé.

Pourtant dernièrement certains nouveaux standards ont vu le jour dans les métiers du développement software, comme le CMMI(4) qui à partir du niveau 3 de cette norme (qui en compte 5) oblige l’entreprise, si elle veut être conforme, à mettre en place des systèmes de mesure avec des indicateurs de performance et des outils de contrôle comme peuvent l’être les cartes MSP(5) et autres instruments de prise de décisions basés sur des faits tangibles comme l’éloignement vis-à-vis de la moyenne compté en nombre de Sigma.

Par ailleurs, et ce également depuis peu de temps (vraisemblablement moins d’une dizaine d’années), on a pu voir l’essor de la méthode Agile/Scrum(6) qui lorsqu’on se penche sur ce qu’elle propose, montre qu’il s’agit en fait de la méthode Lean Manufacturing développée par Toyota appliquée au monde informatique. C’est le concept du juste-à-temps (Just-In-Time), sauf qu’ici au lieu de fabriquer un produit industriel juste-à-temps et ce afin d’éviter de le garder en stock et donc d’avoir des coûts supplémentaires (car le prix que paiera le client à l’achat est différé par rapport au moment où le coût de production est engendré, travail supplémentaire d’adaptation du  produit pour qu’il corresponde aux besoins mis à jour ...), on « produit » le code juste-à-temps (c’est-à-dire dans des itérations courtes - voir Sprint(7)) et on vérifie alors directement avec le client, l’adéquation entre le besoin et le produit auquel il est censé répondre et on s’adapte aux changements et autres modifications qui ne manqueront pas d’être mis en évidence. Ces modifications immédiates seront bien moins coûteuses que celles qui sinon auraient dû être faites plus tard et ce à cause des interactions avec d’autres parties de code auxquels on ne pense pas et qu’on ne va donc pas corriger et qui créeront des bugs, également à cause du fait qu’on a oublié comment et pourquoi  ce code a été écrit (il faut se replonger dedans) et surtout parce que sinon on va continuer à écrire du code qui ne servira finalement à rien.

Dans l’industrie manufacturière, aujourd’hui, on ne parle plus séparément des méthodes d’amélioration Lean et Six Sigma mais on les évoque conjointement dans la phraséologie Lean Six Sigma ; car rien ne sert d’avoir fabriqué rapidement un produit certes fonctionnel mais d’une qualité non acceptable ou encore un produit de qualité mais qui n’est pas disponible lorsqu’il est nécessaire.

Le monde du software a reconnu l’intérêt de prendre en compte les outils de la méthode Lean, qui vient du monde industriel, en adoptant la méthode Agile/Scrum. Maintenant, les nouvelles normes en informatique comme le CMMI poussent à mettre en place des systèmes de mesure et de contrôle comme ils peuvent exister dans toutes les autres disciplines qui sont régies par des processus. Il est donc temps pour les fournisseurs de solutions informatiques d’intégrer la dimension Six Sigma.

Thierry Mariani
Auteur : Thierry Mariani – Juggling Paradigms Sàrl
DFSS and TRIZ innovation expert
Lean Six Sigma Master Black Belt – ISSSP Scottsdale USA
MSc. Mechanical / Automotive Engineering – CNAM Paris, France
Connect with Thierry on LinkedIn at: www.linkedin.com/in/thierrymariani
Auteur : Thierry Mariani – Juggling Paradigms Sàrl
DFSS and TRIZ innovation expert
Lean Six Sigma Master Black Belt – ISSSP Scottsdale USA
MSc. Mechanical / Automotive Engineering – CNAM Paris, France
Connect with Thierry on LinkedIn at: www.linkedin.com/in/thierrymariani


------------------------------------------------------------------------------------------------------------------------------------------------

(1)Par la suite, plutôt que répéter à chaque fois les mots Produits et Processus, on utilisera seulement le mot Processus car un produit peut également être considéré comme un processus de transformations contrôlées d’entrées (on parlera de causes, d’inputs ou de X) en sorties (on parlera d’effets, de conséquences, d’outputs, ou de Y). Contrôlé indiquant qu’il s’agit de transformations normales au sens Gaussien du terme https://fr.wikipedia.org/wiki/Loi_normale. Un produit manufacturé étant responsable de la transformation contrôlée d’entrées en sorties entre donc dans cette catégorie. Ce peut être le cas par exemple, d’un roulement à billes qui transforme ou contrôle les translations axiales ou radiales (les Xs) non désirables d’un arbre de transmission en unique  rotation  (le Y).

(2)Significatif veut dire un changement drastique qui se distingue donc des changements aléatoires inévitables et courants, intrinsèques à toutes les transformations.

(3)Voir article: DFSS a complex but worthwile deployment http://www.jugglingparadigms.com/en/nos-references/dfss/

(4)https://fr.wikipedia.org/wiki/Capability_Maturity_Model_Integration

(5)https://fr.wikipedia.org/wiki/Ma%C3%AEtrise_statistique_des_proc%C3%A9d%C3%A9s

(6)De certains argumenteront, pour distinguer ces deux dernières approches, que :

-La première fait référence à la philosophie de l’agilité qui promeut l’idée de flexibilité dans le développement et ce afin de contraster avec l’image de rigidité de la méthode en cascade ou Waterfall qui aurait pour inconvénient de tout développer en marge du client. L’image véhiculée par le Waterfall étant qu’après avoir obtenu la signature du contrat, on va écrire le programme en fonction du cahier des charges dans son coin pendant des mois voire des années et qu’au final on délivre un produit qui ne correspond pas ou plus aux désidératas du client car soit le contexte a changé, soit il n’avait pas pensé à un certain nombre de choses critiques, soit le cahier des charges a été mal compris, mal écrit, mal suivi, etc.

-Et la deuxième fait référence à la méthode de travail Scrum qui est le nom anglais de la mêlée que font les Rugbymen pendant les matchs. Le Scrum serait donc la façon de faire des développements de type Agile.

La métaphore de la mêlée représente l’idée du mélange et de la confrontation du rapport besoins/solutions que l’équipe du fournisseur (typiquement composée : des développeurs, testeurs, Scrum Master) va avoir avec le client lors des réunions de fin de sprint(7).

(7) Un Sprint représente une itération de développement informatique entre la prise en charge d’un besoin client et la livraison d’une solution fonctionnelle pour répondre à ce besoin. Le Sprint a typiquement une durée d’une ou deux semaines.