Open Space Technology des User Groups de Lyon

Jeudi 7 juillet 2011 s’est tenu le tout premier Forum Ouvert des « User Group » de Lyon. L’objectif était simple : rapprocher toutes les communautés technologiques de Lyon. Pari réussi ! Une quarantaine de participants ont répondu présent. Java, Agile, Microsoft, Ruby, PHP, Flex, Javascript, tous les représentants des associations locales se sont réunis à l’INSA pour se connaître, échanger, apprendre. Retours sur cette soirée.

Auto-organisation et Open Space Technology

Impulsé par le Microsoft User Group, organisé par le Lyon Java User Group et animé par le Club Agile Rhône Alpes, cette soirée se voulait simple aussi bien dans la logistique que dans le format pour permettre à chacun de se rencontrer et surtout de se mélanger. On a donc opté pour le format Open Space Technology qui favorise l’implication des participants car ce sont eux qui font le programme au démarrage de la soirée.

L’introduction démarre par la présentation au cercle des participants de la Loi des 2 pieds et de ses 4 principes :

  • Les personnes qui sont là sont les bonnes personnes
  • Quoi qu’il arrive, c’est la seule chose qui pouvait arriver
  • Quand ça commence, c’est que c’est le bon moment pour commencer
  • Quand c’est fini, c’est fini

L’invitation est ensuite lancée au cercle de proposer des sujets d’atelier. Les premières personnes se jettent à l’eau, rentrent dans le cercle, expliquent en quoi consiste leur thème et l’accrochent au mur. Après 30min, une quinzaine de sujets sont affichés. C’est le temps de la sélection et de la planification. Au programme, 3 tracks d’atelier, et non on ne pourra pas tout voir !

Atelier #1 : DevOps

Des développeurs, des architectes, des chefs de projet, tous réunis avec des implications projet très différentes et une attente commune : comprendre ce qui se cache derrière ce terme qui fait beaucoup parler de lui en ce moment.

Cette hétérogénéité des profils et des expériences aura permis de soulever de nombreuses questions

  • En quoi DevOps adresse les problèmes de production ?
  • Est-ce une méthode ?
  • Quels sont les outils ?
  • Quels sont les retours d’expérience ?
  • Est-ce que DevOps rime avec « amélioration de la qualité de service » ?
  • Comment gérer la communication une fois l’application en production ?
  • Quelles sont les métriques ?
  • Comment remonter l’information de la production au développement ?
  • Quel solution pour le monitoring technique et fonctionnel de l’application ?

Les réponses apportées

  • Une première définition de DevOps est donnée : décloisonnons les services informatiques ! qui sont globalement désynchronisés au niveau des outils et qui ne partagent pas le même vocabulaire
  • DevOps s’appuie sur les méthodes agiles (voire Lean) et quelques outils comme puppet ou CFEngine sont de très bons supports
  • Le monitoring technique est possible par JMX ou SNMP
  • DevOps vise à faire travailler les équipes ensemble : les développeurs devraient être formés à la production, les fonctionnels devraient être formés au développement et ainsi de suite. A ce sujet, l’exemple du circuit d’intégration chez Michelin a été cité (chaque nouveau collaborateur chez Michelin démarre en effet par passer par les étapes de la chaîne de production afin de mieux comprendre le métier de l’entreprise)
  • Il faut prendre en compte dès le début du projet les problématiques de déploiement continu, de cache applicatif et de provisionning automatique
  • Même si Maven ne peut pas se revendiquer d’être au niveau DevOps, c’est un bon outil
  • DevOps c’est l’industrialisation des processus informatiques poussée au maximum. Plus les organisations sont grandes, plus cette industrialisation sera dure et longue à mettre en place
  • Pour adapter DevOps à son contexte, il faut être fainéant en supprimant les tâches manuelles. Quelles sont les opérations que mon équipe ne veut plus faire ? Vous avez trouvé ? Alors c’est certainement par là qu’il faut commencer. Vous investirez ainsi votre énergie sur des chantiers qui ont plus de valeur ajoutée pour vous et l’organisation
  • Lors de la conception des projets, intégrer les exigences d’exploitabilité au même titre que les autres (sécurité, performance, robustesse, utilisabilité, etc.)
  • Le chemin vers l’industrialisation nécessitera de revoir les responsabilités et les rôles de certains membres de l’équipe. La conduite du changement doit être envisagée pour supporter l’adoption à cette nouvelle organisation
  • Intégration continue + dimension sociale = industrialisation de toute la chaîne

A l’écoute de tout ce qui a été dit, le sujet DevOps est bien plus large qu’il n’y parait et adresse des problématiques d’ordre organisationnel, métier, applicatif et technique. Il n’y a donc pas d’approche générique car les contextes sont très différents. A défaut d’apporter des réponses, cet atelier d’une heure a permis de poser un périmètre clair sur un sujet qui restait jusque-là assez flou. A chacun maintenant d’adapter DevOps à la réalité de son environnement.

