Le praticien agile, c’est qui  ?

Il a lu « Scrum & XP from the trenches » un soir, il l’a gardé 2 semaines comme livre de chevet, il l’a rangé, et il a participé à un ou plusieurs projets agiles au sein de sa DSI. il a atteint un certain niveau de maturité sur les projets agiles et a pris du recul sur la méthode. Il se pose aujourd’hui des questions comme « Peut-on vraiment concilier TMA et agilité? »ou alors « Comment pérenniser la dynamique d’amélioration continue au sein de mes équipes » ou bien encore « Comment fluidifier les process en amont et en aval de mon équipe Scrum? », etc.

Le format Open Space c’est quoi ?

C’est un format ouvert sur une demi journée, où les participants proposent et choisissent eux-mêmes les sujets sur lesquels ils vont ensuite travailler par petits groupes lors de sessions de 40 minutes. A l’issue de chaque session, chaque groupe présente à l’ensemble de l’assemblée un compte-rendu des échanges. La philosophie de l’exercice est très bien décrite ici.

Et pourquoi un Open Space pour praticiens agiles ?

Parce que la communauté de praticiens agiles est de plus en plus grande et que nous, OCTO, constatons que les questions qui reviennent chez nos clients Agiles sont souvent focalisées autour des mêmes problématiques.

Après avoir organisé plusieurs ateliers découvertes de l’agile sur le format Open Space ces dernières années, nous avons donc organisé et animé une première session dédiée au praticiens agiles le 24 Novembre dernier, à laquelle ont participé des acteurs comme Médiametrie, FigaroCMS, Viadeo, Danone et Allocine.

Nous avons eu le privilège d’accueillir l’illustratrice Véronique Olivier-Martin (vous trouverez une présentation de ses interventions par Pierre Haski sur Rue89) dont le rôle consistait à capter en direct et faire émerger sur une fresque murale géante les principaux échanges au sein des groupes de travail : le résultat est détonnant et nous souhaitions partager le fruit de ce travail collaboratif riche avec vous.Vous pouvez télécharger la fresque en qualité originale ici. Et pour le plaisir, voici ci-dessous quelques illustrations issues de cette fresque et très représentatifs de nos échanges :

Waouh ça déchire ! La prochaine session c’est quand ?

Nous avons donc décidé de pérenniser l’événement sur le fond et sur la forme ! La prochaine session aura lieu Mardi 14 Février de 14h à 18h chez OCTO.

Super, je suis praticien agile et je souhaite prticiper, comment je m’inscris ?

Vous pouvez d’ores et déjà confirmer votre inscription ici!

Suggestion d'articles :

1. Open Space OCTO : nouvelle session praticiens agiles le 14 Février
2. Open Space pour les praticiens agiles le 24 novembre chez OCTO
3. Open Space « La Pilule Rouge – Comment faciliter la collaboration distante dans nos organisations ? »

On a maintenant l’habitude de voir des principes du Lean Management derrière beaucoup des pratiques Agiles. Par exemple :

• Les tests unitaires et l’intégration continue, sorte de Andon et de Poka Yoke à la fois ;
• Les rétrospectives, support privilégié du Kaizen, sorte de cercle de qualité des équipes de développements ;
• Les taskboards, « kanban boards » et autres radiateurs d’information comme outil de management visuel ;
• etc.

Plus intéressant est l’exercice de voir les bonnes pratiques DevOps comme des instanciations du Lean Management aux activités de livraison, intégration, tests, déploiement, suivi du run.

Les analogies et principes sous-jacents du Lean pouvant alors nous aider à mieux comprendre la « magie » des pratiques DevOps ou même à en imaginer de nouvelles !

Les pratiques DevOps comme instanciation du Lean

Jidoka, l’autonomation

Le Jidoka est le premier pilier du Système de Production Toyota. C’est l’automatisation avec une touche humaine, ou comment automatiser les opérations simples et répétitives, tout en conservant un contrôle humain pour orchestrer tout cet outillage, et prendre en main les situations complexes. La légende veut qu’un fondateur Toyoda ait ajouté un système de détection d’anomalie et d’arrêt automatique sur des métiers à tisser.

En IT, DevOps poursuit la même démarche en poussant au maximum l’utilisation des robots d’intégration continue, de déploiement automatique, de configuration ou de supervision. Tools matter.

Just in Time, le juste à temps

Le Just in Time est le second pilier du Système de Production Toyota. C’est la mise en flux pour livrer juste à temps (ni avant ni après) le produit demandé, dans la quantité demandée. Les outils du Jidoka sont le lissage, la réduction de la taille des lots (livrer plus souvent de plus petits lots) et surtout la diminution du coût de traitement d’un batch avec SMED.

La comparaison avec DevOps saute aux yeux lorsqu’on cherche à mettre en production plus régulièrement de plus petits lots de fonctionnalité.

Une fois le principe du JIT saisi, nous avons entre nos mains les outils théoriques pour mieux comprendre nos problèmes de fréquence de livraison, notamment :

• débusquer les opportunités de « SMED » et de diminution du coût de traitement d’un lot dans notre process dev⇒prod afin de diminuer le coût d’un déploiement, pour tendre vers le déploiement en continu ;
• déterminer la taille de batch optimale, i.e. la taille de MEP optimale pour un niveau d’outillage et de process donnés (à optimiser par SMED en parallèle).

Kaizen, l’amélioration continue

Pilier du Modèle Toyota, le Le Kaizen, consiste à tirer des leçons des problèmes, enrichir notre « système » et ceci à travers une démarche structurée et des outils d’analyse éprouvés (PDCA, 5 pourquois, diagramme de Pareto etc). On a tous envie de s’améliorer, le Kaizen nous aide à structurer et rendre efficace ces efforts d’amélioration.

