//
you're reading...
Analyses

CMMi: un aperçu d’application dans le domaine de la banque


En 2007, BNP Paribas devenait la première entreprise européenne de cette taille à être évaluée CMMi 3. Deux mille informaticiens ont été accompagnés dans cette démarche d’amélioration continue. Suite de l’article 01net.com…

OVERVIEW

Que signifie CMMi ?

CMMi, sigle de Capability Maturity Model + Integration, est un modèle de référence, un ensemble structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités des entreprises d’ingénierie.
CMMi a été développé par le Software Engineering Institute de l’université Carnegie Mellon, initialement pour appréhender et mesurer la qualité des services rendus par les fournisseurs de logiciels informatiques du Département de la Défense US (DoD). Il est maintenant largement employé par les entreprises d’ingénierie informatique, les Directeurs des systèmes informatiques et les industriels pour évaluer et améliorer leurs propres développements de produits.

Source : Wikipedia

Le site officiel CMMi ?

Pourquoi choisir CMMi ?

On choisit CMMi afin de mettre en place un cadre de travail normalisé dans l’entreprise. Cela fait en général partie d’une stratégie plus globale d’amélioration de la qualité, de l’efficacité et de la réactivité dans l’entreprise, tout ceci afin de rester compétitif. Comment ? En gérant mieux les risques inhérents aux projets, toujours plus complexes, avec souvent beaucoup de dépendances.


BNP Paribas a choisi CMMi afin d’améliorer de façon continue la satisfaction de ses clients.

Concrètement, comment cela se passe-t-il ?

A l’origine de cette initiative, la signature d’un document par le CIO qui déclare que tout projet IT doit désormais suivre la méthodologie telle qu’implémentée par BNP Paribas pour viser la conformité avec un niveau du modèle CMMi: Symphony.

Quelle est la valeur ajoutée pour l’entreprise ?

CMMi a pour objectif de fournir un langage commun et une nomenclature/terminologie partagée de tous, parmi toutes les équipes qui doivent être conforme à Symphony. La méthodologie qui est mise en place pour ce faire s’articule autour de phases successives et de jalons prédéfinis qui permet proactivité des acteurs du projet et transparence pour les parties prenantes.

Une entreprise étant composée de centaines d’internes, de consultants, chacun avec sa propre expérience et son propre langage, venant d’autres entreprises ou d’autres méthodologies (Prince 2, Agile, Waterfalls, Six Sigma, etc.), il est nécessaire de standardiser les notions de gestion de projet. Le but n’est évidemment pas d’effacer l’expérience passée, mais de construire de manière solide et standardisée un style de travail commun, partagé de tous à partir de cette expérience diversifiée. Quand quelqu’un parle de la matrice de traçabilité, tout le monde sait de quoi on parle, de quel document, et de quelles notions. Quand un project manager dit que l’on va commencer la phase « Design », tout le monde sait où ce project manager en est dans son projet.

Qui utilise CMMi ?

Alcyonix, partenaire officiel du Software Engineering Institute (SEI) depuis 1998, est le spécialiste mondial de l’amélioration des processus via CMMi®. Fondée au Canada par Richard Basque (Chef Evaluateur & Instructeur sur CMMi certifié par le SEI et également “SEI Visiting Scientist”), Alcyonix aide les entreprises et collectivités à améliorer de façon continue leurs processus de développement et de maintenance.
Alcyonix a formé plus de 2000 personnes à CMM et CMMi, aidé plus de 50 organisations (BNP-Paribas, EADS Astrium Space Transportation, PSA, Airbus, Sopra, Northrop Grumman Corp., etc.) dans leur démarche d’amélioration des processus et réalisé plus de 60 évaluations CMM et CMMi officielles sur tous les continents.

Retours d’expérience classiques :

En général, les retours d’expérience d’un projet parlent de :

« La communication entre les users et les business analysts est mauvaise, le change management est trop souvent négligé. » ou encore : « La mauvaise communication entre un project manager et un développeur entraîne du travail redondant et/ou une mauvaise estimation des charges (développement double, requirements qui se chevauchent, etc.). »

La réponse de CMMi : CMMi apporte un meilleur contrôle dans le déroulement du projet car on arrête lors de certains jalons une baseline des requirements, une baseline des coûts et une baseline des ressources.

Quels sont les autres modèles de maturité sur le marché ?

Capability Maturity Model Integration (CMMI) [CMMI Product Team, 2002]
PRINCE2 Maturity Model (P2MM) dérivé du OGC Portfolio,
Programme and Project Management Maturity Model (P3M3) [Office of Government Commerce, 2006]
Berkeley PM Process Maturity Model [Ibbs et al.1997]
PM Solutions Project Management Maturity Model [Crawford, 2001]
Project Management Maturity Model [Kerzner 2000]
Organizational Project Management Maturity Model (OPM3) [PMI, 2005]

