La passation de dev en dev : nos bonnes pratiques

Chez Les-Tilleuls.coop, lorsqu’un·e consultant·e quitte un projet, nous ne transmettons pas un projet mais les produits livrables, un savoir-faire et les responsabilités en matière de réalisation des besoins (et d'atténuation des risques) au-delà de la fin du cycle de vie d'un projet. Il est nécessaire de s'assurer que toutes les parties disposent d'une vision idéale et que leurs efforts soient alignés sur un objectif commun. Nous considérons que la passation est un processus et non une date. Elle doit être planifiée dès le début du projet et être considérée comme un transfert progressif des connaissances et des opérations de l'équipe du projet vers les activités habituelles.

Pour que les produits à livrer, les connaissances et les responsabilités puissent être transmis à quelqu'un, un plan de gestion de projet doit clairement définir quand quelque chose doit être transféré et quelles sont les exigences précises. Les dates, les priorités et l'attribution des responsabilités doivent être clairement communiquées. L'approximation de ces éléments peut mettre en péril la passation.

Tout comme le souligne l'Association for Project Management dans un rapport : "Dans le cadre de la réalisation d'un projet, on peut avoir tendance à adopter une approche de sage-femme qui consiste à transmettre l'enfant à la naissance et à souhaiter bonne chance aux parents.”.

Cette approche met en péril la réalisation des développements, car elle ne s'attache pas à préparer aux responsabilités et aux changements nécessaires. La préparation avant le transfert et le soutien après le transfert constituent une partie essentielle de la préparation de la transition. Par conséquent, nos processus de passation de devs requièrent deux étapes : l'avant-passation, et la passation. Nous mettons l’accent sur la préparation.

Note : dans le cadre d'une passation d'un projet (et non de développeur·se), se trouve une troisième étape de suivi post-passation.

Voici les points sur lesquels nos équipes sont formées.

Lorsqu'une nouvelle personne arrive sur un projet, nous préconisons un point central des informations. Selon la dimension du projet ou de l'organisation du SI, il peut prendre la forme d'un portail de devs et à plus petite échelle, il peut s'agir d'un simple fichier README.md à la racine du projet. Nous attachons une grande importance à ce que ce dernier référence les éléments suivants :

Nos devs et architectes veilleront à ce que cette description succincte reprenne le contexte dans lequel le projet s'inscrit. Les raisons de son existence, comment s'intègre-t-il dans le SI de l'organisation, les problèmes qu'il tente de résoudre et les moyens technologiques employés.

Lorsqu’une API est mise en place, nous encourageons la mise en place de guides de style dédiés à l’API. L'objectif est de définir des normes permettant d'établir une qualité cohérente de l'aspect et de la convivialité de celle-ci.

Ces guides de style peuvent contenir des règles sur la façon de gérer la gestion des versions, le filtrage, les formats d'erreur, les conventions de dénomination, la pagination et toute autre partie d'une API, aidant ainsi les équipes à prendre ces différentes décisions.

Nous encourageons la mise en place d’un guide de style de code garantissant que tous les membres de l'équipe suivent les modèles de conception modernes. Issus de l'Open Source, ils améliorent l'expérience de développement. La cohérence du code est synonyme de prévisibilité et permet aux développeurs internes et externes de travailler plus facilement avec votre code source, et de le prendre en main plus rapidement. Lorsque celui-ci est agréable à utiliser, l'adoption et la rétention augmentent.

Parmi tous les bénéfices qu'apporte le versioning d'un projet, appliquer des règles de format des commits et le choix d'un bon workflow permet une meilleure collaboration, une meilleure gestion des retours en arrière, des bugs et des déploiements, et évite les écueils tels que les conflits de modification. Nos équipes sélectionnent les méthodes adaptées au projet.

Nos devs documentent les étapes nécessaires pour le démarrage du projet. Cela permet d'appréhender en surface l'infrastructure du projet. Ce kit de démarrage fait gagner du temps afin de se concentrer plus rapidement sur l'essentiel : le code métier.

Les grandes orientations techniques d’un projet sont souvent contextuelles. Avec le temps les raisons deviennent plus difficiles à transmettre avec la même précision. Pour pallier ceci, nos architectes rédigent des fiches de décisions d’architecture (ADR), un document qui rend compte d'une décision architecturale importante prise, ainsi que de son contexte et de ses conséquences.

Lorsque certaines parties du code nécessitent des explications, ajouter des lignes de documentation au-dessus est une bonne pratique. Lorsque des choix techniques sont rapportés à un contexte particulier, et s'éloignent des pratiques communes, nos développeurs prévoient et annotent lorsque des corrections et améliorations peuvent être apportées.

Comprendre les responsabilités de chaque brique applicative est indispensable pour anticiper les comportements et usages. Cela nous permet de mieux anticiper les problèmes, les incidences de nouveaux développements, de la difficulté inhérente, et donc lors des réunions de sprint planning d'avoir des estimations plus justes.

In fine, une infrastructure bien documentée aura un impact positif sur la vélocité, réduira le temps d'adaptation et la courbe d’apprentissage avant d'atteindre la vitesse de croisière. Dans un cadre de gestion de projet et budgétaire, cela offrira une meilleure visibilité et permettra d'anticiper les besoins humains avec précision.

Nos architectes se chargent de sélectionner les méthodes modernes d’urbanisation de SI et de créer ces représentations.

La cartographie d’une organisation, c'est représenter des informations sous forme graphique pour mieux comprendre l’activité et l’organisation de l’entreprise, et bénéficier d’une vue globale et immédiate des éléments représentés. D’un seul coup d’œil, nous pouvons visualiser les liens d’un élément avec les autres (processus, procédures, départements, règlements, rôles, risques, contrôles, collaborateurs, actifs, etc.) sans devoir analyser de longs textes.

Grâce à cette cartographie, une nouvelle personne peut facilement identifier les goulots d’étranglement ou les éléments critiques de l’organisation.

Nos architectes peuvent se charger de créer ces cartographies.

La plupart du temps, le système manque de tests. Lorsque que c'est le cas, nous déterminerons quelles sont les parties critiques de l'application :

Nos développeurs et développeuses se chargent de la rédaction de tests pour ces parties du projet. C’est un excellent investissement pour le travail futur. C'est aussi un excellent moyen de comprendre le fonctionnement du système et de découvrir les bizarreries les plus importantes auxquelles il y a à faire face lors de l’écriture du code.

Les exécuter automatiquement dans la chaîne d'intégration continue est un excellent garde-fou pour la stabilité de votre application. C'est aussi un grand confort et une assurance pour les nouveaux arrivants qui vont pouvoir s'atteler rapidement à des tâches sans craindre de casser le moindre comportement.

Si nous pouvons prévenir et réduire les inquiétudes, le moment de l'arrivée d'une nouvelle personne n'est pas à délaisser. La passation elle-même est une planification. Chez Les-Tilleuls.coop, nous veillons à ce que cette étape cruciale entre nos équipes et les vôtres se déroule dans les meilleures conditions.

Nous nous synchronisons avec votre agenda pour créer une période de passation. Cette planification sert à fixer une durée pendant laquelle deux personnes occupent le même poste. Elle permet d'assurer que toutes les informations aient bien été transmises, et le cas échéant de corriger les documents afin d'améliorer les prochaines passations et arrivées.

Avec vous, nous :

Il est important qu'une communication claire soit faite afin de prioriser le transfert de connaissances plutôt que la correction des derniers bug avant le départ.

Une liste sera rédigée afin de s'assurer de ne rien oublier :

Et afin de s'assurer de la bonne passation, nous envoyons un email récapitulatif de tout ceci.

Et vous ? Appliquez-vous aussi ces pratiques dans la passation de vos projets ? N’hésitez pas à prendre contact avec nous si vous souhaitez du conseil ou un audit sur vos pratiques de développement !