DevOps Game

Jeu DevOps Game - Vincent Daviet

Instructions à disposition, retours appréciés. English version available.
La trame et le matériel de l’atelier DevOps Game V3 (et précédentes versions) : ici, sous licence Creative Commun.

Durée : 1h30 – 2h

Joueurs : 4 à 16 participants par animateur, observateurs bienvenus.

Un jeu de mise en production – accessible à tous (non technique)
Vous construisez des logiciels ? Vous avez des équipes de build (devs) qui réalisent en permanence de nombreuses fonctionnalités ? Vous avez des équipes d’exploitation (ops) qui cherchent en priorité à maintenir un système stable et disponible, et par conséquent à réduire l’introduction de nouveautés ? Ce jeu est fait pour vous !

Venez (re-)découvrir par vous même les réponses à ces questions, à travers un jeu de construction par itération :

  • Comment mieux collaborer ?
  • Comment concilier des objectifs qui paraissent opposés ?
  • Et concrètement quelles pratiques mettre en place ?

Vous expérimenterez comment transformer 2 grandes équipes avec 2 grands objectifs : maximiser les fonctionnalités VS maximiser la disponibilité du système. Serez-vous capable d’en faire 1 seule équipe avec 1 objectif suprême : le maximum de valeur pour vos utilisateurs ?

Une rétrospective sur les principes DevOps (culture, partage, automatisation, excellence technique, mesure), et les parallèles avec nos projets professionnels clôtureront l’expérience.

Feedbacks
De très bons retours après plusieurs sessions en entreprises et en conférences.
Et vous qu’en avez-vous pensé ?

