Vous avez besoin d'aide? +41 43 588 10 36
Choisissez votre pays et votre langue
/Actualité
Actualité

Actualité

Découvrir les dernières nouvelles du monde de la gestion de projet et de l’IT.

Date: 01/04/2020

Le module ITIL 4 Direct, Plan & Improve permet d’acquérir les compétences pratiques nécessaires pour créer une organisation informatique centrée sur l’apprentissage et l’amélioration, avec une direction stratégique forte et efficace.

En outre, la formation ITIL DPI fournit aux praticiens une méthode pratique et stratégique pour planifier et assurer une amélioration continue avec l’agilité nécessaire.

Pour passer l’examen, le candidat doit avoir réussi l’examen ITIL 4 Foundation. De plus, le participant doit avoir suivi une formation accréditée pour ce module.
Une expérience professionnelle en gestion des services informatiques est recommandée.

 

Objectifs de la formation ITIL 4 Direct, Plan & Improve (DPI)

L’objectif de l’examen ITIL 4 Create, Deliver and Support est de vérifier que le candidat possède les connaissances théoriques et pratiques d’ITIL 4 pour pouvoir diriger, planifier et améliorer des services.
La certification ITIL 4 Direct, Plan & Improve constitue l’une des conditions préalables à l’obtention de la certification ITIL 4 Managing Professional et ITIL 4 Strategic Leader.

Après cette formation, le participant doit, entre autre, être capable de:

  • Comprendre les concepts clés “Direct, Plan & Improve
  • Comprendre le périmètre de ce qui doit être dirigé et / ou planifié / amélioré et savoir utiliser les principes et méthodes clés de direction et de planification dans ce contexte
  • Comprendre le rôle de la GRC (Gouvernance, Risque et Conformité) et savoir comment intégrer les principes et les méthodes dans le système de valeur des services
  • Comprendre et savoir utiliser les principes et méthodes clés d’amélioration continue pour tous types d’amélioration
  • Comprendre et savoir utiliser les principes et méthodes clés de communication et de conduite du changement organisationnel pour diriger, planifier et améliorer
  • Comprendre et savoir utiliser les principes et méthodes clés de mesure et de reporting pour diriger, planifier et améliorer
  • Comprendre et savoir diriger, planifier et améliorer les flux de valeur et les pratiques.

 

Public visé par la certification ITIL 4 Direct, Plan & Improve

  • Quiconque souhaite poursuivre son parcours de formation et de certification dans la gestion des services informatiques
  • Responsable ITSM actuel ou futur
  • Responsable de tous les niveaux impliqués dans la mise en place des directions et des stratégies ou qui cherche à améliorer de manière continue une équipe
  • Tout certifié ITIL souhaitant développer ses connaissances

 

Examen ITIL 4 Direct, Plan & Improve

  • Langue: français et anglais
  • Durée: 90 minutes (25% de temps supplémentaire si vous passez l’examen dans une langue autre que votre langue maternelle soit 113 min. au total)
  • Supports autorisés : aucun
  • Examen à livre fermé
  • Questions: 40
  • QCM
  • Taux d’admissibilité: 28 points ou plus
  • Niveaux de raisonnement de Bloom : Niveau 2 & 3 (Bloom’s levels 2 & 3)
  • 12 questions de compréhension (niveau 2)
  • 28 questions de pratique (niveau 3)
  • Format de l’examen : en ligne ou papier
  • Format du certificat : numérique

Le certificat numérique est inclus dans les frais d’examen.
Vous pouvez cependant demander un certificat papier à l’institut d’examen après obtention de votre examen.

Prérequis: le candidat doit avoir réussi l’examen ITIL 4 Foundation. De plus, le candidat doit avoir suivi une formation accréditée pour ce module (la durée recommandée pour cette formation est de 18 heures examen compris).

 

 ITIL 4 Strategist Direct, Plan & Improve.

 

Exemples de questions à l’examen ITIL 4 DPI

Les questions sont toutes « à choix multiples » : standard, négative et liste

Exemple de question de type « standard » :
Quelle est la source des Bonnes Pratiques?
a) Q
b) P
c) R
d) S

 

