La réalisation correspond à l’étape En cours du cycle de vie d’un ticket. Elle commence quand la personne assignée a vérifié qu’elle disposait de tout ce qu’il lui faut et s’achève quand tous les points sont traités et que la validation peut démarrer.
Avant de se lancer
La relecture du ticket n’est pas une formalité de passage d’un statut à l’autre. Elle sert à répondre à trois questions et tant qu’il en reste une sans réponse, le travail ne commence pas :
- ce que nous devons faire, précisément
- comment nous allons le réaliser : techniquement, côté design, seul ou à plusieurs et avec quel impact sur le travail des autres
- comment notre travail sera utilisé et s’il doit être découpé en plusieurs livraisons
Se lancer sans avoir compris la globalité de la demande oblige à refaire des parties du travail faute d’informations, à déranger plusieurs fois les autres pour des questions simples et à revenir sur la demande pendant la validation. C’est notre première source de temps perdu, et la plus simple à éviter.
La troisième question est celle qu’on oublie le plus souvent. Nous ne livrons pas dans le vide : une fonctionnalité s’inscrit dans le travail quotidien et dans les impératifs business de quelqu’un, chez le client comme chez nous. Le calendrier de la livraison fait donc partie de la réflexion, et il se décide au planning.
Une fonctionnalité de code de réduction est estimée à deux jours et posée au planning mardi et mercredi. Pour qu’elle serve, le client doit encore saisir les codes et les associer à ses propres clients. Or il n’est disponible que le mardi après-midi.
Nous livrons donc l’ajout des codes en production mardi en début d’après-midi, pour qu’il fasse sa saisie pendant que nous terminons le reste.
Découper son travail
Entrer dans la réalisation commence par se donner un plan d’actions qui vous permettra d’avancer de manière structurée pour être efficace et ne rien oublier.
L’idée est de découper la tâche en sous-parties indépendantes qui pourront :
- être estimées plus simplement
- être réalisés sur un temps raisonnable
- être finalisés avant de passer à l’étape suivante
Prenons par exemple la réalisation de la tâche suivante :
Ajouter dans l’admin des prospects un onglet permettant la visualisation des réponses aux scripts d’appels ainsi que la possibilité d’éditer les réponses.
Cette tâche peut être réalisée via les étapes suivantes :
- ajout d’un onglet par script selon les options de la campagne
- visualisation des questions et des réponses dans chaque onglet
- écran d’édition sans question pour valider l’enregistrement et le retour à l’écran précédent
- champs d’édition des questions avec chargement des informations actuelles
- action d’enregistrement des modifications
Ce découpage a quatre effets concrets. Il rend l’avancement lisible à tout moment. Il permet de commiter un travail cohérent à chaque étape. Il limite le nombre de fichiers ouverts en même temps, ce qui aide à garder le focus sur l’étape en cours.
Le quatrième effet est moins évident : il rend l’expérimentation possible. Tester une librairie, un outil ou un parti pris de design est bien plus simple quand la charge acquise est sécurisée par un commit propre et qu’un retour en arrière (rollback) est possible.
La mise au point
Quand vous considérez avoir terminé, vous devez prendre du recul et faire une passe globale sur votre poste pour vérifier que tout fonctionne comme demandé. C’est ce que nous appelons la mise au point.
Elle sert à trois choses :
- nettoyer ce qui traîne et ne sert plus
- vérifier que les morceaux s’accordent entre eux, car en travaillant par étapes, nous pouvons faire des redondances ou ne pas avoir un style complètement uniforme
- relire le ticket une dernière fois pour s’assurer que rien n’a été oublié
La mise au point fait partie de la réalisation, pas de la validation. Les tests que vous faites sur votre propre poste ne comptent pas comme une étape de validation, quel que soit leur sérieux.
Anticiper la validation
Selon le contexte, il peut être pertinent d’anticiper la phase de validation pour faire les ajustements nécessaires au plus tôt :
- une première merge request avec une proposition d’architecture pour recueillir un avis
- un premier jet d’affichage pour valider une mise en page
- la livraison intermédiaire d’une partie de la tâche
Dans ces trois cas, il s’agit de travail collectif, pas de l’étape de validation. Le ticket reste En cours et le périmètre de la demande n’a pas encore été soumis à qui doit le valider.
Le travail sur le dépôt pendant cette étape a ses propres règles : la gestion des branches et la merge request.