SEI in Pittsburgh, Pennsylvania

LE MODELE CMMi

Qu’est-ce que le modèle CMMi ?

Le modèle CMMi définit une échelle de mesure de la maturité à 5 niveaux, ainsi que les indicateurs nécessaires pour évaluer les activités menées par une équipe par rapport à cette échelle – l’équipe peut être un groupe de travail, un ou plusieurs projets, une société voire une institution d’État.

Maturité vs. Capabilité ?

D’après la définition donnée dans le CMMi, la maturité d’une organisation est le degré auquel celle-ci a déployé explicitement et de façon cohérente des processus qui sont documentés, gérés, mesurés, contrôlés et continuellement améliorés.
Un niveau de maturité (Maturity Level) correspond à l’atteinte d’un niveau de capabilité uniforme pour un groupe de processus. Un niveau de capabilité (Capability Level) mesure l’atteinte des objectifs d’un processus pour le niveau donné.

Les 5 niveaux de maturité de l’approche étagée


=> sont déjà stabilisés et efficaces (principe d’empilement). Les 5 niveaux sont :

« Initial » (niveau de maturité 1) :

Il n’y a pas de grand pilier directionnel, aucune façon de faire ou standard ne sont établis (ou bien ils sont documentés mais ne sont pas utilisés), tout doit être fait. Il n’y a pas de surveillance (monitoring), aucune évaluation de performance et la communication est absente. Les faiblesses ne sont pas identifiées et les employés ne sont pas au courant de leurs responsabilités de façon définie et absolue. Les réactions aux incidents se font en mode urgence, sans identification claire des priorités. À ce niveau les solutions ainsi que les projets sont décidés, développés et instaurés par un individu. Les compétences et les ressources propres de cet individu sont la raison du succès ou de l’échec du projet (par dérision, ce niveau est aussi nommé héroïque ou chaotique). Il n’y a pas de description du niveau de maturité 1 dans le modèle.

« managed », soit discipliné en français (niveau de maturité 2) :

Une discipline est établie pour chaque projet et se matérialise essentiellement par des plans de projet (plan de développement, d’assurance qualité, de gestion de configuration …). Le chef de projet a une forte responsabilité dans le niveau 2 : il doit définir, documenter, appliquer et maintenir à jour ses plans. D’un projet à l’autre, il capitalise et améliore ses pratiques de gestion de projet et d’ingénierie.

« Defined », soit ajusté en français (niveau de maturité 3) :

Ce niveau est caractérisé par une standardisation adéquate des pratiques, une capitalisation centralisée (en particulier sur les mesures réalisées dans les projets) et une maîtrise du référentiel interne (ou Système Qualité). Il existe des lignes directrices, un plan stratégique et une planification de l’amélioration de processus pour le futur, en ligne avec les objectifs d’affaire de l’organisation. Les employés sont formés et conscients de leurs responsabilités ainsi que de leurs devoirs.

« Quantitatively managed », soit géré quantitativement en français (niveau de maturité 4) :

Les projets sont pilotés sur la base d’objectifs quantitatifs de qualité produit et processus. La capacité des activités (ou sous-processus) critiques est déterminée par l’organisation, ainsi que les modèles de performance et de prévision associés. L’expression de la qualité demandée par le client est prise en compte pour quantifier les objectifs du projet et établir des plans selon la capacité des processus de l’organisation.

« Optimizing », soit en optimisation en français (niveau de maturité 5) :

Les processus qui sont gérés quantitativement pour le pilotage de projet (niveau de maturité 4) sont en optimisation constante afin d’anticiper les évolutions prévues (besoins clients, nouvelles technologies…).

Source : Wikipedia

Cliquez sur l’image pour l’acheter sur Amazon !

EXEMPLE : Zoom sur le 2ème niveau de maturité « managed »

Dans le second niveau de maturité (« managed »), 7 domaines de processus sont couverts :
– la gestion des requirements
– le project planning
– le project monitoring & control
– mesures et analyses
– Process and Product QA (Quality Assurance)
– Configuration Management
– Supplier Agreement Management

Pour chacun de ces processus, il existe un nombre de « specific goals » pour lesquels des templates ont été créés. Il existe aussi des « generic goals » qui concernent tous les domaines de processus.

Que couvre le domaine de processus « gestion des requirements » ?

