Tour d'horizon de Themis

1ère étape : Consultation quotidienne des retours personnalisés 

Cockpit.PNG

Pour qui ?

Le Cockpit permet à chaque développeur de consulter sous forme de fil d'actualité l'impact de ses dernières modifications sur le code en termes de qualité. Le Cockpit peut également être utilisé par les animateurs pour analyser les dernières tendances sur chacun des projets.

Quelles données consulter ?

La lecture du Cockpit doit permettre à chaque développeur d'identifier les défauts de code ajoutés, ainsi que la compréhension des bonnes pratiques associées dans une démarche d'amélioration continue (comment le défaut peut-il être corrigé ?). Les fichiers de code source peuvent être directement ouverts depuis Themis pour obtenir une meilleure compréhension du problème. Idem pour les tests : lorsque la couverture de code d'un fichier a diminué, ou si du code ajouté n'est pas couvert par des tests, le développeur peut facilement détecter les portions de code à l'origine de ce résultat. A l'inverse, le Cockpit conforte chaque développeur lorsqu'il réalise des actions saines, et valorise encore plus son travail dans le cas d'actions réparatrices. 

Quand l'utiliser ?

L'utilisation du Cockpit est recommandée quotidiennement pour chaque développeur, lorsqu'il sait qu'il a effectué des modifications sur le code et qu'il souhaite identifier son impact sur la qualité. En fonction du paramétrage de synchronisation des données appliqué dans Themis, plusieurs consultations par jour peuvent faire du sens. Les développeurs peuvent également choisir d'être notifiés (Mail, Slack, ...) lorsque de nouvelles actions sont disponibles. Le but de ces retours personnalisés sont que les développeurs prennent l'habitude d'aller de manière régulière sur Themis.

2ème étape : Diagnostic et identification des axes d'amélioration

Diagnostic.PNG

En quoi ça consiste ?

La rubrique "Diagnostic" vous apporte une compréhension fine et globale des actions sur un ensemble de projets. Le diagnostic s'effectue par pratique et propose les catégories suivantes :

  • L'évolution du nombre d'actions saines, nocives et réparatrices
  • La répartition des contributions par équipes et développeurs
  • La localisation des actions dans la cartographie du code 

La pratique "Dette technique" offre deux catégories supplémentaires, à savoir :

  • L'ensemble des règles de bonnes pratiques avec le nombre de défauts restants à corriger
  • L'ensemble des règles de bonnes pratiques corrigées/violées sur une période de temps, avec des précisions sur la localisation et les développeurs impliquées

L'utilisation des Filtres dans la barre située en haut de l'écran vous permet d'affiner votre analyse. 

Pour qui ? 

Cette rubrique est destinée aux animateurs et aux développeurs pilotes pour identifier les axes d'amélioration des équipes sur les projets en cours, mais aussi plus généralement pour observer les progrès réalisés ainsi que l'état de santé des projets. 

Quand l'utiliser ?

Il est conseillé d'utiliser cette rubrique à la fin d'une période, en fonction de la dynamique des projets (sprints, 2 semaines/3 semaines). Il est préconisé ensuite de rassembler l'équipe pour partager ces informations, faire un retour d'expérience ensemble et valider collectivement les actions à mener et les préconisations à prendre pour la suite.

3ème étape : Les plans d'actions pour concrétiser votre stratégie 

PA.PNG

En quoi ça consiste ?

Les plans d'actions permettent de définir une liste d'objectifs à atteindre par les équipes. Ces objectifs, qui peuvent être individuels ou collectifs, peuvent avoir différentes natures : non-création de dette, nombre d'actions réparatrices à effectuer, nombre de défauts de code à corriger sur une pratique bien spécifique, ... Un plan d'action a une date de fin qui permet de borner et de calibrer finement les efforts que l'on souhaite mettre en oeuvre sur la stratégie de qualité. Les plans d'actions sont un excellent moyen de fournir aux développeurs les rappels et "todos" en termes de qualité. 

Pour qui ? 

Les plans d'action sont généralement définis par des animateurs ou bien des développeurs pilotes. Chaque développeur peut également librement se créer son propre plan d'action pour l'aider à structurer sa démarche. Les développeurs vont ensuite accéder aux plans d'actions pour obtenir une compréhension des objectifs à atteindre et identifier des actions à mener pour les réaliser. 

