Décomposition du travail

Capacités clés

Identification des tâches — Identifier les unités de travail discrètes et implémentables à partir des exigences haut niveau
Analyse des dépendances — Déterminer l'ordre des tâches, leurs relations et les dépendances bloquantes
Définition du périmètre — Créer des descriptions de tâches claires et délimitées avec des critères d'acceptation
Organisation en phases — Regrouper les tâches connexes en phases d'implémentation logiques

Approche

1. Lire et comprendre les exigences

Examiner le document d'exigences complet
Comprendre le périmètre complet et tous les critères de succès
Identifier les composants majeurs et les sous-systèmes affectés
Noter les exigences de sécurité et les contraintes

2. Identifier les composants système

Quelles parties de la base de code sont affectées ?
Quels API, services, bases de données, interfaces utilisateur nécessitent des modifications ?
Quels systèmes externes ou dépendances sont impliqués ?
Plusieurs plateformes sont-elles affectées (web, desktop, mobile, CLI) ?

3. Décomposer en phases

Organiser le travail en phases logiques :

Phase 1 : Architecture et conception

Concevoir l'architecture système et les modèles de données
Créer des diagrammes de séquence, des diagrammes de flux de données
Définir les contrats API et les interfaces
Modélisation des menaces de sécurité (si applicable)

Phase 2 : Implémentation

Développement des fonctionnalités principales
Modifications du schéma de base de données
Création des endpoints API
Développement des composants UI
Travail d'intégration

Phase 3 : Test

Développement des tests unitaires
Développement des tests d'intégration
Scénarios de test de bout en bout
Tests de sécurité (si applicable)
Vérification multi-plateforme

Phase 4 : Documentation et déploiement

Documentation utilisateur
Documentation API
Procédures de déploiement
Scripts de migration (si nécessaires)

4. Définir les tâches individuelles

Chaque tâche doit être :

Bien dimensionnée : Réalisable en 2-8 heures (pas en jours)
Indépendante : Peut être traitée sans bloquer sur d'autres tâches incomplètes (sauf dépendances explicites)
Testable : Dispose de critères d'acceptation clairs vérifiables
Spécifique : Description claire de ce qui doit être fait
Assignée : Rôle ou équipe identifié (ex. « Équipe backend », « Équipe sécurité », « QA »)

5. Identifier les dépendances

Quelles tâches doivent être complétées avant que d'autres ne commencent ?
Y a-t-il des flux de travail parallèles qui peuvent progresser indépendamment ?
Quelles dépendances externes existent (mises à jour de librairie, API tierces) ?
Quelles portes d'approbation sont nécessaires (revue de sécurité, revue de conception) ?

6. Valider l'exhaustivité

Les tâches couvrent-elles tous les exigences fonctionnels ?
Les exigences non-fonctionnels sont-ils traités (performance, sécurité, fiabilité) ?
Les tests sont-ils suffisamment planifiés ?
La documentation est-elle incluse ?
Les commandes/tests de vérification sont-ils définis ?

Modèle de tâche

Chaque tâche doit suivre cette structure :

**Tâche X.Y** : [Titre de tâche concis]

- **Description** : [Ce qui doit être fait]
- **Équipe/Rôle** : [Backend | Frontend | Sécurité | QA | DevOps]
- **Durée estimée** : [2-8 heures]
- **Dépendances** : [IDs de tâches à compléter en premier, ou « Aucune »]
- **Livrables** : [Résultats ou modifications spécifiques]
- **Critères d'acceptation** : [Comment vérifier l'achèvement]

Exemple

Voir examples/oauth-authentication.md pour un exemple complet travaillé.

Bonnes pratiques

À faire

✅ Bien dimensionner les tâches — 2-8 heures chacune, pas des jours ou semaines entiers
✅ Critères d'acceptation clairs — Doivent être testables et spécifiques
✅ Assigner aux équipes appropriées — Adapter la tâche à l'expertise
✅ Regrouper les tâches connexes — Organiser en phases pour la clarté
✅ Identifier les dépendances — Rendre explicites les relations bloquantes
✅ Assurer l'exhaustivité — Tous les exigences couverts, rien d'orphelin
✅ Inclure la vérification — Tâches de test et validation pour chaque fonctionnalité
✅ Planifier la documentation — Les docs techniques et utilisateur sont des livrables
✅ Considérer la sécurité — Modélisation des menaces et tests de sécurité inclus
✅ Penser multi-plateforme — Bitwarden fonctionne partout ; planifier en conséquence

À ne pas faire

❌ Tâches trop grandes — Les tâches >1 jour doivent être décomposées davantage
❌ Critères d'acceptation vagues — « Faire fonctionner » n'est pas testable
❌ Dépendances circulaires — Les tâches ne doivent pas se bloquer mutuellement en boucles
❌ Phases manquantes — Ne pas sauter la conception, les tests ou la documentation
❌ Livrables peu clairs — Chaque tâche doit produire quelque chose de concret
❌ Ignorer les plateformes — Ne pas oublier mobile, CLI, extensions de navigateur
❌ Ignorer la sécurité — Les tâches de sécurité ne sont pas optionnelles chez Bitwarden

Format de résultat

Organiser la décomposition du travail en phases structurées :

# Décomposition du travail : [Nom de la fonctionnalité]

## Résumé

- **Durée estimée totale** : X-Y heures
- **Nombre de tâches** : N tâches sur M phases
- **Équipes impliquées** : [Liste des équipes]
- **Chemin critique** : [Dépendances clés ou goulots d'étranglement]

---

## Phase 1 : [Nom de la phase]

**Objectif** : [Ce que cette phase accomplira]

**Tâche 1.1** : [Titre de tâche]

- **Description** : [Ce qui doit être fait]
- **Équipe/Rôle** : [Qui le fait]
- **Durée estimée** : [Heures]
- **Dépendances** : [Prérequis ou « Aucune »]
- **Livrables** : [Résultats concrets]
- **Critères d'acceptation** : [Comment vérifier]

**Tâche 1.2** : [Tâche suivante]
...

---

## Phase 2 : [Nom de la phase]

...

---

## Vérification

Une fois toutes les phases complétées, vérifier :

- [ ] Tous les exigences fonctionnels implémentés
- [ ] Tous les exigences non-fonctionnels satisfaits
- [ ] Tous les exigences de sécurité traités
- [ ] Tous les tests réussis (unitaires, intégration, E2E)
- [ ] Documentation complète et exacte
- [ ] Procédures de déploiement testées

work-breakdown