La communauté DevOps n’est pas en reste et reconnaît qu’elle fait face à des systèmes complexes qui échoueront tôt ou tard, les champions étant ceux qui tireront vite et bien les leçons des échecs petits et grands. A titre d’illustration, le livre Web Operations y dédie un chapitre entier : « How to Make Failure Beautiful: The Art and Science of Postmortems ».

L’autre aspect souvent négligé ou mal compris de l’amélioration continue en DevOps vient de la réduction de la taille des lots (i.e. l’augmentation des livraisons de plus petit « batch » de code). Le Lean prend l’image suivante : diminuer le niveau de l’eau fait apparaître les rochers entre lesquels ils faut naviguer.
L’eau c’est le stock, dans notre cas tout ce qui n’est pas déployé, les rocher sont les problèmes. Quand on livre plus souvent on découvre plus souvent des problèmes. On peut dire qu’on met aussi en flux la découverte/résolution de problème !
Les problèmes sont plus fréquents, plus visibles, plus petits (moins de code), plus maitrisables.

Management de la performance

Le Lean Management, comme d’autres corpus de management insiste sur la pré éminence des métriques, les fameuses « KPI », pour factualiser la performance actuelle et l’écart à l’objectif et ainsi mieux piloter le navire. Gardons aussi à l’esprit la mise en garde de Deming qui nous explique que gérer une entreprise seulement par des métriques fait partie des 7 « maladies du management ».

DevOps insiste sur l’importance des métriques, aussi bien sur le système technique (utilisation des ressources, temps de réponse..) que sur le processus (« Time to Diagnose » d’incidents, Lead Time dev⇒prod etc). Mesurons plus nous disent les top performers du web.

Equipe pluridisciplinaire

Dans l’industrie Toyota a initié les cellules en U dans lesquelles un opérateur est multi compétent, passant d’un poste à l’autre, en suivant la pièce le long de la chaîne (à l’opposé du Charlot mono tâche des Temps Modernes).
En Lean Product Development, Toyota a réduit à l’extrême ses délais de conception, notamment en rapprochant designers, motoristes et ingénieurs responsables de la production en série.
DevOps : des dev plus ops, des ops plus dev, des dev et des ops qui binôment.

Conclusion

Il reste un dernier rapprochement entre devOps et le Lean. Womack et Jones ont inventé le terme « Lean » (« léger », « maigre » en anglais) car il trouvait la méthode japonaise plus légère que ses concurrentes occidentales (par exemple ISO), plus explicable, plus « maniable ». C’est ce même caractère de pragmatisme et d’utilisabilité qui frappe quand on compare DevOps à ITIL. Sur les problématiques communes DevOps/ITIL (notamment gestion des changements, gestion des alertes, capacity planning, amélioration continue…), les intentions sont identiques et les recommandations se recouvrent parfois. N’empêche : dans un cas le corpus de pratique est organique et actionnable, dans l’autre il est complexe et nécessite une expertise et une exhaustivité intimidante.

Redécouvrir et approfondir les principes et pratiques du Lean Management nous permet alors d’apporter des gains substantiels au traitement des problématiques DevOps.

Les gurus de la communauté Lean (par exemple Jez Humble, auteur de Continuous Deployment ou les top performers de Wealthfront ou IMVU) ne s’y sont pas trompés lorsqu’ils basent leurs réflexions DevOps sur des outils du Lean comme le Value Stream Mapping, placent la littérature Lean en bonne place dans leur bibliothèque, ou envisagent les problèmes DevOps avec les mots et les concepts du Lean.

Ces derniers mois, les consultants OCTO ont régulièrement pioché dans la « mallette Lean » afin de rendre encore plus efficaces leurs interventions touchant au domaine DevOps.

En définitive, on redécouvre l’étonnante réponse à la question « qu’est-ce que des techniciens de l’industrie automobile peuvent apprendre aux stars de l’IT ». Beaucoup.

Suggestion d'articles :

1. OCTO accueille le 3ème meetup devops parisien le 16 mars
2. 2ème compte rendu du séminaire « Lean dans les Services »
3. Du Lean Software Development au Lean IT

Il y a peu, je participais à une réunion de travail impliquant une trentaine de personnes et j’ai fait une observation qui m’a intrigué. Avez-vous remarqué ce qui se produit lorsqu’un téléphone portable sonne au cours d’une réunion ?

• La personne propriétaire du portable l’éteint rapidement
• Tous ceux qui ne l’avaient pas encore fait vérifient leur portable et activent discrètement le mode silence.

Voilà un exemple de mesure préventive particulièrement efficace! Dans les entreprises où l’on respecte un certain standard de réunion, l’exception que constitue la sonnerie d’un portable ne se produit qu’une seule fois, pas deux. La première “infraction” protège le groupe de toute nouvelle occurrence. Elle agit en quelque sorte comme un “vaccin” sur le fonctionnement du groupe en réunion.

Quelles conditions faut-il réunir afin de créer d’autre vaccins de ce type au sein d’une équipe ? J’en vois au moins trois :

• Qu’il existe un standard explicite ou implicite pour le groupe
• Que l’écart au standard soit détectable rapidement par tous les membres du groupe
• Qu’une prévention des futurs écarts soit possible sans confrontation supplémentaire

Y a t’il des activités de groupe — autres que les réunions — dans lesquelles un vaccin de ce type pourrait fonctionner ? Bien sûr ! Par exemple, certaines équipes de développement utilisent un lapin Nabaztag qui “écoute” en permanence les résultats du serveur de build continu. Ici le standard est que le code déposé par chacun sur le serveur doit passer tous les tests. Lorsque ce n’est pas le cas, le lapin remue les oreilles et dénonce immédiatement l’auteur de l’infraction. Cet évènement incite ledit auteur à réparer le build, et les autres développeurs à toujours mieux vérifier le passage des tests sur leur code avant de le déposer.

