Merge request : la checklist

icon Tags de l'article : , ,

Septembre 10, 2019
Hello,

Comme vous le savez peut-être, en plus d'être développeur, je suis le Scrum Master de mon équipe.

Afin d'améliorer la qualité et la stabilité de notre branche de dev principale, j'ai rédigé une petite checklist à utiliser par les développeurs lors des merge requests.

Pourquoi ?
  • Les listes de choses à faire sont souvent oubliées par l'équipe au moment des merge requests. Parfois partiellement (ah mince je n'ai pas testé sur iPhone), et parfois complètement (ah mince, comme c'était un petit dev je pensais que ça n'avait pas d'intérêt de tester).
  • En effet, une checklist a un impact psychologique bien plus puissant qu'une simple liste de choses à faire. Car en cochant, on indique qu'on a, personnellement, bien réalisé la tâche indiquée.
  • Dans l'idéal cette checklist serait à remplacer par un process CI automatisé. Ou en tout cas les étapes automatisables (build, tests, etc.).
  • La checklist peut aussi faire office de code review cheat sheet.
  • La checklist permet d'avoir un historique des merges, et d'en tirer des tendances.
  • Attention cependant : il ne faut pas que la checklist devienne une trop grosse contrainte. Il faut que le rapport besoin de qualité / contraintes soit optimal. Eviter donc d'avoir une liste de 20 étapes de tests avec 20 cases à cocher. Ca servirait juste à gaver votre équipe.
  • Egalement, il faut que l'équipe accepte et valide cette checklist. Vous devez éviter d'imposer ce type de process de force auprès d'une équipe qui n'en voit pas l'intérêt. A vous de sensibiliser votre équipe sur l'importance de la stabilité de vos branches de développement, du temps que ça fera gagner sur le développement, du nombre de bugs que vous éviterez, du fait que ça protégera des builds qui finissent à 21h, etc.


Voici donc cette petite checklist que j'espère avoir suffisamment teasé (à noter que plein d'éléments dans la partie optionnelle ne concernent qu'Angular/Ionic) :

------------------------------- MERGE REQUEST CHECKLIST -------------------------------

Date :
Dev name :
Reviewer name :
Branch :

MANDATORY
☐ It's a product story ? If yes, the PO validated the dev and gave his/her GO.
☐ The target branch (master/dev) was merged into the current branch
☐ No code / lint warnings or errors
☐ It compiles, starts, and was tested on all target devices/browsers
☐ It builds for all target environments (dev, qual, prod)
☐ The CI pipeline is green
☐ The wiki documentation was updated
☐ If the environment changed (global packages, .env file, …), the CI was updated and the team was warned by email

OPTIONAL (code reminders)
☐ PRODUCT : Every complicated choices are explained somewhere (documentation, specifications, comments, etc.)
☐ CODE QUALITY : No //todo or useless logs
☐ CODE QUALITY : No refactoring planned for later
☐ CODE QUALITY : The code is easy to read and understand
☐ COMPONENTS : OnPush on each component
☐ COMPONENTS : Smart/dumb pattern used
☐ PERFORMANCES : takeUntil($onDestroy) pattern applied on subscriptions
☐ PERFORMANCES : the app is fluid to use, no performances drop
☐ ROUTING : the pages routing is consistent and hierarchical
☐ SCSS : Each component is responsible of its look (not its parents)
☐ SCSS : No size calculations in typescript (only CSS for sizes)
☐ TESTS : tested with 360/375/414/768px of width
☐ TESTS : Unit tests written / updated
☐ ACCESSIBILITY : It works with bigger fonts

------------------------------- /MERGE REQUEST CHECKLIST -------------------------------

En espérant que ça vous soit utile,

Bon dev à tous et toutes !

Comment bien accueillir un-e nouvel-le employé-e : checklist

icon Tags de l'article :

Décembre 10, 2018
Jusqu'à présent, je n'ai été vraiment bien accueilli que dans une seule société parmi les 15 où j'ai pu travailler (que ce soit sur des missions courtes ou longues).

Je trouve ça dommage. Vraiment dommage. Que la personne soit prestataire ou interne, je trouve ça triste de voir que si peu de sociétés font l'effort de préparer une "bonne" intégration.

J'ai donc décider de partager avec vous une checklist de tout ce qu'il faudrait anticiper / faire / communiquer pour offrir une vraie bonne intégration à un-e nouvel-le employé-e. (selon moi).

A préparer en amont
  • La place et le poste de travail (rien de pire que d'arriver et de devoir squatter le poste d'un mec en vacances ou de devoir utiliser un vieux laptop pourri)
  • La liste des logiciels à installer / configurer / utiliser, et pourquoi
  • Se réserver deux à trois heures le premier jour avec le nouveau/la nouvelle pour présenter la boite, les locaux, l'équipe, le projet, etc.
  • Planifier le premier repas avec toute l'équipe (pour éviter que chacun-e ne parte chercher dans son coin et que le nouveau/la nouvelle se retrouve seul-e, déjà vécu...)
  • Prévoir une liste de sujets qu'il faudra aborder et des plages horaires de formation dédiées à ces sujets (avec chacun des membres de l'équipe)
  • Le badge d'accès ou la clef des locaux
  • Demander à l'équipe d'inclure au maximum, dès son arrivée, la nouvelle personne dans leurs routines et leurs échanges (repas, pauses, réflexions, mini-réunions, etc.)