Par exemple, le domaine de processus « gestion des requirements » possède un « specific goal » SG1. qui est : « gérer les requirements ». Ce specific goal se déclinent en 5 « specific practices » :
– SP 1.1 Comprendre les requirements
– SP 1.2 Obtenir l’adhésion à ces requirements
– SP 1.3 Gérer les changements de requirements
– SP 1.4 Maintenir une traçabilité bidirectionnelle des requirements
– SP 1.5 Identifier les irrégularités entre les requirements et le travail effectué pendant le déroulement du projet

Enfin, un certain nombre de documents-types sont créés qui représentent des outils d’aide à l’atteinte de ces objectifs spécifiques ou génériques, par exemple :
– le document « User Requirement »
– la matrice de traçabilité
– le tableau de bord des changements et de leur prise en compte (development dashboard ou change log)

Que couvre le domaine de processus « planification du projet » ?

Il se décline en 3 objectifs spécifiques qui eux-mêmes se déclinent respectivement en 4, 7 et 3 « specific practices« :

SG1 Etablir des estimations
– SP 1.1 Evaluer le périmètre du projet
– SP 1.2 Estimer les livrables et les caractéristiques des tâches à réaliser
– SP 1.3 Définir le cycle de vie du projet
– SP 1.4 Estimer les charges (efforts et coûts)

Exemples de documents types :
– Project proposal
– Governance assessment
– Workload estimation

SG2 Réaliser le planning du projet
– SP 2.1 Etablir le budget et le planning
– SP 2.2 Identifier les risques du projet
– SP 2.3 Plan de gestion des données
– SP 2.4 Plan des ressources du projet
– SP 2.5 Plan des compétences et connaissances nécessaires
– SP 2.6 Plan d’implication des parties prenantes
– SP 2.7 Etablir la planification du projet

Exemples de documents types :
– Project Management Plan
– Deliverable Management Plan
– Project Schedule
– Development Dashboard

SG3 Obtenir l’adhésion au plan
– SP 3.1 Révision des plans liés au projet
– SP 3.2 Réconcilier la charge de travail avec les ressources
– SP 3.3. Obtenir l’adhésion au plan (sign-off)

Les documents types sont ceux du specific goal 2 ci-dessus.

Software Engineering Institute in Pittsburgh, Pennsylvania

AU COEUR D’UN PROJET CMMi/SYMPHONY

Une fois encore, je rappelle que la modèle de maturité n’est pas une méthodologie projet et ne propose donc aucun livrable et aucun processus décrits de manière détaillée. Un exemple d’application du modèle de maturité CMMi chez BNP Paribas a été décliné de la manière suivante :

Ils ont distingué 3 types de projets pour lesquels la méthodologie mise en place (Symphony) est appliquée de manière plus ou moins light :
– De 0.25 à 2 années-homme : application light de la méthodologie
– De 2 à 5 années-homme : application normale de la méthodologie
– Plus de 5 années-homme : application complète de la méthodologie

Rôles et responsabilités

Rôles et responsabilités de domaine

  • Le Responsable de Domaine doit gérer les activités dans le périmètre de son domaine, ce qui inclut : projets, maintenance releases, interfaces avec les comités de pilotage, etc. Il est responsable du plan annuel de domaine et reporte en général à l’Execution Manager.
  • L’Application Manager gère l’activité de maintenance de son application, ce qui inclut à la fois les maintenance releases mais aussi les emergency patch. Il reporte en général au Domain Manager.
  • Le Configuration Manager gère la bibliothèque de développement de l’application (code et documentation), construit les releases, qu’elles soient internes ou externes.
  • Le Test Manager définit la stratégie de tests, planifie les tests, gère l’exécution des tests et des UAT (User Acceptance Tests).
  • Le Supply Manager gère la relation fournisseur (sélection, contrats, audit, etc.).

Rôles et responsabilités de projet

  • Le Project Manager définit le project plan, gère les risques, les problèmes et les changements. Il suit la réalisation du projet conformément à son plan, reporte et communique sur l’avancement et l’état. Il réalise la clôture du projet.
  • Le Business Analyst élabore et gère les requirements, produit les cas de tests d’acceptation si nécessaire, conduits les tests nécessaires lors de la création de nouvelles fonctionnalités. Son rôle est très proche de celui de Project Manager.
  • Le développeur IT fournit l’estimation des charges de son travail, développe les composants nécessaires, effectue les tests unitaires requis, écrit les spécifications fonctionnelles et réalise les révisions de code.
  • Enfin, le coach CMMi assiste toute personne qui le demande dans la définition de son projet, ou dans le processus de releases, identifie et reporte les non conformités à CMMi et en suit la résolution.

Quel est la cycle de vie d’un projet dans un cadre CMMi ?

