Référentiels et bonnes pratiques

Hand mit Daumen hoch durchbricht WandUne bonne pratique n’est pas uniquement une pratique qui est bonne, mais une pratique ayant fait ses preuves et permis d’obtenir de bons résultats, et qui est dès lors recommandée comme modèle. C’est une expérience réussie, testée et validée au sens large, répétée, qui mérite d’être partagée afin qu’un plus grand nombre de personnes se l’approprient.

Voici une liste des plus grands référentiels et méthodologies mises en place dans les entreprises pour le business et pour l’IT:

Au niveau de l’entreprise et du métier

Ces méthodes permettent de bien définir les besoins de l’entreprise ou de l’organisation, les processus métiers et les besoins des utilisateurs : à partir d’une vision, on peut définir une stratégie pour apporter de la valeur à l’entreprise.

  • Balanced ScoreCard (BSC): méthode visant à mesurer les activités de l’entreprise à partir de sa vision et de ses missions (apprentissage, processus, clients et finances)
  • Master of Business Administration (MBA): ce n’est pas une méthode mais un  diplôme international d’études supérieures permettant d’avoir une vue globale  de l’entreprise et de son environnement (stratégie, marketing, finances, ressources humaines et management).
  • Business Process Management (BPM): permet d’identifier les processus métiers de l’entreprise et de leurs interactions pour les optimiser et les fluidifier en les automatisant autant que possible
  • Certified Business Analysis Professional (CBAP): certification basé sur le BABoK (Business Analysis Body of Knowledge) permettant de savoir exprimer les besoins des métiers des clients et identifier les opportunités d’affaire  (analyse d’affaires)
  • Lean Startup est une approche spécifique du démarrage d’une activité économique et du lancement d’un produit. Elle est plus particulièrement adaptée aux Startups qui cherchent à concevoir des produits et services qui satisfont au mieux la demande des utilisateurs, avec un investissement initial minimal. Elles doivent s’adapter rapidement à la demande (scalabilité) en fonction des retours des utilisateurs.

Au niveau de l’IT

Ces méthodes permettent de bien définir les besoins du système d’information (IT) adaptés aux besoins métiers de l’entreprise; ces méthodes doivent apporter:  valeur (cout et qualité optimisés), risques (maitrisés), ressources (humaines et matérielles optimisées), performances (mesures et amélioration continue) et alignement (avec la stratégie de l’entreprise)

  • Control Objectives for Information and related Technology (CoBIT): est un outil qui permet de faire le lien entre la gouvernance d’entreprise et la gouvernance des Systèmes d’Information (rôles et responsabilités de la DSI, traduire les besoins métiers en besoins IT, surveiller et contrôler la DSI)
  • ISO/CEI 27000: suite de normes sur la sécurité des SI permettant de  garantir la sécurité du SI en mettant en œuvre le systèmes de management de la sécurité de l’information (SMSI)
  • Information Technology Infrastructure Library (ITIL): le plus abouti des ouvrages recensant les bonnes pratiques du management du système d’information permettant d’identifier, concevoir, et mettre en ouvre une offre de services informatique adaptés aux besoins du métier, et améliorer l’offre de services en contenu.
  • Lean-IT: permet de garantir l’efficience des processus informatiques et optimiser les ressources (matérielles et humaines); Issue du Lean management, et appliquée à l’IT, il tente d’éliminer tout « gaspillage », c’est à dire tout travail qui n’apporte aucune « valeur métier » aux services informatique.
  • The Open Group Architecture Framework (TOGAF): méthode permettant d’accompagner la transformation progressive de l’entreprise et de garantir l’alignent de l’IT et de la stratégie de l’entreprise sur différents niveaux  (métiers, informations, application, données, systèmes)
  • Capability Maturity Model Integration (CMMI) est un ensemble de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités des entreprises d’ingénierie, initialement les fournisseurs de logiciels informatiques, et maintenant permettant à l’entreprise d’évaluer et d’améliorer ses propres développements de produits.

Gestion de projets

Ces méthodes permettent de livrer des produits des projets avec une qualité, un cout et délai convenus avec le demandeur, mais également de vérifier que le produit est bien aligné au métier en y apportant de la valeur. Si ce n’est pas le cas, il peut être arrêté à tout moment, si possible le plus tôt possible. Il faut cependant bien distinguer les projets des programmes qui impliquent une transformation:

Gestion de projet

Un projet est la livraison du produit selon un périmètre. De ce périmètre on en déduit l’activité nécessaire pour le réaliser, le délai et son cout. Les méthodes « classiques » de gestion de projet imposent de bien définir le périmètre du projet et les parties prenantes. Les méthode agiles permettent de construire le périmètre au fur et à mesure du projet avec des retour des utilisateurs rapides mais selon un rythme imposé

  • Project Management Professional (PMP): recueil de bonnes pratiques basée sur des méthodologies classiques de gestion de projet avec un niveau de certification élevé (impose un certain nombre d’années d’expérience)
  • Prince2 (PRojects IN Controlled Environments): méthode de gestion de projet classique avec une certification plus accessible
  • SCRUM: Méthode agile qui s’appuie sur le découpage d’un projet en unité de temps appelée  « sprints »; il s’appuie sur 3 piliers: la transparence (entre l’équipe et le management), l’inspection (à intervalle régulier on fait les point pour vérifier toute déviation) et l’adaptation (capacité à changer et à s’adapter)

Programme:

Un programme est un ensemble de projets concourant à un même objectif, organisé transversalement dans une entreprise. Ces méthodes permettent de délivrer une transformation et d’accompagner au changement l’entreprise. Pour réussir il doit être organiser avec une gestion en portefeuille avec une priorisation des projets.

  • Managing Successful Programmes (MSP): guide de bonnes pratiques en gestion de programmes pour amener l’entreprise à se transformer en organisant les livraison des projets et garantir l’adéquation des solutions avec les besoins métiers
  • Management of Portfolios (MOP) : guide permettant la gestion de portefeuille avec une priorisation des projets, assurer le choix des projets permettant à l’entreprise d’atteindre ses objectifs, prioriser et équilibrer les portefeuilles.

Amélioration des projets, produits et services

Les processus métiers, produits et services doivent être améliorés en continue, pour être au plus prés de la demande et des existences des clients:

  • ISO 9001 est un norme qui définit des exigences au sein de l’entreprise pour la mise en place d’un Système de Management de la Qualité (SMQ) pour améliorer en permanence la satisfaction client et fournir des produits et services conformes.
  • Lean-6Sigma: méthode qui associe le Lean et 6Sigma pour permettre une fluidité des processus de production (éviter le « gaspillages ») et les variations dans les processus (défauts)
  • Kaizen: processus qui vise l’amélioration continue d’une entreprise en apportant chaque jour de petits changements. Pour être efficace, tous les employés, cadres ou non cadres, doivent participer en donnant des idées.

