Home » Posts tagged 'agile'

Tag Archives: agile

Certifications et compétences qui paient en 2018

Comme chaque année, nous vous proposons un survol des certifications et compétences qui paient le mieux en 2018. Cet article s’appuie sur l’enquête annuelle réalisée par Global Knowledge sur les compétences et les salaires dans le domaine IT.

Les certifications et les compétences les mieux payées en 2018
Crédit © AdobeStock & Gwimages 2018

Notre précédent article sur les 6 certifications qui payaient le mieux en 2017 continue à être l’article plus lu de ce blog. Voici donc la version 2018 avec quelques évolutions notables. On constate un véritable glissement vers de nouvelles certifications et compétences correspondant aux meilleurs salaires. Cependant on peut constater des différences énormes selon les zones géographiques. Elles correspondent totalement à l’économie et aux besoins des entreprises dans chacune des zones. Il reste toutefois clair que les salaires sont dépendants de l’offre de compétences et de la demande régionale.

Vous courrez après les gros salaires? Cet article vous présente les certifications les mieux payées. Cependant il vous indique aussi ce que les employeurs attendent de vous et ce que cela implique. La certification ne suffit pas… C’est, pour un employeur potentiel, une assurance raisonnable quand à vos connaissances dans le cas de certifications courantes et aussi de votre compétence dans le cas des certifications professionnelles. Le recherche trois critères :

  • le savoir (sur la base de vos diplômes académiques et des vos certifications standards),
  • le savoir-faire (sur la base de vos certifications professionnelles et de votre expérience),
  • votre savoir-être sur la base de l’évaluation de votre comportement et de votre attitude (le recruteur ira chercher ces informations sur les réseaux sociaux, auprès de votre entourage professionnel et personnel).

Dans tous les cas, dites-vous que votre futur employeur vérifiera la réalité de ce que vous annoncez dans votre CV. Inutile donc de revendiquer une certification que vous n’avez pas. La vérification auprès de l’organisme émetteur de la certification révèlera immédiatement la supercherie. Cela se retournera contre vous. D’ailleurs, certains organismes de certification n’hésitent pas à porter plainte contre les fraudeurs et réclament des amendes importantes.

Certifications standards vs certifications professionnelles

Lorsqu’on parle de certification, il faut toujours bien faire attention à la signification qu’on donne aux mots. Les certifications standards sont par essence des certifications résultant de la simple réussite à un examen. C’est le cas des certifications ITIL, PRINCE2, VERISM, certaines certifications COBIT, etc. Elles se dénomment souvent Foundation, Practitioner, Intermediate ou encore Advanced. Aucune expérience dans le domaine n’est réclamée et la certification est valide sans limitation de durée.

Dans le cas des certifications professionnelles, à l’inverse, la réussite à l’examen n’est qu’une première étape. Ensuite il est nécessaire de prouver une expérience minimum de 3 à 5 ans dans le domaine concerné. L’organisme de certification effectue donc une vérification auprès des précédents employeurs de du candidat sur la valeur et la durée de son expérience ainsi que sur son attitude et son comportement. Ce n’est que lorsque cette vérification est positive que la certification est délivrée.

En général les certifications professionnelles ont une durée limitée, souvent de 3 ans. Chaque année ou chaque 3 ans, l’organisme exige la preuve que le certifié a bien suivi un nombre minimum d’heures de formation (CPD/CPE/CPU). Le certifié doit également acquitter de nouveau un montant significatif pour le renouvellement de sa certification. L’organisme de certification effectue alors, de façon aléatoire, des contrôles sur l’expérience acquise pendant les 3 ans ainsi que sur le comportement du certifié pendant cette période. A cette occasion la certification peut lui être retirée.

Parmi les certifications professionnelles, on peut citer CISA, CISM, CGEIT, CRISC, PMP, CIA, ISO 27001 Lead Implementer ou ISO 27001 Lead Auditor. Il est bien évident que les certifications professionnelles, plus « sérieuses », sont les plus recherchées par les employeurs. Ce sont donc aussi, logiquement, celles qui correspondent aux meilleurs salaires.

Les compétences les plus recherchées

Les compétences les plus recherchées sont bien naturellement celles qui paient le plus. C’est tout simplement la loi de l’offre et de la demande. Voyons ensemble les 5 domaines de compétences qui suscitent le plus de demandes en 2018. Précisons bien qu’il s’agit là de recherche de professionnels certifiés et pouvant démontrer plusieurs années d’expérience dans le domaine. Donc ce sont des domaines dans lesquels les employeurs recherchent en priorité des détenteurs de certifications professionnelles.

Notons toutefois que parmi ces 5 compétences les plus recherchées, deux certifications sont de niveau Foundation (COBIT 5 Foundation et Six Sigma Green Belt).

La cybersécurité

Comme lors des trois dernières années, les certifications en sécurité tiennent les premières places en matière de rémunération. Lorsque nous élargissons la liste aux 20 premiers, six certifications sont relatives à la sécurité an niveau mondial, y compris les deux premières places: CISSP de (ISC) 2 et CRISC de l’ISACA. Le CISM d’ISACA se classe au sixième rang mondial et au huitième rang en EMEA.

Le CISSP enregistre le salaire global moyen le plus élevé avec 70.177 € en EMEA (100.146 $ aux USA, ce qui représente une différence de plus de 27% entre les deux zones géographiques). Les professionnels de l’informatique possédant des certifications en sécurité ont tendance à avoir des salaires moyens globaux supérieurs de 15% (aux USA) à 63% (dans la région Asie-Pacifique) à la moyenne des autres certifiés.

Pour en savoir plus sur les certifications CISSP et CISM, nous vous invitons à lire notre article CISM vs CISSP : quelle certification choisir?

Le Cloud

Les certifications liées au Cloud, y compris AWS Certified Solutions Architect – Associate, ont des salaires moyens nettement supérieurs à la norme. En Amérique du Nord, le le salaire moyen du personnel informatique certifié AWS est 10% plus élevé que celui des personnels possédant une autre certification dans le Cloud et 29% supérieur au salaire moyen des professionnels IT certifiés dans un autre domaine. Toutefois, l’augmentation du salaire des professionnels certifiés en Cloud computing n’est pas limitée à ceux possédant les certifications AWS.

L’accent mis sur le nuage s’est également étendu à d’autres domaines fonctionnels. Les help-desks et les équipes de support technique recherchent activement des professionnels possédant des certifications dans le cloud computing et les réseaux.

La gestion de projet

Les gestionnaires de projets certifiés en Amérique du Nord ont également des salaires moyens au dessus de la norme. C’est particulièrement vrai pour ceux qui possèdent une certification PMP (103 406 $) par rapport à la moyenne des autres professionnels certifiés en gestion de projet, par exemple PRINCE2  (97 745 $). La tendance est beaucoup moins nette sur la région EMEA. Pour en savoir plus sur ces deux certifications, nous vous invitons à relire notre article PRINCE2 vs PMP : Quelle méthode de gestion de projet choisir?

