# Ameno - Gestion des Tickets

**Type** : Outil / Guide d'utilisation
**Domaine** : Gestion de projet / Product Management
**Outil** : Ameno
**Date de capture** : 26 décembre 2025

---

## 🎯 À quoi sert cet outil

Ameno est l'outil de gestion de tickets/tâches utilisé pour organiser le travail de l'équipe.

**Cas d'usage principaux** :
- Créer et suivre des tickets (bugs, features, tâches)
- Organiser le backlog
- Suivre l'avancement des sprints
- Prioriser le travail

---

## 📋 Guide d'utilisation

### Créer un ticket

#### Informations obligatoires
- **Titre** : Clair et descriptif
- **Type** : Bug / Feature / Tâche / Amélioration
- **Description** : Contexte, problème, résultat attendu
- **Priorité** : Haute / Moyenne / Basse

#### Template de ticket

```markdown
**Contexte**
[Pourquoi ce ticket existe ?]

**Problème / Besoin**
[Qu'est-ce qui doit être résolu/fait ?]

**Résultat attendu**
[À quoi ressemble le succès ?]

**Critères d'acceptation**
- [ ] Critère 1
- [ ] Critère 2

**Notes techniques** (optionnel)
[Informations pour les devs]
```

---

### Workflow des tickets

```
📝 À faire → 🔄 En cours → 👀 En review → ✅ Terminé
              ↓
           ⏸️ Bloqué
```

#### Statuts
- **À faire** : Ticket prêt à être pris
- **En cours** : Quelqu'un travaille dessus
- **Bloqué** : En attente d'une action externe
- **En review** : Code/livrable en attente de validation
- **Terminé** : Validé et déployé/livré

---

### Bonnes pratiques

#### 1. Titres de tickets
❌ **Mauvais** : "Fix bug"
✅ **Bon** : "Fix : L'export PDF plante avec plus de 100 pages"

❌ **Mauvais** : "Améliorer UX"
✅ **Bon** : "UX : Ajouter feedback visuel lors du chargement des données"

#### 2. Description
- **Toujours inclure le contexte** : Pourquoi ce ticket ?
- **Être spécifique** : Éviter les ambiguïtés
- **Critères d'acceptation mesurables**

#### 3. Priorisation
- **Haute** : Bloquant, impact critique, deadline proche
- **Moyenne** : Important mais non urgent
- **Basse** : Nice to have, améliorations

#### 4. Taille des tickets
- **Idéal** : Ticket complétable en 1-2 jours
- **Si > 3 jours** : Découper en sous-tickets
- **Si < 2h** : Peut-être trop granulaire (sauf bugs rapides)

---

## 🔗 Intégration avec le workflow

### Lien avec [[Trunk-Based-Development]]

Quand on utilise Trunk-Based Development :
- **1 ticket = 1 branche courte** (< 24h)
- Découper les gros tickets pour respecter cette contrainte
- Utiliser les feature flags si le ticket nécessite plusieurs jours

### Lien avec les sprints

- **Sprint planning** : Sélectionner tickets du backlog
- **Daily** : Mettre à jour statut des tickets
- **Review** : Démo des tickets terminés
- **Retro** : Analyser vélocité et process tickets

---

## ⚠️ Erreurs courantes

### Erreur 1 : Tickets trop vagues
**Problème** : "Améliorer la performance"
**Solution** :
- Spécifier quelle métrique améliorer
- Définir la cible (ex: "Réduire temps de chargement de 5s à 2s")

### Erreur 2 : Tickets zombies
**Problème** : Tickets en "En cours" depuis des semaines
**Solution** :
- Review hebdomadaire des tickets en cours
- Réassigner ou fermer si bloqué
- Découper si trop gros

### Erreur 3 : Pas de critères d'acceptation
**Problème** : Flou sur "c'est terminé quand ?"
**Solution** :
- Toujours définir 2-5 critères mesurables
- Valider avec le demandeur avant de commencer

---

## 💡 Astuces avancées

### Labels / Tags utiles
- `#tech-debt` : Dette technique
- `#quick-win` : Gains rapides, faible effort
- `#breaking-change` : Nécessite attention particulière
- `#user-request` : Demande utilisateur directe

### Filtres pratiques
- **Mes tickets en cours** : Assigné à moi + Statut "En cours"
- **Tickets bloqués** : Statut "Bloqué" → à débloquer prioritairement
- **Tickets sans assigné** : Pour sprint planning

### Automatisations possibles
- Ticket créé depuis bug tracker automatiquement
- Notification Slack quand ticket bloqué
- Fermeture auto quand PR mergée

---

## 📊 Métriques à suivre

### Par sprint
- **Vélocité** : Nombre de tickets terminés
- **Taux de complétion** : % tickets planifiés vs terminés
- **Temps moyen par ticket**

### Par type
- **Ratio Feature/Bug/Tech Debt** : Équilibre du travail
- **Tickets reportés** : Indicateur de sur-planification

### Qualité
- **Tickets rouverts** : Indicateur de définition incomplète
- **Temps en "Bloqué"** : À minimiser

---

## 🔧 Configuration recommandée

### Champs personnalisés utiles
- **Points d'effort** : Estimation (Fibonacci : 1, 2, 3, 5, 8)
- **Impact utilisateur** : Haute / Moyenne / Basse
- **Équipe** : Quelle équipe prend le ticket
- **Version cible** : Pour quelle release

### Vues recommandées
1. **Kanban board** : Vision flux de travail
2. **Backlog priorisé** : Liste ordonnée par priorité
3. **Sprint actuel** : Focus sur le sprint en cours
4. **Roadmap** : Vision long terme par épic

---

## 🔗 Ressources

### Documentation Ameno
- [Lien vers doc]() - *À compléter*

### Process équipe
- [[Projets/Seenaps/README|Workflow Seenaps]] - Process spécifique projet

### Concepts liés
- [[Méthodes/Management/Agile-Scrum]] - Framework global
- [[Trunk-Based-Development]] - Impact sur granularité tickets

---

## 🏷️ Tags

#outil #gestion-projet #product-management

---

## 📝 Notes

**Utilisation actuelle** :
- Projet [[Projets/Seenaps/README|Seenaps]]

**Points d'amélioration identifiés** :
- *À documenter au fur et à mesure*

**Intégrations actives** :
- *À compléter*

---

*Dernière mise à jour : 26 décembre 2025*
*Note créée avec template par Claude Code*