Références:

 

Qu’est-ce qu’un PMO ?

pmo-project-management-office

3 lettres, mais beaucoup de confusion ! D’après Wikipedia, il est courant en France de désigner le rôle de Chef de Projet par le sigle PMO (pour « Project Management Officer »). Il s’agit d’une erreur : le PMO (« Project Management Office« ) représente bien un service et non une personne.

 

Échec des projets

Dans les années 1990, The Standish Group a noté dans un rapport que 90% des projets ont échoués dans l’atteinte des objectifs QCD (qualité/coûts/délai). Seulement 9% des projets dans les grandes entreprise, 16% dans les entreprises de taille moyenne et 28% dans les petites entreprises ont été réalisés et livrés dans les délais et budgets définis au départ, avec un bénéfice pour le business et les parties prenantes qui ont pu être mesurés. Ces chiffres ont certes doublés dans les années 2000 mais ont tendances à stagner (35% au lieu de 16% pour les entreprises moyennes). Les organisations du monde entier ont alors défini les bonnes pratiques relatives aux processus et à la gestion de projet. Le PMO est mis en place pour pour faire évoluer l’organisation dans une dynamique d’amélioration continue en utilisant ces bonnes pratiques. Il existe trois formes d’organisation: le PMO d’entreprise, le PMO d’organisation et le PMO spécifique à un projet.

La définition du PMO

Dans une entreprise, le Project Management Office (PMO) est le service ou département qui définit et unifie les processus liés à la gestion de projet au sein d’une organisation. Le PMO fait en sorte de standardiser et d’optimiser les charges en identifiant des tâches communes dans la réalisation des projets. Le PMO est une source de documentation, de références et de statistiques pour la réalisation et la gestion de projets.

Dans un souci de performance, le PMO peut fonder ses principes de gestion de projet sur des méthodologies standards et reconnues dans le milieu, telles que PMBOK or PRINCE2.

La réalité

Les rôles des PMO sont potentiellement multiples.Leur rôle n’est pas clairement défini.

Une majorité des PMO créés se focalise aujourd’hui sur la simple gestion d’un seule projet critique. L’équipe PMO peut alors apparaître comme une couche administrative de plus.

La démarche doit être plus ambitieuses : le PMO doit servir de tour de contrôle, tout en assurant la mutualisation des moyens au niveau de l’entreprise, et devenir le garant de la valeur produite par les projets de l’organisation.

Les facteurs clés de succès

Le PMO doit avoir clairement deux rôles : l’un est d’assurer le support stratégique de l’organisation, l’autre est de fournir le support méthodologique aux chefs de projets

– support stratégique des projets vis à vis de l’organisation: le PMO est le garant vis-à-vis de l’organisation sur un ensemble de processus stratégiques  :

  • La direction fournit le cadrages, enjeux, et les objectifs des projets
  • le PMO définit les processus d’innovation centrés sur la stratégie, sa qualité et son efficience, de management du portefeuille de projets et de création de valeur
  • le PMO fournit à la direction un suivi consolidé QCDR (Qualité, Coûts, Délais, Risques) du portefeuille de projets
  • le PMO est garant de l’utilisation optimale des ressources allouées et du le respect de la méthodologie de management des projets .

– support méthodologique à la gestion de projets : le PMO donnera un appui constant aux chefs de projet sur les différents thèmes de la gestion de projets:

  • Tenue du planning et pilotage des délais
  • Tenue du budget et gestion des aléas
  • Management des ressources, qui doivent être optimisées
  • Management de la qualité, qui doit être irréprochable
  • Gestion des risques
  • Audits de projets
  • Gestion du changement
  • Suivi et reporting QCDR par projet
  • Méthodologie en management de projet, bonnes pratiques
  • Gestion documentaire
  • Fin de projet, capitalisation, retour d’expérience

 

Références

Bien démarrer un projet SCRUM

Comment bien démarrer un projet en mode agile comme SCRUM ? L’idée de ce billet n’est pas de détailler toutes ces tâches mais de les présenter dans un cas concret.

Les rôles de chacun dans un projet SCRUM

Pour rappel Scrum définit seulement 3 rôles :

  • Le Product Owner qui porte la vision du produit à réaliser et travaille en interaction avec l’équipe de développement. Il s’agit généralement d’un expert du domaine métier du projet. C’est la personne qui la personne à qui on donne une mission, un mandat, pour mener à bien un projet. On lui délègue des pouvoirs, des moyens et la responsabilité du succès du projet.
  • L’Equipe de Développement qui est chargée de transformer les besoins exprimés par le Product Owner en fonctionnalités utilisables. Elle est pluridisciplinaire et peut donc encapsuler d’autres rôles tels que développeur, architecte logiciel, DBA, analyste fonctionnel, graphiste/ergonome, ingénieur système.
  • Le Scrum Master qui doit maîtriser Scrum et s’assurer que ce dernier est correctement appliqué. Il a donc un rôle de coach à la fois auprès du Product Owner et auprès de l’équipe de développement. Il doit donc faire preuve de pédagogie. Il est également chargé de s’assurer que l’équipe de développement est pleinement productive.

La séparation MOA et MOE

Je rajoute un quatrième rôle que je nommerai l’exécutif, qui représente l’organisation commanditaire, ou autrement dit la MOA, et les intérêts des parties prenantes du projet (utilisateurs, fournisseurs, direction,…). Il en en étroite liaison avec le produit owner qui représente la MOE.  C’est l’exécutif qui a le pouvoir d’arrêter ou non le projet. Le product owner doit alors demander l’autorisation de continuer le projet après chaque phase. Il a donc le contrôle du projet.

A noter que ce rôle n’est pas préconisée par les méthodologies agiles qui ne font de séparation entre MOA et MOE, mais par mon expérience elle est utile pour les projets avec une séparation « contractuelle » entre ces deux entités. Il est cependant recommandé de s’efforcer au maximum de décloisonner ces deux entités qui doivent collaborer étroitement tout au long du projet. En particulier les utilisateurs et opérateurs doivent interagir avec les équipes de développement tout au long du projet (voir DevOps)

La phase d’élaboration