On voit également émerger cette année une demande croissante pour les chefs de projets certifiés sur une méthode agile. Dans ce contexte c’est la certification Certified ScrumMaster (CSM) avec un salaire moyen de 98 562 $ qui tient la tête.

La gouvernance et le management

L’ISACA est une association indépendante axée sur l’adoption et l’utilisation des meilleures pratiques de gouvernance et de management de l’information et des technologies dans les organisations. L’ISACA possède six certifications dans le top 20 mondial, y compris CGEIT, CISA, CRISC et CISM . Une nette tendance se dégage également avec une demande de plus en plus forte de professionnels certifiés sur COBIT 5. Cela se traduit par un salaire moyen des professionnels certifiés COBIT 5 Foundation qui atteint maintenant 65.000 € dans la région EMEA.

Si vous vous posez des questions sur le CISA, nous vous conseillons trois articles précédemment publiés sur notre blog :

Compétences Six Sigma

La certification Six Sigma Green Belt est parrainée par l’association indépendante IASSC. C’est une certification de base sur un ensemble de techniques et d’outils d’amélioration des processus. Une tendance nette se dégage également en faveur des professionnels possédant une certification Six Sigma Green Belt qui obtiennent un salaire moyen de 99.865 $ en Amérique du Nord et de 69.000 Euros en EMEA soit une différence de 21%, la plus faible du top 20 des certifications.

Le top vingt des salaires par certification en Europe

Les résultats du classement 2018 sont extrêmement intéressants car ils montrent un changement important par rapport à 2017. La grande nouveauté est l’arrivée en force des certifications AWS (Amazon) dans les premières places du classement. A l’inverse les certifications qui monopolisaient les premières places ce dernières années subissent un fort recul (CISA, PMP). On voit également apparaître en 7ème position une certification qui fait sont entrée dans les 10 premières : COBIT 5 Foundation. Il est également à noter que cette année les certifications CISCO disparaissent complètement du classement.

Classement 2018 des 20 certifications et certifications professionnelles correspondant au meilleurs salaires en euros
Classement établi sur les salaires en région EMEA (Europe, Moyen Orient & Afrique). L’ordre est différent en Amérique du Nord.

L’autre enseignement de ce classement est la différence très importante des salaires entre la région EMEA et l’Amérique du Nord. Les salaires en EMEA sont tirés nettement vers le bas par la zone Afrique ainsi que le montre la carte suivante.

Salaires des professions IT par région du monde
Moyenne des salaires IT par région du monde – Crédit © Global Knowledge 2018

Conclusion

Ces éléments peuvent vous aider à choisir parmi les certifications disponibles celles qui vous conviennent le mieux. Bien sûr le salaire est un critère mais n’oubliez pas que la certification ne garantit pas le niveau de salaire. C’est votre compétences et votre adéquation au marché qui feront la différence.

N’hésitez pas à commenter cet article en y apportant vos témoignages sur votre expérience personnelle. Posez-nous également des questions. Nos experts se feront un plaisir de vous répondre. Si cet article vous a paru intéressant, n’hésitez pas à le partager sur les réseaux sociaux et à nous mettre un « like » si vous le souhaitez.

Les changements à l’ère de DEVOPS

ITIL propose un processus de gestion des changements destiné à ne mettre en production que des services éprouvés pour éviter les impacts négatifs sur les utilisateurs. A l’heure où les entreprises sont en recherche permanente d’agilité et où DEVOPS s’impose, l’approche ITIL semble dépassée. Mais est-elle vraiment dépassée où n’est-ce pas plutôt un échec de mise en oeuvre des meilleurs pratiques qui est en cause? Dans cet article, nous allons faire un gros plan sur ce que devrait être la gestion des changements. Et nous allons nous intéresser tout particulièrement au CAB (Comité Consultatif des Changements), mal utilisé le plus souvent.

ITIL - Le CAB à l'heure de DEVOPS
Crédit © rawpixel.com 2018

La seule raison pour laquelle la plupart des personnes et des organisations ont entendu parler du CAB (Change Advisory Board) est qu’il est décrit dans la section sur la gestion du changement des publications ITIL. La plupart des organisations ont alors considéré que si le CAB est décrit dans ITIL, c’est qu’il est obligatoire. Souvent il a donc été mis en œuvre avec enthousiasme comme mécanisme de contrôle de la qualité dans les grandes entreprises. Pour beaucoup de professionnels des opérations non informatiques, le CAB est leur seul contact avec ITIL. Il en est d’ailleurs presque devenu synonyme. Cela signifie également qu’ITIL est lui-même devenu synonyme de douleur récurrente qui revient toutes les deux semaines…

Le conte des trois erreurs

Il en va de la gestion des changements comme de beaucoup d’autres domaines de l’informatique. Il y a une différence significative entre la théorie et la pratique. Pourtant, il est exact que la théorie (dans l’ITSM) a été (partiellement) construite sur la base des pratiques du monde réel. Cependant, il s’agit en fait d’une version idéalisée d’une tentative de description globale destinée à être adaptée à chaque situation particulière. Ce n’est en aucun cas une prescription de ce qui doit être mis en oeuvre tel quel dans les organisations.

Nous allons tenter de mettre tout le monde d’accord pour commencer à travailler à améliorer la pratique de la gestion des changement. A mon sens, c’est une approche à privilégier plutôt que d’essayer de se rassurer dans des initiatives de type «dénigrement» ou «coup de tête». Elles conduisent le plus souvent à des actions de type « paniqué-coupé-renommé-collé » à partir d’une théorie mal comprise..

Il y a trois domaines principaux dans lesquels la confusion à propos du CAB (Change Advisory Board / Comité Consultatif des Changements) et des pratiques de gestion du changement en général ont entraîné des dysfonctionnements importants. Nous allons essayer de les identifier avant de les comprendre dans le détail..

Survol des trois erreurs

Tout d’abord, il y a beaucoup d’incompréhension quant à la signification de la lettre «A» dans l’acronyme «CAB». Deuxièmement, il y a également une incompréhension quant aux changements qui devraient «passer par le CAB». Troisièmement, il existe une confusion relative à la séparation des pratiques de gestion des changements et des pratiques de gestion des mises en production. Cela fait beaucoup pour un seul processus, certes majeur, parmi les 25 processus décrits dans les publications ITIL 2011.

Commençons par rappeler quelques notions issues d’ITIL, mais souvent incomprises :

  • CAB signifie «Change Advisory Board» (Comité Consultatif des Changements) et non pas «Change Approval Board» (Comité d’Autorisation des Changements).
  • Le CAB n’est pas obligatoire dans ITIL, pas plus que l’envoi de toutes les demandes de changement (RFC) au CAB.
  • A chaque fois que les auditeurs exigent des décisions du CAB, ils confondent la fin et les moyens.
  • Lorsque les managers exigent des décisions du CAB, alors c’est qu’il existe probablement un problème de confiance.
  • L’automatisation (pour les modifications logicielles) rend même les auditeurs plus heureux.
  • Le logiciel circulant dans le pipeline CI / CD (intégration continue / livraison continue) n’est pas destiné à passer par le CAB.
  • L’amélioration des pratiques de gestion du changement requiert la réduction du nombre d’intermédiaires intervenant dans le processus pour améliorer son efficacité.