Il existe d’autres moyens que le test pour détecter les défauts d’un système en cours de développement. D’après Wikipedia, une analyse faite par Capers Jones sur 12000 projets de développement à montré que le taux de découverte des défauts latents par des inspections formelles se situe entre 60% et 65%. Pour les inspections informelles, le chiffre est inférieur à 50%. Pour les tests en général, le taux de découverte des défauts latents est d’à peu près 30%.

L’inspection formelle, également appelée “revue de code” constitue une mesure de prévention particulièrement puissante pour améliorer en continu la qualité de vos développements. C’est une amélioration générique, qui fonctionne donc également comme un “vaccin” :

• Il existe un standard (correction du code, règles de codage, de lisibilité, de modularité, d’architecture, de couverture par les tests etc).
• L’écart au standard (erreur de logique ou infraction au standard) est détecté rapidement par tous les membres de la revue (le code étant rétroprojeté).
• Après la revue les autres participants peuvent rechercher et corriger rapidement des écarts similaires sur leur code, sans confrontation supplémentaire.

A court terme, la revue permet aux participants — même les plus novices — d’apprendre de nouvelles choses (sans avoir à poser des questions embarrassantes). A moyen terme, son usage régulier réduit significativement le nombre de défauts du système. A long terme la revue de code contribue à créer une culture de la qualité logicielle dans votre entreprise.

Comme dans le cas des vrais vaccins, ce type d’amélioration générique ne va pas sans quelques inconvénients ni réticences. Lorsque vous mettrez en place une stratégie de revue de code, vous rencontrerez très certainement des objections:

- “Mobiliser chaque semaine tous les développeurs va coûter cher et mettre le projet très en retard !”
- “Ici, il n’y a pas de standard de qualité du code !”
- “Ici dès qu’on échange sur le code ou le design cela finit par des débats houleux !”
- “On a déjà essayé de faire des revues et c’était vécu comme du flicage !”

Ces obstacles peuvent être surmontés. Apprenez à mener des revues de code. Mesurez le coût de la non-qualité sur votre projet; essayez des revues de code régulières pour une période de trois mois, puis mesurez le à nouveau. Si votre équipe respecte déjà le standard “pas de sonnerie intempestive en réunion” qu’est-ce qui l’empêche de respecter des standards encore plus cruciaux pour votre entreprise ?

Suggestion d'articles :

1. USI 2011 est à la recherche de ses speakers !
2. OCTO recherche un(e) assistant(e) RH: activez vos réseaux!
3. Ma lecture de l’architecture de Percolator : un composant du moteur de recherche Google

• Demander à chaque participant de donner son rôle sur le projet et ses attentes pour cette rétrospective
• Les noter sur une feuille de paperboard
• Demander au groupe s’il y avait d’autres membres qui ne sont pas présents, importants sur le projet, et leur rôle

L’animation du recueil des événements importants peut se dérouler de la façon suivante:

• Demander à chacun de noter les événements importants du projet pour lui avec les consignes d’écrire en majuscule un seul événement important par post-it: « Quels ont été les événements importants pour vous sur ce projet ?
• Demander à chaque participant d’aller présenter les post-it qu’il a écrit. La consigne pour les autres est de poser des questions de clarification. En fonction, le post-it peut être réécrit pour être plus lisible pour les autres
• Demander ensuite aux participants si d’autres événements leur viennent à l’esprit à partir de ce que chacun a présenté: « Avez-vous d’autres événements qui vous viennent à l’esprit ? »
• Nettoyer la timeline et permettre aux participants de bien l’avoir à l’esprit: « Y’a t-il des événements en doublon ? », « Selon vous, est ce que les événements sont bien positionnés dans le temps ? »
• Redemander aux participants si un événement important a été oublié: « Y’a t-il un événement important qui a été oublié ? »

Conseil d’animation:

• Dans l’étape 1, vous pouvez demander aux participants de trouver 10 événements importants pour leur donner un défi et solliciter leur mémoire. Cette étape se fait en silence pour permettre plus facilement la remémorisation
• Les étapes 3,4,5 permettent « d’ancrer » la timeline dans l’esprit des participants et de solliciter leur concentration grâce à une répétition
• N’hésitez pas à demander aux participants si les post-it sont lisibles et à demander de les refaire sinon (qualité first !)
• Si vous avez des graphiques projets (burndown chart, velocity chart), il peut être pertinent de les afficher à côté de la timeline

La deuxième partie correspondant à la construction du sismographe d’énergie:

• Demander à chaque participant de prendre individuellement un temps de réflexion sur comment était son niveau d’énergie au cours du projet et visualiser la courbe
• Demander à celui qui souhaite, de commencer à tracer sa courbe d’une couleur et de mettre son prénom ou trigramme
• Puis au suivant

Une fois terminé la construction de la timeline et du sismographe, il est alors possible de retirer quelques apprentissages utiles pour d’autres projets.

Exploiter la timeline

L’exploitation de la timeline peut se faire de la façon suivante:

• Inviter les participants à se lever et parcourir la timeline silencieusement pendant quelques temps et une fois qu’ils sont prêts d’aller s’asseoir
• Faciliter une discussion autour de ces questions:
  • Quels sont les événements qui vous ont marqués ?
  • Qu’est ce qui vous surprend sur la timeline ?
  • Qu’est ce que vous a révélé la construction de cette timeline ?
  • De quels éléments souhaitez vous discuter avec le reste du groupe ?
