Deuxième édition du livre fondateur de Kent Beck, Extreme Programming Explained: Embrace changes, détaille les principes, valeurs et pratiques au coeur de cette méthodologie. XP est plus centré sur les pratiques de développement concrètes, sur le code à réaliser, plus technique, tandis que Scrum a une dimension plus organisationnnelle. Les deux méthodes, et toutes les méthodes agiles, mettent au centre l'humain et l'objectif à atteindre, plutôt que des règles strictes, des processus, des structures.[1]
Pratiques principales
Liste des pratiques essentielles de l'XP.
- S'asseoir ensemble: l'équipe doit être, dans la mesure du possible, physiquement regroupée pour faciliter la communication et les échanges.
- Intégrité de l'équipe: former un groupe cohérent, autonome, de taille réduite
- Espace de travail informatif: l'information sur l'état du projet est visible de tous, l'espace de travail contient un ou plusieurs radiateurs d'information, qui permettent d'embrasser rapidement la situation
- Travailler efficacement: le temps de travail doit être adéquat, on ne travaille pas efficacement fatigué, les charettes produisent généralement des bugs.
- Programmation par paire: travailler à deux simultanément sur le code, éventuellement en tournant régulièrement. Permet de croiser les regards
- Narrations: (Stories) pas d'exigences formelles, les besoins sont représentées par des narrations: une description courte de la fonction ou du besoin, de l'évaluation du résultat et une estimation initiale de la charge
- Itération hebdomadaire: le système doit être fonctionnel à la fin de chaque cycle hebdomadaire. L'itération commence par l'écriture des tests correspondant aux narrations choisies. Le cycle est planifié en:
- réalisant un debriefing de l'itération précédente
- choisissant un ensemble de narrations à réaliser dans cette itération
- impliquant l'équipe dans un objectif commun
- Incréments trimestriels: planification des thèmes (plus large que les narrations) pour l'incrément suivant
- Marge: garder de la marge dans l'estimation des charges pour faire face aux imprévus (voir aussi le focus factor
- Construction en 10min: le système doit pouvoir être contsruit et déployé en 10 minutes, le processus de construction doit être automatisé
- Intégration continue: voir sur le sujet l'article de Martin Fowler.
- Tester avant de coder: ou Test Driven Development, rend la portée du code développé explicite
- Conception incrémentale: XP n'interdit pas de concevoir, mais propose une conception juste-à-temps, c'est à dire en fonction de l'apparition des besoins. Une conception sera d'autant mieux adaptée à un problème qu'elle sera proche de la définition de celui-ci.
Pratiques avancées
- Implication du client: un représentant du client doit être présent sur le projet en permanence afin de répondre rapidement aux questions, la recette se fait au fil de l'eau, lors de chaque itération et debriefing, afin d'éviter l'effet tunnel
- Déploiement incrémental: éviter le big bang pour limiter les risques lors du passage en production. Idéalement, le déploiement devrait se faire au fil de l'eau (pas toujours possible), tous les jours.
- Continuité des équipes: créer un esprit d'équipe en maintenant les équipes d'un projet à l'autre.
- Réduction de l'équipe: la charge de travail est maintenue constante en retirant des personnes de l'équipe au fur et à mesure de l'accroissement de la productivité. Permet par ailleurs de diffuser la compétence d'une équipe à l'autre
- Analyse des causes premières: application du principe des 5 pourquoi (5 whys), remonter à la cause réelle des problèmes
- Code partagé: l'ensemble du code du système est visible et modifiable par toute l'équipe, pas de pré carré ou domaine réservé.
- Code et Test: le code et les tests sont les deux seuls artefacts maintenus tout au long du processus de développement, la documentation est intégré au code ou réalisée in fine
- Base de code unique: une seule branche (hormis les branches temporaires pour des développements exploratoires) pour le système
- Daily Deployment: cf. supra.
- Contrat à portée négociée: dans les obligations contractuelles, fixer le prix, les délais, le niveau de qualité mais laisser variable la portée, c'est à dire le niveau de détail du système, le nombre de ses fonctionnalités. L'objectif doit être fixé dans les grandes lignes
- Paiement à l'utilisation: proposer, si possible, un paiement par abonnement ou en fonction de l'utilisation.
Valeurs
XP is ineffective in organizations whose actual values are at odds with the XP values. [...] If an organization's actual values are secrecy, isolation, complexity, timidity, and disrespect, suddenly expressing the opposite values through a new set of practices will caus trouble rather than create improvement.
Liens
Footnotes: [1] En ce sens, les méthodes agiles sont post-modernes
©
2006-2007
OQube
| Dernière publication: 14-04-2007