Gestion de projet avec Gitlab

Ces derniers jours nous avons utilisé Gitlab pour gérer nos projets.

Cette nouvelle approche permet au codeur d’être à la fois plus rigoureux dans la façon d’écrire son code mais aussi de monter en compétence car chaque ligne de code que vous écrivez sera relu et analysé par un autre membre de votre équipe.

Au niveau de l’équipe, cette gestion de projet permet de travailler ensemble et de façon asynchrone sur une même étape importante du projet (Milestone/Iteration).

L’énorme avantage de cette approche est de pouvoir créer, attribuer et gérer des taches qui sont intimement liées au code du projet. C’est à dire de créer une tâche, l’attribuer à un codeur et la lier de façon quasi automatique à une branche de travail. Le codeur pourra ainsi travailler sur cette tâche sans gêner ou ralentir ses collègues, même si ils travaillent sur des parties de code extrêmement proches.

 

LES ISSUES

Sur le même modèle qu’un KANBAN, les issues sont les tâches a faire.

Elles peuvent être attribuées à une ou plusieurs personnes.

Différents Labels (statuts) peuvent leur être assignés, Open, To Do, Doing, Review et Closed

Dans chaque issue, les différents membres de l’équipe peuvent partager et discuter sur la mise en oeuvre de la fonctionnalité demandé.

Chaque issue peut être lié ou non à une milestone (étape importante du projet). La milestone est terminé lorsque toutes les issues lié à cette dernière on été close.

Elles permettent également de créer en un seul clic, une Merge Request et la branche de travail associée.

LE BOARD

Les Board est semblable à un trello. On peut déplacer les différentes issues de labels en labels en fonction de leur avancement.

LES MERGE REQUESTS

Lorsqu’une issue a été prise ou attribuée à une personne, qu’elle est passé en Doing et que la merge request a été ouverte. Le codeur n’a plus qu’a aller travailler sur la branche associée de cette dernière.

Chaque merge request permet de :

  • Comparer les changements entre deux branches lors des codes review
  • Examiner et discuter des modifications proposées en ligne
  • Aperçu en direct des modifications
  • Empêcher de merger grace au status WIP
  • Résoudre automatiquement les problèmes de fusion.
  • Résoudre les conflits de fusion à partir de l’interface utilisateur
  • Squash les commits pour un historique plus propre

 

LE PROCESS A SUIVRE

Maintenant que les différentes couches de cette nouvelle approche de gestion de projet on été vue. Voici le process à suivre pour l’intégrer efficacement dans votre quotidien.

1 – Prendre une issue:

Si la tâche ne vous a pas encore été attribuée, allez dans le Board voir les issues qui sont dans le label To Do.

Sélectionnez l’issue désiré, lisez la en détail et attribuez la vous.

2 – Commencer à travailler:

Une fois l’issue attribuée à votre nom et que vous voulez commencer à travailler dessus.

Dans le Board glissez la dans Doing.

Ouvrez l’issue,  et cliquer sur Create Merge Request

Une merge request avec le satut WIP est crée automatiquement, la branche de travail associé à cette dernière a également été crée.

3 – Dans votre terminal:

Passez sur la branche Develop.

Faites un git pull. La nouvelle branche que vous venez de créer a été rapatrié.

Faites un git checkout votre-nouvelle-branche

4 – CODER

Faites des git commit/ push de temps en temps, le code sera pousser sur la branche de travail.

Faites également un git commit dès que vous voulez changez de branche

5 – Passer en Review:

Une fois que les demandes de l’issue ont été complétées.

git commit, git push votre code.

Allez voir dans GitLab votre Merge Request.

Il se peut que vous ayez des Merge Conflit. Vous pouvez tenter de les résoudre automatiquement sur GitLab.

Sinon dans votre terminal.

git commit votre travail

Puis faites un git checkout develop

un git pull

retournez sur votre branche de travail avec un git checkout votre-nouvelle-branche

git rebase develop, des merge conflits sont apparus!

Résolvez les.

git rebase –continue

git commit, git push -f

Retournez voir dans GitLab, votre problème de Merge Conflit a disparu.

Cliquez sur Resolve Wip Status, pour montrer que le travail est terminer pour cette merge request.