• Après cette discussion, demandez au groupe de se répartir en 3 sous-groupes, chacun répondant à une des questions suivantes sur une feuille de paperboard en s’appuyant sur la timeline et le sismographe:
  • Qu’est ce que nous avons bien réussi ?
  • Qu’est ce que nous pouvons améliorer ?
  • Quelles recommandations pouvons nous faire à une nouvelle équipe projet qui démarre ?
• Demandez à ce qu’un rapporteur de chaque sous-groupe vienne présenter le travail
• Les autres peuvent poser des questions de clarification
• Une fois que le rapporteur a terminé, demandez aux autres participants s’ils ont d’autres choses à ajouter, les noter le cas échéant
• Passer aux autres questions

En clôture de la rétrospective, il est possible de poser deux questions à chaque participant:

• Où en êtes vous par rapport à vos attentes ?
• Quelle est la chose que vous gardez en tête et que vous allez amener dans vos prochains projets ?

Il est important de passer du temps dans la construction de la timeline pour permettre à l’équipe de se remémorer les moments importants du projet car parfois la rétrospective ne se fait pas toute de suite après la fin du projet. Il peut arriver qu’après un atelier comme celui-ci que les personnes aient l’impression d’avoir passé un bon moment et qu’à peine sorties de la salle elles oublient ce qu’elles ont pu dire. La projection dans le futur de chaque participant en clôture est une bonne pratique pour permettre aux personnes présentes de partir au moins avec quelque chose qu’elle pourra réutiliser par la suite. La synthèse écrite est faite en général par l’animateur et doit être bien sûr envoyée à tous les participants et stockée dans l’outil de Knowledge Management de l’entreprise afin de permettre une réutilisation de l’expérience acquise.

Suggestion d'articles :

1. Animer des rétrospectives d’itération
2. Comment mieux prioriser en projet agile
3. Quels sont les types de tests que l’on utilise sur un projet agile ?

La rétrospective dans les méthodes agiles est un moment important dans un projet. La rétrospective est une pratique qui permet de répondre au 12ème principe agile du Manifeste Agile: « À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ». Ritualiser cet événement permet de mettre en place un processus d’amélioration continue. Même si parfois, l’équipe a l’impression qu’il ne s’est rien passé, il s’est passé quelque chose, le plus important étant de garder cet espace de prise de recul.

Couramment, deux types de rétrospectives sont faites dans les projets agiles: les rétrospectives d’itération et les rétrospectives de release/projet. Cet article parlera des rétrospectives d’itérations et présentera 2 outils simples, le Keep Drop Start et la note d’itération.

Pour une rétrospective d’une itération de deux semaines, il est recommandé de faire une rétrospective de 2 heures, pour une itération d’une semaine, 1h.

Keep Drop Start

L’outil le plus simple utilisé pour une rétrospective d’itération est le Keep Drop Start:

Couramment, chaque participant  est invité à noter en gros et majuscule sur des post-it les choses qui lui viennent sans se brider pour chaque partie:

• Ce qui fonctionne bien, ce qu’il faut garder (Keep)
• Ce qui fonctionne moins bien, ce qu’il faut supprimer (Drop)
• Ce qui reste mystérieux
• Ce qui fonctionnerait bien si…, ce qu’il faudrait faire (Start)

Conseil d’animation:

• Si vous sentez le groupe bloqué, vous avez toujours une personne qui a plus d’idées que les autres, demandez lui de dire à voix haute quelques-unes de ces idées et d’aller les afficher
• Si personne n’a d’idées, guider les participants sur des thématiques: « réfléchissez à l’estimation, les réunions, le code, à ce qui pourrait-être améliorer ? » et tant qu’à faire sur ce que vous avez observé vous-même pendant l’itération
• L’important dans l’animation de la rétrospective est que l’équipe prenne conscience par elle-même de ses points de blocages
• Je vous conseille de finir par un vote collectif (vote par bâton ou gommette) sur les 5 grandes idées / actions pour l’itération car cela permet de mobiliser l’équipe et il est irréaliste de croire qu’une équipe puisse faire plus de 5 actions d’amélioration en 2 semaines, au moins au début
• Au bout d’un moment (3/5 itérations), vous pouvez inviter un membre de l’équipe à l’animer à votre place pour favoriser la prise d’initiative et dans l’idéal l’animateur tourne

Pièges à éviter:

• En tant qu’animateur de la réunion, vous voulez que l’équipe sorte absolument avec un plan d’actions, vous voulez alors à la place de l’équipe et donc vous la déresponsabiliser. Parfois la prise de conscience suffit à ce que les choses ne se reproduisent pas

La note d’itération

La note d’itération peut aussi être utilisée si vous avez moins de temps et pour changer. Changer d’outil peut être stratégique car il peut permettre de sortir des habitudes prises par l’équipe.

Pour la note d’itération, vous pouvez utiliser ce processus inspiré de l’approche orientée vers les solutions:

• Demandez à chacun de positionner son niveau de satisfaction de l’itération sur une échelle de 1 à 7
• A partir du niveau estimé (Ex: 4), posez la question: « Qu’est ce qui fait que tu as mis 4 ? »
• Puis posez la question: « Qu’est ce qu’il faudrait pour avoir seulement 5 (4+1) ? »

Conseil d’animation:

• Commencez par les plus discrets et silencieux car ils ont souvent une bonne perception de la situation mais ils n’ont pas souvent la parole et ne la prennent pas
• Déléguez l’écriture sur le tableau blanc à un membre de l’équipe
• Comme vous êtes dans une approche circulaire, au bout de la 3ème ou 4 ème personne, les idées commencent à devenir identiques, vous pouvez alors inviter les prochains à annoncer ce qui est différent de ce qui a déjà été dit

Pièges à éviter:

• Discuter/Contredire ce que dit un participant, ceci aurait pour effet de brider ce que pourrait dire la personne

