Petites Livraisons
Livrez de la valeur tôt et souvent. Obtenez des commentaires avant qu'il ne soit trop tard pour changer de cap.
1Pourquoi Livrer en Petites Quantités
XP préconise des livraisons petites et fréquentes. C'était radical en 1999 quand les livraisons annuelles étaient la norme. C'est encore radical dans de nombreuses organisations.
Avantages des petites livraisons :
Rétroaction plus rapide : Les clients voient du vrai logiciel plus tôt. Ils peuvent vous dire ce qui ne va pas avant que vous n'ayez construit trop de la mauvaise chose.
Risque réduit : Chaque livraison est un petit pari. Si elle échoue, vous avez perdu des semaines, pas des mois. Vous pouvez corriger le tir rapidement.
Livraison de valeur plus rapide : Les fonctionnalités terminées sont utilisées. Une fonctionnalité livrée aujourd'hui vaut mieux qu'une fonctionnalité en attente d'une grande livraison dans six mois.
Moral amélioré : L'équipe voit son travail utilisé. Livrer est satisfaisant. Les longs cycles de livraison drainent la motivation.
Meilleure qualité : Des livraisons plus petites signifient des changements plus petits. Les changements plus petits sont plus faciles à tester, plus faciles à déboguer et moins susceptibles de causer des problèmes.
Tout au Minimum Viable
XP a inventé le produit minimum viable (MVP) avant que le terme n'existe. Kent Beck l'appelait « la plus petite livraison qui ait du sens ».
2Quelle Petitesse Est Petite ?
La bonne fréquence de livraison dépend du contexte, mais visez plus petit et plus fréquent que ce qui semble confortable.
Exemples de fréquence :
- Quotidienne (déploiement continu) : Chaque commit va en production
- Hebdomadaire : Livraison à la fin de chaque itération
- Bihebdomadaire : Livraison après chaque deuxième itération
- Mensuelle : Cycle de livraison mensuel
Chaque étape plus petite est meilleure, jusqu'au point où les frais généraux de livraison dominent. Si livrer prend une journée complète de travail manuel, livrer quotidiennement est impraticable. Corrigez d'abord le processus de livraison.
Signes que vous livrez trop peu fréquemment :
- Les livraisons font peur (trop de changements)
- Les problèmes d'intégration sont courants (gros lots)
- Les clients attendent des mois pour les correctifs
- L'équipe a des « semaines de fusion »
3Exigences Techniques
Les petites livraisons nécessitent un investissement technique :
Tests automatisés : Vous ne pouvez pas livrer fréquemment si les tests prennent des semaines. Des tests automatisés rapides et complets sont essentiels.
Intégration continue : Le code doit s'intégrer en douceur. Les branches de longue durée sont incompatibles avec les livraisons fréquentes.
Automatisation du déploiement : Les livraisons doivent être à un clic. Les étapes de déploiement manuel vous ralentissent et introduisent des erreurs.
Indicateurs de fonctionnalités : Les fonctionnalités incomplètes peuvent être fusionnées mais cachées aux utilisateurs. Cela permet de petites livraisons même lorsque les fonctionnalités s'étendent sur plusieurs itérations.
Stratégie de migration de base de données : Les changements de schéma doivent être déployables sans casser le code existant. Habituellement, cela signifie des migrations compatibles avec les versions antérieures.
Surveillance et retour arrière : Quand quelque chose ne va pas, vous devez le savoir immédiatement. Et vous devez pouvoir revenir en arrière rapidement.
Ce ne sont pas des pratiques XP en soi — ce sont des pratiques DevOps modernes qui permettent la vision originale de XP de livraison continue.
L'équipe livre en production chaque mardi. Le processus est automatisé et prend 10 minutes. Les indicateurs de fonctionnalités cachent le travail incomplet. Le retour arrière se fait en un clic.
Les livraisons ont lieu trimestriellement. Chaque livraison est précédée d'un « gel du code » et de 2 semaines de tests manuels. Le jour de la livraison implique 10 personnes et prend 8 heures. Le retour arrière nécessite la restauration de sauvegardes de base de données.
4Des Livraisons au Déploiement Continu
L'extrême logique des petites livraisons est le déploiement continu : chaque commit qui passe les tests va directement en production.
Cela semble terrifiant. Mais avec les bonnes pratiques, c'est en fait plus sûr que les grandes livraisons :
- Chaque changement est minuscule et facile à comprendre
- Si quelque chose casse, vous savez exactement ce qui l'a causé
- Le retour arrière est trivial (le dernier déploiement remonte à quelques minutes)
- Pas de stress du « jour de livraison » ou de déploiements après les heures de travail
Le déploiement continu nécessite :
- Une couverture de tests très élevée
- Des builds très rapides (10 minutes maximum)
- Des indicateurs de fonctionnalités robustes
- Une excellente surveillance
- Une culture de qualité (pas de raccourcis)
Toutes les équipes ne sont pas prêtes pour cela. Mais toutes les équipes peuvent évoluer vers des livraisons plus petites et plus fréquentes. Commencez par livrer deux fois plus souvent. Puis deux fois plus souvent encore. Voyez jusqu'où vous pouvez aller.
Si le déploiement continu semble impossible, demandez-vous pourquoi. Les obstacles que vous identifiez sont généralement des choses que vous devriez corriger de toute façon : tests lents, processus manuels, code fragile.
- Les petites livraisons fournissent de la valeur plus rapidement et réduisent le risque
- Livrez aussi fréquemment que votre processus le permet — puis améliorez le processus
- Les petites livraisons nécessitent des tests automatisés, l'intégration continue et l'automatisation du déploiement
- Les indicateurs de fonctionnalités permettent de fusionner en toute sécurité le travail incomplet
- Le déploiement continu est l'extrême logique — et souvent plus sûr que les grandes livraisons
- •Penser que les petites livraisons nécessitent des fonctionnalités terminées (utilisez des indicateurs de fonctionnalités)
- •Processus de livraison manuels qui rendent les petites livraisons impraticables
- •Attendre « suffisamment » de changements avant de livrer
- •Traiter le jour de livraison comme un effort héroïque au lieu d'une automatisation de routine