Atelier #2 : Comment travailler efficacement en Open Space ?

Sujet croustillant et éternellement d’actualité pour tout ceux qui sont (ou ont été un jour) sur un plateau. Sur le même rythme que l’atelier précédent, les idées fusent. On y parle

Avantages

  • Les échanges, la communication
  • Parfois un Open Space est calme
  • L’équipe est localisée et disponible
  • Tout le monde peut profiter des discussions sur des sujets très variés
  • Une personne dérangée est valorisée car elle perçue comme référente sur le sujet
  • L’Open Space offre un vrai choix de communication

Inconvénients

  • On a parfois besoin de s’isoler
  • Le bruit (ceux au téléphone, ceux qui parlent fort naturellement ou pire, ceux qui s’interpellent à 10m de distance)
  • Rester vigilant à l’aménagement de l’espace
  • Fluctuation entre calme et tempête, ça dépend des moments de la journée
  • On est souvent dérangé, la concentration est difficile (les populations non techniques se rendent peu compte du niveau de concentration requis pour une production optimale)
  • L’impression d’être surveillé (l’écran est toujours visible)
  • Il existe une taille critique à partir de laquelle la communication se dégrade
  • Distraction facile

Des idées pour améliorer les conditions de l’Open Space

  • Définir des échelles de communications pour apprendre à utiliser à bon escient l’oral, la messagerie instantanée et le mail
  • Etre en télé-travail mais tous les échanges sont principalement par messagerie
  • Quand on met son casque sur les oreilles (voir son casque anti-bruit) c’est qu’on ne veut pas être dérangé (même si certains brisent cette règle, elle reste globalement efficace)
  • Préserver les espaces privés par l’installation, par exemple, d’une cloison dans le dos pour éviter la sensation d’être épié en permanence
  • Il existe des normes définissant les espaces de travail
  • L’organisation de l’Open Space doit être revue périodiquement pour favoriser l’intégration des nouveaux collaborateurs et les anciens
  • N’avoir que des espaces dédiés aux équipes projet
  • Les « habitants » de l’Open Space pourraient s’accorder sur une charte d’usages

Des questions ouvertes

  • Comment organiser l’espace-temps d’un Open Space pour aménager des périodes où on peut être dérangé et d’autres où on reste concentré ?
  • Comment être critique envers le comportement des autres dans l’Open Space sachant, qu’à un moment, on fera également du bruit  ?
  • Est-ce qu’on ne doit pas finalement accepter la contrainte de disponibilité dans un Open Space ?
  • Faut-il privilégier la communication ou la production ? (voir à ce sujet le blog de Joel on Software)

Atelier #3 : Marshmallow Challenge

Un classique des Serious Games qui amène toujours son lot de surprises. 18 minutes pour construire une tour de spaghettis. Simple me direz-vous ? Et pourtant … Entraînez-vous à ce jeu avec vos équipes, tous les participants en tireront de riches enseignements sur leur façon d’aborder les projets. Pour ceux qui ont déjà fait le jeu, chut ! attendez les 18 minutes avant de donner la solution 🙂

Rétrospective : les +

  • La qualité des échanges
  • L’ouverture d’esprit de tous les participants
  • L’organisation et le format de la soirée, légers, simples et efficaces
  • Le soutien de l’INSA (et spécialement Julien Ponge), toujours présent quand il s’agit de prêter ses locaux pour les associations

Rétrospective : les –

  • Améliorer le discours d’ouverture & la présentation de la loi des 2 pieds et de ses 4 principes
  • Ne pas oublier des instructions pour les participants (par exemple les pauses)
  • Récupérer les adresses mails de tout le monde pour une prochaine session
  • Améliorer la phase d’organisation de l’agenda après les soumissions d’ateliers par les participants

Conclusion

La richesse de cette soirée tient à l’implication des participants et la qualité des sujets abordés, actuels et nécessaires. Chaque atelier permet de brasser une multitude d’idées et ouvre encore plus les perspectives sur nos problématiques quotidiennes. Une soirée intense, j’en suis sorti épuisé mais ravi, on en redemande !

Des liens pour aller plus loin

Le site de l’organisation de la soirée
La galerie de photos

Open Space Technology

Les sites des associations représentées

LinkedInBufferViadeoEvernote
Ce contenu a été publié dans Agile, Communautés, Forum Ouvert, Web, avec comme mot(s)-clé(s) , , , , , , . Vous pouvez le mettre en favoris avec ce permalien.

Une réponse à Open Space Technology des User Groups de Lyon

  1. Ping : BarCamp Tech Lyon : un événement VIP en forum ouvert « Opensource et médias sociaux

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *