XP + Scrum

Scrum fournit une structure organisationnelle. XP fournit des pratiques d'ingénierie. Ensemble, ils comblent différentes lacunes :

Scrum vous donne :

• Des rôles définis (Product Owner, Scrum Master, développeurs)
• Un rythme (sprints, événements de sprint)
• Des artefacts (Product Backlog, Sprint Backlog, incrément)
• Des structures de responsabilité

XP vous donne :

• Comment bien écrire du code (TDD, refactorisation, conception simple)
• Comment collaborer sur le code (programmation en binôme, propriété collective)
• Comment livrer de manière fiable (CI, petites versions)
• Des pratiques de santé d'équipe (rythme soutenable, normes de codage)

Scrum est silencieux sur la façon dont les développeurs devraient réellement coder. XP comble cette lacune.

La plupart des « équipes Scrum » qui réussissent font en réalité Scrum + pratiques d'ingénierie XP, qu'elles l'appellent ainsi ou non.

Sprints = itérations Le sprint de Scrum est l'itération d'XP. Limité dans le temps, concentré, livrant un logiciel fonctionnel.

Product Backlog = plan de version La planification de version d'XP crée le travail ; le Product Backlog de Scrum l'organise.

Sprint Planning = planification d'itération Même activité : décider quoi construire cette itération, le décomposer en tâches.

Daily Scrum = mêlée quotidienne Même intention : synchroniser l'équipe, faire remonter les blocages.

Rétrospective de sprint = rétrospective XP ne prescrit pas les rétrospectives aussi rigoureusement, mais la pratique est la même.

User Stories Fonctionnent dans les deux approches. Scrum ne prescrit pas le format ; le format de story d'XP fonctionne bien.

Sprint Review = démo Les démos d'itération d'XP sont essentiellement des Sprint Reviews.

La terminologie diffère ; les pratiques s'alignent.

Les équipes Scrum qui adoptent les pratiques XP constatent généralement :

Meilleure qualité de code : le TDD détecte les bogues tôt. La refactorisation maintient la conception propre. La propriété collective diffuse les connaissances.

Vélocité plus prévisible : quand la qualité est élevée, la vélocité se stabilise. Pas de ralentissements surprises dus à la correction de bogues.

Rythme soutenable : XP nomme et protège explicitement cela. Scrum peut devenir un « sprint » dans le mauvais sens — toujours pousser.

Collaboration améliorée : la programmation en binôme construit des relations. La propriété collective brise les silos.

Amélioration continue : le principe d'amélioration d'XP plus les rétrospectives de Scrum créent une combinaison puissante.

Schéma courant : les équipes commencent avec Scrum parce que c'est organisationnel. Elles ajoutent les pratiques XP en mûrissant. La combinaison est plus puissante que l'une ou l'autre seule.

Bien qu'XP et Scrum fonctionnent bien ensemble, certaines tensions existent :

Scrum Master vs. auto-organisation d'XP XP suppose que l'équipe s'auto-organise profondément. Scrum ajoute un rôle (Scrum Master) pour faciliter. Ceux-ci peuvent coexister, mais si le Scrum Master devient une structure de commandement, l'auto-organisation d'XP en souffre.

Engagement de sprint vs. flexibilité d'XP Scrum met l'accent sur l'engagement de sprint. XP met l'accent sur la réponse au changement. Si l'engagement devient rigide, l'adaptabilité d'XP est perdue.

Définition de terminé vs. qualité continue La « Définition de terminé » de Scrum peut devenir une case à cocher. Les pratiques de qualité d'XP sont continues. Assurez-vous que la DoD reflète la qualité XP, pas seulement « les tests passent ».

Vélocité comme métrique Scrum suit souvent la vélocité. XP met en garde contre la vélocité comme cible (elle est manipulée). Utilisez la vélocité pour la planification, pas la mesure de performance.

Ces tensions sont gérables. La clé est de garder les principes d'XP vivants tout en utilisant la structure de Scrum.

Pour combiner Scrum et XP efficacement :

Utilisez la structure de Scrum :

• Sprints pour le rythme
• Product Owner pour les priorités
• Scrum Master pour la facilitation
• Événements de sprint pour la cadence

Ajoutez les pratiques d'XP :

• TDD pour tout le code de production
• Programmation en binôme (au moins pour le travail complexe)
• Propriété collective (pas de silos de code)
• Intégration continue (plusieurs fois par jour)
• Refactorisation (dans le cadre de chaque story)
• Rythme soutenable (pas d'heures supplémentaires)

Gardez les principes d'XP :

• La qualité n'est pas négociable
• Commencez où vous êtes et améliorez-vous
• Embrassez le changement
• Rétroaction à toutes les échelles

Beaucoup d'équipes découvrent cette combinaison naturellement. Elles commencent avec Scrum, réalisent qu'elles ont besoin de pratiques d'ingénierie, et ajoutent XP. Le résultat est souvent appelé « agile bien fait ».