Au fil de réunions d’équipes full stack developer, nous avons décidé de faire un atelier autour du craftsmanship pour les raisons suivantes :

• Expérimenter des concepts et technologies :
• Faire suite à notre formation TDD, 
• Expérimenter la Clean Architecture avec de l’architecture hexagonale,
• Utiliser NextJS et GraphQL pour les diffuser plus largement au sein de notre équipe,
• Faire du React pour avoir une technologie commune.

• Partager entre développeurs une expérience commune :
• Ne travaillant pas tous ensemble, nous voulions partager nos connaissances,
• Faire du pair programming pour en voir les avantages et pouvoir partager rapidement nos connaissances.

• Créer un outil qui pourra nous servir :
• Création d’un outil de réservation des locaux d’Agaetis en accord avec la jauge covid et les mesures de distanciation sociales en vigueur,
• Recherches autour de l’UI et UX en fonction de nos capacités techniques.
  

Comment s'organise un atelier Craftsmanship ?

Nous avons demandé à Jean-Michel Gourbeau, coach agile, de nous aider pour l’organisation du projet. En amont, plusieurs étapes ont dû être réalisées afin de s’assurer que l’atelier se déroule dans les meilleures conditions possibles. 

Une première réunion de réflexion pour décider des technologies et concepts a alors été organisée puis un backlog a été créé ainsi qu’un projet dans gitlab avec l’initialisation de dépendances et l’ajout d’un exemple d’architecture hexagonale. 

À la suite de ces premières étapes primordiales, un des développeurs de l’équipe et notre chargée de communication se sont occupés de concevoir des maquettes afin de pouvoir visualiser rapidement le rendu de l’application et avoir le plus d’éléments possible pour débuter l’atelier. 

La première étape était de prioriser le backlog sans définir le temps nécessaire pour chaque tâche : no estimate. La seconde était l’explication technique du projet avec React, Next JS et l’architecture hexagonale pour que tous les membres de l’équipe puissent avancer au même rythme en ayant les mêmes connaissances. 

Pour mettre en application la formation TDD reçue quelques semaines plus tôt nous nous sommes séparés pour faire du pair programing avec pour ambition de changer de coéquipier toutes les demi-journées et de nous retrouver tous les matins pour faire un point sur l’avancement du projet. 

Mais voilà, entre le programme souhaité et ce qui se passe vraiment il y a toujours des différences… 

Attentes VS réalité

Un plan se déroule rarement à la perfection, il est normal de s’éloigner de la feuille de route et de rencontrer quelques difficultés, cela ne signifie pas pour autant que c’est un échec. Au contraire, se retrouver face à des difficultés nous pousse à nous adapter et à faire évoluer nos connaissances et le projet en lui-même. Voici les adaptations que nous avons dû faire, face à la réalité :

• Le pair programming :
• Il était en fait assez difficile de changer de binôme tant que la tâche en cours n’était pas terminée. Cela nous faisait perdre du temps, le nouveau binôme devant se familiariser avec la feature à réaliser et le code déjà écrit. 
• Au final, sur trois jours d’atelier nous avons seulement changé deux fois de binôme.

• Le TDD :
• Il est plutôt difficile à mettre en place lorsqu’il s’agit de faire une partie qui concerne particulièrement l’affichage ou l’intégration de SSO par exemple. L’utilisation de Redux peut être une solution.
• Nous avons dû abandonner les tests de rendu UI pour coller à notre fenêtre de 3 jours. 

• Le remote :
• Il nous a été plus difficile de suivre et donc de travailler en utilisant le pair programming,
• Il nous également était moins facile de se concerter pour la coordination et l’organisation des tâches.

• Les nouveautés et la complexité technique :
• L’utilisation de NextJS, GraphQL et toutes les méthodologies, il a été difficile de tout mettre en place en même temps, 
• La gestion du Server side Rendering de Next JS a ajouté de la complexité dans l’utilisation des libs, notamment pour le SSO.  

Et au final ?

Au bout des trois jours d’atelier nous avons réussi à finir toutes les tâches que nous avions classé en priorité 1. Le rendu est donc une application minimale mais fonctionnelle. 

En voici quelques éléments :

• La connexion à l’application se fait grâce au compte mail du collaborateur,
• Il est possible de réserver une date sur un calendrier (matin et/ou après-midi)
• On peut voir les personnes présentes chaque jour dans les locaux 
• Si le créneau souhaité est déjà réservé et que la jauge est remplie, une redirection est faite sur notre Slack permettant d’ouvrir une discussion et ainsi potentiellement libérer une place en échangeant sur les besoins de tous.  

Conclusion

Malgré les quelques problèmes évoqués plus haut dans cet article nous sommes satisfaits du rendu de l’application et surtout heureux d’avoir pu s’exercer à la pratique de pratiques craftsman et d’avoir eu l’occasion de les confronter à la réalité. 



Car plus que la livraison d’un outil pratique, cet atelier avait pour objectif de nous confronter à de nouveaux concepts et technologies pour tester nos connaissances et nos capacités à nous adapter.