En tant que Product Owner / Product Manager nous sommes amenés à accompagner différentes équipes de développement au quotidien. Que nous ayons des compétences techniques ou non, il est important de comprendre ce sur quoi notre équipe travaille (et bloque parfois) afin d’avoir la vision d’ensemble qui nous permettra de gérer correctement notre produit et nos ressources.

Dans ce cadre, vous avez peut être déjà été confrontés à une situation dans laquelle votre développeur tente de résoudre un bug bloquant sans trouver de solution. Après maintes et maintes tentatives, la solution n'apparaît pas et votre développeur se retrouve seul face à un mur. Ayant été confronté à cette situation je me suis posé la question suivante : Comment, en tant que Product Owner n’ayant pas la compétence technique nécessaire pour accompagner le développeur sur la résolution de son problème, je peux l’épauler pour l’aider à trouver une solution ?

Afin de répondre à cette question je vous propose plusieurs ateliers que j’ai pu expérimenter, destinés à accompagner le développeur dans son processus d’analyse du problème, dans sa démarche d’identification des éléments corrompus et dans la mise en place de son plan d’action pour traiter le bug et résoudre le problème. La meilleure solution reste bien évidemment la collaboration entre développeurs, cet article est volontairement orienté vers la collaboration entre un PO et un développeur afin de proposer des solutions alternatives permettant de ne pas déranger d’autres développeurs de l’équipe. Ces différentes solutions ne marchent pas forcément à tous les coups mais dans certains cas elle vous permettront d’aider votre développeur à trouver la solution qui le délivrera.

1 : Identifier le problème et sa source

La détection d’un bug est généralement assez simple car il est souvent découvert coté front et se traduit par un élément qui ne fonctionne pas, par la remontée d’une erreur ou encore par un test qui ne passe pas lors de compilation de l’application. L’identification de la source du problème peut en revanche être beaucoup plus complexe et mener à la situation précédemment expliquée.

Prendre du recul

La première chose à faire pour épauler votre développeur dans ce cas de figure, est de l’aider à prendre du recul sur la situation. Lorsqu’il est sur la résolution d’un bug complexe, il peut entrer assez profondément dans son code et petit à petit se concentrer sur quelques éléments en oubliant la notion de big picture. L’important est ici de lui offrir la possibilité de prendre le recul nécessaire pour analyser son problème et le moyen de le résoudre.

La première étape va consister à mettre à plat l’ensemble des éléments. Votre développeur doit commencer par expliquer à voix haute son problème de manière simple et détaillée pour qu’il puisse être compris par tout le monde. Cela vous permettra de mieux cerner le problème rencontré, aidera votre développeur à mieux identifier son problème et à le formuler.

Vous pouvez ensuite lui demander de schématiser sur un paperboard l’architecture globale ou partielle de l’application afin de recréer les différents flux de données et interactions qui nous aideront à identifier l’endroit où le process est corrompu. Une fois ce schéma réalisé, demandez à votre développeur de vous expliquer en détail (à l’aide de l’architecture dessinée) le flow depuis le démarrage l’application jusqu’au cheminement qui mène au blocage. Cette étape devrait vous permettre dans un premier temps d’avoir une vision plus globale de l’ensemble des variantes pouvant influer sur le bug à traiter et dans un second temps de cibler plus précisément les zones de blocages qui seront vos premières pistes à creuser.

La méthode du Rubber duck debugging

Une fois ces pistes identifiées vous pouvez vous inspirer de la méthode du « Rubber duck debugging» qui consiste à demander au développeur de lire son code à voix haute et d’expliquer chacune des lignes pour comprendre la raison de son implémentation. Initialement prévue pour un développeur seul, cette technique se pratique normalement avec un canard en plastique jaune (comme celui du bain) à qui le développeur s’adresse et qui a pour rôle d’écouter le développeur sans jamais poser de question. Le but n’est pas d’avoir un interlocuteur qui va comprendre l’aspect technique du code et nous apporter une réponse, l’idée est simplement d’énoncer à voix haute l’ensemble des lignes de code afin de faire appel la dissonance cognitive qui permettra au développeur de se rendre compte de son erreur en l’entendant. Je préconise de prendre le rôle du canard, cela vous permettra d’en apprendre davantage sur la structure du code et rendra plus humaine cette interaction pas toujours évidente à mettre en place en open space.

