XP vs Scrum : Approches complémentaires

XP et Scrum ont émergé à peu près au même moment et partagent les mêmes racines, mais ils se concentrent sur des problèmes différents.

Scrum se concentre sur la gestion de projet : Comment organiser le travail? Quels rôles sont nécessaires? Quelles réunions? Quels artefacts? Scrum vous donne un cadre pour gérer le flux de travail à travers une équipe.

XP se concentre sur les pratiques d'ingénierie : Comment écrire réellement le code? Comment assurer la qualité? Comment maintenir la base de code en santé? XP vous donne des pratiques pour bien faire le travail.

C'est pourquoi ils se complètent si naturellement. Scrum vous dit quoi construire dans un sprint. XP vous dit comment le construire.

Malgré des objectifs différents, XP et Scrum partagent des concepts clés :

• Itérations : Scrum a des sprints (2-4 semaines). XP avait à l'origine des itérations de 1-2 semaines.
• Implication du client : Scrum a le Product Owner. XP a le client sur place.
• Rétrospectives : Les deux mettent l'accent sur la réflexion et l'amélioration.
• Équipes auto-organisées : Les deux font confiance aux équipes pour déterminer comment travailler.
• Logiciel fonctionnel : Les deux priorisent le code qui fonctionne plutôt que la documentation.

Une équipe « qui fait du Scrum » ressemble beaucoup à une équipe « qui fait du XP » vue de l'extérieur. La différence est sous le capot.

Scrum est silencieux sur les pratiques d'ingénierie. Le Guide Scrum ne dit rien sur le TDD, la programmation en binôme, le refactoring ou l'intégration continue. Il suppose que les équipes trouveront les pratiques techniques elles-mêmes.

XP est prescriptif sur les pratiques d'ingénierie. XP dit que vous devez écrire les tests en premier. Vous devriez programmer en binôme. Vous allez refactoriser continuellement. Vous allez intégrer plusieurs fois par jour.

Scrum définit des rôles. Product Owner, Scrum Master, Équipe de développement. Ces rôles ont des responsabilités spécifiques.

XP est flexible sur les rôles. Il y a un client et des développeurs. C'est à peu près tout. XP suppose que l'équipe s'auto-organisera autour des rôles au besoin.

Scrum a des événements spécifiques. Planification de sprint, Mêlée quotidienne, Revue de sprint, Rétrospective de sprint.

XP a des cadences plus flexibles. Jeu de planification, mêlée quotidienne, démo d'itération — similaires, mais moins rigidement définis.

De nombreuses équipes performantes utilisent le cadre de Scrum avec les pratiques techniques de XP. Cette combinaison est puissante :

• De Scrum : Sprints, Product Owner, Scrum Master, événements de sprint, Backlog de produit
• De XP : TDD, programmation en binôme, refactoring, intégration continue, propriété collective

Ce n'est pas « impur » ou incorrect. Les créateurs originaux de Scrum s'attendaient à ce que les équipes apportent des pratiques d'ingénierie. XP les fournit.

Un modèle courant :

1. Utiliser Scrum pour planifier et organiser le travail
2. Utiliser les pratiques XP pour faire le travail
3. Utiliser les rétrospectives pour améliorer continuellement les deux

Les équipes appellent souvent cela « Scrum avec les pratiques d'ingénierie XP » ou simplement « bien faire de l'agile ».

Vous pouvez faire du XP sans Scrum. Certaines équipes préfèrent l'approche plus légère de XP :

• Flux continu au lieu de sprints fixes
• Client sur place au lieu d'un Product Owner intermédiaire
• Rôles auto-organisés au lieu de rôles Scrum définis

Cela fonctionne bien pour les équipes qui trouvent la structure de Scrum trop lourde, ou là où le travail arrive continuellement (comme les opérations ou le support).

La clé est que les pratiques techniques de XP ne sont pas négociables. Que vous utilisiez Scrum, Kanban ou autre chose pour organiser le travail, le TDD, le refactoring et l'intégration continue restent essentiels.