Comment décomposez-vous un grand projet en livrables ?

Question

Accepted Answer

Un grand projet est un mur de risques et d'incertitudes. Le diviser en petites pièces indépendamment expédiables le rend **planifiable, parallélisable et réductible en risques**. L'art consiste à découper de sorte que chaque pièce livre de la valeur et révèle les risques tôt.

## Pourquoi c'est important

```text
✓ Slice VERTICALLY — thin end-to-end features, not horizontal layers
✓ Ship the RISKIEST/most uncertain part early — learn before you commit
✓ Make each slice INDEPENDENTLY valuable and shippable if possible
✓ Keep slices SMALL — days, not months
✓ Sequence so the team can work in PARALLEL
✓ Define DONE for each (tested, deployed, not just "code written")
```

## Le vertical surpasse l'horizontal

Ne construisez pas « tout le backend, puis tout le frontend », vous n'avez rien de démontrable pendant des semaines et intégrez à la fin (où tout casse). À la place, construisez une seule fonctionnalité mince complètement, de bout en bout, puis la suivante. Vous livrez et apprenez en continu.

## Un exemple concret

Pour « construire un système de rapports », le premier découpage n'est pas « la couche de base de données ». C'est « un rapport, données réelles, à l'écran, de bout en bout ». Cela prouve que tout le pipeline fonctionne et donne aux utilisateurs quelque chose pour réagir la première semaine.

## Une trappe

Découper trop finement crée une surcharge de coordination ; trop grossièrement et vous êtes de retour au risque du big-bang. Visez des découpes qu'une personne peut terminer en quelques jours.

## Pourquoi c'est important

Les projets big-bang échouent en big-bang, vous le découvrez tard, quand il est coûteux de changer.

Les petits découpes verticales vous permettent de livrer de la valeur tôt, de corriger le cap à moindre frais, et de maintenir toute l'équipe productive en parallèle.