1 – « A » pour « Advisory » (conseiller)

Comme son nom l’indique, le CAB (Comité Consultatif sur les Changements) a pour objectif de conseiller sur l’évaluation des changements. Il est utile principalement lorsqu’il s’agit de changements à haut risque ou de changements à grande échelle qui vont au-delà du champ de perception d’une équipe particulière. Dans ce cas de figure, ils nécessitent la coordination et la gestion de situations complexes. Il faut alors faire face à des priorités conflictuelles et faire des choix en raison de coûts ou de délais. Le rôle du CAB, dans de telles situations, est essentiel car il permet de recueillir les avis de toutes les parties prenantes.

Pour diverses raisons, le mot «Advisory» (Consultatif) est devenu «Approval» (Approbateur) dans de nombreuses entreprises. Le CAB s’est alors transformé en un mécanisme de création de retard sans valeur ajoutée. Il est censé être là pour des raisons de qualité, mais il atteint rarement son objectif. La différence entre les mots est loin d’être seulement une question pédante de sémantique :

  • Advisory: avoir ou exercer le pouvoir de conseiller
  • Approval: acte ou instance d’approbation de quelque chose

Un mode de fonctionnement inefficace qu’il faut absolument améliorer

De plus, les CAB, dans les entreprises, ont souvent tendance à être statiques. C’est toujours même groupe de managers qui discute de tous les changements qui leur sont apportés, quels que soient l’équipe / l’application / le service concerné. Ils invitent parfois les auteurs de RFC (Request For Change / Demande de Changement) ternes et volumineuses à y ajouter un peu de couleur. Cette approche introduit un niveau d’intermédiation qui perd beaucoup de détails.  Par conséquent le risque est grand de créer un type de pratique, fonctionnel techniquement mais défaillant dans la pratique. L’absence d’avis est une chose, mais l’échec en matière d’approbation en est une toute autre.

La pratique consistant à utiliser des RFC dans l’entreprise semble davantage venir d’un livre de recettes que de l’ITSM. La dynamique de la mise en œuvre repose alors sur un examen minutieux afin de s’assurer que tous les champs du formulaire sont remplis. Elle ne repose pas sur des conseils pertinents. En effet, souvent, les RFC contiennent des informations destinées au CAB. Elles ne contiennent pas les questions et les réponses de / à la personne ou l’équipe recherchant un avis.

Cela ne veut pas dire que des contrôles de qualité ne doivent pas être mis en place. Cependant un mécanisme intervenant tardivement dans le jeu, de type Potemkin, est plus susceptible de gêner que d’aider l’entreprise à atteindre ses objectifs. La réduction du nombre d’erreurs est alors obtenue en évitant les changements plutôt qu’en améliorant la résilience du système. En effet, la dynamique est tellement lourde, coûteuse et chronophage que les « petits » changements seront rejetés. Ceci peut souvent conduire, en retour, à un besoin de changements de grande ampleur. C’est notamment le cas  lorsque le système a dépassé sa date de péremption et échoue sur plusieurs fronts simultanément.

Pour améliorer les pratiques dans ce domaine, une réduction réfléchie et consciente des intermédiaires est nécessaire. Ainsi l’évaluation de l’impact et la prise de décision seront rapprochées du lieu où le travail est réalisé. L’efficacité, les coûts et les délais n’en seront qu’améliorés.

2 – Pratiques obsolètes et manque de confiance

Comme nous venons de le voir, le CAB peut être un élément utile de la gestion des changements pour certains types de changements. Il sera beaucoup moins utile pour d’autres. Notez bien que je dis «peut être», ce qui signifie que le CAB est facultatif et en aucun cas obligatoire. Il ne devrait être introduit que s’il est vraiment utile. Sa conception, sa portée, son rôle et sa valeur doivent être réexaminés de manière continue.

Parmi les autres raisons, il y en a deux concernant le «CAB abusif» que je voudrais évoquer ici. La première concerne les pratiques d’audit. Il s’agit de l’exigence de documenter et d’approuver chaque changement. Il est alors tentant de considérer le CAB comme la seule / meilleure méthode pour y parvenir. La première partie de cette exigence est plutôt raisonnable. Pourquoi ne voudrions-nous pas garder la trace des changements? La deuxième partie, par contre, est un exemple de prédominance du « comment » sur le « pourquoi ». Cette exigence est souvent tellement enracinée qu’elle ressemble à une loi intangible. Elle élimine alors d’autres méthodes de travail qui permettraient d’atteindre le même résultat, mais avec un fonctionnement différent.

Les pratiques obsolètes pour satisfaire les auditeurs

Demander au CAB de signer chaque demande de changement a peut-être été le seul moyen pour l’organisation de répondre aux exigences de la vérification par le passé. Ce n’était certainement pas une préconisation figurant dans les directives ITIL. Il suffit de voir, par exemple, l’autorité de changement et la notion de changement standard. Cela a, très probablement, satisfait les objectifs de la gestion des risques, sur papier uniquement. Et finalement cela a été considéré comme suffisant.

Du matériel coûteux, des temps d’approvisionnement longs et des temps de planification encore plus longs ont rendu les approches, idéales d’un point de vue théorique, plutôt populaires. Cependant, le monde a changé.  La plupart des entreprises disposent maintenant d’un soutien suffisant pour investir dans les méthodes et les pratiques informatiques modernes. Il n’est donc plus nécessaire de continuer à jouer ainsi sur le registre de la gestion des risques.

Evitons donc de compter sur des revues de qualité souvent gérées par des personnes ignorantes du contexte. Nous pouvons plutôt utiliser des pratiques d’automatisation, dans lesquelles la documentation détaillée de chaque changement est fournie par défaut. Outre l’amélioration de la qualité du service, nous disposerons alors d’une grande quantité d’informations, plus fiables. Et nous pourrons fournir ces informations aux auditeurs qui seront satisfaits.

L’option d’automatisation s’applique principalement, à priori, aux changements logiciels. Or, dans le contexte du cloud, ceux-ci incluent des éléments de gestion d’infrastructure (« infrastructure as a code »). Mais ensuite, dans quelle mesure est-il raisonnable de prendre en compte les changements logiciels individuels dans le cadre de la gestion «traditionnelle» des changements?

Le manque de confiance dans les équipes