Si d’aventure les éléments examinés lors des premières étapes n’étaient pas suffisants pour identifier la source du bug, je vous conseille d’intégrer de nouveaux outils de monitoring tel que New Relic qui vous permettront de réunir des informations supplémentaires pouvant vous aider à mieux identifier le problème. Faire appel à d’autres développeurs, qu’ils soient en interne sur le projet ou qu’ils fassent parties de la « communauté », peut également être un bon moyen de trouver une solution, de nombreux sites permettent l’entraide entre développeurs. Enfin, vous pouvez bien évidemment tenter une petite recherche Google pour voir si d’autres personnes ont déjà été confrontées à ce cas de figure et comment il a été résolu.

2 : Corriger le problème

Lorsque le problème et sa source sont identifiés, vous pouvez aider votre développeur à mettre en place un plan d’action qui lui permettra d’avancer et de tester différentes hypothèses pour résoudre le bug.

Dégager des pistes de résolution

Je vous propose ici un atelier assez simple à réaliser : Notez sur un paperboard l’ensemble des hypothèses de solutions proposées par votre développeur pour corriger le bug (n’hésitez pas à lui demander d’être exhaustif). Demandez lui ensuite d’attribuer une note allant de 1 à 5 destinée à déterminer le degré de complexité de développement de chacune des hypothèses avancées (1 = peu complexe, 5 = très complexe). Demandez lui ensuite d’attribuer une autre note à chacune des hypothèses mais cette fois ci concernant la probabilité de réussite estimée (1= Cette solution me semble très viable pour résoudre le bug, 5= Cette solution est une piste qui me semble être peu prometteuse). Une fois les notes attribuées, additionnez-les, vous obtiendrez un score sur 10 qui vous donnera une idée de priorisation pour le traitement de vos hypothèses. Les notes les plus faibles étant celles à traiter en priorité. Comme tout atelier, il faut l’utiliser comme un outil, votre priorisation réelle sera peut être différente de celle annoncée par les notes, selon les intuitions de votre développeur ou les nouvelles informations que vous récolterez.

Suivre la résolution du problème

Lorsque votre développeur attaquera le développement de ses hypothèses, n’oubliez pas de tenir à jour le statut des différentes hypothèses testées en renseignant les raisons de leur échec, cela vous donnera de nouvelles billes pour aborder le problème d’une manière différente. Encore une fois, faire appel à d’autres développeurs peut s’avérer très bénéfique, n’hésitez donc pas à organiser une session de pairing avec un autre développeur sur le sujet ou encore un brainstorming rapide avec l’ensemble de l’équipe, cela pourrait faire émerger de nouvelles solutions. En dernier recours vous pouvez aller jusqu’à l’organisation d’une rétro sur le sujet afin d’analyser l’ensemble du processus de développement et concentrer les efforts de tous les membres de l’équipe sur la résolution de ce problème.

Je ne peux conclure cet article sans rappeler l’importance d’avoir un code propre, structuré et monitoré, n’hésitez donc pas à abuser des tests unitaires, des outils de monitoring, de l’organisation de sessions de code review ainsi que de sessions de refactoring cela vous permettra de réduire vos risques de bug et simplifiera votre lecture du code. Voici d’ailleurs un très bon article au sujet des tests automatisés.

Ces différentes techniques devraient vous aider à accompagner vos développeurs dans les moments difficiles, n’hésitez pas nous faire un retour d’expérience sur le sujet dans les commentaires situés juste en dessous.