Passez également le status de la MR en Review

Allez également dans le Board et glisser l’issue concerné dans le label Review.

6 – Attendre les retours de la Review

Si vous avez des retours fait par votre reviewer reprenez à l’étape 4

(Pensez à close les discussions pour chaque commentaire fait lorsque vous avez résolu le problème.)

Si aucun retour sur votre Merge Request n’a été fait, votre reviewer fera le Merge.

7 – Reprendre à l’étape 1 jusqu’à avoir fini la Milestone

 

Vous êtes Reviewer:

Allez voir dans le Board les issues qui sont dans le label Review.

Sélectionnez en une.

Ouvrez la Merge Request associée. Vérifiez qu’il n’y a plus le statut WIP et qu’il n’y a pas de Merge Conflict. Sinon renvoyez au codeur.

Lisez dans Changes le nouveau code. Cliquez sur une ligne pour y laisser un commentaire si vous avez une question sur le fonctionnement ou une proposition de changement. Veuillez à que votre commentaire soit toujours bienveillant envers le codeur. Enseignez les bonnes pratiques.

Le codeur sera notifié de vos commentaires et saura qu’il doit retourner modifier son code.

Une fois que tout les changements on été effectués et que la Merge Request est parfaite à vos yeux. Vous pouvez merger.

Avant de Merge, pensez à sélectionner Remove Source Branch pour supprimer automatiquement la branche lié à la merge request et Squash Commits pour ne pousser qu’un seul commit dans la branche develop. (Ce commit portera le nom de la merge request)

 

 

 

 

 

#Barcamp : Journée 4, la dernière !

Pour la dernière journée, nous avons prévu une séance de veille de 2H + présentation puis de rendre le gîte à midi pour faire la rétrospective l’après-midi dans un lieu encore tenu secret 😉

Vincent et Julien sont partis sur la limite entre traitement client et traitement serveur (une bonne pratique à mettre en commun ;))

Thomas et Lise sur les pseudo élément CSS, pour expliquer ces concepts assez peu répandus dans le service.

Pierre-Olivier regarde les nouveautés du côté de Rails 5 et oui il faut évoluer avec notre framework.

Matthieu regarde l’utilisation des assets Ruby On Rails.

Jérémie pour sa part nous a présenté les canvas et leur utilisation.

Midi, nous rendons le gîte et c’est parti pour un resto suivi d’une rétrospective.

Fin de la journée, et voilà le volet du Barcamp 2016 refermé.

A l’année prochaine, on espère 😉

Le service Web

#Barcamp : Journée 3, seconde journée de veille complète

En ce jeudi du printemps agile, que nous avons donc raté :(, dommage, nous nous sommes remis au travail.

Le départ est lancé à 8H40, sur des sujets très divers pendant une séance de 3H suivie des présentations toujours riches en discussion. Le barcamp permet vraiment de confronter des visions et de trouver un consensus commun partagé et appliqué par tous (même si on ne peut pas contenter tout le monde chacun fait des concessions, merci l’agilité d’avoir mis fin à la raison du plus fort ;)).

Pierre-Olivier et Vincent sont en pleine réflexion sur la factorisation du code notamment sur le développement Ruby on Rails.

Julien et Lise sont partis sur les slideshow touchable et swipeable, une étape nécessaire pour les écrans tactiles notamment qui représentent plus de 50% de nos visiteurs, on doit faire attention à l’ergonomie pour ceux-ci.

Matthieu et Jérémie partis ensemble sur les systèmes d’animation que ce soit CSS3 ou SVG, ils se sont vite aperçus que ces 2 éléments de veille étaient trop distincts pour être traités ensemble, ils sont donc partis chacun sur un sujet.

Thomas quant à lui est parti sur la veille pour les sites one page, une sorte de site que l’on commence à faire pour les marques qui ne nécessitent pas trop d’investissement sur le numérique.

C’est la pause, le midi, un repas bien mérité et on s’y remet.

C’est reparti pour 3H et les présentations.

Jérémie et Matthieu repartent ensemble sur les unités relatives

Pierre-Oliver et Julien sur l’organisation de réalisation de sites et de communication notamment avec un service avec qui nous traitons souvent.