Quand l'utiliser ?

Les plans d'action peuvent être créés à tout moment au sein d'une période. Il est préconisé de mettre en place en place des plans d'actions en début de période. Les développeurs vont ensuite durant toute la durée du plan d'action consulter l'état d'avancement des objectifs pour identifier le reste à faire. En fin de période, il est préconisé de rassembler l'équipe et d'analyser ensemble l'issue des plans d'actions. Ce travail s'effectue idéalement en complément de l'étape 2 (Diagnostic). Après le debrief des précédents plans d'actions, et suite au travail de diagnostic, les plans d'actions pour la nouvelle période sont mise en place. 

Comment atteindre les objectifs ? 

Pour chaque objectif, Themis accompagne chaque développeur en lui proposant des suggestions personnalisées. Ces dernières sont basées sur les habitudes de travail du développeur, et sur les parties du code qu'il maîtrise le plus. Accessible dans Themis, les suggestions sont également envoyées aux développeurs régulièrement sous forme de notifications.

4ème étape : Le jeu comme vecteur d'engagement

 Jeu.PNG

 

Pourquoi un jeu ?

L'objectif du jeu est de renforcer l'engagement et l'implication des développeurs dans la stratégie de qualité logicielle. Cette partie permet de rendre ludique la gestion au quotidien de la qualité logicielle. Le jeu constitue pour les développeurs une source de motivation supplémentaire à effectuer des actions saines et réparatrices sur le code. 

En quoi consiste le jeu ?

Les développeurs peuvent se rassembler au sein de salon de jeu avec d'autres développeurs. Un salon couvre un ensemble de projets et est rythmé par des tours de jeu, dont la durée est configurée à la création du salon de jeu. 

Dans un salon, chaque développeur possède un niveau qui augmente en fonction des actions effectuées. Les actions saines et réparatrices permettent de remporter des points. Les développeurs peuvent ensuite obtenir des badges. Tous les badges sont uniques et se remportent grâce aux "achievements" des développeurs : peu d'actions nocives, participation aux plans d'actions, réduction de dette technique... Le classement permet d'instaurer une émulation saine et ludique aux sein des équipes.

Il est important de noter que des personnes travaillant sur des projets ou des technologies différentes peuvent participer ensemble au même salon de jeu. Cela permet à plusieurs développeurs ne travaillant pas sur les même projets de tout de même créer une émulation entre eux.

Pour qui ?

Accessible par les développeurs et animateurs, seuls les développeurs peuvent participer à un salon et apparaître dans le classement. Une synthèse des badges et des niveaux sur la période en cours est également accessible via le Cockpit

Chaque développeur est libre de rejoindre un salon de jeu. Il n'y pas d'impact sur le reste de l'utilisation de Themis pour les personnes qui ne participent pas au jeu.

5ème étape : Suivi d'indicateurs et reporting

Suivi.PNG

 

RapportPDF.PNG

Ces pages vous permettent de suivre des indicateurs à plus haut niveau : la dette technique, la couverture de tests, le nombre de bugs. Vous pouvez alors observer l'impact de Themis sur les différents projets. En affinant la fenêtre temporelle grâce aux filtres, vous pouvez ainsi identifier des tendances majeurs sur la période qui vous intéresse. Vous pouvez également importer vos propres données métiers pour détecter des corrélations et métriques possibles. 

Cette partie d'adresse aux animateurs et pilotes en charge de suivre les indicateurs de qualimétrie et indicateurs métiers, et d'identifier les prochaines actions à mener pour atteindre les différents jalons.

Quand utiliser ?

Pour extraire des données de qualimétrie (dette technique, couverture de code, ...) et partager ainsi les résultats des actions menées dans Themis pour des personnes extérieurs à l'équipe, cette rubrique dédiée au reporting fournit des éléments synthétiques sur le suivi des bonnes pratiques et l'impact sur les données de qualimétrie. Le reporting peut être également utilisé en support interne pour les équipes lors des point de fin de période abordés précédemment.

Les rapports PDF serviront à communiquer les données de Themis à l'extérieur. Ils sont utilisés lors des points avec l'équipe afin de synthétiser les informations. 

Cet article vous a-t-il été utile ?
Utilisateurs qui ont trouvé cela utile : 0 sur 0

Commentaires

0 commentaire

Veuillez vous connecter pour laisser un commentaire.