Exemple de question de type « liste » :
Quel énoncé sur la gestion des actifs de service et des configurations est CORRECT?
Elle supporte Q
Elle supporte P
Elle supporte R
Elle supporte S
a) 1 et 2
b) 2 et 3
c) 3 et 4
d) 1 et 4
REMARQUE : deux options parmi la liste sont correctes. Les questions de type «liste» ne sont jamais négatives.

 

Exemple de question de type « négative » :
Laquelle des options suivantes n’est PAS un domaine de valeur défini ?
a) Q
b) P
c) R
d) S
REMARQUE : les questions négatives sont utilisées uniquement à titre exceptionnel, lorsqu’une partie des acquis d’apprentissage consiste à savoir qu’un élément est manquant ou ne devrait pas se produire.

 

Certification ITIL 4 Direct, Plan & Improve (DPI) 

Le candidat qui réussit l’examen obtient la certification. Le certificat en ligne est inclus dans les frais d’examen.

QRP International est un organisme de formation agréé (ATO) par Peoplecert pour le compte d’Axelos.
Il est autorisé à dispenser les formations ITIL 4 DPI et peut vous préparer à l’examen de la certification de gestion des services informatiques ITIL 4 DPI.

Lire plus
Date: 26/03/2020

Le contexte actuel nous challenge tous de différentes manières. Le télétravail est un des grands défis rencontrés par les professionnels, quand ils ont la chance de pouvoir le faire et que l’activité le permet.
Souvent, les réunions sont annulées, les plans changés et les activités habituelles interrompues.

QRP International, tout comme votre entreprise, a dû modifier la planification de ses formations et s’adapter.
La pandémie a été la dernière impulsion dont nous avions besoin, pour enfin exécuter le projet de formations à distance que nous souhaitions mettre en place depuis longtemps.

C’est désormais chose faite !  À partir de maintenant, nous sommes en capacité de proposer toutes nos formations en virtual classroom. Mêmes experts, mêmes méthodes d’apprentissage stimulantes et même énergie !
La seule différence : vous êtes tous à distance.

 

Notre solution Virtual Classroom

Nous mettons tout en œuvre pour satisfaire nos clients.

C’est en suivant cette valeur fondamentale que nous avons développé notre solution. Nous avons pensé à vous offrir la meilleure expérience d’apprentissage possible. Dans cette optique, nous avons décidé de ne pas simplement transmettre les formations en présentiel en ligne, en vous laissant devant une webcam pendant sept heures d’affilée.

Au contraire, nous avons souhaité vous proposer une solution flexible et adaptée au contexte. Nos formations virtual classroom sont donc constituées d’un mélange de formation en ligne en direct et de travail en autonomie.

Durant les demi-journées de session en direct, le formateur vous explique la méthodologie, c’est l’occasion de poser des questions au formateur et de dialoguer avec les autres participants.
Le reste de la journée, vous serez libre de vous organiser.

Nous demandons seulement 1 à 2 heures de votre temps libre pour appliquer activement tout ce que vous avez appris en faisant des exercices. Nous avons choisi un logiciel de pointe comprenant des questions tests, exercices et simulations d’examens pilotées par l’IA, afin de faciliter votre apprentissage par la répétition des éléments non acquis. Ainsi après avoir terminé la formation, vous serez plus que prêts pour passer l’examen!

 

La qualité avant tout

Le Q de QRP est synonyme de qualité.

Nous avons développé une solution à distance répondant à nos standards de qualité habituels.
Nous sommes conscients que le format virtual classroom est un réel challenge et, par conséquent, notre équipe s’est efforcée de développer une solution permettant une excellente expérience d’apprentissage pour vous ou vos équipes.

Les formations virtual classroom sont dispensées par nos formateurs, expérimentés et toujours actifs dans leurs domaines respectifs. Les formations comprennent des exemples de situations réelles et sont adaptées au groupe de participants afin de leur offrir la meilleure expérience possible.

 

Pourquoi maintenant?

Les changements dans vos activités habituelles et la réduction de l’activité pourraient vous laisser un peu de temps. Une fois que la situation sera revenue à la normale, vous serez probablement confrontés à une surcharge de nouveaux projets, programmes et développements de  logiciels.

Et si ce ralentissement d’activité était l’occasion de vous former ou de former vos équipes ?