Thomas et Lise se lancent dans la communication avec un autre service avec qui nous traitons souvent.

Vincent part seul sur le temps réél, la veille c’est aussi revenir sur des sujets déjà étudiés pour voir s’ils ont évolué et dans notre métier c’est souvent le cas quand un an s’est écoulé.

Fin de la journée 18H45-19H, ce soir restaurant conseillé par Thomas le fin gourmet de l’équipe.

A demain.

#Barcamp : Journée 2, première journée de veille complète

La journée du Mercredi commença à 8H30 par une première séance de veille de 3H suivie d’une heure de présentation des sujets étudiés.

Thomas et Vincent nous ont présentés leur veille sur Flexbox, une technique qui simplifie grandement la gestion de position des blocs HTML, sûrement dans nos prochains sites, à suivre…

Lise et Pierre-Olivier nous ont présentés leurs idées sur l’amélioration de la communication d’une équipe avec une personne en télé-travail. Ce sujet ne remplissant pas les 3 heures, ils ont aussi commencé à plancher sur le sujet de la typo web, ses limites, les bonnes pratiques pour ne pas avoir de comportement bizarre quand le chargement est lent…. Pas de présentation pour le moment, le sujet sera revu ultérieurement.

Matthieu et Jérémie ont quant à eux présenté une utilisation avancée de Sass, les fonctions, les mixins, les héritages, ceci entre directement en résonance avec les sujets CSS et notamment l’organisation de celui-ci pour un repérage plus facile.

Enfin Julien a étudié les astuces présentes dans les vidéos du site hackademy.io, site destiné à apprendre sur les technologies web et notamment Ruby qui est notre langage principal depuis maintenant 6-7 ans. Ce service est proposé par Synbioz, une agence de communication très reconnue dans les métiers du Web et qui utilise comme technologie de base Ruby, il est donc toujours intéressant d’écouter les conseils de ces acteurs qui ont une expérience plus qu’avérée.

La pause du midi, se déroula dans un petit resto sur Courseulles sur Mer et retour au gîte pour la seconde séance de veille 3H suivie de la présentation des sujets étudiés.

Jérémie et Vincent ont présenté les Webcomponents, technologie peu répandue mais qui pourrait être intéressante à l’usage.

Pierre-Olivier et Thomas sont partis sur l’intégration des emailing, cela tombe bien nous en faisons de plus en plus, pour les pharmaciens d’une part et nous allons nous (re)lancer dans les emailing pour les consommateurs. L’aspect responsif de ces emailing est l’une des pistes qui a été étudiée.

Matthieu et Julien ont quant à eux défriché le sujet ReactJS, le besoin d’utiliser cet outil ou un concurrent n’est pas flagrant mais la technologie ne doit pas nous faire refuser un projet à nous même de proposer des outils performants via ces nouvelles technologies. Mais la conclusion est sans appel, cet outil est un peu complexe, pas super mûr et ne répond pas à nos besoins pour l’instant (un peu comme angular à l’époque). Ces outils ne sont utilisés que dans des cas bien particuliers, or nos cas sont tout à fait réalisables avec un code jQuery mieux organisé. Nous resterons donc sur nos technologies actuelles, c’est aussi ça la veille, prendre du temps pour étudier un sujet et pouvoir prendre la bonne décision de l’utiliser ou non et parfois c’est non car ce qui prime est le contexte.

Lise est partie vers la veille des webdesigns et tendances actuels afin de pourvoir partager avec nos interlocuteurs ces données récoltées. Et les tendances ne sont pas toujours celles qu’on croit.

La journée de travail se termine à 17H45, un petit quart d’heure et toute l’équipe se lance dans une session de course à pied jusqu’à 19H15 pour certains et d’autres jusqu’à 18H20 😉 et oui chacun son niveau mais tout le monde court ensemble… Un bon moment commun de détente, chacun son ordinateur, ok on est un peu geek mais certains luttent contre cette conclusion en sortant des livres 😉 et bonne nuit.

La suite demain…

#Barcamp : Journée 1, arrivée et lancement du Barcamp 2016 !

En ce jour du mardi 22 Mars 2016 à 9H15, nous arrivons sans heurt au gîte hormis pour Matthieu, Jérémie et Julien qui avec une voiture plus que chargée (à cause des courses) se sont perdus, enfin ont pris un raccourci qui n’en était pas un 😉

