# Extreme Programming


---

## Définition

### Base
L'extrême programming (XP) est une méthode agile plus particulièrement orientée sur l'aspect de la réalisation d'une application, sans pour autant négliger l'aspect gestion de projet. XP est adapté a l'utilisation d'une équipe réduite ayant pour but de pousser à l'extrême les principes de base.

---

### Pratiques extrêmes

- réduire les coûts de changement
- meilleure flexibilité
- ouverture au changement
- introduction de valeur de base

---

### Cycles de développement
XP se repose sur des cycles rapides de développement qui ne dure que quelques semaines dont les étapes sont les suivantes :

- une phase d'exploration qui détermine les scénarios (client) qui seront fournis pendant cette itération
- l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels

---

- chaque développeur s'attribue des tâches et les réalise avec un bînôme
- losque le produit satisfait tous les tests fonctionnels, il est livré


ainsi le cycle se répète tant que le client peut fournir des scénarios à livrer.

---

## Préceptes préférés

### Jeu du planning ou planning poker
Le client crée des scénarios pour les fonctionnalités qu'il souhaite obtenir. L'équipe évalue le temps nécessaire pour les mettre en œuvre. Le client sélectionne ensuite les scénarios en fonction des priorités et du temps disponible.

---

### Intégration continue

Lorsqu'une tâche est terminée, les modifications sont immédiatement intégrées dans le produit complet. On évite ainsi la surcharge de travail liée à l'intégration de tous les éléments avant la livraison. Les tests facilitent grandement cette intégration : quand tous les tests passent, l'intégration est terminée.

---

### Rythme soutenable

L'équipe ne fait pas d'heures supplémentaires. Si le cas se présente, il faut revoir le planning. Un développeur fatigué travaille mal.

### Convention de nommage

Puisque tous les développeurs interviennent sur tout le code, il est indispensable d'établir et de respecter des normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc.

---

#### Autres principes

- ne pas ajouter de fonctionnalités plus tôt que prévu
- n'optimiser qu'à la toute fin

#### Cette méthode s'appuie sur :

- une forte réactivité au changement des besoins du client
- un travail d'équipe
- la qualité du code
- la qualité des tests effectués au plus tôt

---

## Application en formation

### En amont
- daily meetup
- être au clair à l'avance sur les conventions de nommage

---

### Pendant
- pusher plusieurs fois par jour pour que les coéquipiers aient une version à jour du code lorsqu'ils veulent le checker
- essayer de checkout quotidiennement les branches des coéquipiers (revue permanente du code)
- travailler en binôme lorsque cela est possible pour réduire le travail de familiarisation et les risques de dispersion, mais aussi pour perdre moins de temps en ré-explications

---

### Après
- regarder régulièrement dans le rétroviseur pour apprécier ce qui pourrait être refactoré dans la base déjà existante
- tester, tester, tester, ne rien valider qui ne soit pas testé, mais intégrer le plus tôt possible
- ne pas sur-anticiper, rester concentré sur le livrable du moment : KISS
- s'assigner des échéances claires et peu espacées ; les soupeser en poker planning
- ne pas déborder des heures du travail, rester frais et dispo

---

## Exemples

- petit schéma de la XP LifeCycle

---

- contrairement aux idées reçues, XP n'est pas une méthode adaptée uniquement pour les petites startups. Pour preuve cette méthode fut créée par des ingénieurs de chez Chrysler.

- qui ont mis au monde cette voiture des plus immonde.

---

## Témoignages

- XP works well for debugging code (not development)
- XP and SCRUM can ==increase my productivity up to 300%==. But, after 5 years of successful XP and SCRUM practice, ==I burned out==

---

- So I did XP for about three years. ==I loved it, esp when you get to pair with someone you like==. Tdd is fun and will improve ur coding if you get the feel for it or work in a stack that really supports it.
However, ==getting paired with morons sucks== and it may happen to you occasionally. Tdd code from beginners is hard stuff to look at. Sometimes the scheduled togetherness sucks, esp when u got other stuff on your mind. You also get less slacking off time due to shared computer.

---

==This leads to lots of phone usage and can be a bit annoying==. Also you might disagree on an implementation, and have to resolve that on the fly. Senior devs will push agenda or discount Jr dev's ideas. ==People problems, essentially, but amplified==.

---

> -In the words of Samuel Johnson:
"Sir, your work is both brilliant and original. Alas, the brilliant portions are not original, and the original portions are not brilliant."

---

- Been doing it with a consulting company we are being forced to work with for about 6 months now.
==Lots of stuff I like. Small iterations, using testing to verify assumptions==, not building more than I need at any moment.
But ==I hate the pair programming. The promised productivity gains and bug reductions simply do not exist.==