Cette phase permet de s’assurer que l’on dispose de toutes les autorités nécessaires pour initialiser le projet, que l’on dispose d’informations suffisantes pour définir le périmètre du projet, que les modalités de livraisons ont été convenus, et que des candidats ont été retenus pour constituer l’équipe projet.

  • Nommer un exécutif et un product owner : c’est une condition préalable pour s’assurer que le projet est justifié par l’entreprise
  • Recueillir les retours d’expérience passés: il  est possible que d’autres projets menés par entreprise aient permis de tirer des leçons concernant les faiblesses ou les points forts des processus, techniques ou outils utilisés; les personnes ou les équipes justifiant cette expérience préalable doivent être consultées
  • Composer et nommer l’équipe projet: composer l’équipe projet, SCRUM master et développeurs, estimer le temps et l’effort pour chacun de ces roles
  • Préparer les objectifs et enjeux du projet: l’exécutif expose au product owner les informations qu’il dispose (objectifs, raisons, normes, contrat, exigences qualité, critères d’acception, délais, cout, risques …)
  • Définir l’approche projet: le product owner évalue et valide avec l’exécutif la manière dont le projet doit être abordé avant d’être planifié (solution de livraison possibles, confirmer les objectifs, périmètres, contraintes, tolérances, interfaces ..), l’approche agile par SCRUM doit être également validé par l’exécutif.
  • Planifier la phase initialisation: la phase d’initialisation (premier incrément SCRUM) est planifié.
  • valider la phase avec l’exécutif: l’exécutif doit autoriser le démarrage de la phase d’initiation; sans cette autorisation le projets est arrêté.

La phase d’initialisation

La phase initialisation (Sprint Init) a pour but de doter le projet de fondations suffisantes pour mieux comprendre le travail à faire. Voici une liste de tâches pouvant être intégrée dans la phase d’initialisation.

  • Préparer la stratégie du projet: le product owner définit les objectifs, la procédure, les outils ainsi que le rôle et la responsabilité de chacun pour les domaines suivants: risques, qualité, communication, gestion des incidents …
  • Valider les objectifs et les enjeux du projet: le Product Owner présente et valide avec toute l’équipe les objectifs et les enjeux du projet : il doit partager les points qui ont vu dans la phase précédente avec l’exécutif comme par exemple: concurrence, Dead Line et contraintes « imposées » par le client …
  • Découper le projet en livraison et priorisation: le Product Owner présente sa vision du contenu des livraisons du projet, objectifs, jalon et utilisateurs et définit les priorités;
  • Découper les livraisons en Sprint et priorisation: le Product Owner présente un découpage « grossier » du contenu des livraisons avec la priorisation des Sprints.
  • Rappeler des principes de Scrum: un rappel collective à l’équipe et le Product Owner par le Scrum Master ne fait jamais de mal
  • Mettre en place de l’architecture technique: l’environnement technique doit être définit et prêt dés ce premier sprint, avec au minimum un environnements de développement et d’intégration opérationnel (installé et configuré), règles de développement, gestion du code source avec les règles de fonctionnement, le processus de sauvegarde et idéalement un processus d’intégration et de test automatisé
  • Mettre en place le management visuel: l’équipe prépare les  indicateurs visuels du projet: scrum board (user stories, product backlogs, sprint backlogs, burn down chart, identification du sprint courant et contenu) que l’on peut compléter par une partie : problèmes techniques ou organisationnel et actions à faire suite au sprint précédent .
  • Réunion de planification collective: Le product Owner présente les exigences fonctionnels et non fonctionnels des livraisons et l’équipe chiffre avec la technique de Planning Poker et ordonne en  taches. Le découpage permet de valider ce qu’il va y avoir dans chaque Sprint. le Product Backlog est alors constitué et affiché par ordre de priorité.
  • Réunion de planification du Sprint 1: la durée de la réunion doit être de 2h par semaine de Sprint (soit 4h pour un sprint de 2 semaines). On doit définir:
    • le quoi: le produit owner revoit avec l’équipe de développement l’objectif du sprint et le Product Backlog. L’équipe vérifie les estimations, confirme qu’elles sont exactes et sélectionne en haut du Product Backlog les exigences qu’elle se sent capable de convertir en fonctionnalités utilisables d’ici la fin du sprint
    • le comment: L’équipe fait ensuite l’inventaire des tâches qui permettront de convertir les exigences sélectionnées en fonctionnalités utilisables d’ici la fin du sprint. Les tâches de développement sont centralisées dans le Sprint Backlog
  • valider la phase avec l’exécutif: le product owner demande à l’exécutif d’autoriser le démarrage de la phase suivante; sans cette autorisation le projets est arrêté.

Sprint 1

  • Daily Scrum Meeting: Le point quotidien de l’équipe avec le Product Owner; le  tableau du reste à faire Burndown Chart est remis à jour. Les obstacles rencontrés, doivent être priorisées par le product owner, qui doit les suivre et bien sûr s’efforcer de les lever au plus tôt afin de garder l’équipe pleinement concentrée et productive.
  • Développement et tests: l’équipe se concentre sur l’accomplissement des tâches du Sprint Backlog;la tache doit être validée, testée et documentée avant être considéré comme terminée. Le pair programmation peut être mis en place pour veiller à la qualité du code d’une exigence donnée.
  • Réunion de planification du Sprint 2: Dans la dernière semaine du Sprint, l’équipe, le Scrum Master et le Product Owner préparent le Sprint suivant, comme pour le pour Sprint 1
  • Fin du développement du Sprint 1: les taches doivent être développées, testées et disponibles sur l’environnement d’intégration
  • Revu de Sprint: Prévoir une heure par semaine de sprint (soit 2h pour un sprint de deux semaines) ; L’objectif de la revue de sprint est d’inspecter l’incrément produit au cours du sprint écoulé, faire un point sur l’avancement de la version et adapter au besoin le plan et le Product Backlog. L’équipe de développement présente au Product Owner idéalement accompagné d’utilisateurs, les nouvelles fonctionnalités développées au cours du sprint. Le Product Owner donne un feedback à l’équipe, il accepte ou refuse les fonctionnalités présentées.
  • Rétrospective de Sprint: Prévoir une durée de 45 min par semaine de Sprint (soit 1h30 pour un Sprint de 2 semaines) : l’équipe et le Scrum master  analyse les obstacles du Sprint 1 et les axes d’amélioration.
  • Mise en place physique du tableau des obstacles: C’est la tâche qui permet de ne pas oublier de mettre à jour la liste des obstacles.
  • Mise à jour des définitions de fini pour une tâche et pour le Sprint (en fonction de la rétrospective): Cette mise à jour dépend des retours de la rétrospective.
  • Calculer la vélocité du Sprint 1: Combien de temps l’équipe a-t-elle passé à développer (et tester) des fonctionnalités pour la release ?

Sprint 2

  • Daily Scrum Meeting
  • Développement et tests
  • Réunion de planification du Sprint 3
  • Fin du développement du Sprint 2
  • Revu de Sprint
  • Rétrospective de Sprint et comparaison avec les rétrospectives précédentes
  • Mise en place physique du tableau des obstacles
  • Mise à jour des définitions de fini pour une tâche et pour le Sprint (en fonction de la rétrospective)
  • Calcul de la vélocité du Sprint 2 et comparaison avec le Sprint 1