La deuxième raison pour laquelle les CAB sont si populaires et pourtant mal utilisés est la méfiance. Derrière cela se cache aussi la nécessité de sauver ses fesses au cas où quelque chose se passerait mal. Le CAB devient alors un mécanisme pour imposer un contrôle sur des équipes de spécialistes. En effet, sinon, comment savoir si elles travaillent exactement comme on le souhaite?

Dans ce scénario, plutôt que d’utiliser le concept d’autorité de changement et de laisser les équipes les plus proches du travail prendre des décisions, toutes ces décisions sont transférées au niveau du CAB. C’est là que les responsables du responsable du responsable de l’équipe discutent et décident des changements acceptables. Même si le pouvoir décisionnel revient au CAB, c’est toujours le demandeur du changement qui est tenu pour responsable. C’est-à-dire que, si quelque chose se passe mal, le CAB pourra prétendre avoir demandé des informations complètes et justes. Alors, la raison pour laquelle des résultats inattendus sont obtenus sera qu’il disposait d’informations erronées ou incomplètes. Et, on vous expliquera que dès qu’on identifiera qui est l’individu responsable du fiasco, on s’assurera que cela ne puisse plus se reproduire…

3 – La bataille du RAP

La troisième incompréhension porte sur la confusion entre les changements et les mises en production. Mais elle renvoie également au défi que pose la portée du CAB. La gestion du changement détermine si quelque chose doit être changé et quand. La gestion des mises en production vérifie si le package de modifications, quel que soit son contenu, est prêt à être mis en production et à quel moment. Par souci de simplicité, examinons la gestion des mises en production dans le cadre de la gestion des changements…

La manière dont le CAB a été conçu dans de nombreuses organisations pour les changements liés aux logiciels est en réalité un processus d’approbation de mise en production (RAP : Release Approval Process). D’ailleurs ce processus est assez amusant. Plutôt que d’évaluer l’état de préparation à la mise en production et au déploiement (ce qui est à nouveau une tâche à effectuer, de préférence de manière automatisée avec beaucoup de retours), le RAP/CAB évalue la viabilité du changement lorsque le travail sur ce changement a déjà commencé, ou même le plus souvent, a déjà été achevé. C’est évidemment bien trop tard!

Les processus de prise de décision pour les changements (si une modification logicielle est nécessaire) et pour les mises en production (comment valider au mieux la modification) sont déconnectés et mal alignés. Dans ces organisations, la pratique de gestion du changement – bien que généralement non dénommée ainsi – s’appuie sur« le métier», et« l’informatique » et permet de prendre les commandes une fois la décision prise, de livrer ce qui était prévu (mais rarement décrit correctement), et d’assurer qu’aucune perturbation ne surviendra sur aucun service.

Il y a trop de dysfonctionnements dans ce scénario pour pouvoir les détailler et les intégrer dans cet article. Aussi, ce que je voudrais faire, c’est proposer un point de vue différent pour examiner les changements logiciels. Cela permettra peut-être de supprimer en partie la tension entre la communauté ITSM et la communauté DevOps.

Etendre le mandat

Examinons le développement logiciel agile avec intégration continue (CI: Continuous Integration) et livraison continue (CD: Continuous Delivery). En principe, nous pouvons supposer que le code injecté dans le pipeline CI / CD a été pré-approuvé. C’est-à-dire que le développeur a le mandat de travailler dessus. Il nécessite seulement de passer les contrôles de qualité (automatisés) avant d’atteindre l’environnement de production.

Cette approbation préalable ne signifie pas que quiconque a demandé que le travail de développement soit effectué soit sûr à 100% que ces changements spécifiques produiront les résultats escomptés. Pas plus que le développeur n’est totalement convaincu que le code passera les revues qualité sans problèmes. Le temps de retour pour le développeur se compte en minutes / heures. Il se compte pour le client en heures / jours / semaines, en fonction de la conception du pipeline et de la méthodologie de développement utilisée. Le délai de retour est donc extrêmement long et ne correspond pas aux besoins des métiers.

Si le client a déjà décidé qu’il souhaite le changement, cette décision doit en réalité être une décision du CAB. Mais ce n’est pas le CAB tel qu’il est mis en oeuvre habituellement. Ainsi, plutôt que d’essayer même d’évaluer manuellement chaque version logicielle en cours de traitement dans un CAB (ou RAP), les équipes chargées de la gestion des changements et des mises en production doivent alors travailler ensemble pour concevoir et améliorer le pipeline CI / CD. et des revues qualité automatisées.

Est-il raisonnable de démanteler le CAB?

Quelle que soit la conception de votre CAB actuel ou futur, la question clé à garder à l’esprit est la suivante: aide-t-il à obtenir les résultats attendus des métiers?

Une Gestion des Changements efficace ne peut pas être limitée à un portique de sécurité pour l’accès au service informatique. Cela signifie que la gestion du changement n’est pas basée uniquement sur le CAB. Le CAB n’est pas le processus de gestion des changements. C’est juste un mécanisme qui peut être utile au sein du processus. Il reste probablement beaucoup d’autres choses nécessitant une amélioration dans votre gestion du changement.

S’agissant de votre CAB, s’il s’agit d’un groupe de personnes qui ne connaissent pas les détails des changements / mises en production dont ils discutent mais qui prennent cependant des décisions en évitant de répondre de ces décisions, alors c’est clairement un CAB à éliminer d’urgence.  En effet, ce n’est pas du tout le CAB, préconisé par les bonnes pratiques, dont votre entreprise a besoin..

Mais si c’est un groupe de personnes qui peuvent conseiller sur les changements planifiés, aider à la coordination et à la hiérarchisation, et qui sont là pour aider l’organisation plutôt que leur carrière personnelle, alors conservez-le. Mais améliorez-le de façon continue également.

Vous souhaitez évaluer la viabilité des changements? Alors, vous devez le faire en vous appuyant sur des personnes qui comprennent ces changements. C’est la viabilité des Mises en Production que souhaitez évaluer? Alors, cette tâche devrait être effectuée par des personnes qui comprennent ces Mises en Production.

Pour améliorer la qualité, n’oubliez jamais que vous devez réduire les intermédiaires et automatiser autant que faire se peut.

 

Crédits : cet article est inspiré d’une publication de Kaimar Karu

VeriSM: le nouvel ITIL de l’ère digitale?

En proposant une approche nouvelle de la gestion des services, le modèle VeriSM pourrait bien être l’évolution digitale du référentiel ITIL à l’ère du numérique.

VeriSM est-il le nouvel ITIL de l'ère digitale?
Crédit © VeriSM Global

ITIL, le référentiel phare d’AXELOS, commence à sérieusement prendre de l’âge et à perdre de son avance. VeriSM, plus adapté aux contraintes de l’entreprise du futur, pourrait bien être un challenger sérieux dans les prochains mois pour ITIL. AXELOS est bien conscient de la nécessité de faire évoluer son cadre de bonnes pratiques. La Société Britannique a d’ailleurs lancé récemment une initiative qui devrait aboutir Q1/2019 au lancement de ITIL 4. Il n’en reste pas moins que de sérieux concurrents commencent à voir le jour. VeriSM a été conçu dès l’origine pour répondre aux attentes des Entreprises de l’ère digitale. Ce nouveau cadre de bonnes pratiques semble être, assez logiquement, aujourd’hui, en bonne position pour prendre l’avantage.