QRP développe les professionnels pour faciliter le changement. C’est pourquoi nous avons souhaité adapter notre plan d’action et être en mesure de vous fournir des solutions pendant cette période difficile. Vous pouvez bénéficier de nos formations e-learning et virtual classroom, en attendant le retour de nos formations présentielles.

Si vous souhaitez en savoir plus contactez-nous directement au +41 43 588 10 36 ou à l’adresse e-mail switzerland@qrpinternational.com.

Téléchargez notre brochure virtual classroom et découvrez notre solution flexible.

 

Calendrier Interentreprises / formation virtual classroom
PRINCE2 Foundation – formation virtual classroom
AgilePM Foundation – formation virtual classroom
ITIL4 Foundation – formation virtual classroom

Lire plus
Date: 24/03/2020

Coach Agile depuis quelques années Damien accompagne les entreprises dans le développement de leurs projets, leurs démarches d’amélioration continue et leur recherche de performance au sein même d’une équipes, dans un esprit Lean et Agile.

 

Quelle est votre fonction actuelle, quelles sont vos missions ?

J’ai deux activités. Je suis président d’une start-up dans la logistique dédiée à la santé et je suis également coach agile depuis plus de quatre ans. Mes missions récurrentes en tant que coach agile sont principalement l’accompagnement dans la transformation digitale et le passage à l’agilité des entreprises, de la R&D à la direction.

 

Comment avez-vous connu SCRUM ?

J’ai connu SCRUM lorsque je travaillais pour une société en pleine transformation, qui est passée d’une gestion de projet très classique, très cycle en V, à des bases plus agiles dans le secteur médical. J’ai suivi un cursus de Coach Agile avec le SEI (Software Engineering Institute) à Pittsburg puis j’ai suivi une formation SCRUM Master avec Jeff Sutherland, l’un des co-créateur de la méthode et j’ai été emballé.

 

Qu’est-ce qui vous a le plus plu dans la méthode ?

J’ai beaucoup aimé la simplicité de la méthode et sa légèreté. C’est aussi ce qui en fait son piège, c’est simple, léger, ça tombe sous le sens mais c’est très difficile à maîtriser. La partie qui m’intéresse particulièrement dans cette méthode agile, c’est la position de l’humain au centre et c’est ce qui selon moi, en fait sa grande force aujourd’hui.

 

Qu’est-ce que SCRUM a changé dans votre quotidien ?

J’ai un background en management de projet très classique type PMP (Project Management Professional).  Ce qui m’a aidé en tant que directeur recherche et développement dans mon quotidien c’est vraiment la prise en compte des dynamiques d’équipes et de la manière dont les équipes sont organisées afin de mener à bien les projets.

A cela s’ajoute l’importance de la communication et de la collaboration inter-équipe au sein d’une même entreprise. C’est très important et très puissant dans un contexte SCRUM.

 

Quelles sont les erreurs fréquentes que vous observez dans les organisations qui souhaitent mettre en œuvre la méthode ?

La plus grosse erreur est de vouloir faire une transformation agile pour suivre la mode. Dans un tel contexte, la transformation est vouée à l’échec. Il y a malheureusement beaucoup d’entreprises qui se lancent sans forcément anticiper  les conséquences.

Lorsqu’on responsabilise l’humain et qu’on lui donne les clefs de l’auto-organisation, il faut forcement s’attendre à un certain nombre de changements au niveau ressources humaines dans les organisations. Il faut donc être prêt à jouer le jeu au niveau entreprise.

 

Quels conseils pouvez-vous donner aux professionnels souhaitant implémenter Scrum ?

Les personnes qui pensent que l’agilité va résoudre tous les problèmes d’un coup de baguette magique doivent être accompagnées et sensibilisées dès le départ  aux tenants et aboutissants d’une telle transformation. C’est avant tout une question d’état d’esprit.

C’est une très belle méthode mais qui demande beaucoup de rigueur et de discipline.
Si on part avec des aprioris comme quoi tout va devenir plus simple et plus facile, il y a de forte chances qu’il y ait des blocages lors de la mise en pratique.

Je pense qu’il y a un gros travail à faire en parallèle au niveau de la direction, des donneurs d’ordre et des ressources humaines, qui n’est pas négligeable. Mon conseil est dans l’initialisation et la préparation de la transformation Agile. Il faut impliquer les parties prenantes en amont en les sensibilisant sur la démarche et définir ensemble la stratégie à mettre en œuvre.

 