Il y a exactement les mêmes tâches entre le Sprint 1 et le Sprint 2 : Seul le contenu change, les résultats du Sprint 1 vont influer sur le Sprint 2 et ainsi de suite jusqu’au dernier Sprint.

A noter que le dernier Sprint correspond à la confirmation que la livraison du produit a été accepté  et que le projet peut être clos pour être passé en maintenance.

Centre de services, régie et forfait

Il est bon parfois de rappeler certain principe. Quand on parle de centre de services en informatique, on parle du point de contact entre les gens du métier qui ont la connaissance fonctionnelle (c’est la maitrise d’ouvrage), et les services informatiques, qui ont la connaissance technique des infrastructure ou des application (c’est la maitrise d’œuvre), pour traiter des demandes pour un projet ou un service donnés. En externalisant ces services, cela constitue une manière efficace d’organiser les projets en termes de réactivité, de montée en charge ou en compétences techniques, de qualité et de transfert de savoir-faire. On parle alors de sociétés de services en informatique (ou du numérique) ou plus vulgairement d’ESN ou antérieurement SSII.

On distingue deux types de services:

Centre de services orienté Compétentes

Traditionnellement, quand une entreprise confie un projet informatique à une société de services en informatique (SSII ou ESN), le projet est réalisé dans les locaux du donneur d’ordre, par un ou des salariés de la SSII délégués sur place et facturés au nombre de jours passés. On parle alors de régie. Cela concerne la mise en place d’un ensemble de profils dotée de compétences bien identifiées.

Les critères de qualité et d’efficacité de ce centre de service sont principalement:

  •     la disponibilité des équipes (recrutement),
  •     la capacité à monter en charge,
  •     les compétences des ingénieurs (profils, formation, évolution),
  •     leur motivation et leur implication.

Les compétences demandées peuvent être techniques (MOE) ou métier, on parle alors d’assistance à la maitrise d’ouvrage ou AMOA.

Le pilotage du projet se fait par le client sur une période donnée.Un taux journalier (TJ) est négocié pour ces intervenants sur cette période. Certaine régie peuvent être « forfaitisée » avec un engagement de résultat. Dans ce cas aucune facturation ne peut se faire en cas dépassement, voir des pénalités de retard peuvent être encourues si le contrat le prévoyait.

Centre de service orienté Projet

Depuis quelques années, la plupart des SSII (ESN) ont développé une approche alternative à la demandes de leurs clients. Celle-ci repose sur la constitution de centres de services, regroupant des ingénieurs ou techniciens spécialisés sur une technologie ou un secteur d’activité, et intervenant sur des projets de développement applicative. Concentrant ces spécialistes dans un centre de service, cela permet d’améliorer les méthodes de développement et de mutualiser les profils sur plusieurs projets, bref d’optimiser les couts.

Ce centre de services s’engage sur un ensemble de projets au Forfait, en termes de délais, coûts, qualité. Il est dédié au développement d’applications sur toutes les phases de développement, depuis l’analyse, la spécification fonctionnelle, la réalisation, jusqu’au déploiement, avec un engagement basé sur les charges et de couts, les délais et la qualité des livrables. La gestion de la qualité doit s’assurer de la satisfaction du client tout au long du projet.

La facturation se fait sur un coût global, le périmètre précis et une date de livraison ont été définis et négociés. Chaque évolution est facturée comme un avenant au projet. La encore des pénalités de retard peuvent être encourues si le contrat le prévoyait.

Centre de service orienté Maintenance

Le Centre de Services Maintenance, traite des demandes de type TMA ou TRA.

  • maintien en condition opérationnelle des applications : corrections et évolutions,
  • amélioration de la performance et de la qualité des applications,
  • évolutions techniques et fonctionnelles,
  • support à différents niveaux.

Il fonctionne sur le même mode d’organisation que le Centre de Services Projets. Des indicateurs de qualité de services (SLA) peuvent être mis en place entre le client et le fournisseur pour mesurer la qualité des livrables et la tenue des engagements. Des revues périodiques permettent de s’assurer du bon fonctionnement.

 

 

Qualité logicielle et logiciel libre

D’après la définition de Wikipédia, « la qualité logicielle est une appréciation globale d’un logiciel, basée sur de nombreux indicateurs: la complétude des fonctionnalités, la précision des résultats, la fiabilité, la tolérance de pannes, la facilité et la flexibilité de son utilisation, la simplicité, l’extensibilité, la compatibilité et la portabilité, la facilité de correction et de transformation, la performance, la cohérence et l’intégrité des informations ».

quality survey

Indicateurs de qualité logicielle

La norme ISO 9126 définit six groupes d’indicateurs de qualité des logiciels :

  • la capacité fonctionnelle:  capacité qu’ont les fonctionnalités d’un logiciel à répondre aux exigences et besoins explicites ou implicites des utilisateurs. ;
  • la facilité d’utilisation, qui porte sur l’effort nécessaire pour apprendre à manipuler le logiciel: facilité de compréhension, d’apprentissage et d’exploitation ;
  • la fiabilité: capacité d’un logiciel de rendre des résultats corrects quelles que soient les conditions d’exploitation (dont la tolérance aux pannes) ;
  • la performance: rapport entre la quantité de ressources utilisées (moyens matériels, temps, personnel), et la quantité de résultats délivrés: temps de réponse, débit et extensibilité ;
  • la portabilité: aptitude d’un logiciel de fonctionner dans un environnement matériel ou logiciel différent de son environnement initial (facilité d’installation et de configuration).

La recherche en informatique

Le problème n’est pas nouveau: depuis les années 1970 la recherche en informatique s’est intéressée à l’idée décrire du code à partir de spécifications et d’en prouver sa validité à partir de logique mathématique. Cela a donné lieu à un foisonnement de recherche qui visent à employer les méthodes formelles pour s’approcher de cet objectif: il a fallu plusieurs décennie pour arriver aux exploits d’aujourd’hui qui sont la production d’une chaine de compilation certifié, la vérification de code ou la certification d’un noyau de système exploitation.

Mais la complexité du code développée aujourd’hui et la vitesse avec lequel il change, oblige à la mise en place de tests systématiques, et une lisibilité, maintenabilité et évolutivité du code qui ont fait également l’objet de nombreux recherches dans l’architecture, et le processus de développement et de maintenance des logiciels avec le besoin de fournir des mesures exploitables. Le logiciel libre est un moyen qui s’est généralisé parmi les chercheurs pour partager leurs résultats et faciliter les contributions.

On peut se référencer pour cela au livret bleu du logiciel libre sur la qualité logiciel de Systemics (voir référence en bas) dont cet article est largement inspiré et qui liste les grands projets de recherche dans le domaine.