De rétrospectives en rétrospectives

Je constate souvent que les équipes agiles oublient ce qui s’est passé dans les rétrospectives précédentes, une sorte de perte de mémoire qui fait que rien ne se passe hormis le fait que tout reste pareil. La rétrospective est alors une sorte de bureau des plaintes où chacun exprime ses peurs, ses reproches, pour que tout fonctionne comme avant. Sommes-nous dans une approche d’amélioration continue ? pas si sûr.

En tant qu’animateur, que faire avec ça ?

• Attendre. Pas d’actions, pas de réactions dans une rétrospective, ce n’est pas si grave quand cela arrive 1 ou 2 fois. Laisser l’équipe dans son jus a du bon pour la responsabiliser
• Demander au groupe quelles sont les actions qui avaient été décidées la dernière fois
• Se focaliser sur une action et aller chercher chaque étape en détail
• Faire un atelier pour sortir l’équipe du rituel rétrospective et faire un travail de fond
• Questionner le groupe sur les avantages pour lui de faire une rétrospective ou mieux avec une approche paradoxale: quels seraient les bénéfices de ne plus faire de rétrospective ?
• Provoquer le groupe: « Je pense qu’il est temps d’arrêter de faire des rétrospectives » accompagné d’un silence en espérant une réaction et qu’un leader va émergé… c’est un peu du quitte ou double

Il est courant de croire que la rétrospective est le seul moment où l’on puisse faire de l’amélioration continue. Dans la réalité, il est possible d’introduire des feedbacks de 10 minutes en fin de chaque réunion pour habituer l’équipe à se responsabiliser sur son fonctionnement.

L’amélioration continue est une approche de petits pas qui visent à ancrer un niveau supérieur dans une roue dentée. Il est clair que parfois cela ne suffit pas, même pire cela renforce le non changement d’une équipe, il faut alors envisager d’autres façons de faire, en rupture, qui demandent beaucoup plus de doigté car déstabilisantes pour une équipe.

Suggestion d'articles :

1. Animer une rétrospective projet
2. L’artefact ne fait pas le moine
3. Espace détente

En 2007 ITIL (IT Infrastructure Library), a lancé sa version V3 en devenant le référentiel le plus répandu de bonnes pratiques pour le management de services informatiques (ITSM). Il se focalise sur le « comment » gérer chaque phase d’un service, en contraste par rapport à des autres référentiels qui se focalisent sur le « quoi », ce qu’on doit gérer.

ITIL v3 élargit le périmètre en donnant une vue “cycle de vie” des services, par rapport à sa deuxième version (v2) qui se focalisait sur les processus pour le Soutien de Services (Service Support) et la Fourniture de Services (Service Delivery)[i],

Cet article vous présente d’une façon globale ITIL à l’égard de la version 3 en montrant son but, les bonnes pratiques proposées pour gérer chaque phase d’un service et ce dont il faut tenir compte pour l’adoption de ce référentiel.

Tout d’abord, qu’est-ce que c’est un service ?

ITIL entend par service « l’ensemble des moyens mis en œuvre pour produire de la valeur pour un client, sans que celui-ci n’en supporte ni les coûts spécifiques et supplémentaires ni les risques associés ». En conséquence, une relation client-fournisseur est établie, le fournisseur du service pouvant être interne ou externe à l’entreprise. Pour illustrer l’idée d’un service, voici une liste de services :

• Services d’hébergement (applications, bases de données, sites internet, …)
• Service de support et maintenance applicatif
• Services de messagerie (Email, chat, …)
• Service de connectivité (internet, vpn, …)
• Service de vidéo conférence et de téléphonie
• …

Pour quoi un référentiel sur le management de services informatiques ?

Les DSI et les fournisseurs de services externes doivent :

• Fournir des services à valeur ajoutée au métier
• Rendre un service de qualité en respectant les contrats de service et les coûts
• Augmenter la flexibilité et la rapidité du système pour intégrer les mises à jour des services existants et la mise en place de nouveaux services, tout en sécurisant l’existant

Pour atteindre ces objectifs il faut mettre en place une organisation horizontale de collaboration entre les différents acteurs (clients, métier, conception, développement, exploitation, qualité,…).

ITILv3 cherche à vous aider à assurer ce rôle de fournisseur de services d’une façon efficace et il vous fourni de bonnes pratiques pour savoir:

• Comment créer et gérer un portefeuille de services ?
• Comment concevoir des services qui donnent de la valeur (alignement métier-SI)?
• Comment améliorer et sécuriser les mises en production de nouveaux projets et de changements tout en préservant l’existant ?
• Comment traiter plus efficacement les incidents, événements et les problèmes dans le SI ?
• Comment gérer les changements des actifs et les configurations?
• Comment mettre en place des mesures et des indicateurs dans les processus de la DSI pour améliorer la gouvernance ?
• Comment assurer la disponibilité, la continuité, la sécurité, la capacité et la fiabilité de services ?
• Comment formaliser les compromis client-fournisseur et comment on définit des contrats de niveaux de service (SLA ou Service Level Agreements), contrats de niveaux d’exploitation (OLA ou Operational Level Agreements) et contrats de sous-traitance (UC ou Underpinning Contracts) ?
• Comment mettre en place une amélioration continue des services ?
• …

Alors ITILv3 vous propose :