Citez trois notions que vous souhaiteriez apprendre dans un proche avenir pour vous développer en tant que professionnel ?

  • En tant que coach je souhaiterais approfondir mes connaissances sur l’approche systémique pour développer mes compétences sur l’aspect humain.
  • Au niveau agilité, je souhaiterais en savoir plus sur les différents frameworks, notamment sur la scalabilité des méthodes agiles et obtenir divers retours pour être en mesure de faire grandir l’agilité à l’intérieur d’une entreprise.
  • Sur le plan personnel, quand on est facilitateur, il faut connaître beaucoup de techniques de facilitation voir même de la facilitation graphique. J’aimerais donc creuser le sujet, bien que je n’ai pas du tout l’âme d’un artiste, mais je pense qu’il y a quelques clés simples pour pouvoir accompagner les équipes sur le thème en question.
    Je suis convaincu que la facilitation graphique est une technique qui marche, c’est un élément important dans le monde de l’agilité et de la transformation agile puisque c’est une image qui reste dans les esprits et c’est un réel atout pour favoriser les échanges et les réflexions au sein d’un groupe afin de lui permettre de construire une vision commune.
    Elle sert, d’autant plus à alimenter la collaboration et j’ai déjà pu observer les résultats bénéfiques de la présence d’un facilitateur graphique lors d’une de mes missions.

 

Damien Galzi

scrum-coach-damien-galziCoach Agile depuis quelques années Damien accompagne les entreprises dans le développement de leurs projets, leurs démarches d’amélioration continue et leur recherche de performance au sein même d’une équipes, dans un esprit Lean et Agile. Il est certifié Professionnel Scrum (CSM,CSP), PMP, Lean 6Sigma Green Belt et Coach Agile (TSP).

Suivez Damien sur Linkedin

Lire plus
Date: 18/03/2020

Nous étions à table. C’était un espace de co-working que je souhaitais tester, dans ma région, regroupant des co-workers d’horizons divers prêts à partager leur savoir et leur savoir-faire avec d’autres personnes d’autres entreprises. Une expérience neuve pour moi. Nous étions en 2014 et je venais de recevoir ma certification ITIL V3.
Je préparais la formation de mes 60 collègues.

Un jeune homme, très fraîchement sorti des études monopolise non pas l’attention mais du moins la conversation, convaincu d’avoir quelque chose à vendre à toute cette joviale assemblée… Son discours est assez péremptoire, il semble assez sur de lui et a une forte envie d’en découdre avec tout supporter d’ITIL

Je l’entends dire : « il faut absolument se séparer de la bureaucratie inhérente à l’implémentation d’ITIL dans les entreprises ». Je défends une conception de la gestion des services qui est beaucoup plus flexible et efficace.
Mon référentiel est facile à mettre en place, remplacera rapidement ITIL qui coûte cher et enferme les entreprises dans des processus lourds et inutiles.

Tous ceux qui ont implémenté ITIL s’en mordent les doigts parce qu’aujourd’hui ils souhaiteraient en sortir et n’en ont plus la possibilité.

Je venais d’investir une semaine de mon temps, et m’apprêtais à signer un bon de commande de 40000 € pour former tout un service aux bonnes pratiques, vous imaginez donc mon inquiétude. En même temps, il me fallait en savoir plus.

 

Je posai donc quelques questions rapides :

  • Comment résout-on les incidents avec ce framework ?
  • Il n’y en a presque plus, donc un retour au tableau Excel est largement suffisant.
  • Wow… Donc il y a une gestion de l’imprévu en amont, une résolution proactive d’incidents potentiels sur base d’événements constatés ?
  • Même pas, les systèmes sont stables par nature…
  • Eh bien, et ce grâce à un ensemble de choix technologiques particuliers ?
  • Oui bien sûr, mais surtout grâce à une méthode de développement qui supprime tout bug à la source…
  • Une méthode Agile ?
  • Quoi, il y a d’autres méthodes de développement ?

 

Là, j’ai pensé « On avance » !

  • Dis-moi, as-tu des exemples concrets d’organisations qui sont enfermées dans ITIL et voudraient en sortir ? Cela m’intéresserait de partager leur expérience pour éviter cela à mon Service.
  • Toutes !

 