Le gîte est superbe, 7 chambres distinctes, 4 salles de bain et une grande table, juste ce qu’il faut pour 7 voire 8 personnes. Petit lancé de dé pour attribuer les chambres et chacun pose ses affaires dans son espace nuit.

10H30 : Tout le monde est prêt, on lance le premier sujet et pas des moindres « la définition et la mise en commun de bonnes pratiques », sujet basé sur notre expérience individuelle et mise en commun.

Il nous aura fallu pas moins de 7 heures acharnées de discussion sur des sujets aussi variés que le nom de nos variables jusqu’à l’indentation du code en passant par les endroits et la façon de factoriser du code.

Ce sera évidemment le seul sujet abordé et on en a sûrement oublié des choses, mais forcé de constater que cela était nécessaire.

Et oui, on ne fonctionne pas en équipe à 7 comme on fonctionnait à 4, les choses changent, évoluent et de nouvelles contraintes apparaissent, de nouvelles idées aussi, il faut savoir prendre le temps qu’il faut pour mettre à plat tout ça et garder une cohérence dans l’activité du service.

La journée se termine donc à 19H, s’en suit une préparation du repas en commun ainsi qu’un tout petit moment de détente individuelle car ce soir c’est poker… Il est lancé à 21H et se soldera par une victoire de Jérémie, partie tout aussi acharnée avec chacun son moment de grâce.

Le barcamp continue demain….

Développement de projet guidé par le comportement – Printemps agile 2015

David et Pierre, de KNP Labs à Nantes, nous ont présenté le technique du développement de projet guidé par le comportement, Behavior Driven Development (BDD), lors du Printemps agile 2015.

Les 3 grandes questions qu’ils se posent sont les suivantes :

  • Comment décrire les besoins d’un projet en évitant un énorme cahier des charges exhaustif ?
  • Comment utiliser le même langage entre l’équipe du marketing et l’équipe de développement afin d’éviter les incompréhensions ?
  • Comment accélérer le début du projet afin de développer et tester une fonctionnalité le plus tôt possible ?

C’est notamment suite à cette conférence que je me suis intéressé à RSpec, celui-ci se définissant comme un framework de test guidé par le comportement pour Ruby.

La vidéo de leur présentation est disponible sur le site de KNP : KNP au Printemps Agile : La BDD expliquée à Michel, le maçon

Les TDD en toute agilité, par Julien et Pierre-Olivier – Printemps agile 2015

Notre équipe a été invitée à faire une présentation durant ce Printemps agile 2015. Julien et Pierre-Olivier se sont lancés et ont proposé d’aborder la technique du TDD, ou Test Driven Development (développement piloté par les tests en français), technique que l’équipe pratique quotidiennement.

Juste après avoir (peu) mangé, Pierre-Olivier et Julien ont donc présenté la technique du développement piloté par les tests. Ils ont montré l’intérêt de cette technique et ont, à travers un live-coding, expliqué la façon dont nous la pratiquons au sein de l’équipe.

Les TDD en toute agilité
Pierre-Olivier et Julien nous présentent le contenu de leur présentation.

La qualité des questions posées à la fin de la présentation a montré l’intérêt porté par l’assistance à cette présentation. Les questions ont permis d’approfondir quelques points abordés succinctement et d’élargir le dialogue aux tests d’intégration, sujet qui n’avait pas été développé durant la présentation, et au développement de tests automatiques pour des applications existantes non testées. Ne pratiquant pas les tests d’intégration, Pierre-Olivier et Julien ont laissé la parole à Frédéric, présent dans l’assemblée, qui a évoqué les deux solutions Selenium et Nagios. La personne s’étant questionnée sur la refonte d’applications non testées a été invitée à suivre la présentation de Mathieu Sadouni et Pierre-Emmanuel Fringant intitulée « Sécuriser une refonte avec le Golden Master Testing » se déroulant juste à la suite de celle-ci.

Les slides de la présentation « Les TDD en toute agilité » sont disponibles à l’adresse : http://slide.julien-anne.fr/les-tdd-en-toute-agilite

Definition of done, comment ?

