Pourquoi les tickets existent

Les connaissances de l'équipe stockées uniquement dans les têtes sont des connaissances avec un point de défaillance unique. Un développeur qui « sait simplement » comment fonctionne le pipeline de déploiement, quelles variables d'environnement sont requises ou pourquoi le service d'authentification a cette logique de nouvelle tentative étrange porte une mémoire institutionnelle à laquelle le reste de l'équipe ne peut pas accéder, qu'elle ne peut pas rechercher ou vérifier.

Les tickets externalisent ces connaissances dans un système partagé et consultable. Lorsqu'un développeur crée un ticket pour un élément de travail, il ne fait pas que suivre une tâche — il enregistre que le travail existe, ce qu'il nécessite et pourquoi il est important. Six mois plus tard, lorsque quelqu'un demande « avons-nous déjà corrigé la condition de concurrence dans le flux de paiement? », la réponse est une requête de recherche, pas un message Slack à quelqu'un qui a peut-être quitté l'entreprise.

L'alternative — garder le travail dans les têtes, les fils Slack et les notes autocollantes — fonctionne pour une équipe de 3 personnes dans une même pièce avec une mémoire parfaite. Cela se brise dès que quelqu'un part en vacances, change de projet ou démissionne. Chaque élément de connaissance stocké exclusivement dans la tête d'une personne est un risque de facteur bus que l'équipe choisit de porter. Les tickets n'éliminent pas le besoin de conversation, mais ils donnent à ces conversations un artefact durable qui survit aux personnes qui les ont eues.

Chaque décision non triviale dans une base de code finit par être remise en question. « Pourquoi avons-nous ajouté ce point de terminaison? » « Qui a décidé d'abandonner le support d'IE? » « Quand la logique de tarification a-t-elle changé? » Sans tickets, répondre à ces questions nécessite de l'archéologie — fouiller dans Slack, contacter d'anciens coéquipiers, lire les différences de commits et deviner l'intention.

Les tickets créent une piste de décision. Chaque ticket enregistre qui a demandé le travail, quand il a été priorisé, quels étaient les critères d'acceptation et — par le biais des PR et commits liés — exactement quel code a changé pour le réaliser. Ce n'est pas du travail inutile; c'est la différence entre « je pense que nous avons changé ça en mars » et « voici le ticket, la PR et la discussion de révision ».

La traçabilité compte aussi pour la conformité et la réponse aux incidents. Lorsqu'un bogue de production apparaît, la question « qu'est-ce qui a changé récemment? » devrait prendre des secondes, pas des heures. Une équipe avec une bonne hygiène de tickets peut retracer d'un déploiement à une fusion, d'une fusion à une PR, d'une PR à un ticket et d'un ticket à la demande originale. Une équipe sans cela lit git log et devine.

Les tickets sont la couche de coordination pour les équipes qui ne peuvent pas être dans la même pièce en même temps. Dans une équipe colocalisée de trois personnes, vous pouvez coordonner en tournant votre chaise. Dans une équipe distribuée de huit personnes réparties sur trois fuseaux horaires, « parlez-vous simplement » n'est pas une stratégie de coordination — c'est un souhait.

Un système de tickets donne à chaque élément de travail une URL stable, un statut et un responsable. Un développeur à Londres peut prendre un ticket, voir ce qui est attendu, vérifier les critères d'acceptation et commencer à travailler — sans attendre que le développeur à San Francisco qui l'a créé se réveille. Le ticket est le point de transfert asynchrone.

Cela fonctionne aussi bien pour les petites équipes que pour les grandes. Même une équipe colocalisée bénéficie de la coordination asynchrone lorsque les gens sont en réunion, malades ou en travail de concentration profonde. Le ticket est toujours disponible. La personne qui l'a écrit ne l'est pas.