J’ai compris à ce moment que j’avais en face de moi une brillante jeune pousse formée à l’argumentation et au bagout, mais en aucun cas à la gestion des services.
Laissant la discussion se terminer de cette façon, je remis à plus tard la suite de mon interrogatoire.

De retour à nos postes de travail, je retournais près de lui pour connaître le nom de ce référentiel magique.
Du bout des lèvres, il me dit : ça s’appelle ‘DevOps’. Ce fut mon premier contact avec DevOps, et j’avais déjà l’intuition qu’il avait bien retenu les leçons de son gourou, mais qu’il n’en avait pas capté l’essence.

J’ai donc cherché par moi-même… trouvé de bonnes pistes et suis finalement entré dans ce monde, sans jamais quitter ITIL. Il n’y avait à cette époque que très peu de documentation vraiment structurée sur le sujet. Des bonnes idées qui ensemble formaient un magma plein de bonnes intentions dont on ne pouvait que ressentir l’énorme potentiel.

C’est durant cette année cependant qu’une première mise en mots vit le jour. Un roman sur l’IT et  DevOps appelé « The Phoenix Project ». Une immersion dans un effort de transformation d’une entreprise à travers la modification profonde de son service IT.
Lire ce livre, c’est un peu comme prendre de l’expérience sans rien faire : une immersion pleine d’enseignements.

Il est vrai qu’au début du livre, certains processus ITIL sont attaqués pour leur lourdeur, mais en aucun cas il n’est recommandé de s’en défaire complètement. Mieux au fil du livre, on se rend compte de l’influence essentielle des bonnes pratiques ITIL sur la réussite de la transformation DevOps, et de l’égale importance pour celles-ci d’être élaguées de ce qui ne produit pas de valeur. On peut donc avancer vers un concept de Lean-ITIL, et une partie du chemin vers DevOps est parcouru.

Avec le temps, DevOps ayant gagné en maturité, de même que ses adeptes et praticiens, il est clairement indiqué, dans les premières pages des formations ‘Foundations’ que les 3 sources d’inspiration de DevOps sont ITIL, Lean et l’Agilité. Pour insister un peu plus, l’obsolescence d’ITIL est considérée comme l’un des mythes accompagnant systématiquement le seul nom DevOps.

Je crois fermement que ITSM et le mouvement DevOps ne sont pas opposés. Au contraire, ils offrent un mariage Culturel parfait (Selon Gene Kim, auteur – entre autres-  du Phoenix Project et du DevOps Handbook, traduction libre de l’auteur de cet article) .

Cette citation a été lancée avant même la sortie d’ITIL 4… qui s’est agilisé.
DevOps n’effaçait pas l’intérêt d’ITIL V3, inutile de dire ce qu’il advient d’ITIL 4 dans ces conditions.

Il reste donc critique pour les services IT de prendre connaissance et de mettre en place les pratiques ITIL , DevOps en utilisera le fruit avec succès.

J’ai souvent repensé à ce jeune homme. Je ne peux que le remercier d’avoir déclenché cette remise en question.
En aucun cas je ne lui reprocherai sa légèreté insouciante… Au contraire, je lui souhaite aujourd’hui d’avoir gagné en maturité au même rythme que le mouvement qu’aujourd’hui nous représentons ensemble.

 

Xavier Heusdens

Xavier a plus de 20 ans d’expérience dans la gestion de projets, programmes au sein des organisations. En plus de son activité de consultant, Xavier est formateur multilingue pour PMP, PRINCE2 et DevOps. Il est également formé aux méthodes AgilePM, ITIL, COBIT, MOP et change management.

Suivez Xavier sur Linkedin

Lire plus
Date: 11/03/2020

«Les approches agiles n’impliquent pas de planification» est certainement l’une des idées reçues les plus courantes sur l’agilité. C’est en réalité l’exact opposé!

Dans cet article, nous passerons en revue quelques conseils et techniques pour gérer le changement de manière agile et présenterons une approche pour réaliser une planification de haut niveau ainsi que les techniques nécessaires pour développer des plans spécifiques pour chaque élément de changement.

Dans notre précédente interview avec Mélanie Franklin, coprésidente du Change Management Institute UK, nous avons vu combien il est important de gérer le changement dans un monde agile.

