Tâche et ticket — ce que c'est, systèmes de suivi et travail avec les tâches

Qu'est-ce qu'une tâche et un ticket ?

Tâche — une unité de travail enregistrée dans un système de suivi. Elle contient description, priorité (Critical, High, Medium, Low), responsable, date limite et statut. Dans le développement mobile, une tâche peut être « Ajouter un écran de profil avec avatar », « Implémenter la pagination du fil d'actualité » ou « Mettre à jour targetSdk vers 35 ». Chaque tâche est liée à un projet, sprint et à un développeur ou une équipe spécifique.

Ticket — une entité plus large. Un ticket peut être un rapport de bug (« L'application plante lors de la rotation de l'écran sous Android 14 »), une demande de fonctionnalité (« Ajouter le support du thème sombre »), une demande d'assistance technique (« La notification push n'arrive pas ») ou une tâche du manager (« Préparer le rapport de taux de crash du mois »). La frontière entre tâche et ticket est floue : dans Jira, les deux concepts sont combinés dans Issue. La différence clé : une tâche a toujours un responsable, tandis qu'un ticket peut être une demande sans responsable spécifique jusqu'au triage.

Dans Scrum et Kanban, les tâches sont l'élément principal du backlog. Chaque tâche doit répondre aux critères INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Les tâches indépendantes peuvent être implémentées dans n'importe quel ordre. Estimables — l'équipe peut estimer l'effort. Petites — tiennent dans un sprint. Testables — ont des critères d'acceptation clairs. Les grandes tâches (epics) sont décomposées en tâches plus petites jusqu'à ce que tous les critères soient remplis.

Types de tâches dans le développement mobile

Feature — nouvelle fonctionnalité de l'application. Exemple : « Écran de connexion biométrique (Face ID / Touch ID) ». Les tâches Feature sont toujours liées à une user story et ont des Critères d'Acceptation. L'estimation est en story points (1, 2, 3, 5, 8, 13). Bug — un défaut trouvé lors du développement ou des tests. La priorité d'un ticket de bug est déterminée par la gravité (crash → Critical, bug UI → Medium, faute de frappe → Low). Dans le développement mobile, un taux de crash supérieur à 0,1% est un bug critique nécessitant une correction immédiate.

Tech Debt / Chore — tâches techniques sans effet visible pour l'utilisateur : mise à jour de bibliothèques (Dependency Bump), refactoring (Migration de ViewPager vers ViewPager2), configuration CI/CD, écriture de tests. Les tâches de Tech Debt sont souvent sous-estimées, bien que selon Stripe 2025, jusqu'à 30% du temps d'une équipe mobile est consacré à la maintenance et au remboursement de la dette technique. Ignorer la dette technique entraîne une augmentation des bugs et un ralentissement du développement des nouvelles fonctionnalités.

Types supplémentaires : Spike (tâche de recherche — explorer une nouvelle technologie, écrire un POC), Task (tout travail non lié au code — documentation, revue de design), Improvement (amélioration d'une fonctionnalité existante — optimisation du temps de chargement d'écran). Dans Jira, les types d'issues sont personnalisables par projet. L'ensemble standard pour une équipe mobile : Story, Bug, Task, Improvement, Epic. Epic — un grand thème unissant plusieurs histoires. Exemple : « E-commerce : panier et finalisation de commande ».

Cycle de vie d'une tâche : de la création à la clôture