• Un découpage du cycle de vie d’un service en 5 phases :

  

  Image 1.  Phases du cycle de vie

  Stratégie de services :

  Transformer le SI en un actif stratégique de l’entreprise en identifiant les besoins des clients pour définir les services qui produisent de la valeur et que respect le coût de fourniture. Il se traduit par la construction d’un portefeuille de services.

  Conception de services :

  Concevoir un service en prenant en compte tous les éléments liés au development et á l’exploitation. La solution doit réponde aux attentes du client, aux niveaux de service engagés et à ce qu’ils soient en phase avec la capacité de l’infrastructure et l’architecture du SI.

  Transition de services :

  Mettre en place de nouveaux services et de mises à jour dans un environnement de production d’une façon sécurisée et effective en préservant la bonne exploitation du système.

  Exploitation de services :

  Assurer la bonne fourniture du service aux utilisateurs en respectant les niveaux de services engagés. Assurer le monitoring du service, la bon gestion des incidents et des problèmes ainsi que le traitement de demandes de services et d’accès.

  Amélioration continue de services :

  Mesurer et suivre les différents processus de gestion de services pour aider à définir les actions correctives afin d’améliorer les services existants et son alignement avec les objectifs stratégiques.

• Une mise en place de processus standard pour chaque phase du cycle de vie et la création de 4 fonctions ou unités fonctionnelles:

Image 2.  Processus et fonctions ITIL v3

• Une définition des activités et interactions par processus

Image 3. Activités du processus de gestion des événements.

• Une définition de rôles et responsabilités par processus (Matrice RACI)

• Une définition de mesures et indicateurs par processus (KPI)

Ne pas oublier !

Si vous voulez implémenter ITIL dans votre organisation n’oubliez pas :

• De définir les objectifs organisationnels. L’objectif ne peut pas être « mettre en place ITIL », cette démarche doit répondre à un besoin d’amélioration dans l’organisation.
• De former et sensibiliser les acteurs pour que tout le monde soit familiarisé avec les termes, les objectifs et les gains qui emporte la démarche. ITIL implique un changement organisationnel et culturel au sein de l’entreprise donc il peut être difficile à implémenter si tout le monde ne partage pas la même vision.
• D’analyser votre organisation actuelle et identifiez le GAP qu’il y a par rapport aux meilleures pratiques pour identifier où ITIL peut vous aider.
• De définir une roadmap par phases en priorisant les processus qu’à la fois vous donne plus de valeur (pour atteindre les objectifs définis) et qui sont plus simples à mettre en place. Ne pas faire un « Big Bang ».
• De mesurer dès le début! La seule façon de savoir si vous atteignez les objectifs est de définir des indicateurs et mesures qui vous indiquent le progrès et la performance de vos processus.
• De mettre en place un cadre d’amélioration continue. Les processus ont besoin d’évoluer, d’être ajustés et d’être optimisés à travers le temps pour qu’ils soient bien adaptés spécifiquement à chaque organisation et qu’ils accompagnent les évolutions métier.

Complémenter ITIL

ITIL peut être complémenté et peut cohabiter avec des autres référentielles comme COBIT, ISO 27002, CMMI, etc. Des autres méthodologies comme le Lean peuvent encore améliorer les processus qui ont été mise en place (Lean-ITIL)[ii]. Un seul référentiel ne fait pas tout et même si dans sa version 3, le périmètre d’ITIL a été élargi, il ne couvre pas tous les aspects de la gestion informatique.

En conclusion

ITILv3 propose de bonnes pratiques pour comment gérer chaque phase du cycle de vie de services et pour faire collaborer d’une façon organisée tous les acteurs en mettant en place de processus et de responsabilités. D’après des études[iii] on a pu constater que cette démarche permet aux fournisseurs de services (internes ou externes) d’améliorer la qualité dans la fourniture de services et la satisfaction du client. Il permet aussi l’alignement métier avec l’identification et la mise en place de nouveaux services qui donnent de la valeur.

Le principal obstacle pour son adoption est qu’il doit faire face à la résistance aux changements organisationnels[iv]. Risque majeur des échecs qui peut être maitrisé avec la formation, la sensibilisation ou la certification[v] des acteurs au référentiel pour les aligner sur les buts et les bénéfices qu’ITIL peut apporter.

Il a été adopté par des entreprises comme NASA, HSBC, IBM, Telefonica, HP, BT entre autres et ses pratiques son le pilier pour acquérir la certification de l’organisation dans le standard ISO/IEC 20000[vi]. Ils existent beaucoup des sites web[vii] où on peut approfondir sur le contenu et le détaille de chaque phase et processus en plus des ouvrages officiels publiés par son organisme créateur l’office du commerce britannique (OGC).

Suggestion d'articles :

1. ITIL : Information Technology Infrastructure Library
2. La gestion des processus IT
3. Autres standards de gestion des processus IT

Thoughtworks, le cabinet de conseil spécialisé dans les pratiques de développement agile et XP, faisait figure de pionnier de l’intégration continue lors de la sortie de leur outil d’automatisation de build CruiseControl il y a quelques années.
Cependant, la concurrence fut rude ces dernières années, notamment grâce à Hudson ou TeamCity, et CruiseControl apparaît aujourd’hui comme un outil fonctionnel mais sans plus.

La réponse de Thoughtworks ne s’est pas faite attendre longtemps: la sortie de Go, un outil de gestion du cycle de vie des applications exprime leur volonté de remplacer leur outil historique CruiseControl et de passer de l’intégration continue au déploiement continu ou continuous delivery: déploiement continu dans tous les environnements, y compris la production.

Nous allons aborder dans cet article ce qui caractérise cet outil, ses points forts et ce qu’on aurait aimé y voir.

Formalisation et personnalisation du processus de production de logiciel

Go permet de formaliser et manipuler des concepts importants dans le cycle de vie d’un logiciel. Voici une capture d’ecran de Go avec les différentes notions formalisées :