Les changements agiles sont en effet complexes et continus.

  • Complexes car l’innovation continue implique une obsolescence continue, de sorte que la durée de chaque changement devient de plus en plus courte et les changements de plus en plus fréquents.
  • Continus parce qu’ils font désormais partie de l’entreprise comme une activité habituelle.

 

Comment planifier dans un environnement agile?

Dans un contexte Agile, on parle souvent de «solution évolutive» (evolving solution).
Une solution évolutive nécessite une planification continue tout en gardant en vue l’objectif final.

Pour planifier chacun des changements nous avons besoin d’orientation, d’avoir un but/une destination, qui conduira à la transformation de notre façon de travailler. Il faut ensuite se demander quelle est la partie la plus utile, celle qui pourrait vraiment nous aider à atteindre l’objectif.

C’est ce qu’on appelle réaliser un schéma de décomposition, où l’on prend une idée dans sa totalité et on la divise en petites parties. Il est ensuite plus facile de comprendre quelles parties réaliser en premier et lesquelles faire ultérieurement.

Il est donc conseillé d’utiliser une approche “bottom up” pour identifier le temps et les ressources nécessaires et d’en informer les parties prenantes.

Dans la planification agile, il y a une forte implication des ressources, afin qu’elles puissent réellement contribuer au projet. Il faut constamment se demander : « faisons-nous vraiment la chose la plus pertinente dans notre planification en ce moment« ?

Cette activité peut sembler facile, mais ce n’est pas le cas: il est important de se demander constamment quelles composantes de l’idée finale peuvent réellement fonctionner et donner vie à l’objectif final.
De cette façon on obtient une planification globale de haut niveau puis une planification plus spécifique pour chacune des parties. Avec l’agilité, le niveau de détail augmente progressivement.

 

Changement de comportement

Qu’est-ce que c’est et pourquoi c’est important

L’une des plus grandes difficultés des approches agiles est de comprendre l’importance du changement de comportement. Souvent, l’accent est exclusivement mis sur le temps pour créer des changements techniques et tangibles, mais l’impact du changement sur la façon de travailler est sous-estimé.

Les employés seront peut-être déstabilisés, leur expertise ou méthode de travail se trouvant impactées et ils devront être formés aux nouvelles techniques et aux nouveaux systèmes. Les activités de transition prennent du temps, il faut accepter le changement, partager l’objectif, accepter de faire des erreurs, continuer de s’entraîner et pratiquer les nouvelles méthodes de travail.

Lorsque le changement est constant, il est essentiel que les ressources acceptent que leur travail change et donc de prendre en compte leur bien-être émotionnel.

Il est nécessaire de s’assurer que les ressources impliquées sont prêtes pour les nouvelles activités et les nouvelles façons de travailler. Il arrive souvent que la partie technique et tangible aille beaucoup plus vite et qu’une différence se crée entre les activités du projet et celles du changement.
Ils se peut malheureusement que les ressources soient encore absorbées par les récentes activités de changement.

Mélanie Franklin identifie trois éléments de changement de comportement:

  • tester de nouvelles façons de travailler
  • comprendre comment faire les choses
  • créer de nouvelles habitudes

Par conséquent, les activités de projet et de changement de comportement doivent être synchronisées afin de ne pas avoir de nouvelles fonctionnalités ou choses que les ressources n’utilisent pas car elles ne sont pas encore en mesure de le faire.

La première étape consiste à être conscient que le changement n’est pas seulement matériel, mais qu’il affecte également les ressources humaines et leur façon de travailler.
Ainsi on obtient l’équation: livraison + mise en œuvre = une nouvelle façon de travailler.

À la fin de chaque itération, les parties prenantes devraient être d’accord sur la façon de gérer le changement.
Il s’agit d’une activité collaborative, puisqu’elle implique les responsables du changement et les utilisateurs.

 

L’importance d’une livraison ponctuelle

Respecter les délais de livraison permet d’anticiper, de savoir quand les changements arriveront et le temps nécessaire pour voir des améliorations. Diviser les activités et respecter les délais, c’est aussi donner une réponse aux ressources qui attendent le nouveau service et la nouvelle façon de travailler, ces mêmes ressources qui ont reçu les outils et la formation adaptée pour pouvoir commencer à travailler autrement.