VeriSM, qu’est-ce que c’est?

VeriSM (de l’anglais Value-driven Evolving Responsive Integrated Service Management) a été développé en 2017 par l’IFDC. Il s’agit d’une gestion des services intégrée, réactive, évolutive et centrée sur la création de valeur.

Cette approche vise à mettre en place des pratiques nouvelles de gestion des services, au niveau de l’ensemble de l’organisation. On ne se focalise plus sur le seul département informatique. Ces nouvelles pratiques sont plus flexibles. Elles sont également plus centrées sur la création de valeur et l’accélération du « Time-to-Market » de produits ou services nouveaux.

ITIL ne suffit pas?

En 2007, le référentiel ITIL a été revu en intégralité dans une version ITIL V3 plus cohérente et ambitieuse, autour de 5 ouvrages. Chacun de ces ouvrages recense les meilleures pratiques pour la gestion des services informatiques (IT Service Management ou ITSM) en suivant les 5 phases du cycle de vie des services. En 2011, le Cabinet Office, alors en charge du portefeuille des bonnes pratiques de l’état Britannique publie une refonte « cosmétique » d’ITIL dénommée ITIL 2011. Malheureusement, ITIL 2011 n’apporte pas de grand changement aux bonnes pratiques d’ITIL V3. ITIL reste ITIL. C’est d’ailleurs le sens de l’appellation ITIL 2011 qui n’est en aucun cas une nouvelle version du référentiel. Il est cependant évident que depuis la parution d’ITIL V3 en 2007 le contexte des Entreprise a largement évolué. La mondialisation des affaires nécessite toujours plus d’agilité des Entreprises pour qu’elles puissent survivre.

Pourquoi un échec relatif d’ITIL à créer de la valeur business?

Dans le même temps, les mises en oeuvre des bonnes pratiques basées sur ITIL ont largement échoué à produire les résultats attendus. La faute n’est pas à ITIL. La faute est à attribuer pour une large part à des consultants incompétents lorsqu’on parle de mise en oeuvre. Les implémentations réalisées ont essentiellement contribué à « rigidifier » les entreprises pour tirer un maximum de bénéfices au niveau de l’informatique. Hélas ces avantages ont été ciblés au détriment de l’agilité du business.

La faute est également à porter à l’étendue du cadre de bonnes pratiques d’AXELOS. Il ne se focalise malheureusement que sur les aspects informatiques. Une entreprise ne devrais utiliser l’informatique que comme un « outil » au service du business. Or les mises en oeuvre de processus basés sur ITIL sont réalisées pour la plupart pour les DSI. De plus, elles se déroulent bien souvent sans la participation du Business. Or c’est bien le business qui crée de la valeur et en aucun cas l’informatique. L’informatique est et doit rester un outil au service du business.

AXELOS s’en est d’ailleurs est bien rendu compte et a publié « ITIL Practitioner » accompagné d’une nouvelle certification. Cette publication, mal positionnée et surtout mal ciblée a été un échec. La plupart des consultants « experts » ont échoué à obtenir la certification ITIL Practitioner.

Qu’apporte VeriSM en plus d’ITIL?

L’évolution du modèle d’affaire des Entreprises entraîne un besoin d’évolution des pratiques. Et c’est cette évolution des pratiques qui explique le besoin des professionnels de l’informatique de disposer d’un nouveau référentiel intégrant les nouveaux enjeux de la DSI et des métiers (et plus seulement ceux de la production) : « time-to-market », « user experience / customer experience (UX/CX) », agile-DevOps, nouvelles pratiques du support, intégration du cloud sous toutes ses formes dans la fourniture des services, positionnement de la production en tant qu’agrégateur de services, etc. Autant d’enjeux déjà embarqués dans le modèle VeriSM. VeriSM pourrait donc bien être une alternative au référentiel ITIL 4 dont la sortie est prévue en 2019. Ce d’autant que le contenu t’ITIL 4 reste encore largement inconnu.

Comment est conçu VeriSM?

Le modèle VeriSM, récemment traduit en français, est décrit dans plusieurs ouvrages, dont un « pocket guide » disponible sur le site de Van Haren Publishing proposant une approche de la gestion des services d’un point de vue organisationnel.

La première publication, structurée en quatre parties, parait finalement assez générique :

  • La première partie, plutôt exploratoire du service management, interroge sur le bien-fondé d’une culture « service », sa structuration et ce qu’elle implique, notamment en matière de gestion des compétences.
  • La seconde partie, plus descriptive, est au cœur de l’ouvrage. A première vue, elle parait très conceptuelle et est pourtant enrichie d’exemples explicites.
  • La troisième partie propose un rappel des concepts, technologies et pratiques liés à l’agilité, à la culture DevOps, au Lean management, au cloud, au big data, à l’IoT, au shift left, à la CX et UX (Consumer et User eXperience), au continuous delivery, à la méthode Kanban, à la Théorie des contraintes ou encore à l’amélioration continue.
  • Enfin, la quatrième partie propose des annexes illustrant par exemple les notions d’asset management, de « security by design » ou encore la structure générique d’une « policy ».

Le modèle VeriSM repose également sur un découpage intéressant – façon SIAM (Service Integration And Management) – et décrivant les activités clés d’un intégrateur de services. VeriSM propose d’aider les métiers à se digitaliser en ne se contentant plus de fournir des services en mode infrastructure. Il faut désormais créer de la valeur, identifier et explorer des technologies de pointe. Cela nécessite des compétences nouvelles dans un écosystème qui se diversifie chaque jour un peu plus.

Le modèle VeriSM
Le modèle VeriSM © IFDC Global

Alors pourquoi adopter VeriSM?

Toute l’originalité de VeriSM réside dans le cœur même de son modèle, le « Management Maillé » sur lequel s’appuient quatre groupes d’activités autour du cycle de vie d’un service : définir, produire, fournir et supporter.

Ce modèle favorise une approche flexible permettant de s’adapter aux besoins d’un produit ou d’un service spécifique.

VeriSM - Le management maillé
Crédit © Van Haren Publishing

L’idée centrale du modèle est de construire un modèle d’opération couvrant ces 4 groupes d’activités en s’appuyant et en mixant intelligemment l’utilisation de pratiques et de facilitateurs issus des 4 pôles du « management maillé » :

  • L’environnements : les éléments « stabilisateurs » (processus, métriques, outillages), les concurrents, la culture, les contraintes légales, etc.
  • Les ressources : équipes, budgets, actifs, connaissance, temps, etc.
  • Les pratiques de management : ITIL / COBIT / CMMI / IT4IT, ISO/CEI 20000, ISO/CEI 27000, DevOps, agilité, lean management, PPM, SIAM, etc.
  • Les technologies émergentes : cloud, containers, IoT, big data, automation, dont certaines ne sont plus forcément émergentes mais désormais intégrées dans la fourniture de services.

