Extreme Programming est une méthodologie de développement logiciel conçue pour améliorer la qualité du logiciel et sa capacité à s’adapter correctement aux besoins changeants du client ou du client. Au milieu et à la fin des années nonante, alors qu’il travaillait sur le Chrysler Comprehensive Compensation System (C3) pour aider à gérer la paie de l’entreprise, L’ingénieur logiciel Ken Beck a d’abord développé la méthodologie de programmation Extreme., En octobre 1999, il a publié Extreme Programming Explained, détaillant l’ensemble de la méthode pour les autres, et peu de temps après, le site officiel a également été lancé.

semblable à d’autres méthodes agiles de développement, Extreme Programming vise à fournir de petites versions itératives et fréquentes tout au long du projet, permettant aux membres de l’équipe et aux clients d’examiner et de revoir l’avancement du projet tout au long de SDLC.,

tout au long de cet article, nous examinerons exactement ce Qu’est la programmation extrême et son fonctionnement, des valeurs et principes qui la sous-tendent, aux règles et meilleures pratiques procédurales utilisées pour mettre en œuvre un nouveau projet de programmation extrême, alors commençons!,/ td>

Rational Unified Process Big Bang Model V-Model Conceptual Model Kaizen Model Kanban Model Spiral Model

valeurs extrêmes

ces cinq valeurs fondamentales constituent la base sur laquelle repose l’ensemble du paradigme de la programmation extrême, permettant aux personnes impliquées dans le projet de se sentir confiantes dans la direction que prend le projet et de comprendre que leurs commentaires personnels et leur perspicacité sont aussi nécessaires et bienvenus que quiconque.,

simplicité: nous ferons ce qui est nécessaire et demandé, mais pas plus. Cela maximisera la valeur créée pour l’investissement réalisé à ce jour. Nous prendrons de petites mesures simples pour atteindre notre objectif et atténuer les échecs au fur et à mesure qu’ils se produisent. Nous allons créer quelque chose dont nous sommes fiers et le maintenir à long terme pour des coûts raisonnables.

Communication: tout le monde fait partie de l’équipe et nous communiquons face à face quotidiennement. Nous travaillerons ensemble sur tout, des exigences au code. Nous allons créer la meilleure solution à notre problème que nous pouvons ensemble.,

commentaires: nous prendrons chaque engagement d’itération au sérieux en fournissant un logiciel fonctionnel. Nous démontrons notre logiciel tôt et souvent, puis écoutons attentivement et apportons les modifications nécessaires. Nous parlerons du projet et adapterons notre processus à celui-ci, pas l’inverse.

Respect: tout le monde donne et ressent le respect qu’il mérite en tant que membre d’équipe apprécié. Tout le monde apporte de la valeur, même si c’est simplement de l’enthousiasme. Les développeurs respectent l’expertise des clients et vice versa. La direction respecte notre droit d’accepter la responsabilité et de recevoir l’autorité sur notre propre travail.,

Courage: nous dirons la vérité sur les progrès et les estimations. Nous ne documentons pas d’excuses pour l’échec parce que nous prévoyons de réussir. Nous ne craignons rien parce que personne ne travaille jamais seul. Nous nous adapterons aux changements quand ils se produiront.

Extreme Rules

initialement publié par Don Wells en 1999, le propriétaire du site Web Extreme Programming, cet ensemble de règles de programmation extrême était initialement destiné à aider à contrer les affirmations selon lesquelles Extreme Programming ne prend pas en charge certaines des disciplines importantes nécessaires au développement moderne.,

planification

• Les histoires D’utilisateurs sont écrites.
• La planification des versions crée le calendrier des versions.
• faire de petites sorties fréquentes.
• Le projet est divisé en itérations.
• La planification des itérations commence chaque itération.

Gestion

• Donner à l’équipe dédiée de travail ouvert de l’espace.
• établissez un rythme durable.
• Une réunion au début de chaque journée.
• La Vitesse du projet est mesurée.
• Déplacer les gens autour.
• Correction de la programmation extrême lorsqu’elle se casse.

Conception

• la Simplicité.,
• Choisissez une métaphore du système.
• utilisez des cartes CRC pour les sessions de conception.
• créer des solutions de pointe pour réduire les risques.
• aucune fonctionnalité n’est ajoutée précocement.
• refactoriser chaque fois que possible.

Codage

• Le client est toujours disponible.
• Le Code doit être écrit selon les normes convenues.
• coder d’abord le test unitaire.
• tout le code de production est programmé par paire.
• une Seule paire intègre code à la fois.
• Intégrer souvent.
• configurez un ordinateur d’intégration dédié.
• Utilisation de la propriété collective.,

Test

• Tout le code doit avoir des tests unitaires.
• Tout le code doit passer tous les tests unitaires avant d’être libéré.
• lorsqu’un bogue est détecté, des tests sont créés.
• Les tests d’acceptation sont souvent exécutés et le score est publié.

pratiques extrêmes