Il est important de respecter les promesses de livraison car le changement est toujours une source de stress: les ressources mettent tout en œuvre pour être prêtes et un retard pourrait augmenter l’impact émotionnel du changement. Le respect des temps est donc fondamental.

Mais comment décomposer la totalité de l’échéancier ?
M. Franklin suggère des niveaux de planification (image ci-dessous)

La période donnée (timeframe) est décomposée en itérations, où les résultats (outcome) sont identifiés à la fin de chaque itération. Afin d’atteindre les différents jalons (milestone), Mélanie Franklin met en place un processus reproductible composé de 3 étapes:

 

agile-change-management-different-levels-of-plans

  1. Getting started
  2. Making progress
  3. Realising benefits

 

1 Getting started
Cette première étape est un brainstorming sur toutes les activités à faire (si le projet évolue dans un environnement agile cela se fera sous forme de user stories). Il s’agit d’une activité collaborative et il est essentiel de couvrir à la fois les «livraisons» et les «transitions», liées aux activités de conduite du changement.

C’est l’occasion pour toutes les personnes impliquées de comprendre comment le temps sera géré et quelle est la meilleure façon de travailler.

 

2 Making progress
Cette étape est celle qui inclut tous les changements dans les procédures de travail, c’est-à-dire les changements techniques qui entraîneront également des changements dans la façon de travailler. À la fin de cette étape, le travail effectué est passé en revue et la qualité des éléments de changement évaluée, tout en prenant en compte les différentes conséquences qu’ils impliquent.

 

3 Realising benefits 
La solution/les résultats obtenus sont utilisés mais les utilisateurs essaient encore d’encourager l’élimination de tout ce qui n’est plus nécessaire. Pour finir, il est important de créer un environnement motivant, en remerciant les ressources pour le travail accompli (par exemple en partageant les remerciements d’un client pour le service).

Ces étapes offrent une structure répétable pour chaque itération utilisée pour planifier les éléments de changement Agile.

Pour en savoir plus sur Agile Change Management, consultez l’article: Comment améliorer la conduite du changement dans un monde Agile – Interview de Mélanie Franklin

 

Sources : How to plan and Agile change initiative, APMG International

Lire plus
Date: 04/03/2020

Nous savons tous que DevOps est une transformation des personnes et de la culture.
Briser le «mur de confusion» entre les Dev et les Ops suppose la collaboration et DevOps encourage une culture de collaboration et d’apprentissage.

DevOps veut créer des équipes interfonctionnelles et, bien sûr, requiert une équipe de spécialistes pragmatiques ayant une expérience pratique. Mais DevOps n’est pas un métier et il n’y a pas d’équipe spécifique.

En parlant “d’équipe DevOps”, l’industrie est divisée sur la question de savoir s’il devrait y avoir une équipe DevOps ou non. L’article “The Industry Just Can’t Decide about DevOps Teams”* présente différents points de vue. L’opinion la plus populaire est que les équipes DevOps sont un contre-modèle: elles peuvent créer des silos supplémentaires et, plus généralement, toutes les personnes d’une organisation doivent souscrire à la culture DevOps.

 

Theresa Naete, dans

“Break down DevOps team roles so you can actually get to DevOps”**précise: «Le fait est que nous ne pouvons mettre en place DevOps si nous continuons à cloisonner les équipes. (…) Dans un environnement DevOps, les dev et les op font partie de la même équipe. Je répète: la même équipe ! Ce que certains d’entre nous ne comprennent pas, c’est que la culture est primordiale et essentielle pour les outils. Cette culture comprend la suppression des rôles de l’équipe DevOps, des silos et des barrières de travail afin que tous les outils choisis puissent ensuite être optimisés pour atteindre les résultats souhaités.»

 

Il y a aussi des partisans de l’idée que les équipes DevOps sont un moyen efficace de passer à une nouvelle façon de travailler et, malgré le fait que la majorité de l’industrie pense que les équipes ne sont pas la bonne approche pour faire évoluer les capacités DevOps à travers une organisation, les équipes DevOps sont en augmentation.