Pour chaque produit, ces domaines sont pris en considération et interagissent.

Même si, aujourd’hui, la description du cœur même du référentiel n’est pas encore très détaillée et peut-être un peu trop « stratosphérique », la prochaine version dont la sortie est planifiée pour fin 2018 devrait tenir ses promesses et offrir de nouveaux horizons à la gestion des services. Tous les espoirs sont désormais  permis. Ce modèle est pensé et structuré pour répondre aux nouveaux enjeux de la transformation digitale des entreprises. Il pourrait donc devenir le nouveau référentiel de pratiques pour le management des services.

 

Combiner PRINCE2 et PMP pour des projets réussis

PRINCE2 et PMP présentent des perspectives très différentes en matière gestion de projet. Cependant la combinaison des deux fournit un outil puissant pour les organisations garantissant la réussite des projets. Dans cet article, nous décrivons les différences et les similitudes entre les deux approches de gestion de projet les plus reconnues au niveau mondial. Nous discuterons également des avantages à tirer de l’utilisation combinée de ces deux approches complémentaires pour la gestion de vos projets.

Combiner PRINCE2 et PMP

PMP versus PRINCE2

Le guide PMBOK® (Project Management Book of Knowledge) et PRINCE2® (Project IN Controlled Environment) abordent la gestion de projets sous des perspectives très différentes.

PMBOK se positionne du point de vue du Chef de Projet. Il lui fournit tout ce que qu’il doit connaître et comprendre dans son rôle de Gestionnaire du Projet.

PRINCE2, à l’inverse, adopte le point de vue organisationnel et vise à atteindre les objectifs de l’Organisation, en définissant les rôles et les responsabilités des différentes parties prenantes dans le processus d’exécution d’un projet.

PRINCE2 est donc une méthode générique de Gestion de Projet qui couvre l’ensemble des rôles et responsabilités impliqués dans la Direction et le Management du Projet. PRINCE2 s’appuie sur 7 principes soutenus par 7 thèmes et 7 processus. PMBOK, à l’inverse, est un cadre de bonnes pratiques à appliquer par le Chef de Projet lui-même. La combinaison des deux fournit donc un outil puissant pour les Organisations, leur permettant de réussir leurs projets de bout en bout.

Les Organisations me demandent souvent s’il serait préférable pour elles d’utiliser PMBOK ou PRINCE2 et quelle approche serait la meilleure dans leur cas. Je leur réponds généralement qu’elles me posent la mauvaise question et que je ne peux pas y répondre.

En effet, PMBOK et PRINCE2 ont des objectifs très différents. En fonction des problèmes auxquels l’Organisation doit faire face, ils peuvent travailler efficacement ensemble ou en tandem avec d’autres approches de gestion de projet, telles que Agile ou des approches basées sur des normes (ISO 21500 par exemple), ou encore séparément.

Un gestionnaire de projet PRINCE2 a besoin d’un ensemble de connaissances à utiliser afin d’être compétent et PMBOK répond à cette attente. D’un autre côté, le Guide PMBOK nécessite une méthode que l’équipe de gestion de projet puisse adopter, et cette méthode peut être PRINCE2.

Les différences clés entre les deux approches

PMBOK, s’appuie sur un patrimoine de connaissances remontant à 1987. Il fournit une base de connaissances destinée au gestionnaire de projet. PRINCE2, pour sa part, s’appuie sur une première version (PRINCE) publiée en 1990 mettant spécifiquement l’accent sur les projets  IT. C’est en 1996 qu’a été publiée la version 2 (PRINCE2), laquelle a été mise à jour de façon importante en 2009. PRINCE2 fournit des processus de bout en bout pour gérer tout type de projet au sein d’une organisation. 

PMBOK est un guide maintenu par le PMI® (Project Management Institute). Les qualifications associées portent le nom de PMP®. Il fournit des conseils sur tout ce qu’un chef de projet devrait faire, ainsi que certains outils et techniques spécifiques pour le faire. PMBOK ne comprend pas de rôles et de responsabilités définis, ni la description des produits ni l’ordre des activités dans les processus. Il se limite exclusivement au rôle du Chef de Projet.

A l’inverse, PRINCE2 est une méthode claire avec des rôles, des responsabilités, des principes et des processus, permettant de gérer un projet de bout en bout grâce à une équipe complète. Dans certains pays, voire dans certaines Organisations internationales, il est obligatoire pour un gestionnaire de projets d’être certifié PRINCE2. La certification PRINCE2 garantit que la personne possède la connaissance de la méthode (certification Foundation) et qu’elle sait l’appliquer (certification Practitioner). 

Qu’est-ce qui caractérise PRINCE2?

Prince2-manualPRINCE2 met fortement l’accent sur l’avant-projet et la phase de démarrage du projet. Il se focalise sur les produits du projet, et cherche à s’assurer qu’il y a une justification business qui demeure valide tout au long du projet. Si la justification disparaît, à tout moment, le projet prendra fin. D’autre part, bien que les phases PMBOK comportent des aspects de surveillance et de contrôle, l’accent est moins mis sur la justification initiale pour l’entreprise.

Lors de la planification, PRINCE2 adopte l’approche par décomposition du produit, tandis que PMBOK adopte une approche par répartition des activités. D’un côté, on s’assure que tous les produits nécessaires sont prévus et de l’autre, on s’assure que tout le travail nécessaire est planifié.

Qu’est-ce qui caractérise PMBOK?

PMBOK-manualLe PMBOK est un guide de bonnes pratiques plutôt qu’une méthodologie. Il est donc possible d’utiliser différentes méthodologies et outils en conjonction avec PMBOK. PMBOK est très large et couvre beaucoup plus de domaines de connaissance de gestion de projet que PRINCE2. PRINCE2 fournit un ensemble de principes de base, les divise en thèmes qui expliquent pourquoi il est important de faire les choses et comment vous allez les faire, puis définit des liens vers les processus. Mais il ne va pas dans le détail de tous les outils et des techniques qu’un gestionnaire de projet doit utiliser. PRINCE2 est plus réduit en termes de périmètre (seulement 7 processus), mais plus profond sur chacun des aspects. PMBOK, au contraire, couvre 47 processus, chacun ayant des intrants, des outils, des techniques et des extrants. Ces processus sont divisés en dix domaines: l’intégration, la portée, le temps, le coût, la qualité, les ressources humaines, les risques, la communication, l’approvisionnement et les parties prenantes.

Différences clés entre les deux approches

