Bon que ce soit bien clair : je n’aime pas et je n’ai jamais aimé les dashboards électroniques que l’on peut créer via Jira, Redmine, ou peut importe le logiciel de suivi de besoins.
Je trouve déterminant la mise en place d’un management visuel « physique » (c’est-à-dire bien visible, facilement modifiable et partagé par toute l’équipe) pour la bonne marche d’une équipe.
Et puis il y a dashing. Cela lui là je l’aime bien. Il faut que je vous raconte pourquoi…

Découverte et premier dashboard

J’ai découvert Dashing il y a quelques mois grâce à Vincent et Philippe. C’est un outil open source et gratuit créé par une boite américaine Shopify. J’ai regardé l’outil, vu la démo. C’est cool et c’est joli en effet …
bon …
je retourne bosser.

Mais Philippe insiste. Il envisionne la création d’un dashboard électronique qui nous permettrait de voir en un clin d’oeil si tout est ok sur l’équipe ou non. Son idée est d’avoir des widgets qui soient intégralement verts lorsque tout roule et rouges lorsqu’il y a un soucis et qu’il faut prendre une action.
Un peu pour lui faire plaisir et un peu par curiosité je décide de m’y mettre. Je vois qu’il existe de nombreux widgets, certains attirent mon attention comme le widget Jenkins (état de l’intégration continue), ou le widget Rickshaw graph  qui permet de faire de jolies graphiques.
Cependant, je ne trouve pas forcement mon bonheur pour tout et je me rends vite compte qu’il faudra vite faire du custom…

Je me lance en me posant la question « que voulons nous voir ? » (et non pas : « que pouvons-nous voir ? » ) :

• Certains jobs Jenkins (intégration continue) tombent en échec et nous les laissons parfois rouge quelques jours ce qui nous pose beaucoup de problèmes. 
• Nous avons un mécanisme de réalimentation d’un référentiel qui se lance trois fois par semaine en soirée et celui-ci crash de temps en temps. L’impact est très mineur, mais au plus l’analyse est faite tardivement au plus celle-ci est compliquée.
• L’humeur de l’équipe de teammood. Lorsque certaines journées sont mauvaises (deux/trois membres de l’équipe mettent un mauvais mood) ou au contraire très bonnes, nous ne nous en rendons compte que quelques jours après et il est trop tard pour discuter et comprendre ce qu’il s’est passé.
• Nous avons mis en production un module de floutage automatique des plaques d’immatriculation de voitures et nous nous regardons quasiment quotidiennement ces résultats sur kibana.

Après quelques tâtonnements j’arrive à un premier résultat (note : certaines parties business sont volontairement masquées, désolé 🙂 ) :

C’est encourageant. Avec l’équipe nous jugeons que ce premier opus a assez de valeurs et nous installons donc dashing sur un serveur et demandons un écran dédié pour l’afficher en continue sur notre bureau, bien visible par tous.

Et premiers résultats

Les premiers résultats sont intéressants, nous mettons la gomme pour remettre les builds Jenkins au vert et travaillons pour les rendre moins fragiles. De même pour les réindexations qui tombaient en échecs, nous les voyons maintenant très rapidement et nous finissons par fixer la source du problème.
Autre effet intéressant, le dashboard expose petit à petit aussi nos KPI métiers et cela permet de partager avec nos sponsors nos indicateurs et de nous réaligner sur l’un d’eux.
Enfin, dernier bonus, le dashboard nous permet de faire du monitoring temps réel. Ainsi nous avons pu détecter immédiatement que notre chaine de logs était tombée en rade avant que celle-ci ne finisse par saturer le disque, nous avons pu voir que certains tests de composants étaient lancés directement sur la prod au lieu de la recette ou bien qu’une intégration de clients s’était mal passée.

Les premiers résultats sont intéressants et nous réinvestissons donc pour passer à la deuxième étape : colorer les widget en vert/rouge.
En parallèle nous rencontrons quelques soucis sur le traitement des pull request qui est un peu long et nous créons un widget spécifique pour les voir (cf. précédent article).

Nous rajoutons également quelques widgets : 

• des widget pour afficher nos KPI
• des widgets pour mesurer la performance de notre équipe kanban (lead time, throughput, éléments bloqués)
• un widget pour afficher les versions de nos applications sur tous nos environnements
• à la demande de notre ops un widget pour afficher le nombre de mise en prod

Et enfin un widget giphy pour afficher un gif animé et rendre notre board plus sympa 😀 (ça c’est la faute à Slack et son plugin giphy)

Voici ce que cela donne actuellement : 

Conclusion

Notre dashboard a en partie modifié notre façon de travailler et ce dans le bon sens. Nous voyons sur dashing des informations qui sont trop fastidieuses à maintenir pour être affichées quotidiennement sur notre management visuel physique.

Cependant, la mise en place de dashing a un véritable cout. Il ne s’agit pas d’un produit sur étagère que l’on peut customiser en quelques clics, c’est un outil orienté « techs » que l’on configure à cout de ruby, coffeescript et scss. C’est un peu rebutant au démarrage mais c’est aussi sa force, on va pouvoir au final réellement faire ce que l’on veut, choisir finement ses KPI et avoir un dashboard ultra concis et efficace.
J’aime le résultat final qui contient en un seul endroit les KPI business de l’équipe, les KPI techniques, la santé et la productivité de l’équipe. Si l’on veut tendre vers une équipe homogène avec des objectifs communs et partagés c’est pour moi un bon point de départ.
En terme de motivation le dashboard à aussi un effet rassurant. Lorsque j’arrive le matin est que tout est vert je ne ressens plus le besoin d’aller faire un tour de tous les systèmes. Et le soir lorsque je pars je me sens tranquille sachant que tout est au vert!

Si vous êtes intéressés à vous lancer, le prochain article parlera technique et mise en place de Dashing.
Sinon, si vous souhaitez de l’aide sur la mise en place de dashing chez vous, vous pouvez nous contacter pour que l’on étudie cela ensemble : contact@agiletribu.com