Vous êtes développeurs et vous faites de l'agile, et donc vous êtes fiers de livrer de la valeur pour vos clients et utilisateurs. Et lorsqu'un souci arrive, vous faites tous les efforts possibles pour résoudre le problème et remettre tout en ordre pour vos utilisateurs. Mais, accordez-vous assez d'attention à vous-même dans votre travail quotidien ? Combien de temps perdu à traiter les anomalies ?
Il est temps de réaliser qu'un développeur doit commencer par prendre soin de lui-même, dans le but de pouvoir mieux prendre soin de ses clients et utilisateurs !
Charité bien ordonnée commence par soi-même
Vous avez déjà entendu ce proverbe, qui évidemment est une piètre façon de vous convaincre.
"Il faut préserver ses intérêts pour pouvoir aider l'autre dans la durée. On est en effet parfois tenté d'être excessif dans sa générosité (pour des questions de reconnaissance, existence, etc.) ce qui fera qu'on ne recommencera peut-être pas ou qu'on ne pourra plus recommencer." (source: l'internaute)
On ne doit surtout pas se négliger et oublier d'être sympa, de penser à soi. Au contraire, on doit tout faire pour se rendre la vie plus facile. "Une sorte d'égoïsme utile voire indispensable pour ne pas se rendre l'esclave" des problèmes et risquer de se mettre en situation difficile. Un peu comme le conseil de penser en priorité à soi, à son couple puis à ses enfants, dans cet ordre, afin justement de pouvoir mieux être généreux avec tous.
Equipements de remontées mécaniques à la montagne, avec échelles, passerelles et barrières de sécurité pour la maintenance facile.
Les problèmes "exceptionnels" sont-ils vraiment si rares ?
Vous utilisez certainement un mécanisme de logging dans vos logiciels. En cas de souci signalé par un utilisateur, le réflexe est de rechercher le fichier qui pourra expliquer ce qui s'est passé, puis d'analyser dans le code, la base de donnée etc. Ce n'est pas spécialement agréable, surtout en situation d'urgence, avec un client énervé ou impatient de l'autre coté du téléphone. Est-ce vraiment une situation rare ?
Vous mettez en production, vous vous connectez au système et là c'est le drame : des erreurs partout apparaissent, et l'application qui vous semblait bien testée ne se comporte pas du tout comme sur l'environnement de pré-production. Vous commencez alors à enquêter, d'une façon ou une autre, avec là encore, la pression du manager qui vous demande toutes les 10 minutes ce qui se passe. Est-ce vraiment une situation rare ?
Un trader vous appelle pour savoir pourquoi un trade a eu lieu à un prix qu'il n'a jamais soumis. Là encore, vous fouillez les logs pour comprendre si l'erreur provient de lui ou du logiciel. Est-ce rare ?
Vous gérez une place de marché avec des dizaines de catégories de produits, chacun avec son taux de taxe produit par produit. Changement de président, changement de taux de taxe et il faut mettre à jour des centaines de paramétrages. Les équipes qui s'occupent habituellement de cela sont dépassées et ça vous revient. Vous devez alors improviser un script. Ça vous rappelle quelque chose ? Est-ce vraiment une situation si rare que ça ?
Le toit d'un monument, avec escaliers et barrières pour une circulation facile. C'est vrai qu'on va sur le toit tout le temps, c'est bien connu !
Comment font les autres métiers ?
Lorsqu'on construit une usine chimique, avec des énormes machines, des tuyaux tentaculaires et des grandes hauteurs, la facilité d'accès pour la maintenance est conçue dès les premiers plans et représente une part importante du coût. Cela vaut-il la peine ? A vous de conclure.
Sur les installations de remontées mécaniques à la montagne, les échelles et les passerelles sur chaque pylône sont très visibles. Une installation de remontées mécaniques serait fortement simplifiée sans tous ces équipements, qui pourtant sont systématiquement installés.
Un moteur de bateau, avec ses passerelles et escaliers pour accéder facilement à chaque détail. Quel luxe !
Les ponts aussi intègrent des passerelles et escaliers pour leur inspection intime et leur entretien. Les moteurs géants sur les bateaux sont aussi encombrés de passerelles et escaliers pour faciliter l'accès à chaque pièce. Il semble que les autres industries ont fait un choix clair, le choix d'investir pour rendre la vie des techniciens de maintenance plus facile. Il ne faut pas oublier que les exemples précédents concernent des installations à longue durée de vie, mais c'est bien le cas de la grande majorité des logiciels. Même un logiciel prévu pour être remplacé à court ou moyen terme se retrouve finalement vivre bien plus longtemps, comme illustré avec les bugs autour du passage à l'an 2000.
Passerelles d'accès de maintenance sous un pont. Pourtant on aurait pu se contenter d'une grue ou d’échafaudages le jour où on a besoin de maintenance...
Que faire alors ?
Lors des rétrospectives par exemple, réfléchissez au temps passé sur les détails des problèmes : combien de temps passé à retrouver l'heure du problème de production ? Combien de temps à rechercher le bon fichier de log ? Combien de fichiers à ouvrir pour expliquer le bug ou la plainte du client ?
Repensez à toutes les frustrations de votre dernier sprint. Mieux, notez toutes vos frustrations sur un post-it au moment où vous les rencontrez et ajouter-les dans une corbeille dédiée ou sur une timeline sur le mur. Cela améliorera énormément vos rétrospectives, comme expliqué par Linda Rising lors d'une conférence en octobre dernier.
En passant en revue chaque frustration rencontrée vous aurez un sentiment plus précis de la pénibilité totale quand vous intervenez sur votre propre application. C'est le signe qu'il est temps de penser à vous, dans l'intérêt de tous, et d'améliorer enfin votre logiciel pour votre propre usage, votre usage de développeur.
Si une application de e-trading par exemple, on pourra ajouter une page dans la section d'administration pour directement consulter les logs en mémoire, filtrés par date, utilisateur et section du workflow de trade. Sur un logiciel très intensif en base de données, on pourra ajouter un écran avec des droits spéciaux qui permet d'écrire des requêtes SQL directement, en lecture seule par exemple. Pourquoi ne pas re-utiliser des protocoles comme RSS pour diffuser les logs et les consulter dans votre navigateur, ou Jabber (XMPP) pour certaines interactions ?
Il s'agira souvent d'ajouter de l'observabilité à votre application, et selon Steve Freeman et Nat Pryce (auteurs de l'excellent livre Growing Object-Oriented Software Guided by Tests, ou #goos), cette observabilité est aussi la clé pour tester de bout-en-bout votre système. Ce qui est bon pour vous est aussi bon pour vos tests.
Comment prioriser ces caprices de développeurs ?
Dans votre équipe Scrum, toute story est dans le backlog et est priorisée par le Product Owner. Comment faire admettre l'importance d'une story à destination des développeurs ? Je n'ai pas de réponse toute faite, et tout dépend de votre force de persuasion. Une idée est de chiffrer les frustrations en temps ou story points, pour mettre en évidence l'impact sur la capacité de l'équipe. Il reste naturel que le Product Owner décide et arbitre en fin de compte entre une "vraie" feature, et une feature qui améliorera la livraison des features suivantes en rendant la vie des développeurs plus facile. Vos opinions sur tout ça ?
Directeur Technique d'Arolla
Excellent, ça fait réfléchir !
PS :
“Passerelles d’accès de maintenance sous un pont. Pourtant on aurait pu se contenter d’une grue ou d’échafaudages le jour où on a besoin de maintenance…”
XD……..