PRINCE2 et PMP ont des différences importantes de terminologie et il est utile d’en avoir une vue d’ensemble. Par exemple, les termes «assurance qualité» et «contrôle qualité» ont des définitions très différentes dans chacune des approches, même si PMBOK et PRINCE2 considèrent tous deux que l’examen des résultats, tels que les produits livrables, à l’intérieur du projet fait toujours partie du contrôle qualité, et l’examen des processus par quelqu’un externe au projet est toujours du ressort de l’assurance qualité.

Prince2-Pmbok-vocabulaire
Différences entre les deux approches au niveau de la Qualité

 Dans le PMBOK on s’appuie sur des «Commanditaires de projet» tandis que PRINCE2 a un «Exécutif». Le PMBOK parle de «Phases» tandis que PRINCE2 définit les «Séquences de Management». Le Projet est basé sur un «Enoncé du Contenu du Projet» dans PMBOK, tandis que PRINCE2 s’appuie sur la «Description de Produit du Projet» correspondant à son principe de focalisation sur le produit.

Prince2-Pmbok-vocabulaire-2
Quelques exemples de différences dans le vocabulaire

En raison de son origine dans le domaine public, PRINCE2 ne gère pas les achats alors que le PMBOK le fait. PRINCE2 considère que lorsque des connaissances spécialisées telles que la connaissance d’approvisionnement sont nécessaires, cela ne relève pas du domaine du gestionnaire de projet. La compétence du gestionnaire de projet sera seulement d’aller chercher un soutien spécialisé auprès d’autres ministères, comme dans le cas de  l’approvisionnement, lorsque cela s’avèrera nécessaire. PRINCE2 dit qui doit être impliqué, quand ils doivent être impliqués, ce qu’ils doivent faire et pourquoi ils doivent le faire. Il suppose que le chef de projet possède les compétences nécessaires pour gérer le projet. PMBOK, au contraire, se concentre sur ces compétences et fournit la compréhension et les connaissances nécessaires pour les soutenir.

PRINCE2 et PMP : la synergie gagnante

Bien que PMBOK et PRINCE2 abordent la gestion de projets à partir de deux perspectives différentes, ils s’intègrent et se complètent parfaitement. Ce sont les deux approches de gestion de projet les mieux reconnues au niveau mondial et la combinaison des deux couvre intégralement le périmètre de toute Organisation.

Les Entreprises multinationales en cours de fusion et d’acquisition peuvent largement bénéficier d’une combinaison de PMBOK et de PRINCE2. Dans la pratique, les grandes Organisations ont souvent une expérience et une pratique fragmentaires, à la fois du PMBOK et de PRINCE2. En combinant les deux et en créant une approche intégrée pour développer des processus communs et cohérents, elles garantiront le succès de leurs futurs projets.

Comment gérer l’agilité avec les deux approches

À mesure que les Organisations envisagent d’utiliser PMBOK® et PRINCE2®, beaucoup évaluent également comment ces méthodologies / cadres s’intègrent à l’approche Agile de plus en plus populaire dans le monde de l’Entreprise. En juin 2015, AXELOS, propriétaire de PRINCE2®, a publié PRINCE2 Agile™ afin d’offrir aux Organisations le meilleur des deux mondes. En fait, beaucoup de techniques dites « Agile » s’accordent très bien avec PRINCE2 car il n’a jamais été stipulé qu’il n’y a qu’une seule façon de livrer un produit.

Agile est d’abord apparu comme une approche spécifique au développement de logiciels, mais les organisations utilisent également le terme Agile pour signifier qu’elles recherchent l’agilité et la capacité de changer l’environnement de chaque projet. En effet, de nombreuses organisations ont utilisé des techniques Agiles avant que le manifeste Agile ne les formalise. Par exemple, de nombreuses organisations utilisaient des prototypes et des tests rapides comme moyen de développer des produits dans les années 80 et 90, avant même que le manifeste Agile ne soit publié.

Les organisations qui doivent considérer l’intégration de PRINCE2 avec Agile (ou PRINCE2 Agile) peuvent faire face au défi d’inclure PMBOK dans leur périmètre qui peut aussi leur être très utile. Agile est une approche de livraison de produits. Donc, en tant que tel, c’est un plug-in spécialisé pour la «Gestion de la Livraison des Produits» de PRINCE2, de la même manière que les approches spécialisées utilisées dans d’autres segments de l’industrie peuvent également intégrer leur approche de développement de produit spécifique. PRINCE2 ne spécifie pas l’approche de livraison du produit car il traite des besoins génériques de la gestion du projet plutôt que des exigences spécifiques de chaque domaine spécialiste. A contrario, PMBOK fournit une base de connaissances utilisable par les deux approches.

Vous souhaitez en savoir plus? N’hésitez pas à nous adresser vos commentaires et vos questions. Un de nos experts en gestion de projets vous répondra.

Etes-vous plutôt agile ou classique?

AGILE ou traditionnelle, quelle approche choisir?

L’approche agile vous semble peut-être nouvelle ou au contraire, peut-être êtes vous un ou une adepte des méthodes agiles? Quoi qu’il en soit, il est important de partir sur de bonnes bases. Déjà quand nous parlons d’agile à quoi faisons-nous référence? Ce blog étant spécialisé dans la gouvernance, le management et la sécurité, vous comprenez bien sûr que nous faisons référence à l’agilité dans la gestion de projets. Avant de démarrer il faut comprendre que le terme « Méthode » est trop limitatif pour aborder ce mode de gestion de projet. Le terme approprié serait plutôt « Approche Agile » car il s’agit plus d’une philosophie que d’une méthodologie.

Approche agile

Cette approche, donc, est devenue au cours de ces dernières années, très populaire dans les entreprises. Elle est conçue de sorte à apporter de nombreux avantages mais requiert une discipline stricte pour produire la valeur promise. Chaque étape est importante et indispensable. Nous allons vous montrer, au travers de cet article, les avantages de cette approche déjà très populaire. Il vous appartient ensuite de décider si elle est pertinente pour vous.

Agile, de quoi s’agit-il?

Né aux Etats-Unis, le mouvement agile est apparu en 2001, lorsque 17 experts se sont alliés pour mettre au point une nouvelle façon de développer des logiciels, visant à réduire le taux d’échec important des projets informatiques. C’est d’ailleurs à cette occasion que le terme Agile est apparu pour  qualifier cette nouvelle approche. Ce rassemblement a donné naissance à un manifeste définissant quatre axes de valorisation pour les projets :

  • Les individus et leurs interactions avant les processus et les outils
  • Des fonctionnalités opérationnelles avant la documentation
  • Collaboration avec le client plutôt que contractualisation des relations
  • Acceptation du changement plutôt que conformité aux plans

L’approche agile est une approche de gestion de projet défiant les approches classiques. La notion même de « Gestion de projet » est remplacée au profit de « Gestion de produit » de façon à mieux se focaliser sur le produit plutôt que sur le projet. L’objectif de tout projet est de livrer un produit. Dans une approche dite « classique », on attend généralement du client une expression détaillée et validée du besoin. Cette expression de besoin validée en début de réalisation laisse peu place au changement. La réalisation prend le temps qu’il faut et rendez-vous est repris avec le client pour la recette. Cet effet tunnel peut être mauvais et très conflictuel.