Les informations à donner (de préférence par écrit !)

  • Les horaires officielles
  • Les horaires officieuses / tolérées
  • Règles : ce qui est autorisé (flexibilité des horaires, télétravail, appels téléphoniques, absences médicales) et ce qui est interdit (quitter les locaux sans prévenir, jouer au ping pong/babyfoot à certaines heures, etc.)
  • Où se trouvent les toilettes
  • Où mange l'équipe en général (restaurants ? ils vont chercher ? si oui où ?)
  • La liste des logiciels à installer (ordre, versions, etc.)
  • Un plan du bureau/openspace avec les noms de chaque personne (si possible avec photos)
  • Un guide basique sur les logiciels et les routines associées (déclaration des heures par exemple)
  • Une fiche résumée de ce qui a été abordé le premier jour : méthodos de travail, outils, vision macro du projet, vision produit du projet, présentation rapide de l'équipe, détail de l'architecture du projet, etc.

Premiers jours

  • Avoir préparé la liste des premières tâches / premiers sujets pour le nouveau/la nouvelle
  • Avoir détaillé le plus possible ces tâches/sujets
  • Inviter la nouvelle personne dans les réunions (nouvelles, existantes et récurrentes)
  • Organiser un point quotidien de 30 minutes avec le nouveau/la nouvelle pour suivre son avancement, l'aider, donner des conseils, débloquer une situation, etc.
  • Ne PAS lui demander d'effectuer des tâches désagréables ou complexes qu'on ne ferait pas soi-même. Ou qui ne nous font pas du tout envie.

Pour rappel, un-e bon-ne manager c'est quelqu'un qui délègue ce qu'il/elle aime faire, pas ce qu'il/elle n'aime pas faire. Car ainsi il/elle pourra toujours être disponible pour aider, accompagner, encourager, et offrir plus d'autonomie à son équipe. Après-tout... l'objectif ultime d'un-e bon-ne manager c'est de créer l'équipe la plus autonome possible.

Au jour le jour
  • Mettre de côté les sujets parfaits pour un nouveau (par exemple un sujet pas du tout critique, simple mais long, et qui fait toucher à beaucoup de morceaux de code)
  • Documenter l'installation du poste : les problèmes rencontrés, les logiciels à installer, dans quelle versions, etc. Mettre à jour à chaque changement / arrivée d'une nouvelle personne.
  • Essayer de maintenir à jour un Wiki le plus clair possible (et avec suffisamment d'informations, même si la clarté et la concision sont plus importantes)
  • Essayer de garder à jour un plan des bureaux (avec les noms des personnes) et (si possible) un trombinoscope de l'équipe (rien de mieux pour un nouveau ou une nouvelle)

Ca semble extrême non ?

"Oui mais on a un nouveau que tous les 6 mois, ça fait un max de taf pour pas grand chose, la personne apprendra d'elle-même !"

Trois conséquences possibles (je dirais même probables) quand on fait mal les choses :
  • Si la personne est timide, introvertie ou mal à l'aise au début, elle risque de passer un très mauvais moment (impression de gêner, n'ose pas poser de questions, mal à l'aise en permanence...)
  • On passera toujours plus de temps à répondre aux questions et à penser à tout "après" qu'avant. Le temps de préparation de l'intégration de la personne sera toujours rentable (4 heures à préparer l'intégration c'est facilement 6 à 8 heures de gagnées derrière, car personne sera efficace plus vite, rencontrera moins de blocages, aura moins de questions, dérangera moins l'équipe, etc.).
  • Parfois des dérives vraiment problématiques peuvent apparaitre. Exemple : dans mon taf actuel où j'ai 12h à rattraper car on ne m'avait pas communiqué les bonnes horaires hebdomadaires attendues...

Après le plus important reste... les efforts humains. Une des meilleures intégrations que j'ai pu connaître s'est faite grâce à des gens qui venaient souvent vers moi, qui cherchaient à m'intégrer dans les conversations, qui étaient curieuses de mes passions, et qui plaisantaient avec moi !

De plus, en plus vous préparez une intégration, en plus la suivante sera facile et rapide à préparer ! ;)