Source de l'image: pixabay.com

Programmation extrême

Imaginez ceci: un projet de développement de logiciel pour un nouveau produit, basé sur l'avantage du premier sur le marché, vient d'être repéré sur le radar de votre entreprise. Les méthodes traditionnelles de programmation extrême, où le client sait «exactement» ce qu'il veut, sont exclues. Votre équipe est petite et composée de jeunes professionnels susceptibles de bien répondre à un modèle de gestion de projet radical. Quelles sont vos options?

Vous êtes susceptible de dire, Agile Project Management, bien sûr! Mais quelle méthodologie aimeriez-vous utiliser? Il y a plusieurs options: d'une part, il y a le Scrum très populaire: il s'agit de créer de courts «sprints» basés sur le carnet de tâches client. Et puis, il y a Kanban, qui travaille sur l'optimisation du pipeline de travail. Il existe également Extreme Programming, souvent abrégé en XP, qui se concentre sur l'amplification des aspects positifs des modèles de programmation traditionnels afin qu'ils fonctionnent à leur plein potentiel.

La programmation extrême est une méthodologie extrêmement populaire (mais pas aussi populaire que Scrum) visant à répondre aux exigences changeantes des clients. Le premier projet Extreme Programming a été lancé en mars 1996 par Kent Beck chez Chrysler. Dans son livre de 1999, Extreme Programming Explained: Embrace Change, il a détaillé les aspects du développement logiciel.

Kent Beck a également été le pionnier du développement piloté par les tests, qui a mis les tests de cas d'utilisation sur le radar comme une amélioration par rapport à la façon dont les choses se faisaient alors: écrire des lignes et des lignes de code, puis les tester. Il a également été l'un des premiers signataires du Manifeste Agile, aidant à façonner le manifeste pour changer la façon dont les logiciels de programmation extrême ont été écrits.

Les cinq valeurs de Extreme Programming basées sur Explained sont:

la communication

La programmation extrême ne dépend pas d'une documentation complète. En fait, une documentation de programmation extrême n'est suggérée qu'en cas de besoin. La méthodologie repose donc fortement sur la communication entre les membres de l'équipe et également avec les utilisateurs.

Simplicité

C'est au cœur de la programmation extrême. La méthodologie privilégie des conceptions simples, ne pensant pas trop loin dans l'avenir, mais se concentrant sur les exigences d'aujourd'hui, tout en rendant le programme lui-même suffisamment robuste pour ajouter les exigences de l'avenir.

Retour d'information

Cette boucle essentielle de va-et-vient différencie les systèmes Agiles en général et la programmation extrême en particulier, des autres méthodologies de gestion de projet logiciel. La rétroaction continue peut fonctionner de différentes manières, mais elles contribuent toutes à rendre le système plus fort et plus fiable.

Les commentaires peuvent prendre différentes formes:

  • Depuis le programme lui-même: le code est vigoureusement testé tout au long du cycle de développement du projet, afin que les modifications puissent être mises en œuvre par les développeurs.
  • Du client: c'est une partie essentielle de la plupart des systèmes Agiles. Les clients écrivent les tests d'acceptation sur lesquels le développement est basé, ce qui constitue l'épine dorsale du processus de développement. Toutes les itérations sont également livrées au client, pour un retour périodique.
  • De l'équipe: Une fois qu'un nouveau cas d'utilisation / histoire a été créé, l'équipe revient immédiatement avec l'estimation des coûts et du calendrier, renforçant les exigences à mesure qu'elles surviennent. Dans Extreme Programming, personne ne «possède» de code et, par conséquent, au sein des équipes de programmation extrême, les commentaires sur le code de l'autre sont encouragés.

Courage

Cela peut sembler une valeur étrange dans une programmation extrême pour le développement de logiciels, plus adaptée à quelque chose comme l'armée ou les marines! Cependant, pensez-y: les projets logiciels ont longtemps été enlisés par les méthodes de gestion traditionnelles de programmation extrême; sécurisé dans le confort d'une documentation complète et d'une hiérarchie qui ne permet pas l'innovation. Cette valeur illustre le cœur de la programmation extrême: soyez prêt à sauter, sans parachute s'il s'agit de cela! Regardez ce style différent de gestion de projet, et soyez prêt à être responsable, à renoncer à la hiérarchie et à être responsable et à travailler sans tout savoir au début lui-même.

Le respect

Le respect, la cinquième valeur, a été ajouté plus tard et signifie le respect des autres et de soi. Cela implique également le respect du code en cours d'écriture et des attentes et besoins du client. Cette valeur sous-tend également la communication entre les différentes parties prenantes.

Activités d'un projet de programmation extrême

