Ce qui fait un bon ticket
Rédiger un bon ticket est probablement la tâche la plus difficile de la réalisation d’un projet. C’est aussi celle qui a le plus d’effet sur tout ce qui suit.
Un ticket doit remplir plusieurs conditions pour être réalisé correctement et être réellement utile au projet :
- il correspond au besoin
- il est réalisable et validable de manière autonome
- il est compréhensible par tous les acteurs qui vont intervenir dans sa réalisation et sa validation
- il est cohérent avec le budget
- il est cohérent avec le planning
Les deux dernières conditions sont souvent oubliées à la rédaction. Un ticket irréprochable sur le fond mais qui ne tient ni dans le budget ni dans le planning n’est pas un bon ticket : c’est un sujet à retravailler.
Il existe plusieurs types de demande : nouvelle fonctionnalité, correction, lot d’évolution. La trame ci-dessous est notre base commune, elle s’allège ou s’étoffe selon le cas.
La trame d’un ticket
Le titre
Le titre doit permettre de comprendre et de retrouver le ticket sans avoir besoin de l’ouvrir. Nous le préfixons par le type de demande ou par la partie du projet concernée :
- TECH : amélioration du code coverage
- TECH : montée de version 5.4
- STAT : météo des campagnes
- FACTURE : création d’un avoir
L’objectif
Avant d’entrer dans le détail, il faut prendre de la hauteur. Un ticket commence donc par un titre de niveau 2 Objectif, d’une à trois lignes en général. C’est un résumé qui doit faire comprendre le résultat attendu et le niveau de qualité souhaité.
L’objectif du ticket à deux utilités : cerner le besoin au moment de la rédaction et se recentrer en cours de réalisation quand le détail prend le dessus.
Un administrateur doit pouvoir accéder à l’ensemble des informations d’un prospect et les modifier.
L’import de fichier dans la base prospect doit pouvoir supporter des fichiers de 10 000 lignes.
Un utilisateur doit pouvoir se connecter à son questionnaire le plus simplement possible, tout en nous assurant qu’il s’agit bien de la bonne personne.
Les données complémentaires
Deux informations s’ajoutent explicitement selon le contexte :
- Origine : l’origine de la demande ou qui l’a remontée. L’auteur du ticket n’est pas toujours celui qui est à son origine. Par exemple : atelier utilisateur du JJ/MM/YYYY, assistance client avec le lien du ticket, Sentry avec l’URL de l’erreur, demande par email du JJ/MM/YYYY.
- Temps : défini par le responsable du projet, il indique où le temps passé sur ce ticket doit être saisi.
La description
La description apporte le contexte de la demande et les étapes à réaliser. Sauf pour un ticket basique ou un bug simple, elle est divisée en sous-parties : une par étape de la réalisation.
Le ticket porte donc un second titre de niveau 2 Description, suivi d’un titre de niveau 3 par sous-partie. Pour la mise en place d’un CRUD sur un client :
- Liste des clients
- Création et édition d’un client
- Suppression d’un client
Cette structure sert autant à la compréhension de la demande qu’au suivi de son avancement.
Le découpage en checklists et sous-tâches
Selon la difficulté de la demande, les étapes tiennent dans une seule checklist ou dans plusieurs, pour isoler des règles de gestion plus spécifiques.
Le découpage apporte deux choses : la certitude que tous les points sont traités et un responsable clair pour chaque action.
Sur une demande plus complexe, plusieurs checklists cohabitent :
Quand la demande est plus lourde encore, les sous-tâches permettent de construire une arborescence de tickets. C’est aussi la bonne configuration pour structurer une partie du projet ou un lot d’évolution.
Si le workflow paraît trop juste pour une demande, c’est presque toujours le découpage qui manque, et non une étape supplémentaire.
Jeux de données
Lors de la conception, vous devez définir des données d’exemple réalistes pour confirmer et illustrer votre demande. Une conception trop théorique aboutit à des règles inutiles ou à des oublis. Les exemples réels alignent la conception et la réalisation, ce qui évite les erreurs d’interprétation sur une partie de la demande.
Ce travail a sa page dans ce chapitre : les jeux de données.
Validation
La validation se prépare dès la phase de conception !
Lorsque vous rédigez votre ticket, vous devez expliquer clairement le process de validation afin que la personne assignée puisse pleinement comprendre le périmètre de la tâche qu’il doit réaliser.
Suivant la difficulté de la tâche, la validation peut se dérouler en une ou plusieurs actions ou être traitée en tant que sous-tache.
Ce travail a sa page dans ce chapitre : préparer les cas de test.