L’informatique embarqué critique

Malgré ces exploits, l’utilisation de ces méthodes restent anecdotiques dans le monde industriel, qui y ont recours que dans des environnements hautement critiques. Dans ces domaines des normes obligent les industrielles à un effort de qualification (et donc couteux) pour des exigences de fiabilité (transport, avionique) ou de sécurité (carte à puce, télécommunication): l’activité de programmation y est soumise à des règles très contraignantes (et donc très couteuses): voir l’article sur la norme DO 178 .

Dans ces environnements, les industriels ont besoins de s’appuyer sur des standards pour la certification et aux  preuves formelles pour poser les bases de la qualité logiciel.

L’informatique en milieu industriel non critique

Dans le contexte non critique, on trouve des niveaux d’exigence divers: SI d’entreprise et d’administration, transaction bancaire sensible, informatique embarquée non critique.

Ces cas sont caractérisés par une grande quantité de codes, une inter connectivité entre les systèmes croissante et un large recours aux tests, avec une combinatoire impossible à couvrir de manière exhaustive que ce soit pour des méthodes manuelles ou automatisées.

L’enjeu devient donc d’optimiser les moyens de tests pour minimiser les risques; on a alors recours à des méthodes qui visent à ce que le code ait un niveau jugé suffisant pour répondre aux besoins, plutôt que de le valider par les méthodes formelles. Pour cela on cherche à garantir le processus de développement par l’utilisation de bonnes pratiques, en corrigeant et en traçant par exemple les erreurs pour éviter toute régression. La qualité du logiciel est améliorée en industrialisant le processus de développement avec des métriques et différents types de tests. On parle alors de forge logicielle. Ces forges ont été largement répandues par le développement de logiciel libre. On parle alors d’ingénierie collaborative qui caractérise le monde du logiciel libre avec les technologies associes: forges logicielles, démarches agiles, cloud, intégration continue …

Les méthodes agiles et les logiciels libres

L’apparition des processus agiles ont été popularisé dans les année 1990 par les grands acteurs du Web. Contrairement aux méthodes traditionnelles qui visent à anticiper et découper au maximum les différentes étapes de développement, les méthodes agiles visent sur la communication tout au long du projet entre les différents intervenants. Avec le DevOps, le processus est même traité en un seul flux depuis les besoins utilisateurs  jusqu’aux opérations (exploitation).

La qualité logicielle est alors traitée différemment: les processus traditionnels tentent de mesurer et valider en aval alors que les méthodes agiles en font un pré requis permanent tout au long du projet: l’imprévu est alors partie intégrale de la qualité logicielle.

Parmi les pratiques popularisées par les méthodes agiles, la principale est le développement piloté par les tests (TDD) : les tests, généralement automatiques, sont écrits avant même la réalisation de la fonctionnalité, ce qui force le développeur à réfléchir en permanence sur la qualité de son code, en plus d’éviter les régressions. Les plateforme d’intégration continue permettent de rejouer les tests unitaires et de non régression pour constituer de véritable chaines de qualification en continue.

Une autre pratique est celle du pair programming: l’idée étant que deux développeurs travaillent sur la même machine qui garantir de façon plus efficace le code produit; bien que cette pratique reste assez rare (car couteuse),  le « peer-reviewing » est plus répandue : cela consiste à inspecter le code produit par les pairs ce qui est plus efficace que les tests car cela permet d’éliminer de 80 à 95% des anomalies contre 30% par les tests.

Ces pratiques se sont largement répandues grâce à la disponibilité des logiciels libres (Git, jenkis, xUnit…) mises à disposition par les communautés des développeurs.

Utilisation des logiciels libres

Un autre facteur de qualité est le démocratisation de l’utilisation de logiciels libres et ouverts: plutôt que de grand projets centralisé avec du code source gardé secret, de plus en plus de projets en logiciel libre sont intégrés comme briques logiciels ; l’intérêt est que ces briques sont alimentées par des contritions venant de toute part et accessible à quiconque ce qui est gage de qualité car potentiellement ils sont revus par des milliers de personnes. Le défi étant alors de les intégrer ensemble sur des systèmes différents.

Les métriques

Autres éléments importants, les métriques qui permet de mesurer la qualité logicielle d’un code source. Le document en référence, « métriques et critères dévaluation de la qualité du code sources d’un logiciel« , vise à introduire les métriques et les critères fréquemment utilisés pour caractériser et évaluer la qualité d’un code source. Une attention toute particulière  a été portée sur l’importance et les limites de ces paramètres. Voici la liste des métriques qui ont un intérêt élevé:

Métriques standards:

  • Complexité cyclomatique:  mesurer la complexité d’une fonction (max 10);
  • Couverture de code: proportion  du  code  source couverte par des tests,   généralement  automatisés (80%)
  • Afferent and efferent coupling: mesure respectivement le nombre de références vers une classe et le nombre de types que la classe « connait » (max 20)
  • Instability: niveau de résistance au changement
  • Abstractness: niveau d’abstraction par rapport aux autres classes
  • Distance  from  main  sequence: équilibre du module entre l’abstractness et l’instability (max 0.7)
  • Lack of Cohesion Of Methods (LCOM): niveau de cohésion d’une classe
  • Relational Cohesion:  nombre moyen de relations internes à un module (entre 1.5 et 4)
  • Specialization index: degré de spécialisation d’une classe (max 1.5)
  • Number of coding rules violations : violation des règles de codage dépendantes du    langage ou des technologies utilisés

Critères supplémentaires:

  • Maintenabilité: directement liée à l’architecture logicielle, elle doit être simple et efficace
  • Évolutivité: l’architecture logicielle doit permettre une bonne évolutivité
  • Fiabilité:  nombre de défaillances rencontrées dans un intervalle de temps donné. inclut également la tolérance aux pannes.

Les outils open source

Voici une sélection d’outils non exhaustive pour une bonne qualité logicielle selon les bonnes pratiques décrits précédemment: agilité et travail collaboratif

 

Références:

Outils collaboratifs en ligne

Les outils collaboratifs en ligne deviennent incontournable pour la gestion de projet. De très nombreuses solutions existent. Outre les solutions complètes proposées par les géants de Web (Google, Microsoft…), il existe de très nombreux outils simples et pratiques qui pour certains ne nécessitent aucune connexion préalable. A noter également la suite d’outils très complètes composée de logiciels libres, proposée par Framasoft, association qui tente de « degoogoliser » internet en proposant pour chaque service une alternative avec des logiciels libre. Cette approche est intéressante car on a vu c’est dernières années une concentrations des services en lignes à quelques géants du Web (GAFAM) qui n’hésitent pas à utiliser les données, pourtant privées, des utilisateurs pour mieux cibler leurs besoins. L’association propose des alternatives à chaque outil centralisé par ces géants.

