Cet article décrit l’infrastructure et les méthodologies que l’on met en place afin de gérer la leadership technique d’un projet avec:
- Une équipe de 25 personnes
- un public de parties prenantes composé de 270 personnes.
Initialement, l’équipe de SpazioCodice était une cellule de développement indépendante au sein du projet. Progressivement, on nous a demandé de gérer l’ensemble du cycle de développement en termes de
- Planification
- surveillance
- gestion du référentiel logiciel
- gestion des versions et des publications
- tests automatisés
Voici une description détaillée de la manière dont nous avons organisé ce qui précède.
Qu’est-ce que le client s’attendait de nous?
Le client souhaitait que nous mettions en œuvre une combinaison de compétences techniques et managériales.
- La gestion d’équipe
- la gestion des versions
- la planification
- la surveillance et le reporting
- des environnements observables et fiables où chaque fonctionnalité ou correction peut être facilement vérifiée après sa mise en œuvre
- la réinstallation automatique des environnements après la fusion d’une fonctionnalité
- des builds automatisés, centralisés, historisés et observables sur toutes les branches (develop, release, work)
- des notifications via un canal Slack
Comment avons-nous satisfait à ces exigences ?
Dans les sections suivantes, nous avons résumé les principaux éléments qui composent notre approche. Comme vous pouvez le constater, chacun d’eux est un sujet vaste, alors j’ai simplement rédigé un résumé essentiel qui devrait, je pense, donner une bonne idée à ce sujet.
En tout cas, j’aimerais entendre des questions, des doutes et des commentaires à leur sujet. N’hésitez pas à nous contacter dans ce cas.
Itérations
Les itérations sont une manière agile et flexible d’établir des jalons vérifiables de petite taille dans un projet de moyenne/longue durée.
Dans notre expérience, une itération devrait avoir une durée raisonnable en termes de semaines, où “raisonnable” signifie
- pas trop courte, sinon les réunions (voir ci-dessous) sont inutiles et trop rapprochées (par exemple, les participants ont peu ou rien à dire lors d’une rétrospective hebdomadaire), et pas trop longue .
- une itération longue inclut nécessairement beaucoup de travail, ce qui est difficile à terminer et à vérifier.
Bien que la signification exacte de “court” et “long” dépende du contexte concret du projet, nous fixons généralement la durée de l’itération à 3 semaines.
Planifier, suivre et publier : JIRA
Atlassian JIRA est un outil très puissant pour la gestion d’un projet logiciel. Il propose de nombreuses fonctionnalités (au moins plus que nous utilisons) et des intégrations avec des outils externes tels que les référentiels logiciels et les systèmes de build.
Chaque partie prenante pertinente (y compris les développeurs) possède un compte dans JIRA. Le projet suit une approche Scrum, organisé en itérations de 3 semaines.
Le flux de travail de développement est simple. Il y a un backlog où n’importe quel utilisateur peut créer des tickets (bugs, idées, demandes) à tout moment, et un tableau qui contient la quantité de travail planifiée pour l’itération active (c’est-à-dire déplacée dans l’itération avant ou pendant la réunion de planification).
Le tableau de l’itération comprend quatre états différents pour les tickets :
- À FAIRE: Les tickets sont en attente de développement.
- EN COURS: Les tickets sont en cours de traitement.
- RÉVISION: Le résultat du ticket (c’est-à-dire le code, l’analyse, les résultats) est vérifié par une autre personne. Le réviseur examine le code et sa correction formelle et s’assure qu’il y a une couverture de test (formelle) satisfaisante.
- VÉRIFIER: La fonctionnalité/correction a été déployée dans l’environnement vérifiable ; une personne doit vérifier manuellement sa correction. Avant cette phase, le demandeur initial rédige des étapes de vérification détaillées.
- TERMINÉ: Fonctionnalité/ correction implémentée, révisée et vérifiée avec succès. La tâche est accomplie.
Pour les tickets d’analyse, la phase de vérification est ignorée, tandis que, pour les tickets de code, la transition d’une étape à une autre ne peut se faire qu’après le soi-disant « build vert » (c’est-à-dire, l’exécution de la suite de tests automatiques par le système de build et la réussite de tous les tests).
Feuille de route du projet
Une itération est une excellente façon d’organiser des engagements à court terme. Cependant, les projets sont généralement plus longs qu’une itération, et les clients souhaitent avoir une vue d’ensemble à haut niveau de la quantité totale de travail en termes de :
- Quoi
- Quand
- Combien (effort et coût)
Par conséquent, la première chose que nous faisons généralement dans un projet où les exigences fonctionnelles ont été recueillies est une analyse technique, où nous examinons/discutons/exploirons les exigences une par une et créons les tickets JIRA correspondants au niveau “technique”.
D’abord, nous définissons les domaines fonctionnels et techniques de haut niveau ; pour chacun, nous créons un type spécifique de ticket JIRA appelé Épic : tout autre ticket que nous créons doit appartenir à un Épic (c’est-à-dire à une zone de besoins fonctionnels ou techniques). Les tickets peuvent capturer les types de travail suivants :
- Analyse: généralement créée sous forme de « Story » (un autre type de ticket JIRA), elle demande au destinataire d’investiguer une zone spécifique et, à la fin, de créer les tâches d’implémentation correspondantes.
- Implémentation: le type de travail que les développeurs adorent; une tâche d’implémentation est quelque chose, une fonctionnalité par exemple, que le destinataire doit mettre en œuvre.
- Corrections: Les bogues ne sont généralement pas créés dans la première phase (nous n’avons pas de système testable). Plus tard, ils sont très difficiles à prévoir et à planifier. Par conséquent, ils ne font pas partie de la feuille de route.
Jusqu’à présent, tout va bien : nous avons les Épics, et ils sont peuplés des tickets créés lors de l’analyse technique. Maintenant, il est temps de les répartir sur une chronologie.
JIRA vient à la rescousse avec une fonctionnalité appelée (sans surprise) Timeline. Elle permet la création d’une feuille de route qui inclut les Épics et les tâches correspondantes.
L’image suivante en est un exemple.
La colonne de gauche répertorie les Épics. Pour chaque Épic, une barre colorée indique sa durée sur la chronologie. Sous la chronologie, vous pouvez voir plusieurs blocs gris représentant les itérations (Sprints) et les points bleus représentant les versions (0.9 et 1.0 dans l’exemple).
Bien que cette perspective offre une bonne vue d’ensemble du projet, nous pouvons étendre les Épics et voir les tâches concrètes (analyse et/ou implémentation) ainsi que leurs dépendances.
Voyez l’exemple suivant où un Épic a été développé.
Comme vous pouvez l’imaginer, si nous ouvrons tous les Épics, la vue résultante est presque illisible. Cependant, la perspective est très utile car les dépendances entre les tâches sont incluses, et en cas de problème, elles sont mises en évidence en rouge (comme dans l’exemple).
Réunions
Nous avons généralement des réunions régulières et des réunions sur demande. Alors que la deuxième catégorie comprend, comme son nom l’indique, des réunions nécessaires pour un besoin spécifique, les réunions régulières sont les suivantes :
Réunion quotidienne (15 minutes)
Un par un, les membres de l’équipe décrivent brièvement ce qu’ils font, avec d’éventuels défis ou obstacles. En cas de défi ou d’obstacle, une réunion dédiée est planifiée entre le rapporteur et les personnes qui peuvent aider.
Estimation (1 heure)
Lorsqu’un nouveau ticket est créé, quel que soit son type, il va dans la file d’attente du backlog. À ce stade, il n’est pas estimé et n’a aucune priorité.
Pendant la réunion d’estimation, les tickets sont discutés un par un, améliorés dans leurs détails (par exemple, description, versions de correction, critères d’acceptation), estimés et priorisés.
Planification (1 heure)
Avant le début d’une nouvelle itération, son contenu, initialement défini par la feuille de route, est vérifié et éventuellement ajusté en tenant compte de nouvelles priorités soulevées. Ces changements peuvent entraîner une (éventuellement petite) réitération de la feuille de route.
Coup d’envoi et rétrospective (1 heure)
Au début de chaque itération, généralement le premier jour, avant d’appuyer sur le bouton « Démarrer », une courte réunion de lancement est utile pour s’assurer que tout le monde est aligné et satisfait du contenu de l’itération.
Temps de démo : Si une fonctionnalité, une correction ou un résultat d’analyse utile doit être partagé avec l’équipe, le destinataire organise une courte démo/présentation.
Enfin, il y a 5 minutes où chaque membre de l’équipe peut remplir un document Google sur :
- Remerciements et félicitations
- Ce qui s’est bien passé
- Ce qui peut être amélioré (+ points d’action)
Les éléments écrits dans le document sont ensuite lus et discutés ensemble.
Environnements vérifiables
Comme indiqué précédemment, quelqu’un effectue une vérification dans un environnement réaliste avant qu’une tâche puisse être marquée comme terminée.
Cet environnement doit inclure l’ensemble des modules/composants logiciels. La seule différence réside dans les données sous-jacentes, qui devraient être :
- Petites : l’environnement est reconstruit/réinstallé plusieurs fois par jour ; ce processus doit être aussi rapide que possible.
- Contrôlées et déterministes : les données sont créées par des experts du domaine ; lorsque le système démarre, nous connaissons précisément son état.
Il existe deux types d’environnements où cette vérification a lieu:
- Test d’intégration système (SIT): il s’agit de l’environnement directement connecté aux développements. Chaque fois qu’une fonctionnalité/correction est fusionnée dans la branche principale, le service pack ou la branche de correctif, un environnement SIT correspondant est reconstruit pour inclure ce changement. Les environnements SIT contiennent les dernières modifications mais sont très instables car ils sont fréquemment redémarrés/réinstallés.
- Test d’acceptation utilisateur (UAT):
comme son nom l’indique, cet environnement est principalement destiné aux utilisateurs finaux/testeurs (côté client). C’est un endroit où ils peuvent essayer les dernières fonctionnalités mises en œuvre dans le projet, stables et vérifiées. L’environnement est construit périodiquement (par exemple, chaque semaine), il est donc stable pendant cette période.
En note complémentaire, il convient de noter qu’il n’y a pas seulement un SIT et un UAT, mais plutôt un pour chaque version. Cela est nécessaire car si une fonctionnalité est mise en œuvre uniquement dans une version spécifique, il doit y avoir une paire d’environnements vérifiables (SIT et UAT) pour cette branche spécifique.
Référentiel de code : BitBucket
Y a-t-il un projet logiciel sans code ? Le code, la documentation et les artefacts associés doivent être stockés, versionnés, gérés et manipulés.
Nous avons choisi BitBucket comme référentiel logiciel pour le projet que nous discutons. Étant un produit Atlassian, il s’intègre étroitement avec JIRA.
Les modifications sont gérées, organisées et appliquées dans des branches, et il existe plusieurs types de composants :
- Les branches de travail sont des branches temporaires où les fonctionnalités ou corrections sont mises en œuvre.
- Branche principale : la branche où la prochaine version majeure sera publiée. Chaque fonctionnalité ou correction y est d’abord intégrée.
- Branches de Service Pack/Hotfix : immédiatement après la première version (par exemple, 1.0.0), la branche develop ne peut plus capturer les versions installées dans les différents environnements. Par conséquent, nous avons besoin de deux types supplémentaires de branches dans le référentiel logiciel. Les Service Packs sont destinés à capturer des éléments, des fonctionnalités, voire des corrections qui ne représentent pas des fonctionnalités importantes, mais qui introduisent en même temps des changements bloquants, non rétro-compatibles. D’un autre côté, les Hotfixes sont des éléments que nous pouvons appliquer immédiatement à une version existante, principalement des corrections simples de bogues.
Registre de paquets et d'images
Les artefacts logiciels doivent être stockés et versionnés. Malheureusement, Bitbucket ne propose pas ces fonctionnalités, disponibles plutôt dans GitHub et GitLab. Nous avons choisi GitLab sans aucune raison particulière (les registres d’artefacts qu’ils proposent sont similaires).
Les artefacts du projet sont :
- Bibliothèques Java: stockées dans le registre de paquets Maven de GitLab, elles sont utilisées comme dépendances dans le projet.
- Images Docker: stockées dans le registre d’images GitLab, elles sont utilisées pour les tests et les déploiements
Intégration continue : Jenkins
Chaque fois que quelqu’un pousse une modification dans le code, un serveur d’intégration continue dédié, Jenkins, est chargé de s’assurer que tout va bien avec la suite d’intégration.
Spécifiquement,
- Si la modification est liée à une branche de travail, le code est extrait, et la suite de tests d’intégration est exécutée.
- Si la modification est fusionnée dans la branche principale, le code est extrait, la suite de tests d’intégration est exécutée, et l’environnement de Test d’Intégration Système (SIT) est réinstallé à partir de zéro.
- Si la modification est fusionnée dans une branche de Service Pack ou de Hotfix, le code est extrait, la suite de tests d’intégration est exécutée, et le Test d’Intégration Système de l’environnement correspondant (SIT-SP, SIT-HOTFIX) est réinstallé à partir de zéro.
Tout ce que fait Jenkins doit être notifié aux utilisateurs concernés. Pour ce type de notifications, nous avons remplacé les e-mails par un canal Slack dédié:
Versions majeures, Service Packs, Correctifs
Nous avons décidé d’utiliser une approche simple pour gérer les versions et les publications. Tout d’abord, nous avons adopté une approche de versionnement sémantique, qui identifie une version donnée à l’aide de 3 nombres X.Y.Z.
- X, le nombre le plus à gauche, représente une version majeure, qui regroupe un ensemble de fonctionnalités pertinentes (probablement en rupture avec l’API existante).
- Y est la version mineure. Nous augmentons ce nombre lorsqu’il y a des fonctionnalités isolées et bloquantes que nous devons publier avant une version majeure.
- Z est la version de correctif. Nous augmentons ce nombre pour appliquer des correctifs et des changements non pertinents et non bloquants à une version existante
Rapport d'itération
À la fin de chaque itération, le chef d’équipe envoie un rapport informel de synthèse qui comprend :
- Considérations générales
- Domaines d’implémentation couverts
- Défis, obstacles
- Objectif principal de la prochaine itération
Conclusions
La direction technique est une définition de très haut niveau ayant le but de regrouper un ensemble de services qui contribuent à orienter un projet dans la bonne direction. Elle peut être mise en œuvre de plusieurs manières. Ce que nous avons décrit dans cette étude de cas est l’une d’entre elles; c’est ce que nous avons choisi pour gérer un projet.
