59 lines
2.2 KiB
Markdown
59 lines
2.2 KiB
Markdown
XP
|
|
===
|
|
|
|
Rappels d'agiles
|
|
|
|
Historique
|
|
|
|
Créé en 1999 par 3 chefs de projet . Débuté en 96, à la base un système de calcul des rémunérations
|
|
Doit être le plus simple possible : KISS
|
|
|
|
Principe : faire simple et efficace au plus possible.
|
|
|
|
Travail direct avec le client sur des cycles très courts. Travail en binôme
|
|
|
|
Méthode non révolutionnaire, mais pousse les 12 principes d'agile à l'extrême
|
|
|
|
## Valeurs
|
|
|
|
Tout le monde travaille ensemble : beaucoup de communication et de respect. Autorité très respectée
|
|
Faire simple
|
|
|
|
Tests d'acceptance sont réalisés par le client
|
|
Tests unitaires sont utilisés par toutes méthodes d'agile
|
|
|
|
## Pratiques
|
|
|
|
Le dev se préoccupe donc pas du produit final, mais just du dev. En cas d'erreur ils ont toujours les feedboack
|
|
Réunions fréquentes où pas mal de trucs sont décidés (planning game)
|
|
Client très intégré, il sert de "beta tester"
|
|
Métaphore : scénario global qui sert de
|
|
Rythme : pas plus de 40h de travail par semaine
|
|
Convention de nommage unique pour toute l'équipe pour garantir compréhension du code
|
|
|
|
## Rôles
|
|
|
|
Petites équipes en XP (5 max)
|
|
Vérificateur s'assure que la commmunication dans l'équipe est ok, peut éventuellement demander de l'aide
|
|
Client écrit les user story
|
|
Développeurs définissent les tâche d'ingénierie, le temps pour les faire, implémentent les stories et font les tests unitaires
|
|
Testeur implémente les tests fonctionnels réalisés
|
|
Coach planifie les réunions, note les résultats, est le mentor de l'équipe mais ne dit pas comment travailler. Supervise mais chacun reste autonome => EQUIPE EN RÉSEAU, EH OUAIS MAGUEULE
|
|
|
|
Un membre de l'équipe peut avoir plusieurs rôles (tout n'est pas compatible)
|
|
|
|
## Planification et gestion
|
|
|
|
Un planning de livraison est réalisé permettant de réaliser un planning d'itération. Réunion au début d'une itération pour produire le planning
|
|
|
|
## Conception et développement
|
|
|
|
On les garde simple : on se base sur une petite partie à chaque fois.
|
|
Solutions pointues pour réduire erreurs et éviter d'ajouter fonctionnalités inutiles : on vise l'utile à l'instant *t*
|
|
|
|
## Recommandations
|
|
|
|
Une rétrospective au moins toutes les 3 itérations
|
|
|
|
Une des méthodo les plus utilisées
|