On remarque fréquemment un déphasage entre le besoin initial et l’application réalisée. On se rapporte alors aux spécifications validées et au contrat. La majorité des projets se terminent très mal au risque d’affecter la relation avec le client. De plus, il peut arriver que certaines fonctionnalités demandées soient inutiles à l’usage. D’autres, découvertes en cours de route, auraient pu donner plus de valeur au produit.

En quoi consiste réellement l’approche agile?

En 1994, une enquête réalisée par le «  Standish Group » a démontré que 31% des projets informatiques sont stoppé en cours d’exécution, 52% n’aboutisse pas et ne respectent pas les délais et le budget imposés proposant souvent moins de fonctionnalités qui étaient prévus. Et pour finir, seuls 16% des projets sont synonyme de réussite. La même enquête de nouveau menée en 2008 indique un taux de réussite de 35%. Cela représente une nette progression mais reste insuffisant.

Parmi les principales causes d’échec relevées on peut citer :

  • Manque d’implication des utilisateurs finaux : 12,8 %.
  • Changements de spécifications en cours de projet : 11,8 %.

L’approche Agile propose de réduire complètement les conséquences de cet effet tunnel en donnant davantage de visibilité, en impliquant le client du début à la fin du projet et en adoptant un processus itératif et incrémental. Elle considère que le besoin ne peut être figé et propose au contraire de s’adapter aux changements de ce dernier. Mais cela ne peut pas se faire sans un minimum de règles.

Comment est-ce que cela fonctionne?

Le principe de base des méthodes « Classiques » est qu’il peut être contre-productif. C’est-à-dire qu’avant de développer un produit, il faut le planifier et en spécifier les moindres détails. En effet, prévoir tous les aspects de la production entraîne dans la plupart des cas des frustrations et pertes de temps car les imprévus surviennent très souvent pendant la réalisation. C’est cette approche prédictive et séquentielle de type waterfall ou cycle en V que les tenants des méthodes « Agile » veulent casser.

Ainsi, le mieux serait de procéder par étapes c’est-à-dire se fixer des objectifs à court terme et commencer le développement sans perdre de temps. Une fois l’objectif atteint, on passe à la phase suivante et ainsi de suite jusqu’à atteindre le but recherché. Concernant le niveau de développement de logiciel, il appartient au client de transmettre à l’équipe de développeurs sa vision du produit avec les fonctionnalités qui l’accompagnent. Cela permet ainsi d’avoir un échange direct avec l’équipe et et de définir ensemble le coût de chacune des fonctionnalités pour aboutir à un budget final approximatif. L’équipe devra choisir ensuite une partie des exigences du client à exécuter dans un court délai appelé « itération ».

Itération agile

Le principe des itérations

Dans chaque itération se trouvent les travaux de conception, les techniques de développement et les spécifications fonctionnelles. Au terme de chaque itération, le produit semi-fini mais utilisable, est montré au client. Il peut donc se rendre compte par lui-même du travail réalisé dans un temps très court. Quant à l’utilisateur final, il peut déjà se projeter dans l’usage du produit. Cela lui permet de transmettre des feedbacks importants pour les prochaines itérations. Cette transparence est un grand avantage pour solidifier la relation de confiance et de collaboration entre le client et le fournisseur. Cela permet ainsi d’économiser son budget et de récolter rapidement un premier retour sur investissement. Le client a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n’ont pas encore été développés (prochaines itérations).

Cette souplesse ainsi offerte est donc un véritable atout pour le client. Encore une fois, on pense plus « Produit » que « Projet » d’où le terme approprié ici est « gestion de produit » remplaçant celui de « gestion de projet ».

Les différentes méthodes agiles

Il existe plusieurs types de méthodes Agiles, se différenciant par leur capacité d’adaptabilité à certains projets. Parmi ces méthodes nous retrouvons la méthode RAD qui implique par exemple la présence d’une tierce personne pour résoudre les problèmes et les incompréhensions. La méthode SCRUM, la méthode FDD et la méthode DSDM sont quant à elles basée sur l’organisation de plusieurs mais courtes réunions permettant de d’approuver chaque étape, contrôler les avancées et développer une bonne relation de confiance entre les intervenants en la rendant plus interactive.

Loin d’être une simple méthodologie, l’approche Agile définit un état d’esprit impactant l’ensemble des entreprises souhaitant s’y conformer. Cette démarche, à la fois longue et difficile à mettre en œuvre, en vaut largement la peine. Elle permet, en effet, d’obtenir des résultats très satisfaisants. Il est donc primordial d’en maitriser chaque partie afin de faire accepter ce changement tant au sein de l’entreprise qu’auprès du client.

Les évolutions récentes

La plupart des méthodes « agile » de gestion de projet sont ciblées sur les projets de développement de logiciel. Est-ce à dire qu’on ne peut utiliser Agile que pour l’informatique? A l’heure où la mondialisation exige des Entreprises qu’elles soient toujours plus agiles pour se repositionner sur le marché grâce à des innovations constantes, ne pourrait-on pas imaginer créer des produits non logiciels de façon agile?

La réponse est bien sûr positive. Les méthodes de gestion de projet traditionnelles se sont récemment enrichies d’une version agile. L’agilité n’entame en rien la nécessité d’utiliser une méthode éprouvée. Aussi, récemment les principaux éditeurs ont publié des versions « agile » de leur méthode traditionnelle :

  • AXELOS, éditeur de PRINCE2, vient de publier PRINCE2 Agile qui à donné naissance à la certification PRINCE2 Agile Practitioner,
  • PMI a créé récemment la certification PMP-ACP (PMP Agile Certified Practitioner).

Alors au final vous êtes plutôt Agile ou Classique?

Les méthodes Agiles pourront être utilisées pour de gros projets car elles proposent une adaptabilité, une meilleure visibilité et gestion des risques. Elles pourraient tout aussi bien être utilisées pour les projets où il n’y pas de documentation détaillée. Le client peut alors suivre la progression du projet et l’adapter au fur et à mesure selon ses besoins.

.Par contre, les méthodes Traditionnelles seront plus adaptées si vous avez une idée précise de votre projet avec un cahier des charges et planning très détaillé où vous avez anticipé tous les risques envisageables. Nous essaierons prochainement de vous orienter entre l’approche Traditionnelle ou l’approche Agile selon les types de projets. Notre prochain article proposera une étude comparative des approches et méthodes « agile » pour vous aider à faire un choix raisonné.

Bien sûr, nous vous invitons à réagir et à nous communiquer vos commentaires.

Catégories

Archives

Calendrier

février 2019
L M M J V S D
« Jan    
 123
45678910
11121314151617
18192021222324
25262728  
%d blogueurs aiment cette page :