Typiquement, la notion de pipeline: une suite d’étapes correspondant à un maillon dans la chaine de la fabrication d’un logiciel, en général constitué des étapes de compilation + tests unitaires + déploiement sur un environnement de test. Les tests fonctionnels d’acceptance peuvent correspondre à un autre maillon de cette chaîne. Le lancement des tests de performance et le déploiement en pré-production ou en production peuvent constituer d’autres étapes.

Le schéma ci-dessous permet de faire un zoom sur le pipeline de tests d’acceptance :

Go propose en outre de gérer les dépendances entre pipelines. Cela permet par exemple de dire que le pipeline de déploiement en production dépend du succès des pipelines de tests d’acceptance et de déploiement en pré-production. La capture ci-dessous montre trois pipelines: un contenant les tests d’acceptance, un deuxième les tests de performance et un troisième le déploiement sur l’environnement de production :

Il faut noter que Go convient aux structures multi-projets. La description d’un pipeline (adresse du gestionnaire de sources, commandes à exécuter dans chaque étape, etc.) peut être commune à plusieurs projets. Ceci permet donc une homogénéité et une mutualisation de la configuration des projets.

Les actions faites au niveau de chaque étape d’un pipeline, appelées stages, peuvent notamment être exécutés par des scripts shell, .bat, ant, rake ou makefile. On regrettera le manque de support de Maven mais Thoughtworks ne l’exclut pas pour les versions à venir. On devra en attendant écrire des scripts qui lanceront les commandes Maven…

Formalisation de la notion d’environnement

C’est un des principaux atouts de l’outil. En formalisant la notion d’environnement, avec pour chacun sa fonction (dev, UAT, Pre-Prod, Prod, etc.) et les ressources dont il dispose, il permet une vision globale du processus de production: quelle version du logiciel est déployée dans quel environnement à quel moment?
Cette vision claire facilite le passage d’un environnement a un autre, avec un simple clic. Il faut tout de même noter que cette vision des environnements est disponible uniquement dans la version Entreprise, ce qui limite fortement l’intérêt de la version communautaire.
Les différences entre les deux éditions sont exposées dans ce tableau :

Parallélisation des tests avec la notion d’agents et de jobs

La parallélisation est une fonctionnalité incontournable aujourd’hui pour un outil d’intégration continue. Ici, elle s’implémente avec des agents et des jobs. Un job est une unité de travail indivisible. Un pipeline est une suite de stages eux-mêmes composés de jobs parallélisables. Les agents s’approprient des jobs en s’adressant au serveur principal, et les exécutent.

Aucune intelligence cependant n’est à attendre de la part de l’outil en ce qui concerne la parallélisation des jobs en général et notamment des tests. Si on veut paralléliser des tests, on doit lancer chaque test sur un job séparé et ainsi ils seront parallélisés de fait. Cela reste donc possible mais fastidieux.

Conclusion

Avec Go, Thoughtworks rattrape le retard accumulé, et formalise des notions que sont les environnements, le déploiement continu, les pipelines de build, etc. Un des avantages non cités de l’outil est son ergonomie, sa vision globale des environnements, des ressources et des versions déployées à tout moment et son niveau d’industrialisation qui conviendra aux contextes multi-projets. Go vient combler un vide et répondre à un vrai besoin.

Cerise sur le gâteau, la documentation est très complète et Thoughtworks organise des sessions de formation régulièrement : http://www.thoughtworks-studios.com/webinars.

Suggestion d'articles :

1. 5 bonnes raisons de déployer en continu
2. Automatiser le deploiement over the air
3. Déploiement d’une application sur l’infrastructure AMAZON (3/3)

OCTO organise un petit-déjeuner avec Danone et Open ERP sur le thème « Agilité et ERP » le mardi 22 mars 2011 de 9h à 11h à l’atelier BNP Paribas.

Vous pouvez vous inscrire directement sur notre site internet.

Suggestion d'articles :

1. OCTO organise un petit-déjeuner Gestion des Identités le 27 janvier – Témoignage d’Air Liquide
2. Petit-déjeuner OCTO « SI et Innovation métier », le 24 mars avec Generali
3. Vidéo du petit-déjeuner NoSQL : « l’Extreme Transaction Processing » devient une réalité

Y’a-t-il une clinique dans votre société ?

Est-ce que votre patron, comme dans le film Inception, lance une extraction pour vous récupérer en mission ?

En fin de réunion, organisez-vous un ROTI avec les participants ?

Un One on One avec votre manager relève-t-il nécessairement du harcèlement sexuel ?

« Typiquement » est-il réellement le mot le plus prononcé par les informaticiens ?

Une aventure collective : un livre, des auteurs

Partageons ce qui nous départage est un ouvrage collaboratif, écrit par une trentaine d’OCTOs, sur les petites recettes et les meilleures pratiques qui font la différence au quotidien, au sein-même de notre société et également chez nos clients. Et qui répond, accessoirement mais non sans humour, à ces multiples questions liminaires.

Derrière cette idée, un OCTO – David Alia – qui a endossé la double casquette de rédacteur en chef et de responsable de ce projet fédérateur. Ensemble, ces OCTOs ont  relevé le défi d’écrire un livre en moins de 3 mois… ou presque.

Collaboratif, ce bouquin l’est génétiquement puisqu’il permet, grâce aux flashcodes ingénieusement disséminés tout au long de l’ouvrage, de commenter directement les articles à l’aide d’un smartphone sur le blog éponyme : www.partageons-ce-qui-nous-departage.com.

Kifomètre, ROTI, boîte à meuh, perfection games… des recettes qui fonctionnent

Attention, pas de recettes magiques : il ne s’agit nullement d’un grimoire à portée universelle. Simplement des « trucs », des idées, des valeurs dans lesquels tout un chacun puisera probablement quelque trouvaille à adapter à son contexte professionnel ou personnel.