Le but de cette veille était de voir l’intérêt de cette definition of done (définition de terminé ou fait en français) et comment la mettre en place au sein du service si cela peut être intéressant.

Déjà d’où vient cette définition ? Sur ce point je me suis souvent trompé en pensant qu’elle venait du système Kanban. Et bien non elle provient de Scrum. Mais Kanban n’est pas en reste car il possède une notion similaire qui est la ou les règles de passage d’une colonne à l’autre. Scrum nous indique que la definition of done est la liste des critères que doit remplir un incrément pour être considéré comme terminé. Scrum indique aussi que si un des critères n’est pas rempli l’incrément n’est pas terminé donc pas compté dans la vélocité (nous on ne la calcule pas vraiment donc pas de souci). Cette définition doit être composée de différents types de critères : pérennité du logiciel, support de mise en production (doc si besoin, commit de git, merge si nécessaire, …), requis du monde des affaires (prévenir le PO, les utilisateurs, tracer les changements, …). Ces différents aspects permettent de couvrir les différents points de vues des acteurs de l’incrément.

Quelques erreurs à éviter selon Scrum :

  • Liste de critères trop importante -> contre productif
  • Liste implicite peu d’intérêt plutôt mettre par écrit les choses même triviales car il arrive à tout le monde d’oublier.
  • Éviter les incréments en suspend en se disant je reviendrais dessus plus tard.
  • Il faut que dans tous les cas on puisse checker la totalité des critères.

Pour notre part on ne va pas choisir entre l’un et l’autre nous allons prendre les deux. D’un côté comment déterminer qu’une tâche est terminée et de l’autre comment faire avancer ces tâches dans chacune des colonnes de notre Kanban. Voyons maintenant comment déterminer ces règles qu’il faut écrire, afficher et partager entre tous les membres de l’équipe, l’objectif est d’avoir une façon de travailler proche et de limiter les erreurs sur des choses que l’on ne fait pas régulièrement.

De mon point de vue, il faut partir du contexte dans lequel vous êtes, prendre toutes les bonnes pratiques de chacun en discuter avec tous les membres et se mettre d’accord sur les points qui peuvent poser problème.

Par exemple, je fais une branche, j’écris au moins un test qui échoue, j’écris le code de l’application, je lance tous les tests, ils passent tous puis je merge ma branche, je push mon code, je fais un test en prod et je préviens le PO.

Voilà, il est important de prendre conscience que ces règles ne peuvent être universelles, elles peuvent être proches mais pas universelles, chacun fonctionne à sa manière et le but n’est pas de standardiser cela mais bien d’améliorer cette manière de fonctionner.

Systémique, par Rémy Génin – Printemps agile 2015

Rémy Génin nous a présenté la « Systémique », une séance riche voir très riche. La systémique est une approche au même titre que l’agilité. Il a donc tout au long de la présentation fait un parallèle entre ces 2 approches similaires mais pas identiques, et cependant compatibles. La systémique a été élaboré en 1958.

Premier point commun, ce sont toutes deux des approches empiriques, elles se pratiquent en faisant, on teste, on essaie, on change, on revient en arrière, …

Qui dit systémique dit système. Un système est un ensemble d’éléments en interaction pour un objectif commun.

Les fondations sont la relation entre les différents éléments, la qualité individuelle des personnes passe après la relation.

Il y a toujours une finalité positive à toute action réalisée, mais on ne la voit pas toujours de notre point de vue. Il faut alors recadrer sa vision pour trouver cette finalité positive et ainsi pouvoir discuter avec la personne a l’origine de l’action, si celle-ci est négative pour le système.

La systémique lutte contre les procédures, pas contre les processus. Les procédures sont les chemins qui permettent d’atteindre un objectif, ils n’ont pas besoin d’être définis. Les individus savent quel chemin prendre et ils peuvent même le modifier pour le rendre plus efficace. Le processus quant à lui indique un but, un objectif. Ce dernier est suffisant pour les éléments du système.

Le principe de totalité nous indique que le tout est supérieur à la somme des partis, lors du binômage, certains disent que 1+1=3. L’interaction des 2 premiers individus génère les idées qui auraient pu être apporté par une 3e personne, ce qui est un gain énorme de productivité. Lorsque vous êtes 6 répartis en 3 binômes, vous pouvez quasiment atteindre la productivité de 9 personnes travaillant seules.