Extreme Programming distingue quatre activités simples d'un projet. Elles sont:

  • Codage : Extreme Programming considère cette activité comme la plus importante. «Sans code, il n'y a rien», explique Kent Beck, le fondateur d'Extreme Programming.
  • Test : Le code est juste cela, sauf si testé. Extreme Programming est obsédé par les tests, utilisant des tests unitaires pour confirmer que le code fonctionne et des tests d'acceptation générés par le client pour confirmer que le code teste ce qui doit être testé.
  • Écoute: L' écoute, illustrée par la valeur fondamentale de la communication, est une activité qui oblige les développeurs à non seulement entendre les clients, mais vraiment écouter ce qu'ils veulent. Le développement et les affaires sont deux choses différentes et, souvent, les développeurs ne comprennent pas l'analyse de rentabilisation d'une décision particulière. Les besoins du client, ainsi que ceux des développeurs, constituent la base de l'activité «d'écoute».
  • Conception : Cela peut vous surprendre que dans un projet de développement logiciel, l'activité de conception, souvent si importante et principale, soit placée à la fin. En effet, Extreme Programming veut délibérément sortir les gens de la mentalité de «conception et développement» que l'industrie a entretenue pendant de nombreuses années. Il ne s'agit pas de limiter l'importance de la conception. Au contraire, un design bon et minimal est l'une des caractéristiques d'un projet.

Des valeurs et des activités émergent les 12 principes de la programmation extrême, tels que conçus par son fondateur, dans son livre, Extreme Programming Explained.

  • Jeu de planification
  • Programmation en binôme
  • Développement piloté par les tests
  • Équipe entière
  • Intégration continue
  • Amélioration de la conception
  • Petites versions
  • Normes de codage
  • Propriété du code collectif
  • Conception simple
  • Métaphore du système
  • Rythme durable

Certaines de ces pratiques de programmation extrêmes, toutes mappées aux meilleures pratiques de l'ingénierie logicielle, sont différentes des méthodologies génériques Agile. Certaines des pratiques de programmation extrême sont expliquées ci-dessous:

  1. Jeu de planification

Il s'agit de la partie planification du projet, appelée «jeu de planification». Il comprend la planification de la prochaine itération et de la prochaine version, en consultation avec l'utilisateur / client, ainsi qu'une planification interne des équipes, quant aux tâches sur lesquelles elles travailleront.

  1. Programmation en binôme

Cela implique deux personnes travaillant sur un morceau de code. Une personne, appelée le clavier, tape le code tandis que l'autre, appelée le moniteur, supervise le code, le commentant et l'affinant, selon les besoins. Les deux personnes échangent souvent leurs rôles. Il a été prouvé que cela améliore considérablement l'efficacité du code. Cela peut ne pas convenir à tous les scénarios de développement, et c'est quelque chose à considérer avant de vous inscrire à Extreme Programming.

  1. Développement piloté par les tests

Tout le code qui est écrit est revu par unité, c'est-à-dire que chaque morceau de code qui peut faire quelque chose est d'abord testé. Extreme Programming met beaucoup l'accent sur les tests. Cela permet de confirmer que le code fonctionne et qu'il peut ensuite être envisagé pour être inclus dans le projet de programmation extrême lui-même. C'est analogue aux tests unitaires à l'école: de petites informations testées, pour que l'enseignant / l'élève puisse faire des corrections de cours et ne patauge pas lors des examens annuels!

  1. Amélioration de la conception (refactoring)

Les projets XP, basés sur sa caractéristique de simplicité, visent à améliorer continuellement le code qui est écrit. Cela signifie que le code entier (et parfois, la base de données aussi) est toujours amélioré. La refactorisation n'ajoute aucune fonctionnalité; il améliore simplement le code existant. Le rend plus serré et plus clair. Cela revient à éditer un morceau d'écriture, à le polir et à le rendre meilleur.

  1. Conception simple

Dans Extreme Programming, les fonctionnalités ne sont ajoutées que lorsque cela est spécifiquement requis. Même si le code en cours d'élaboration est très similaire à ce qui pourrait être requis à l'avenir, il n'est repris que s'il est accepté comme une user story.

  1. Métaphore du système

Cela inclut la standardisation de toutes les conventions de dénomination afin que son but et sa fonction soient facilement déchiffrés. Par exemple, les opérations ou peuvent aider tout programmeur à comprendre leurs fonctionnalités. Cela devrait être fait sur l'ensemble du projet de programmation extrême, afin qu'il soit facile pour quiconque de regarder le code et de le modifier ou de l'améliorer, selon le cas.

Rôles dans un projet de programmation extrême:

Comme Scrum, Extreme Programming a quelques rôles désignés dans chaque projet. Désormais, les rôles ne doivent pas toujours être remplis par des personnes distinctes, et une personne peut jouer plusieurs rôles.

Les rôles Extreme Programming sont:

  • Client : Auto-explicatif. La raison du projet. Elle décide de ce que le projet doit faire. Elle fournit les histoires d'utilisateurs.
  • Programmeur : C'est la personne qui:
    • Prend les histoires que le client propose
    • Crée des tâches de programmation à partir d'histoires
    • Implémente les user stories
    • Teste le code à l'unité
  • Entraîneur : L'entraîneur s'assure généralement que le projet est sur la bonne voie et intervient également pour aider au besoin.
  • Tracker : Le Tracker fait des requêtes spécifiques aux programmeurs à un intervalle défini. En règle générale, il vérifie les progrès des programmeurs, offrant de l'aide si nécessaire de plusieurs façons: retrousser les manches et aider directement avec le code, informer le coach ou organiser une réunion avec le client, selon les besoins.
  • Testeur : exécute des tests fonctionnels. Le testeur n'exécute pas de tests unitaires, qui sont exécutés par les programmeurs eux-mêmes.
  • Doomsayer: Cela, comme son nom l'indique, s'apparente au chapeau noir dans le système de pensée de groupe d'Edward De Bono. N'importe qui pourrait être un Doomsayer, qui signale généralement les problèmes potentiels et aide à garder les problèmes dans la bonne perspective.
  • Manager : Le Manager dans un projet Extreme Programming ressemble plus à un planificateur, s'assurant que les réunions se déroulent comme prévu, et s'assurant que les décisions prises lors des réunions sont transmises à la personne appropriée, le plus souvent, le Tracker. Le gestionnaire, cependant, ne dit pas aux gens quoi faire et quand le faire. Cela est fait par le Client et / ou les User Stories eux-mêmes.
  • Propriétaire d'or : Le propriétaire d'or est la personne qui finance le projet. Cela pourrait être le client, mais pas nécessairement.

Certains des rôles de programmation extrêmes, comme décrit ci-dessus, peuvent être combinés, mais certains ne le peuvent clairement pas.

Le client, par exemple, ne peut pas être également le programmeur. De même, le programmeur et le tracker ne peuvent pas être la même personne.

Les rôles de programmation extrêmes sont définis suffisamment clairement pour qu'il n'y ait pas de confusion et créés pour une flexibilité et une efficacité maximales.

Inconvénients de la programmation extrême:

Alors que les partisans de la programmation extrême brossent un tableau rose, le fait est que la programmation extrême, comme son nom l'indique probablement, est extrêmement difficile à mettre en œuvre. Les facettes de la programmation extrême peuvent être intégrées aux projets avec plus de succès que l'adoption complète de XP.

Certains des inconvénients de la programmation extrême sont:

  • La programmation extrême s'avère plus efficace dans les petits groupes . Son efficacité dans les grands groupes est contestée, et une meilleure option est de diviser les équipes de programmation extrêmes afin que les groupes soient plus petits.
  • L'une des principales caractéristiques de la programmation extrême, la programmation par paires ne fonctionne pas bien dans de nombreux cas . Le codage complexe peut nécessiter deux têtes, mais toutes les tâches peuvent ne pas nécessiter deux personnes, la deuxième personne étant un poids mort. En fait, la programmation par paires, si l'un des membres n'est pas synchronisé avec l'autre, est l'une des principales raisons de l'échec de la programmation extrême dans de nombreux cas.
  • La dépendance à l'égard du client, au point de suggérer une ressource sur site du côté du client, peut être profondément troublante. Cela peut également entraîner des interférences, réelles et imaginaires, pendant le développement.
  • L'accent mis par Extreme Programming sur la simplicité peut rendre très difficile l'ajout au projet actuel, ce qui signifie un budget plus élevé pour des changements même simples, qui ne restent plus simples.
  • La structure hiérarchique plate signifie que l'équipe doit toujours être concentrée, et en l'absence d'un gestionnaire pour corréler des types de personnes divergents, une équipe de programmation extrême dépend entièrement de la maturité émotionnelle de tous les membres de l'équipe, un facteur qui n'est pas toujours fiable. .

Même avec ces facteurs, la programmation extrême reste un outil puissant à utiliser pour le bon projet, les entreprises signalant une augmentation multiple de leur efficacité après l'adoption du processus de programmation extrême. Un système axé sur les développeurs par opposition à Scrum, qui est davantage un système axé sur les processus, Extreme Programming, ou au moins certaines parties de celui-ci, peut entraîner une révolution dans la façon dont nous développons des logiciels de programmation extrême.

Catégorie:

Développement de l'entrepreneuriat