Le kifomètre permet par exemple de prendre la température (le kif) de vos équipes, la boîte à meuh devient un moyen de cadrer vos réunions, le ROTI mesure l’intérêt porté par les participants à une réunion qui s’achève, ou encore, le Perfection Game est le protocole pour évaluer un collaborateur de manière constructive pour arriver à la copie parfaite.

Tout ce que vous lirez ici a été testé, aucun blessé n’a été répertorié : vous pouvez faire tourner.

L’ouvrage sera disponible prochainement (mi-décembre) sous format papier, aux éditions OCTO Technology.

En attendant vous pouvez le précommander en nous contactant à publications@octo.com ou partager avec nous vos bonnes pratiques directement sur le blog : http://partageons-ce-qui-nous-departage.com/ ou sur la page facebook : http://www.facebook.com/partageons.ce.qui.nous.departage



Suggestion d'articles :

1. Partageons ce qui nous départage : le livre est sorti !
2. 01 informatique enquête sur les pratiques de management chez OCTO : instaurer un rapport gagnant-gagnant
3. Mes bonnes pratiques en PowerShell v2

Dans la première partie de l’article, nous avons vu comment la supervision pouvait apporter de la valeur à court terme au SI. Dans cette seconde partie, nous verrons comment la supervision peut permettre d’établir des services répondant à des besoins à plus long terme.

Pour cela on va utiliser la supervision pour capitaliser et modéliser.

Capitaliser sur les incidents rencontrés n’amène pas forcément jusqu’à la proactivité mais :

• Cela amène à une réactivité encore plus importante : j’ai déjà rencontré ce problème, j’ai déjà la solution.
•  Cela permet de résoudre définitivement un problème : j’ai déjà rencontré ce problème plusieurs fois, j’en connais la solution réactive, je décide d’apporter la solution définitive en l’appliquant à la source.

La supervision permet de remonter un événement (un incident, une alerte) qu’il est possible de rapprocher d’un événement déjà survenu et renseigné dans une base de connaissance et dont je peux établir directement la cause pour proposer une solution. Le but est donc de capitaliser sur l’analyse post-mortem pour améliorer continuellement le système : On a trouvé la cause du mal et on sait guérir, on sait détecter les symptômes pour agir avant propagation du mal, on a trouvé le vaccin contre le mal. A ce jeu, le Lean et les 5 pourquoi sont certainement vos meilleurs alliés et des outils indispensables pour réaliser des post-mortem efficaces.

Modéliser, c’est essayer de rendre son système prédictif en construisant des abaques d’utilisation des ressources matérielles par la solution applicative. On y corrèle les temps de réponses, l’utilisation des ressources et l’activité métier au cours du temps sur la production. Là où la campagne de tests de charge permet d’identifier les évolutions matérielles nécessaires au passage d’un palier en termes de volumétrie (charge utilisateurs d’une nouvelle organisation déployée, volume de  données reprises), la modélisation, en reposant sur la supervision continue du système, va permettre d’identifier les évolutions matérielles en fonction de l’accroissement naturel de la volumétrie dans le système (nouveaux utilisateurs, volume de données créés par les interfaces) et de mesurer les impacts réels en production de nouvelles fonctionnalités dans la solution.

On définit ainsi le plan de capacité de la solution qui va permettre à un directeur informatique de mieux prévenir les besoins matériels et de concevoir son budget en conséquence en apportant les éléments de justifications à sa direction.

Ce dispositif permet également de détecter les problèmes de performance dans la solution (fuites mémoires, consommation excessive de la CPU, temps de réponses qui se dégradent…).

Le deuxième enjeu a attrait à la performance métier du SI. On l’associe souvent à la supervision de type BAM (Business Activity Monitoring) ou BPM (Business Process Monitoring). Ce sont pour moi des outils qui adressent plus une problématique métier (gestion des stocks au quotidien, détection en temps réel d’une activité anormale sur mon callcenter,…) qu’une problématique DSI (en l’occurrence montrer que l’IT répond aux exigences de performance métier).

Plutôt que de mettre de tels outils en place, il est peut-être préférable de l’intégrer dans la solution existante en écrivant les informations utiles dans les logs applicatives par exemple. Quelles sont ces informations utiles ? Des indicateurs de la performance métier du SI. Il s’agit en définitive de mesurer des métriques sur certaines activités métier clés du SI. Assez simple à réaliser dans le contexte d’un traitement batch où l’on veut savoir le nombre de produits mis à jour par exemple, plus complexe lorsque l’on veut connaître le temps moyen de souscription à un produit, transaction qui parcours notre SI du Front office jusqu’au Back office et peut traverser un serveur web, un ESB ou un EAI, un Application Server, une base de données, des firewalls…Rien d’insurmontable non plus, je vous rassure.

Ce type d’indicateurs est plus représentatif de la performance de la solution que « le temps d’accès à une page web est inférieure à 3 secondes». Il est aussi plus « parlant » quand il s’agit de s’adresser par des chiffres et des indicateurs à une direction métier.

Pour conclure, la mise en place de la supervision du SI doit apporter à une DSI un levier pour :

• Maîtriser son parc IT
• Maîtriser les investissements et les coûts de maintenance
• Assurer la qualité du service
• Etre en capacité à évoluer et à répondre aux besoins métiers
• Promouvoir l’IT auprès de la direction générale et des directions métiers et justifier les budgets

Elle repose sur la mise en œuvre :

• D’indicateurs métiers, applicatifs et infrastructures cohérents avec les enjeux business
• D’outils de surveillance, de mesure, de capitalisation et de reporting

Suggestion d'articles :

1. Vers une supervision IT de la performance métier du SI (1/2)
2. L’architecture d’entreprise : vision métier ou technologique?
3. La performance des SI