TreizePratiques

AgileFrance | DernieresNouvelles | Preferences | AideEnLigne

Client sur le Site (On-Site Customer): pour une meilleure communication, le client et les développeurs travaillent dans le même espace autant que possible.

Séance de Planification (Planning Game) : le client définit les scénarios utilisateurs prioritaires. Les développeurs discutent le contenu de ces scénarios, définissent les tâches techniques sous-jacentes, estiment ces tâches et y souscrivent.

Intégration Continue (Continuous Integration) : Le système est intégralement assemblé et testé une à plusieurs fois par jour.

Livraisons Fréquentes (Frequent Releases) : Le rythme des livraisons est de l'ordre de quelques semaines.

Rythme Soutenable(Forty-hour Week) : l'équipe ne fait pas d'heures supplémentaires deux semaines de suite. (Sujet connexe : PartirTot)

TestsDeRecette (Acceptance Tests): retour d'information rapide sur le système, en général automatisé, constitué à partir de critères de tests définis par le client.

TestsUnitaires(Wiki:UnitTesting) : tests automatisés écrits pour chaque classe, chaque méthode, et pour tout "ce qui pourrait casser" en général. Ces tests doivent passer à 100% continuellement.

Conception Simple (Simple Design) : Le code doit passer tous les tests et répondre aux critères de maintenabilité : concision, modularité, cohérence, lisibilité.

Métaphore(Metaphor) : Une analogie utilisée comme modèle conceptuel du système en cours de développement.

Remaniement Continu (Wiki:MercilessRefactoring) ou RefactorisationDeCode pratiquée sans relache: modification du code par laquelle on améliore sa conception sans en modifier le comportement.

Convention de Code (Coding Standard) : Le code doit suivre une convention de nommage et de présentation afin d'être lisible par tous les membres de l'équipe.

ProgrammationEnBinome (Pair Programming) : Le code de production est toujours écrit par deux développeurs : le pilote et le copilote. Les binômes changent au cours du projet.

Propriété Collective du Code (Collective Code Ownership) : Chaque développeur peut modifier chaque partie du code si le besoin s'en fait sentir.

Les pratiques et règles XP peuvent aussi se décliner par rapport aux rôles.