Open (To Do) — tâche créée mais non commencée. Contient description, Critères d'Acceptation, priorité. Dans ce statut, la tâche doit passer par le grooming (affinement et estimation) avant d'entrer dans un sprint. In Progress — le développeur a commencé à travailler. Dans le développement mobile, il est important de lier les commits et pull requests à la tâche : dans Jira via Smart Commits (APP-123 #comment fix bug), dans GitHub/GitLab via des mots-clés dans la description du PR (Closes APP-123).

In Review — code envoyé pour révision. Vérifications automatiques : CI (Gradle build, lint, unit tests), SonarQube (qualité du code), Danger (changelog, tests). Le développeur ne peut pas prendre la tâche suivante tant que la tâche actuelle est en Review — cela évite le multitâche. QA / Testing — le testeur vérifie sur des appareils réels (Android — différentes versions d'OS et tailles d'écran, iOS — différents modèles d'iPhone). Si des bugs sont trouvés, la tâche retourne en In Progress avec un commentaire.

Done (Closed) — tâche terminée : code fusionné dans main/master, testé, prêt pour la sortie. Certaines équipes ajoutent un statut Deployed — la tâche atteint l'utilisateur seulement après la publication du build dans les stores. Il est important de fermer les tâches avec un commentaire sur le résultat : quelle version, quel PR, quelles métriques ont changé. Selon Linear (2025), les équipes qui ferment les tâches avec une description du résultat ont 40% moins de chances de revenir aux mêmes tâches.

Le cycle de vie peut inclure un statut Blocked — la tâche ne peut pas être terminée en raison d'une dépendance externe (attente de design, réponse du backend, approbation du manager). Les tâches bloquées doivent avoir un commentaire avec la raison et la date de la prochaine vérification. Une revue hebdomadaire des tâches bloquées aide à identifier les retards systémiques dans le processus de développement. Les bloqueurs durant plus de 2 semaines nécessitent une escalade au niveau du product manager.

Systèmes de suivi des tâches

Jira — la norme industrielle pour les équipes de 10 personnes ou plus. Prend en charge les tableaux Scrum et Kanban, la personnalisation avancée des workflows, les champs personnalisés, les automatisations et l'intégration avec Bitbucket/GitHub. Inconvénients : excessif pour les petites équipes, UI lente, configuration complexe. Pour les projets mobiles, Jira est personnalisé avec : le plugin Mobile-specific fields (Platform, OS version, Device model), l'intégration avec TestFlight et Firebase Test Lab, et l'automatisation des builds de release. Jira est le choix pour les projets d'entreprise avec des processus bureaucratiques.

Linear — un tracker moderne pour les équipes produit. UI rapide, support de première classe pour les raccourcis clavier, Cycle intégré (analogue au sprint), intégration avec GitHub et Slack. Avantages : création rapide de tâches via CMD+K, distribution automatique en phases (Triaged → Backlog → Upcoming → Current → Completed), documentation et roadmaps intégrées. Linear est choisi par les startups et les équipes produit qui valorisent la vitesse. En 2025, 40% des nouveaux projets mobiles utilisent Linear.

Trello — un tableau kanban simple pour les petites équipes (2–5 personnes). Cartes avec listes de contrôle, étiquettes, dates d'échéance. Inconvénient : pas de sprints, analytique limitée, difficile à passer à l'échelle. YouGile — un analogue russe de Trello avec tableaux kanban, chat et visioconférences. Asana — un tracker axé sur les projets et les chronologies. Le choix du tracker dépend de la taille de l'équipe, du budget et des préférences : Jira pour l'entreprise, Linear pour les équipes produit, Trello/YouGile pour les startups. Important : l'outil doit être unifié pour toute l'équipe — designers, développeurs, QA, managers travaillent tous dans le même système.

Bonnes pratiques pour la gestion des tâches

Écrivez des Critères d'Acceptation — les critères d'acceptation doivent être spécifiques et vérifiables. Mauvais : « L'écran de connexion fonctionne ». Bon : « L'utilisateur saisit son email et mot de passe, clique sur Connexion. Si les identifiants sont corrects — navigation vers l'écran principal. S'ils sont incorrects — affichage de l'erreur « Email ou mot de passe invalide » ». Les Critères d'Acceptation (CA) sont le contrat entre le développeur, le testeur et le product manager. Sans CA, une tâche ne répond pas à la Definition of Ready (DoR) et ne doit pas entrer dans un sprint.

Lie tout. Commits, PRs, cas de test, maquettes de design (Figma), discussions Slack — tout doit être lié à la tâche. Dans Jira, cela se fait via des liens dans les commentaires ; dans Linear, via la liaison automatique des PR. La règle d'un clic : de la tâche au design/code/tests — pas plus d'un clic. Le développeur ouvre la tâche et voit immédiatement la maquette Figma, le lien PR et les cas de test. Cela accélère l'intégration des nouveaux membres de l'équipe de 30% selon Linear (2025).

Ne créez pas de tâches fantômes. Une tâche sans description, sans CA et sans priorité est une poubelle. Si à la daily personne ne se souvient pourquoi une tâche a été créée — elle doit être supprimée ou clarifiée. La règle des 48 heures : si une tâche est restée en statut In Progress sans activité pendant 48 heures, le développeur doit laisser un commentaire sur les raisons du retard. Selon Jira (2025), 60% des tâches inactives plus de 3 jours finissent par être fermées sans être terminées.

Décomposition des tâches : epics, user stories et sous-tâches

Epic — un grand domaine fonctionnel unissant de nombreuses histoires. Exemple : « Onboarding utilisateur » inclut « Écran de bienvenue », « Sélection des centres d'intérêt », « Téléchargement d'avatar », « Paramètres de notification ». User Story — une tâche du point de vue de l'utilisateur. Format : « En tant que [rôle], je veux [action] afin de [valeur] ». Exemple : « En tant qu'utilisateur, je veux me connecter par biométrie pour ne pas avoir à saisir mon mot de passe à chaque fois ». Les User Stories sont écrites par le product manager ou le product owner.

Sous-tâche (Sub-task) — décomposition du travail technique au sein d'une Story / Task. Exemple pour la Story « Écran de profil » : Sous-tâche 1 : Construire l'UI (XML / SwiftUI), Sous-tâche 2 : Connecter au ViewModel, Sous-tâche 3 : Écrire les tests unitaires, Sous-tâche 4 : Tests de snapshot, Sous-tâche 5 : Tests UI (Espresso / XCUITest). Règle de décomposition : chaque sous-tâche est terminée en 1–2 jours. Si un développeur estime une sous-tâche plus longue — divisez-la davantage. Les sous-tâches sont une technique interne d'équipe, elles ne sont pas visibles dans le backlog produit. La somme des estimations des sous-tâches n'est pas nécessairement égale à l'estimation de la Story parent (une partie du travail est la communication, la revue de code, les tests).

Pyramide de décomposition : Epic (Trimestre / Semestre) → Feature / Story (Sprint) → Task (1–3 jours) → Sub-task (Plusieurs heures). La technique INVEST aide à vérifier la qualité de la décomposition. Si une tâche n'est pas Independent (dépend d'autres) — cela signale une décomposition incorrecte. Si une tâche n'est pas Small (plus de 8 story points) — elle nécessite une division supplémentaire. Modèle courant : Epic → 5–15 Stories → chaque Story → 3–8 Sub-tasks. L'estimation finale de l'epic = somme des estimations des Stories, mais le premier sprint donne généralement une marge d'erreur de 20–30% dans les estimations.

Erreurs courantes lors du travail avec les tâches

Erreur 1 : tâches trop volumineuses. Une tâche de 2 semaines est un epic qui doit être décomposé. Les grandes tâches ne peuvent pas être intégrées dans le suivi quotidien ; elles restent en In Progress pendant des semaines. Règle : taille maximale d'une tâche — 2–3 jours de travail. Tout ce qui est plus grand doit être décomposé. Effet secondaire : le développeur ressent une progression en fermant 2–3 tâches par semaine au lieu d'une tâche géante. Cela augmente la motivation et la prévisibilité du calendrier.

Erreur 2 : absence de Critères d'Acceptation. Le développeur a implémenté la fonctionnalité, le testeur a vérifié — tout va bien. Le manager : « Où est le bouton d'édition ? » — « Ce n'était pas dans la tâche ». Sans CA, chaque partie comprend la tâche différemment. Résultat : reprise, conflits, délais non respectés. CA est un contrat : si la tâche n'a pas de critères, elle n'est pas prête pour le sprint. Lors du grooming, la première chose vérifiée est la présence de CA. Si CA manque, la tâche est renvoyée au Product Manager pour affinement.

Erreur 3 : oublier la dette technique. L'équipe ne fait que des tâches Feature sprint après sprint. Six mois plus tard : la compilation prend 15 minutes, Gradle est en retard de 3 versions majeures, les tests échouent sur CI en raison de dépréciations. Solution : réserver 20% du temps de l'équipe pour la Tech Debt (pratique Google SRE « Budget d'erreur basé sur SLO »). Créez au moins une tâche de Tech Debt pour chaque sprint de Features. Proportion : pour 3 tâches Feature — 1 Tech Debt ou Bug. Cela évite l'accumulation de dette technique et maintient la vélocité de développement.