réseaux sociaux

Les agendas collaboratifs

Les outils suivants sont gratuits et nécessite une inscription préalable. Ils sont souvent associés à d’autres services (partages de documents, stockage,…) qui peuvent être payant.

> L’agenda selon Google associé à Gmail, Docs et Drive

Disponible sur web et mobile, Google Agenda est l’une des applications incontournables proposée par Google, rattachées au service de messagerie Gmail, et au côté des Google Docs, Google Drive et  Google Plus.  Elle permet de créer des agendas, de les partager avec les utilisateurs de son choix, y compris avec des personnes qui n’utilisent pas Google Agenda. Plusieurs utilisateurs peuvent consulter et modifier le même agenda.

> L’application calendrier selon Microsoft

De même Microsoft propose la solution Outlook rattachée à la messagerie et au gestionnaire de tache, et associée à l’ensemble des outils de l’éditeur: Word, Excel, PowerPoint, OneNote, et également OneDrive et Skype, il devient la solution ultra complète et incontournable (mais payante pour certains services).

> L’agenda de Yahoo Mail

L’agenda accessible depuis Yahoo Mail propose des fonctionnalités similaires aux solutions décrits précédemment. Il dispose également d’un espace de stockage de 1 To.

> L’agenda de Framasoft, l’alternative libre

A cotés des géants du Web cités précédemment, Framasoft met à disposition une solution libre Framagenda  basé sur le logiciel nextcloud avec un service en ligne de gestion et de partage de calendriers. Leur mot d’ordre: « ne partagez plus votre planning (ni vos contacts) avec la NSA ! ». L’outil propose les mêmes fonctionnalités que ceux décrit précédemment.

Stocker et partager les documents

Les outils suivants sont gratuits et nécessite une inscription préalable. Ils permettent le stockage de documents sur le Web (Cloud) et leur partage

> L’incontournable Google Drive

Google propose un service de stockage et de partage de fichiers incontournable. Il regroupe la suite bureautique Google Docs, Sheets et Slides,  permettant de modifier les documents, feuilles de calcul, présentations, dessins, formulaires, etc. Google propose la solution G Suite pour les professionnels (et donc payante) avec un espace de stockage illimité et des outils d’audits et de signature numérique des documents.

> OneDrive, la solution de Microsoft

De son coté, Microsoft propose le même service incontournable, associé à l’ensemble de ses services en ligne : Word, Excel, PowerPoint et OneNote. Le service peut s’utiliser à travers un navigateur web, ou à travers le gestionnaire OneDrive qui permet une synchronisation avec les supports et les outils installés sur le poste associé, ce qui permet de travailler hors connexion en toute sécurité sur les documents partagés.

> Dropbox, le plus populaire

L’autre figure incontournable du Web est Dropbox qui fournit un outil de stockage et de partage simplifié multi plateforme. Il propose plusieurs déclinaisons de son offre selon les contextes d’utilisation (grand public, pro, entreprise) avec des fonctionnalités différents et payantes.

> Box, tourné vers les entreprises

Box propose les mêmes offres que ses consœurs avec une orientation plutôt orienté entreprise et donc payante. Elle s’intègre avec de nombreux progiciels en ligne dont Office 365 avec une authentification via Active Directory. L’offre offre de nombreux outils de business intelligence, gouvernance des données et preuve électronique.

> Framadrive, la solution libre avec ownClould

Framasoft propose une solution de stockage et de partage de documents basé sur le logiciel libre ownCloud. L’association, dont les financements dépend de dons, limite volontairement le nombre de comptes disponibles (actuellement le nombre maximum a été atteint). Leur principe repose sur le degré de confiance qu’on peut accorder à une société privé (par exemple Dropbox) dont les clauses d’utilisation peuvent être changées jusqu’à s’autoriser l’usage des fichiers que vous leur confiez. La solution libre est une alternative car le code source peut être facilement audité pour vérifier les failles et degrés de fiabilité du système

Outils collaboratifs avec inscription

Après avoir balayer les outils en ligne indispensable , voici une sélection d’outils collaboratifs divers. Ces outils nécessitent une inscription préalable sur un compte.

> La gestion de projet avec Trello et autres

Trello est un outil de gestion de projet en ligne pour la  gestion de tâches. Il est constitué d’une liste de listes remplie de cartes, gérées par l’équipe. Les cartes sont assignables à des utilisateurs et sont mobiles d’une planche à l’autre, traduisant leur avancement.

De nombreuses autres alternatives existent:

  • Asana est une application web conçue pour permettre le travail d’équipe sans email.
  • Azendoo est une application web de gestion de projets et de tâches collaboratives.
  • Basecamp est un outil Web de gestion de projets
  • Framaboard l’alternative libre de Framasoft pour la  gestion de tâches basé sur Kanboard
  • Phabricator est une suite d’application web d’outils de développement de logiciel
  • ppulse est un outil de gestion de projet complet et rapide, avec gestion de tâches, discussions, partage de documents, wiki,
  • ProjeQtOr l’alternative libre pour la gestion de projet
  • Wrike est un fournisseur privé d’accès internet de gestion de projet

> Partage de disponibilité

Vous créez une page de planification personnelle. Vous connectez vos calendriers et définissez vos préférences hebdomadaires de disponibilité. Vous partagez votre lien avec n’importe qui demandant une réunion. Ils choisissent un temps disponible et un email est envoyé à tout le monde avec la confirmation de la réunion. Calendly est très simple à utiliser, il peut se connecter à Google Calendrier, Office 365 et Outlook.

autres alternatives:

> Chat avec Framateam / mattermost

Framateam est un service de tchat libre qui permet de communiquer avec son équipe en notifiant ses collaborateurs, de conserver les conversations et d’y faire des recherches.

Autres alternative:

> Questionnaires avec Frameforms / Drupal Webform

Framaforms est une alternative à Google Forms, qui vous permet de créer rapidement des questionnaires.

Autres alternative:

> Cartes mentales avec Framamindmap / Wisemapping

Framindmap permet de créer et partager des cartes mentales ou heuristiques. Dans cette version web, il faut être enregistré.

Autres alternative:

> Réseau social avec Framasphère / Diapora

Framasphère est un réseau social libre décentralisé. Au lieu que les données de tout le monde soient concentrées dans d’énormes serveurs, propriétés de grandes entreprises, de petits serveurs « pods » locaux peuvent être créés n’importe où dans le monde.

Il n’existe pas d’alternative proposant une solution décentralisée.

Écrire des notes partout avec Framanote / Trurl

Écrire , gérer et emporter vos notes avec vous, partout, tout le temps. C’est une alternative libre au très célèbre Evernote.

Autres alternative:

Autres outils collaboratifs sans inscription

