Utiliser Trello comme bugtracker ?

Dans ma quête incessante pour outiller mes clients de sorte que leur collaboration au projet ne soit pas une source de stress ni de coût pour moi, je cherche à éviter les démoniaques habitudes « email x Word x Excel ». Et puis arrive cet épisode critique du projet qu’est la Recette.

La recette (oublions la capitale dramatisante), même si on est agile, est ce moment où le prestataire a livré une version utilisable du produit, charge au client de l’essayer, le faire marcher avec des jeux de données, des cas d’usages etc. Ce qui souvent (toujours) donne l’occasion de rencontrer des bugs.

🐛 Des bugs !!!?

Ben, oui, ça arrive avec les projets numériques, comme avec l’informatique… Même si souvent ce ne sont pas vraiment des bugs, mais soit des cas d’usage non spécifiés (c’est mal, d’où Agile) soit des nouvelles idées que le client ou l’utilisateur aura en jouant pour la première fois avec son idée devenue logiciel (d’où Agile), soit des menus ajustements de wording / maquette. Pour rester neutre, on va parler de « tickets ».

Un bon protocole de communication entre les patries prenantes du projet est crucial. Y compris avec le client (donneur d’ordres, maître d’ouvrage…) Pourquoi ? Simplement pour réduire la friction, réduire les risques liés à des informations mal collectées, mal formulées, mal qualifiées, mal transmises, finalement mal comprises…

Pour collecter les observations des premiers utilisateurs, quand je suis en charge d’un projet, j’essaie d’interdire E-mails et listes Excel. En effet, l’impression de familiarité — « tout le monde sait se servir de l’e-mail et d’un tableur » — masque souvent l’absence d’un protocole de communication efficace. Il en résulte des litiges qui peuvent tourner au conflit, temps perdu, coût.

Conscients de ce besoin, les développeurs ont inventé les bug-trackers ou Logiciels de suivi de problème ou de gestion de tickets. Les plus couramment utilisés : TRAC, Redmine, Mantis, Bugzilla… Il y en a des tas1, plus ou moins pratiques. Jamais présentables à un « vrai » utilisateur : rentrer un bug est fastidieux, bureaucratique, la présentation des états est décourageante, même si les fonctionnalités y sont, ils ressemblent plus à une base de données qu’à un outil de collaboration.

En revanche j’ai constaté que les utilisateurs arrivent à entrer dans la logique d’une interface de type tableau de suivi de tâches, façon tableau Kanban2, du nom de la fameuse méthode de gestion de projet japonaise. Des web-applications de ce type, y en a des tas aussi. Par exemple l’excellent Azendoo (proudly developped in Bordeaux)

Simple-kanban-board-.jpg
By Jeff.lasovskiOwn work, CC BY-SA 3.0, Link

Pour ce projet, j’avais converti les auteurs / utilisateurs à Trello. Trello est un outil de gestion de projet en ligne basé sur une organisation en tableaux sur lesquels l’équipe définit des colonnes représentant un état d’avancement d’une fraction unitaire de projet, celui-ci représenté par une « carte ». Les cartes sont assignables à des utilisateurs, peuvent avoir une échéance, faire l’objet de descriptions et commentaires, recevoir des pièces jointes, des check listes etc. Outre son caractère intuitif — la métaphore du tableau à colonnes est triviale — les utilisateurs apprécient la flexibilité de l’outil, qui permet de définir une structure de projet et des règles adaptées à leurs besoins.

Voici une façon d’utiliser Trello dans un groupe de travail, pour le suivi de tickets.

L’objectif est de collecter et suivre les tickets de dysfonctionnements créés par les utilisateurs lors de tests et des premiers temps d’usage d’une application.

On crée un nouveau Tableau Trello

Avec 4 colonnes :
– tickets
– pris en charge
– à retester
– résolu

Dans ce tableau, on définit des étiquettes, code couleur auquel on attribue une valeur conventionnelle, dan ce cas, la sévérité du bug :
– critique : rouge
– majeur : orange
– mineur : bleu marine
– cosmétique : bleu clair

Et on met en place le process :

1. testeur : découverte d’un dysfonctionnement

2. testeur : copie d’écran
outils recommandés : SnagIt Windows, Skitch, sur Mac, ou une extension de navigateur si le projet est en ligne

3. testeur : création de la carte Ticket dans Trello avec a minima,
– nom explicite du ticket
– description du dysfonctionnement, condition du test etc.
– attache de la copie d’écran

4. chef de projet, si besoin : échanges avec le créateur du ticket

5. chef de projet : attribution de sévérité (étiquette)

6. chef de projet : affectation au développeur concerné

7. chef de projet : possible création d’une checklist au sein de la carte

8. développeur : déplacement de carte dans la colonne Pris en charge

9. développeur si besoin : échanges avec le créateur du ticket

10. développeur : livraison de la correction -> déplacer dans la colonne À retester

11. développeur : attribution à l’auteur du ticket pour tests

12. testeur si besoin : échanges avec le développeur ou le chef de projet

13. testeur : déplacer dans la colonne Résolu

On voit que ce process fait une bonne part à la communication, à l’échange entre les parties prenantes. Un autre bénéfice est la transparence. Le cycle de vie de la carte « ticket » et son déplacement de colonne en colonne permet d’avoir une vue d’ensemble des tâches de débugage en cours, leur prise en compte et leur issue. Ce qui est toujours appréciable pour les personnes qui testent une application nouvellement livrée.

Trello used as ticket management (source) : un exemple d’usage de Trello pour la gestion de tickets, un peu plus compliquée que notre propre schéma


  1. sur Wikipedia 

  2. Kanban board 

Ce contenu a été publié dans e-business, avec comme mot(s)-clé(s) , , , . Vous pouvez le mettre en favoris avec ce permalien.
  • Thanks for sharing this helpful information with this smart explanation.

  • mikeefos

    Good article about what should be necessary procedures when moving into testing phase of all developments.

    The importance of clear bug tracking sometimes gets overlooked in the urgency of rolling out projects.

    One observation that I have made is the need for easily adding images to tickets. Solutions such as Mantis only enables the user to add images saved from their computer, which can prove to be tiresome when dealing with multiple tickets.

    To remove this constraint another useful tool to use is Gitlab as this solution enables the user to copy screenshots directly into the body of the tickets without having to save and then upload it.

    • Thanks for reading and commenting Mike. You’re right: adding screenshots is often tedious. But with Skitch or Snagit, or event the OS native screen capture utilities, it is « less worse ». About getting actual users on any Git clients… Really?

      • mikeefos

        Our major issues was using Mantis and the amount of bugs we were having to treat. As screen captures is a ‘must have’ we found the extra step of having to capture, save and then upload it added to the tasks on hand.

        By using GitLab we had a benefit that we were able to plug into the development projects in progress and use the Issue Board and which is essentially a Kanban where we create a grab and paste this directly into the body without having to upload.

        https://youtu.be/UWsJ8tkHAa8

        I realise that this is also a possibility with Trello and I can see the only difference between these two options is that the developers preferred to have only one tool (GitLab) and not have to check tasks in Trello and then toggle back to their development in Git.

        It’s always about making your developer happy! It makes life so much easier!

        In saying that, I do find Mantis stripped back and also powerful. Also the user role management is good when needed to share with clients.

        Thanks again!