commentaires
  1. Serge HARDY dit :

    Bonjour Vincent et merci beaucoup pour la mise à disposition de ce jeu.

    Après essai avec quelques comparses, il nous a manqué quelques éléments de compréhension dans la notice pour en tirer pleinement bénéfice.

    Voici la liste des points en suspens:

    – d’une itération à l’autre, les réalisateurs reprennent-ils le contenu de la production?
    – d’une itération à l’autre, les opérateurs reprennent-ils le socle d’origine?
    – d’une itération à l’autre, que fait-on des fonctionnalités non implémentées?
    – l’environnement de livraison ne devrait-il pas plutôt s’appeler « préproduction »? Par livraison on s’attend peut-être à avoir une notion de livrable packagé, or là il est déployé
    – qu’est ce qu’une « face »? le dessus peut-il être une face?
    – le socle compte-il dans la réalisation, fait-il donc partie de la « face »?
    – qu’est-ce qu’un « étage »? est-ce l’épaisseur d’une ou deux briques?
    – les tests de charge doivent-ils être effectués sur la « livraison » pour être acceptés?
    – « une seule main », est-ce une seule personne, ou une seule personne à la fois, ou autre?

    Merci d’avance pour les réponses!

    Serge

    • vincentdaviet dit :

      Bonjour Serge, bravo pour ta première partie ! Et merci ton retour qui va contribuer à l’amélioration du jeu.

      – oui, les réalisateurs reprennent le contenu de la production,
      – non, les opérateurs repartent du dernier socle de production,
      – les fonctionnalités non implémentées sont laissées dans la colonne « A faire » et peuvent être sélectionnées plus tard dans les itérations à venir,
      – en effet, la remarque est juste, « préproduction » pourrait être plus pertinent car en effet il s’agit bien déjà d’un premier déploiement,
      – une « face » est un des côtés de la tour (le dessus n’en est pas une),
      – non le socle ne fait partie de la « face »,
      – 1 étage = 1 épaisseur de brique,
      – non, les tests de charge sont faits sur la « production »… sauf si les réalisateurs demandent à tester plus tôt,
      – « une seule main » = une seule main d’une seule personne (sans aucune autre aide)

      Bien à toi.

  2. ouelcum dit :

    Merci pour ce billet Vincent, j’ai une question concernant les instructions après une lecture rapide du descriptif, dans l’idée, c’est plus comment construire/poser les pièces une par une en prod, ou comment déplacer la structure de dev en prod ?

  3. ouelcum dit :

    en relisant, la question n’est pas claire, elle concerne les « instructions » ou la « doc d’installe » que donne les devs aux ops 🙂

    • vincentdaviet dit :

      Laurent, la « doc d’installation » donné par les Devs aux Ops contient les instructions sur la manière de prendre, déplacer, reposer la structure depuis la plateforme physique de dev jusqu’à la plateforme physique de prod.

  4. ouelcum dit :

    je me suis posé la question si l’option donner un procedure pour constuire la structure etait en prod. Dans le document c’est bien marqué « déplacer », mais du coup, je me suis demandé si un groupe me proposer X déplacement dans une doc, si je les laisser faire ou pas. Dans l’esprit Devops cela me semble bien, par contre, coté sensibilisation aux problèmes, un peu moins
    .

  5. ouelcum dit :

    J’ai joué le jeu avec les collègues, pour simplifier un peu, on a réduit un peu le rôle de l’équipe « ops », et allongé un peu la durée des itérations pour éviter trop de frustration sur la construction.
    Du coup, cela peut déjà faire un bon exercice de sensibilisation auprès des devs.

  6. DENEUX dit :

    Bonjour,
    le lien vers les instructions ne fonctionne pas …
    Merci

  7. Sylvain CHERY dit :

    Bonjour,
    Nous venons de tester le jeu en interne et nous en avons apprécié l’esprit et la structure. Le seul bémol est que les OPS ne semblent pas réellement préoccupés par la stabilité de l’environnement de production, car les défis qu’ils ont à réaliser sont assez étranges de ce point de vue (2 briques croisées sur la tranche, socle avec moins de briques…).
    Cependant nous avons eu un peu de mal à saisir les instructions dans le détail… Les précisions déjà apportées ci-dessus seront utiles.
    Voici d’autres questions :
    – Est-ce que ce sont les DEV qui livrent en environnement d’installation (ou renommé environnement de préproduction) ? et les OPS qui installent en Production ?
    – le timing d’une itération n’est pas clair, en particulier l’itération 1
    – qui est chargée de la validation (secouer) ?
    – qu’est-ce que la doc d’utilisation demandée aux OPS est censée expliquer ?
    – itération 3 : est-ce que les DEV repartent de la tour livrée à l’itération 2 (ils doivent alors la retirer de l’environnement de Production pour la modifier) ?
    – tableaux de suivi : si une carte n’est pas validée elle retourne dans la colonne « à faire » ?
    – tableau de bord DEV : si la tour s’effondre lorsqu’on la secoue, quel impact sur les points ?
    – tableau de bord OPS : quel est l’impact du nombre d’anomalies sur les points cumulés ?
    Je serais intéressé pour échanger directement avec vous sur le jeu, notamment pour contribuer à une v3, n’hésitez pas à me contacter.

    • vincentdaviet dit :

      Bonjour, super nouvelle. Faites-vous partie des équipes qui l’ont traduit en anglais et joué hier sur Grenoble ?
      Avec plaisir pour prendre votre contribution à une future V3. 🙂
      Voici des éléments de réponse.
      – Oui, les DEV livrent sur l’Installation et les OPS sur la Production.
      – 2 minutes de Réalisation et 2 minutes d’Installation (parfois je laisse plus de temps à la 1ère itération).
      – L’animateur est chargé de la validation (secouer).
      – La doc demandée aux OPS explique comment utiliser le nouveau socle créé.
      – Itération 3 : oui, les DEV repartent de la tour livrée à l’itération 2
      – Tableaux de suivi : oui, une carte non validée retourne dans « à faire ».
      – Tableau de bord DEV : si la tour s’effondre lorsqu’on la secoue, les DEV marquent 0 point et les OPS ont la pénalité « échec d’installation » de -1000 points.
      – Tableau de bord OPS : une anomalie = une carte refusée, pas d’impact pour les points OPS mais impacte les points DEV.

      • sylchery dit :

        Bonjour, nous avons joué le jeu au Luxembourg. C’est intéressant de savoir qu’une traduction anglaise est en cours ; là aussi nous pouvons aider si besoin. Pour contribuer à une future V3, dans un premier temps je pensais incorporer les précisions apportées en Q&A sur le blog directement dans la documentation. A vous de voir…
        N’hésitez pas à me contacter en direct via LinkedIn
        Cdlt,

  8. Alain Sacquet dit :

    Bonjour

    De quel type de licence creative common s’agit -il ?

    Computer Associate utilise en effet également un jeu de rôle DevOps pour évangéliser son marcher…

    C’est très intéressant et je pense m’en servir dans une version peut être simplifiée.

    Je vous tiens au courant.

    Alain

    • vincentdaviet dit :

      Bonjour,

      Vous pouvez réutiliser le jeu à titre commercial et le modifier tant que vous citez la source et l’auteur.
      Je suis intéressé par des pistes de simplification. 🙂

      Bien cordialement,
      Vincent

  9. Thierry de Pauw dit :

    Bonjour,

    Tout d’abord merci de mettre ce jeu à disposition !

    Je teste le jeu en utilisant des briques Kapla à fin d’éventuellement l’utiliser pour un workshop DevOps. J’aime beaucoup le concept.
    Pendant mes testes je me suis posés quelques questions:
    – Le socle de base pour les Ops pendant l’itération #1 est bien: 2 carrés super-posés avec une croix au dessus (2 deux briques en diagonales). C’est bien le but que le socle de production ne soit pas très stable pour recevoir la construction des Devs ?
    – Est-ce que pendant l’itération #1 les Devs sont sensé avoir un socle (pré-production) pour leur réalisation ? Ce n’est que dans l’itération #3 que l’on parle d’une pré-production pour les Devs.
    – Est-ce que ce sont les Ops qui viennent prendre la réalisation des Devs et qui l’installent en production ?
    – Si ce sont les Ops, pourquoi doivent-ils rédiger un manuel d’utilisation pour les Devs dans le Défi #1 ?
    – Ou est-ce que les Devs livrent leur realisation ?
    – Défi #2 « socle en production avec le moins de briques possible »: est-ce que cela veut dire que le socle ne consiste plus que d’un seul carré (4 briques) voir de 2 briques en parallèlles ?
    – Défi #2 « les Devs livrent à une seule main »: c’est comment l’astuce pour livrer à une seule main (j’ai beau cherché, je manque de créativité à parement 😉 ) ?

    Merci d’avance pour ton temps.

    Bien à toi,
    Thierry

    PS: Si j’utilise le jeu, je planifie de le traduire en anglais. Bien sûr je t’enverrai la version anglaise.

    • vincentdaviet dit :

      Bonjour Thierry, je partage ma réponse par email sur le blog :

      – Oui c’est bien le but que le socle de production ne soit pas très stable pour recevoir la construction des Devs.

      – Est-ce que pendant l’itération #1 les Devs sont sensé avoir un socle (pré-production) pour leur réalisation ?
      > Ils peuvent le faire s’ils en ont l’idée. Sinon l’animateur l’introduit dans l’iteration 3.

      – Est-ce que ce sont les Ops qui viennent prendre la réalisation des Devs et qui l’installent en production ?
      – Ou est-ce que les Devs livrent leur realisation ?
      >Les devs livrent sur la feuille environnement de livraison. Les ops font le mise en production en prenant la construction pour la déposer sur la feuille environnement de livraison.

      – Si ce sont les Ops, pourquoi doivent-ils rédiger un manuel d’utilisation pour les Devs dans le Défi #1 ?
      > Ils expliquent aux devs comment utiliser le nouveau socle.

      – Défi #2 « socle en production avec le moins de briques possible »: Cela veut dire que par exemple le socle ne consiste plus que d’un seul carré (4 briques) voir de 2 briques en parallèlle.

      – Défi #2 « les Devs livrent à une seule main »: c’est comment l’astuce pour livrer à une seule main ?
      > Très peu de briques construites. Ou Utiliser un support comme un plateau. Ou alors ne pas retenir cette option.

  10. elannema dit :

    Merci Vincent pour ce partage.
    J’ai récemment joué à ce jeu pendant un meetup « Agile playground » et c’était très sympa. Nous n’avons malheureusement pas pu creuser l’aspect pédagogique mais nous avons passé un bon moment.

  11. Bonjour Vincent,
    Nous apprivoisons votre jeu à Montréal, auriez-vous une vidéo sur le déroulement de votre jeu pour avoir un apercu complet des sprints ?
    Merci !

Laisser un commentaire