Chez BNP Paribas, le cycle de vie d’un projet CMMi a été rythmé des phases suivantes :
Proposal > Definition > Design > Construction > Transition > Operations, phases qui couvrent l’ensemble de la démarche depuis « Je pense que je vais lancer un projet » à « Le Go Live du projet a eu lieu ». Il s’agit aussi de jalons importants, telles que checkpoint, reviews, etc. Au sein de chaque phase, plusieurs activités doivent être réalisées, chacun comprenant un certain nombre de livrables et de tâches à effectuer, avec des outils prédéfinis. Tous les templates nécessaires dans le cadre de la méthodologie CMMi/Symphony sont mis à disposition de tous.

Quels sont les outils mis à disposition par CMMi ?

  • Un outil d’estimation des charges, fortement apprécié des développeurs
  • Un outil Diagramme de Gantt
  • Une gouvernance, avec définition des rôles de chacun des acteurs du projets

Les 5 phases d’un projet CMMi/Symphony

  • La phase Proposal

Cette phase ne dure pas plus de 2 à 3 semaines. Elle répond à la question : Dois-je décider de lancer un projet ?

La réponse est oui si :
– le projet est pertinent d’un point de vue business
– le projet est réalisable d’un point de vue IT
– les demandes en provenance du business sont les inputs de cette phase, et elles parviennent à l’IT sous des formats divers (tickets dans le systèmes de remontée d’incidents, documents Word détaillés, demande de nouvelle fonctionnalité ou de modification, etc.).

Pour des projets de taille significative, il peut être obligatoire de faire valider les dépenses engendrées.

Si l’approbation du projet est obtenue, on commence alors la phase de définition.

  • La phase Definition

Il s’agit ici de définir suffisamment précisément le projet afin d’obtenir les ressources nécessaires à sa réalisation.

On aura notamment besoin de :
– Spécifications fonctionnelles détaillées
– Plan de gestion des livrables
– matrice de traçabilité
– du compte-rendu du Kick-Off
– des estimations de quantité de travail, de charge, de ressources et de coûts
– d’un plan de gestion de projet
– d’un planning détaillé (Gantt)
– d’un plan de gestion de la configuration
– d’un tableau de bord du développement

Si l’approbation technique du projet est obtenue, et le budget validé, on commence alors la phase de design.

La phase Design

Il s’agit ici de définir suffisamment précisément la solution afin d’être capable de l’implémenter.

On aura notamment besoin de :
– révision technique complémentaire
– révision éventuelle du budget
– design de la stratégie de tests du système
– s’assurer que les développements et les environnements de tests sont complètement installés

Si l’approbation du design de la solution est obtenue, tant en termes techniques que de périmètre et de budget (si revu), on commence alors la phase de construction.

  • La phase Construction

Il s’agit ici de construire et tester la solution afin qu’elle soit acceptée par l’utilisateur final.

On aura notamment besoin de :
– livrer la version avec un code cohérent,
– se préparer pour la phase transition (SLA, trainings, manuel utilisateurs, etc.)

Si la validation de la solution est obtenue, on commence alors la phase de transition.

  • La phase Transition

Le système a été installé, il faut donc contrôler sa bonne implémentation et sa stabilité d’un point de vue opérationnel.

Le projet étant sur le point de se terminer, il est important d’enregistrer toute recommandation d’amélioration (lessons learned). On prendra également la décision d’effectuer une Post-Implementation Review ou non.

On aura notamment besoin de :
– livrer la version avec un code cohérent,
– se préparer pour la phase transition (SLA, trainings, manuel utilisateurs, etc.)

Si la validation de la solution est obtenue, on commence alors la phase de transition.

Campus of Carnegie Mellon University

CONCLUSION

Il est important de noter que le modèle de maturité CMMi explique quoi faire, mais n’explique pas comment. Il est du ressort de l’équipe CMMi (coach, PMO, etc.) de savoir accompagner les employés d’une entreprise dans l’approche à adopter, et dans la bonne application des concepts CMMi. Ce sont donc eux qui forment les employés d’une organisation aux méthodologies mises en place en vue de remplir les conditions d’un niveau donné du modèle CMMi, ce sont eux également qui créent les documents types dont la livraison rythme le cycle de vie d’un projet conforme à CMMi.

J’entends souvent dire « Oui, mais bon, cette méthodologie n’est pas révolutionnaire ». En effet, aucune ne l’est véritablement. Là où cela devient révolutionnaire, c’est quand la méthodologie est appliquée correctement et quand elle correspond aux besoins et aux problématiques du métier. Alors à vous de jouer !

Publicités

Discussion

Rétroliens/Pings

  1. Pingback: La Matrice de Traçabilité | Blog AurGa - 8 mars 2013

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Follow me!

%d blogueurs aiment cette page :