Les systèmes sont toujours englobés par un système plus grand, l’objectif du système le plus englobant prime sur l’objectif du système englobé. Si une action apporte un bénéfice à un service mais devient négatif pour une entreprise cette action doit être annulée.

La systémique se base aussi sur le concept de rétroaction. Le postulat comme quoi une cause entraîne un effet puis une fin est faux. Pour la systémique, une cause entraîne un effet qui entraîne un effet qui entraîne un effet … de façon infinie.

Le « Pour quoi ? » (dans quel but ?) est important, le « Pourquoi ? » (la cause) l’est moins.

Pour résoudre un problème, il faut un mouvement dans le système, cela entraînera un changement qui peut permettre de résoudre un souci.

Mais attention, un système répond au principe de l’homéostasie : Il cherche toujours un équilibre et se stabilise. Si le changement est trop superficiel, il sera absorbé par le système et celui-ci reviendra à son état d’origine.

Un autre principe est que la réalité est construite environ 30% provient des sens (réalité de première ordre commune à tous) et 70% environ provient de nos souvenirs et expériences passées (réalité de second ordre propre à chaque individu). Le but est d’agir sur cette réalité de second ordre en élargissant notre vision en changeant de pont de vue et en agissant sur ce que perçoivent les individus et non ce qu’ils sont.

La systémique donne aussi des retours rapides. Si le message n’est pas compris il faut le reformuler pour s’adapter à son interlocuteur. Cela présume que l’interlocuteur ce sente assez en confiance pour indiquer qu’il n’a pas compris certaines choses.

Afin de mieux comprendre ce que perçoit notre interlocuteur, nous devons changer notre façon de penser grâce à un recadrage en ouvrant. Il faut éviter les prophétie auto-réalisatrice négative, si on dit à une personne « tu es mauvais », elle le sera.

Rémy nous a ensuite invités à regarder une conférence TED sur l’éducation positive.

Il indique que la systémique n’est pas un système binaire bien ou mal mais un système ou cela peut être bien et mal.

Afin de modifier un système, il existe deux types de changements :

  • Le type 1 : Adapter les règles existantes. Il est simple et indolore.
  • Le type 2 : Plus contraignant : remplacer les fondamentaux. Cela nécessite de l’apprentissage.

Cela doit toujours se passer dans le respect et l’écoute de l’avis de chacun des éléments du système.

Les outils pour mettre en mouvement le système et ses acteurs sont divers et variés :

  • Le questionnement
  • La réflexion
  • Le silence permet de prolonger sa réflexion

Ces outils permettent aux acteurs de trouver LEURS solutions et non pas les miennes. Elles seront donc plus facilement acceptées, manipulation positive.

Il faut susciter le désir. Être convaincant ne suffit pas, il faut montrer en quoi le progrès est positif. Il faut montrer le chemin et non pas l’emprunter à la place des personnes. Il faut se donner rendez-vous à un point (objectif – vision). L’important n’est pas le moyen de s’y rendre mais bien de s’y rendre.

Il faut, à intervalles réguliers, faire un état des lieux des points qui fonctionnent bien et un ce qu’il faut améliorer.

Explorer les solutions dans les expériences de chaque éléments du système pour voir si elles peuvent répondre au besoin du moment.

Ne pas hésiter à faire rêver, cela aide les personnes à passer le pas du changement. Recadrer en utilisant le « et » pas le « ou ». Imagine le pire est aussi un moyen de sauter le pas du changement, si le pire n’est pas trop atroce ;). Dire que l’on a une solution sans la dire, cela invite les gens à réfléchir en se disant qu’une solution existe, et qu’ils leur faut la trouver. Cela retourne de la manipulation bienveillante car réalisée pour les autres et non uniquement soi. Il faut cependant toujours s’adapter au contexte et non partir d’une base inexistante.

La finalité est le maître mot de la systémique : sans vision les personnes ne pourront comprendre l’intérêt du changement.

Les bonnes intensions ne suffisent pas, il faut réaliser les actions qui vont avec. Il n’y a pas forcément 1 ou 2 solutions mais peut être une 3e. Essayer d’aller dans le sens de l’interlocuteur pour comprendre son point de vue et voir comment ce point de vue peut s’intégrer dans le système.

C’est par le système auquel il appartiennent que les individus se définissent, il est donc important que celui-ci soit bâti avec eux (ex: un service).

Voici pour la présentation sur la systémique, forte intéressante et effectivement, elle partage pas mal de notions avec l’agilité.

Retour et débrief du barcamp 2015

L’heure du barcamp 2015 étant sonné, il est temps de débriefer et de faire une rétrospective (et oui contexte agile oblige 😉).

Le débrief a duré environ 2 heures, quand on donne la parole aux personnes ils la prennent et cela fait plaisir.

Plusieurs axes de retours :

L’espace de travail, des locaux : Le retour est sans appel, il nous faut à la fois un open space pour la synergie des idées à l’instant T et des espaces d’isolement pour les tâches qui demandent une concentration maximale.

Le lieux géographique : A l’identique, le retour ne donne pas place aux doutes, le barcamp doit avoir lieu à l’extérieur de la société, la proximité du quotidien à notamment pesé sur la gestion des petits tracas non urgent mais que l’on n’aime pas laisser trainer.

Renforcement de la cohésion d’équipe : Cet aspect a été complétement laissé de côté dû au fait que les personnes rentrent chez elles tous les soirs (lieux géographiques) et ne mangent pas ensemble ni n’ont d’autres activités que celle du travail. Un exemple concret la partie de poker avec des pizzas (achetés en minibus ?) le soir après 22H a manqué à chacun des participants. Ce point marque définitivement le lieux géographique de cette année comme à ne pas reproduire.

La durée : Ce point a soulevé plus d’échanges, 4 jours oui mais, la majorité indique quand même que cela est plutôt une bonne durée. La séparation est elle aussi au coeur des débats mais un système de 2*2 jours avec un week-end entre deux serait la solution préconisée. A voir les possibilités qui s’offriront à nous les prochaines fois.

Le format : deux points sortent du lot, horaires peu flexibles dommage et pas de time box sur les présentations qui du coup s’envolent un peu parfois.

Déconnexion du quotidien : Sur ce point des choses sont à améliorer ou au moins revenir à ce que l’on a pu faire en 2013, à savoir être moins à la disposition des collègues pour éviter les appels pas utiles qui génèrent toujours une pensée en plus et une déconcentration. Il est clair que ce genre d’évènement ne raisonne que si l’on ne fait que ça. Mais nous ne pouvons pas omettre que les projets ne permettent pas de faire ce que l’on veut, peut-être faut-il mieux prévoir le moment du barcamp. Un petit manque de communication aussi sur cette activité et son aspect trop peu officiel auprès de nos collègues. Encore une fois sur cet aspect l’environnement géographique prend toute son importance.

Matériel : Point positif pour les ordinateurs portables, un petit bémol sur les serveurs qui mériteraient peut être d’être préparés en amont du barcamp afin de faire des tests de manière plus rapide lors du barcamp.

Contenu : Le contenu convient car les participants les ont déterminé eux-mêmes. Petit bémol sur le manque de temps pour pousser les sujets les plus « gros » ou « intéressants ».

Ecrire les articles : Oui mais quand ? Cela pose souci à tous les participants, pendant le barcamp cela perd du temps réel de veille hors du barcamp nous n’avons plus le temps.

Préparation du barcamp : Un serveur de test, la définition du contexte et des problématiques actuelles et le partage plus tôt des sujets aurait permis une meilleure organisation du barcamp.

D’autres retours en vrac : le barcamp est apprécié par l’équipe, il permet d’approfondir les nouveautés. Mais il est sporadique donc trop chargé (trop de choses à voir), un étalement serait peut-être intéressant avec une veille de 2H par semaine avec présentation si nécessaire le vendredi après midi. Nous allons essayer cette formule et voir si cela est jouable. Il a manqué un peu de JS dans ce barcamp, pas assez de binomage sur les sujets. Un manque de mise en pratique direct même si certains sujets ont été mis en pratique, cela est loin d’être le cas standard.

Voilà pour les retours, nous essaierons d’améliorer les choses la prochaine fois.