Retour d'expérience

D'un projet Swag

Créé par Baptiste Donaux

Baptiste Donaux

Pourquoi un retour d'expérience ?

  1. Pour parler méthodologie
  2. Pour parler technique

La méthodologie

Quand on entend méthodologie, on pense entendre agilité.

Mais il faut aussi trouver des méthodes propres à son équipe.

On applique déjà

Les SPRINTs

  • Livraisons régulières
  • Définition du contenu des SPRINTs avant leur lancement
  • Une réunion de fin de SPRINT pour :
    1. présenter le travail réalisé
    2. parler du prochain SPRINT
    3. débriefer les retours clients

On a appliqué pour vous

Merge Request

Pas la peine, on est sur un projet one-shot.

On a appliqué pour vous

Merge Request

Inconvénients

  1. Perte de temps instantanée
  2. Fonctionnalité disponible moins rapidement

On a appliqué pour vous

Merge Request

Avantages

  1. Moins d'erreurs techniques dans le code
  2. Moins d'erreurs de workflow dans le code
  3. Une feature est connue/comprise par au moins (1 + nombre de relecteurs développeurs)
  4. Si une personne est absente, meilleure reprise du projet
  5. Le level des développeurs va se lisser
  6. Consensus sur les avis de chacun
  7. Obligation d'utiliser un workflow Git défini au préalable
  8. 1 feature = 1 branche

On a appliqué pour vous

Télé-travail

« Mois d'août oblige, c'est bibi qui gère le projet.
Mais bibi il n'a pas eu de vacances 😥
Donc bibi il part en Corrèze, profiter de l'air pur. »

On a appliqué pour vous

Télé-travail

Comment on a fait ?

  • Mise en place d'un groupe de discussion où tout le monde pose ses questions dedans (ça peut intéresser tout le monde).
  • Besoin de discuter à propos du cachier des charges, un petit appel
  • Utilisation des Merge Requests

On a appliqué pour vous

Télé-travail

Ce qui n'a pas fonctionné

  • Mauvais ressenti des deadlines par l'équipe
  • Potentiel difficulté à découper le projet/remplir les SPRINTs
  • Full-time, l'inertie R&D diminue

On a appliqué pour vous

Télé-travail

Ce qui a fonctionné

  • Meilleure gestion du projet car plus d'explications dans des tickets
  • Plus de calme pour travailler
  • Sollicitation répartie (il n'y a pas 2 personnes qui posent deux questions en même temps)

La technique

Il m'faut du swag

« Mieux qu'hier, moins bien que demain »

  1. Gagner du temps dans nos devs
  2. Gagner en flexibilité
  3. Gagner en Swag

Tester son code

Tests unitaires, tests fonctionnels. Avant d'en arriver là, des tests de syntaxes ne coûtent pas grand chose.

  • Meilleures uniformités
  • Standards partagés par tout le monde
  • Facilite la relecture
  • PHP-CS-FIXER pour le PHP, JSHint et ESLint pour le JS
  • Marquer des points auprès de son client

Définir des standards dans son application

  • Toutes nos URL finissent par un /
  • Toutes les routes doivent avoir des méthodes d'acceptation données

Appliquer des règles strictes pour les MR

Pour qu'une Merge Request soit acceptée, il faut que les tests réussissent.

Mettre en place un workflow Git

  1. Une demande dans Redmine (parfaitement détaillée)
  2. Une personne assignée
  3. Une branche Git dédiée qui part de la branche du SPRINT
  4. MR sur la branche du SPRINT en cours
  5. Fin de SPRINT, on tag et on merge la branche sur dev
  6. Mise en production, on merge sur master

Mettre en place un workflow Git

Utilisation des traductions

  • Léger investissement de temps
  • Nécessite de trouver une méthode pour le nommage des variables
  • Fait gagner beaucoup de temps pour une éventuelle feature
  • Permet de découper le DOM du contenu

Utiliser des outils qui nous aident

(on l'a fait pour vous)

  • Utilisation de Browserify
  • Utilisation de Babel
  • Utilisation de React
  • Utilisation de ES2015 (ES6)
  • Écrire du JavaScript, pas du jQuery !

Vous voulez voir du JavaScript avec Browserify ?

… enfin écrire avec la syntaxe Common.js

Rendez-vous dans la prochaine présentation

Conclusion

Bilan du projet

  • Délai dépassé…
  • … mais peu de retours du client
  • Des livraisons de SPRINT sans erreurs techniques
  • Des workflows qui collent aux besoins du client
  • Une équipe qui a pu se faire plaisir
  • Une dette technique potentiellement faible
  • Un projet re-prenable par 3 personnes à tout moment
  • Une base stable pour les prochains projets
  • Des proccess ré-utilisables

Merci !