créées à l’aide de ce qui était considéré comme les meilleures pratiques de développement logiciel à l’époque, ces douze meilleures pratiques de programmation extrême détaillent les procédures spécifiques à suivre lors de la mise en œuvre d’un projet utilisant la programmation extrême.,

rétroaction Fine

programmation par paires

en substance, la programmation par paires signifie que deux personnes travaillent en tandem sur le même système lors du développement d’un code de production. En faisant fréquemment tourner les partenaires au sein de l’équipe, Extreme Programming favorise une meilleure communication et le team-building.

Jeu de planification

souvent, cela prend la forme d’une réunion à un intervalle fréquent et bien défini (toutes les une ou deux semaines), où la majorité de la planification du projet a lieu.,

dans le cadre de cette procédure, il existe l’étape de planification des rejets, où l’on détermine ce qui est requis pour les rejets imminents. Les Sections de la planification de la libération comprennent:

• Phase D’Exploration: les cartes D’histoire sont utilisées pour détailler les exigences les plus précieuses des clients.
• Phase D’engagement: la planification et les engagements de l’équipe sont pris pour répondre aux besoins de la prochaine version du calendrier et le sortir à temps.,
• Phase de pilotage: cela permet d’ajuster les plans précédemment développés en fonction de l’évolution des besoins du projet, à l’instar de nombreuses autres méthodologies de modèle Agile.

à la suite de la planification de la publication se trouve également la section Planification de L’itération, qui se compose des trois mêmes sous-phases, mais avec des variantes sur leurs implémentations:

• Phase D’Exploration: toutes les exigences du projet sont écrites.
• Phase D’engagement: les tâches nécessaires à accomplir pour répondre à la prochaine version d’itération sont attribuées aux développeurs et planifiées de manière appropriée.,
• Phase de pilotage: le développement a lieu et, une fois terminé, l’itération résultante est comparée aux cartes d’histoire décrites créées au début de la procédure de planification.

développement piloté par les tests

bien qu’un article entier puisse être écrit sur le développement piloté par les tests, le concept est assez bien connu des développeurs et signifie effectivement que des tests sont générés pour chaque exigence du projet, et c’est seulement alors que le code est développé qui réussira ces tests.,

toute l’équipe

comme pour beaucoup d’autres méthodes et pratiques de SDLC, Extreme Programming favorise l’inclusion des clients et des clients tout au long du processus, en utilisant leurs commentaires pour aider à façonner le projet à tout moment.

processus continu

intégration continue

Une autre pratique courante dans le développement moderne, l’idée derrière l’intégration continue est que tout le code développé dans l’ensemble de l’équipe est fusionné dans un référentiel commun plusieurs fois par jour., Cela garantit que tous les problèmes d’intégration dans l’ensemble du projet sont remarqués et traités dès que possible.

refactoring de Code

Une autre pratique très courante, l’idée derrière le refactoring de code est simplement d’améliorer et de redessiner la structure du code déjà existant, sans modifier son comportement fondamental. Des exemples simples de refactoring incluent la correction de noms incorrects de variables ou de méthodes, et la réduction du code répété à une seule méthode ou fonction.,

petites versions

très conforme aux pratiques du modèle itératif, ce concept garantit que le projet comportera de petites versions itérées sur une base fréquente, permettant au client ainsi qu’à tous les membres de l’équipe d’avoir une idée de la façon dont le projet se développe.

compréhension partagée

normes de codage

la norme de codage est simplement un ensemble de meilleures pratiques au sein du code lui-même, telles que la mise en forme et le style, que toute l’équipe respecte tout au long du cycle de vie du projet., Cela favorise une meilleure compréhension et lisibilité du code non seulement pour les membres actuels, mais aussi pour les futurs développeurs.

propriété Collective du code

Cette pratique permet à tout développeur de l’équipe de modifier n’importe quelle section du code, si nécessaire. Bien que cette pratique puisse sembler dangereuse pour certains, elle accélère le temps de développement et tout problème potentiel peut être résolu avec des tests unitaires appropriés.

conception Simple

Il y a peu de raisons de compliquer les choses chaque fois qu’une option plus simple est disponible., Cette pratique de base de garder tous les composants et le code aussi simple que possible garantit que toute l’équipe évalue toujours si les choses pourraient être faites de manière plus facile.

métaphore du système

mieux pensée dans le cadre des normes de codage, la métaphore du système est l’idée que chaque personne de l’équipe devrait être capable de regarder le code de haut niveau qui est développé et d’avoir une compréhension claire des fonctionnalités que ce code exécute.,

bien-être des programmeurs

rythme durable

un concept clé pour un meilleur équilibre travail-vie personnelle avec les développeurs sur un projet de programmation extrême est la notion que personne ne devrait être tenu de travailler au-delà de la semaine de travail normale prévue. Les heures supplémentaires sont mal vues, tout comme le concept de « crunch time”, où les développeurs sont censés travailler des heures extrêmes vers la fin d’une version pour tout terminer à temps.