L’objectif de DevOps au sein d’une organisation est d’améliorer la livraison de valeur pour les clients et l’entreprise; différentes organisations pourraient avoir besoin de différentes structures d’équipe afin de créer une collaboration efficace entre les Dev et les Ops.
Cela signifie que la structure organisationnelle idéale pour implémenter DevOps dépend de nombreuses variables.

 

Les rôles DevOps

Comme nous le disions précédemment, il n’y a pas de structure unique établie pour une équipe DevOps (l’équipe DevOps n’existe pas). Les rôles et les responsabilités varient selon les organisations: le plus important est d’identifier les rôles et responsabilités clés et d’avoir les professionnels qualifiés pour les couvrir.
Selon TechBeacon ***, les rôles DevOps les plus courants, qui sont essentiels pour toute organisation qui souhaite adopter une approche DevOps réussie, sont:

  • DevOps Evangelist : la personne qui fait la promotion des avantages de DevOps dans toute l’organisation.
    Il / elle est passionné(e) par DevOps et son rôle est d’assurer l’adhésion des équipes de développement et opérationnelles. L’évangéliste DevOps est votre leader DevOps.
  • Release Manager : parfois appelé Release Engineer ou Product Stability Manager, il ou elle est responsable de la progression globale et coordonne, gère le produit du développement à la production.
  • Automation Architect : également appelé ingénieur / expert en automatisation ou spécialiste de l’intégration; il analyse, conçoit et met en œuvre diverses stratégies pour le déploiement continu du produit.
    Ce rôle est essentiel car il garantit un environnement fiable entièrement automatisé et exempt d’obstacles.
  • Software Developer/Tester : ce rôle est bien sûr au cœur d’une organisation DevOps (le Dev de DevOps!). Mais dans un environnement DevOps, les développeurs sont responsables non seulement de la conversion de nouvelles exigences en code, mais également des tests unitaires, du déploiement et de la surveillance continue.
  • Experience Assurance (XA) Professional : si dans le développement de logiciels «classique», l’assurance de la qualité (AQ) a un rôle vital pour la livraison réussie du produit final, dans DevOps, il évolue dans l’assurance de l’expérience, car ce rôle doit également garantir que toutes les nouvelles fonctions et fonctionnalités sortiront en ayant à l’esprit l’expérience de l’utilisateur final.
  • Security Engineer : il/elle travaille en collaboration étroite avec les développeurs, sécurisant le produit en cours de développement.
  • Utility Technology Player : professionnel traditionnel des opérations informatiques ou de l’administration de systèmes qui se concentre sur le maintien des serveurs en fonctionnement; il/elle opère efficacement sur les plateformes de développement, les réseaux, les bases de données, les serveurs et les outils.

 

La culture DevOps

DevOps consiste à partager et à apprendre. Avoir une personne qui veut constamment apprendre et échanger dans l’équipe est aussi important que d’avoir un membre qualifié.

Il y a trois caractéristiques clés pour un professionnel DevOps:

  • Avoir un bon esprit d’équipe et être capable d’intégrer la culture de l’organisation.
  • Etre curieux et avide d’expérimentation. Expérimenter encore et encore et continuer d’essayer même en cas d’échec, jusqu’à ce que la solution soit trouvée : DevOps encourage l’échec, mais un échec responsable.
  • Etre capable de s’adapter et d’approcher le changement avec positivité.

 

devops leadership peoplecert

 

Copyright 2017-2019 Peoplecert International Ltd.

Other sources:

* Helen Beal, The Industry Just Can’t Decide about DevOps Teams
** Theresa Naete, Break down DevOps team roles so you can actually get to DevOps
*** 7 key DevOps roles you need to succeed
What Team Structure is Right for DevOps to Flourish?

Lire plus

Evénements

Découvrez nos évènements gratuits

Nous avons aidé des milliers de professionnels à monter en compétence. Nous pouvons Vous aider également.

Inscrivez-vous à notre newsletter et choisissez les contenus que vous souhaitez recevoir: Gestion de projets, programmes, portefeuille ou Gouvernance IT ou bien les deux catégories. Vous recevrez 1 fois par mois des articles, études de cas, invitations à nos conférences, webinars et nos offres spéciales. Pas de spam. Juste des conseils utiles et professionnels.

Restez connecté à la communauté
Suivez-nous sur Linkedin e Twitter

Actualité

Lire les dernières news

Evénements

Voir les prochains évènements