Catégories
e-business

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