Voici enfin une sélection d ‘outils simples et intuitif pouvant être utilisée très rapidement sans inscription préalable.

> Vidéoconférences avec Appear.in

Appear.in est un outil collaboratif qui permet de créer en un clin d’œil des vidéoconférences à partir d’un simple navigateur

autres alternatives:

> Conférence téléphonique avec OVH

Si vous avez des problèmes de communication avec la visioconférence, votre bon vieux téléphone vous permet de faire une conférence téléphonique gratuitement ! Le service proposé par OVH permet de réserver moins de 24h à l’avance une « salle » de conférence. Un courriel vous est envoyé dans la foulée avec le numéro de téléphone et le code d’accès. Il vous suffit alors de partager ces coordonnées à vos contacts.

> Tableur partagé avec Framacalc / EtherCalc

EtherCalc est un tableur collaboratif en temps réel, libre. Les données sont automatiquement sauvegardées sur internet avec un lien unique, et les collaborateurs peuvent collaborer sur le document en même temps. Tous les changements sont visualisés en temps réel.

> Éditeur de texte partagé avec Framapad / Etherpad

Un « pad » est un éditeur de texte collaboratif en ligne. Les contributions de chaque collaborateur sont signalées par un code couleur, apparaissent à l’écran en temps réel et sont enregistrées au fur et à mesure qu’elles sont tapées.

Autres alternatives:

> La planification de réunions simplifiée avec Doodle

Doodle est un site web de planification des événements, réunions, rendez-vous, etc et de sondage

Lien: doodle.com

Autres alternatives

> Le partage de liste de tâches avec Flask

Flask permet de partager avec une équipe une liste de tâches. Il suffit de créer une liste et envoyer l’url à toutes les personnes avec qui vous souhaitez la partager. Chacun aura accès à votre liste et pourra la compléter ou marquer une tâche complétée. On peut donner des couleurs différentes aux tâches et signaler comme prioritaires certaines d’entre elles. Flask fonctionne sur ordinateur ou smartphone.

Lien: Flask.io

Il existe d’autres alternatives mais une identification préalable est nécessaire:

> Le carnet de notes simplifié avec Nooot

Nooot est un outil collaboratif ultra simple.  Il s’agit d’un carnet de notes collaboratif à partager, idéal pour un brainstorming à la volée ou un texte à plusieurs mains.

> Le tableau de notes avec Framememo / Scrumblr

Framememo est encore un outil collaboratif ultra simple.  Il permet d’éditer et gérer des notes sous la forme de « post-it », type tableau scrum: à faire, en cours et fait

> Le dessin partagé avec CosKetch et Framavectoriel

CoSketch est un outil de dessin et de collaboration. Avec Cosketch vous pouvez dessiner à plusieurs sur une feuille blanche en ligne. Il dispose d’un service de tchat .

Framavectoriel est une alternative permettant de créer rapidement des images vectorielles au format SVG.

> Le partage de fichiers avec Framadrop / lufi

Framadrop est un service Web minimaliste de partage de fichiers des fichiers de manière confidentielle et sécurisée.

Line: framadrop.org

> Le partage de texte, image ou de lien sécurisé avec Framabin, pic et link

Framabin est un service en ligne libre et minimaliste qui permet de partager des textes de manière confidentielle et sécurisée. Le même service site pour les images ou pour partager un lien.

Lien: framabin.org   framapic.org   frama.link

Six Sigma, l’excellence ?

six-sigma-logoSix Sigma ou 6 Sigma est une méthode structurée de management visant à une amélioration de la qualité et de l’efficacité des processus. La méthode Six Sigma a d’abord été appliquée à des processus industriels avant d’être élargie à tous types de processus, notamment administratifs, logistiques, commerciaux et d’économie d’énergie. Depuis le début des années 2000, elle connaît un grand essor en raison de la complexité des organisations et de l’internalisation des processus qui imposent une vision mondiale des problèmes.

Origine

Six Sigma signifie la marge d’erreur d’un process. C’est une notion statistique. 1 Sigma est l’écart type (la zone autour de la moyenne). L’écart type peut être assimilé à la dispersion d’un processus. Le but est que le process de qualité est une fiabilité quasi absolue, donc qui assure une fiabilité jusqu’à 6 fois l’écart type.

Dans une démarche qualité classique on pourrait supposer qu’il suffit de s’approcher d’un taux de 99% de résultats corrects pour se sentir satisfait et estimer le devoir accompli. Le coût représenté par ce 1% de pertes de production et de manque à gagner fera la différence entre les entreprises qui réussissent et les autres. L’avantage concurrentiel repose sur ce jusqu’au-boutisme de la maîtrise de la variabilité des processus.

6 sigma est à l’origine une démarche qualité née au cœur même de Motorola. Elle a ensuite été perfectionnée par d’autres groupes industriels, comme General Electric, Allied- Signal ou Texas Instruments par exemple, qui l’ont mise en œuvre avec succès.

Principe

Six sigma s’appuie sur 3 notions principales:

  • le client: mieux connaître les attentes des clients et les facteurs clés de la qualité au sens du client et non au sens des habitudes et pratiques de l’entreprise: c’est avant tout prendre en compte la voix du client (recueil de besoins, sondage, avis..) , c’est-à-dire recueillir et analyser les avis des clients.
  • les processus: afin de connaître et maîtriser les facteurs influents de la qualité qui permettent de cibler du plus efficacement possible les actions d’amélioration des processus avec la certitude de toujours aller dans le sens de l’accroissement de qualité selon le client.
  • la mesure: des mesures fiables mesurant la performance du processus métier afin de maîtriser la variabilité des dits facteurs, et d’encadrer la variabilité des facteurs influents de la qualité au sens du client dans les limites de l’acceptable et d’éliminer définitivement les possibilités d’écarts imprévus. Bref d’accroître la satisfaction client en continue.

L’ennemie des processus c’est la variabilité qui entraine la non qualité et l’insatisfaction des clients. Donc on cherche à améliorer le processus jusqu’à ce que seuls les produits qui correspondant aux attentes, aux spécifications soient livrés : produire de la manière attendue dès la première fois en évitant ainsi les corrections, les retouches, les réparations et surtout les coûts associés. La méthode Six Sigma vise à améliorer le processus pour que ces produits soient tous bons, il ne s’agit pas de contrôler les produits, mais de s’assurer que le processus est fiable.

La méthode Six Sigma peut s’implémenter dans tout type de processus et pas seulement de production, il suffit simplement que les performances du processus soient mesurables.

La méthode

La méthode se base ainsi sur cinq étapes qui se contractent dans l’acronyme « DMAIC » : Define, Measure, Analyse, Improve, Control:

dmaic_process_flow

  • D. Définir l’objectif: Définir les besoins des clients et préciser les objectifs à atteindre, cadrer le projet. Elle permet de définir le périmètre du projet, les attendus, les ressources et délais nécessaires. Quels sont les paramètres critiques (facteurs influents) au sens de la qualité pour le client ? Ce sont ceux-ci qu’ils s’agit de suivre, de mesurer, d’analyser et de traiter.
  • M. Mesurer les attentes du client: Adopter une méthode rationnelle de mesure des facteurs influente (Xi) et des attentes du clients (Yi) en garantissant le système de mesure. Collecter les données représentatives, mesurer la performance, identifier les zones de progrès. Évaluation de la performance actuelle et de sa variation (tendance, cycle…). Vérifier l’adéquation du processus avec  la performance.
  • A. Analyser les problèmes, les forces et faiblesses: réaliser une analyse de données pour identifier les facteurs Xi les plus influents sur les Yi. Utilisation des outils analytiques et statistiques pour identifier les causes de problèmes (Schéma de cause à effet). A ce stade du déroulement de la méthode, il faut comprendre les problèmes et leurs origines pour pouvoir formuler par la suite les solutions susceptibles de combler l’écart entre la situation présente et les objectifs clients.
  • I. Améliorer, innover, se différencier: Identification et mise en œuvre des solutions relativement aux Xi les plus influentes. Cette phase particulièrement importante doit permettre de tester et de valider les solutions les plus adéquates en définissant les tolérances acceptables  et le déroulement
  • C. Contrôler et garantir la qualité à long terme: en mettant en place des outils de pilotage du processus. Il est important d’éviter tout retour en arrière. L’effort doit être soutenu voire réorienté. Il est important de maintenir le processus « sous contrôle » avec de la documentation à jour, un pilotage par tableau de bord, puis un accompagnement du changement et le transfert de connaissance.

la méthode DMADV

La méthode DMADV est plus adaptée lorsqu’il s’agit de mettre en place de nouveaux processus. Cette méthode assez similaire à DMAIC se compose des phases suivantes : Define, Measure, Analyze, Design,Verify

Les 3 premières phases sont similaires à la méthode DMAIC.

  • La phase Design définit dans le détail le processus afin d’être en parfaite concordance avec les attentes des clients.
  • La phase Verify vérifie que la performance et la capacité sont conformes aux objectifs et aux attentes des clients.

Réussite d’un projet 6 Sigma

Au-delà de la méthodologie, la réussite d’un projet Six Sigma doit s’appuyer d’un conduite du changement. Souvent, par facilité ou pour gagner du temps, les entreprises tendent à mettre en place des solutions toutes faites qui répondent selon elles à des problèmes. Avec la méthode Six Sigma, l’objectif est de bien cerner le problème, à travers des analyses de processus ou de mesures. Une fois le problème bien identifié, la solution découle souvent de source. Un accompagnement avec soutien de la direction est souvent nécessaire pour éviter un blocage ou d’un enlisement. Des projets courts, montrant des résultats concrets combinés à un schéma directeur plus longs procurant des bénéfices à plus long terme, permettent de soutenir ce type d’initiative.

On est très proche du processus Lean décrit dans les articles  précédents.

Le Lean  Six Sigma

D’ailleurs une autre méthode consiste à associer au Six Sigma, le Lean. Le Lean 6 Sigma prend de plus en plus le pas sur le Six Sigma. Le Lean Six Sigma est donc l’utilisation du Six Sigma et du Lean Manufacturing.

On l’a vu précédemment, les deux méthodes, Lean et Six Sigma, sont orientées vers le client. Mais elles différent sur les points suivants:

  • Le 6 Sigma vise à diminuer la variabilité des processus afin de les fiabiliser, les rendre stables et prévisibles, s’assurer de la reproductibilité « parfaite » du processus
  • Le Lean est un mode d’organisation qui vise l’élimination des tâches sans valeur ajoutée pour le client et l’entreprise. Pour rappel, afin de réduire tout gaspillage et gagner en agilité, le Lean utilise 3 principes fondamentaux : le juste nécessaire, la remise en cause permanente (agilité) et l’intelligence collective (on lâche-prise pour mieux garder le contrôle!).

Les deux démarches sont donc compatibles et complémentaires. Elles visent à l’amélioration en  continue de l’efficience de la productivité associée à la réduction de la dispersion des processus. La démarche Lean va chercher à optimiser le processus, en adaptant les méthodologies et les outils nécessaires aux enjeux et à la situation, la démarche 6 Sigma va réduire la dispensation.

La gestion de projet en mode agile

Le Six Sigma est une démarche d’amélioration continue qui se rapproche de la gestion de projet en mode agile et permet la réalisation de projet plus rapidement et avec une plus grande probabilité de réussite. La mise en place se fait en 5 itérations suivant le DMAIC afin d’avoir une  :

  • Meilleur qualité de la communication : les exigences plus facilement clarifiées (Phase D)
  • Meilleur visibilité sur l’avancement des actions avec un management visuel (Phases M, A,C)
  • Contrôle des phases et étapes : les évaluations et revues de projet sont réalisées en continue en tant que de besoins (Phase C)
  • Détection des risques : Les risques sont détectés et évalués plus tôt et régulièrement mis à jour. (Phases M,A)
  • Motivation et confiance de l’équipe : satisfaction d’atteindre un objectif fixé par des animations à intervalle court (Phase A,I)
  • Maîtrise des coûts : le projet peut être arrêté si les gains attendus ne sont pas obtenus.(Phase C)

La méthode Six Sigma s’inspire du schéma pyramidal, avec à la base des personnes disposant d’un premier niveau de qualification et au sommet les plus aguerris au système.

Il est possible de passer des certifications pour apprendre à implémenter correctement la méthode Six Sigma.  Montez les échelons de la pyramide Six Sigma. Comme au judo, les niveaux d’expertise sont représentés par des ceintures de différentes couleurs.

Les green belts (ou ceintures vertes), consacrent une proportion moindre de leur temps au projet global d’amélioration. Arrivent ensuite les black belts, qui s’y consacrent pleinement. Ils pilotent les premiers, car ils maîtrisent la méthode dans son ensemble. Et l’on peut citer encore les master black belts qui sont les garants de la méthode et qui encadrent les black belts.

Les Green et Black Belt sont des chefs de projets qui vont déployer la démarche DMAIC . Ils se distinguent par l’ampleur des projets (étendue, complexité, gains financiers), leur niveau de formation et le temps disponible pour réaliser les projets:

  • Projet Green Belt : gains intéressants, durée du projet entre 3 et 5 mois
  • Projet Black Belt : gains importants, durée du projet de 6 à 8 mois.

La maîtrise du management par projet est un pré-requis pour lancer et réaliser des chantiers lean six sigma.

Référence: