Réflexion sur la méthodologie eXtreme Programming


Programmation en équipe

Pilote et Copilote

Il y a toujours un petit feeling de dire qu’on travaille avec une méthodologie extrême. Mais est-ce que le mot extrême est un peu exagéré? Personnellement, ça m’a pris un certain temps à comprendre pourquoi on classait l’extrême programming ou XP dans les méthodes agiles. Pourquoi ne pas mettre la méthodologie du Héros aussi en agile? Les deux méthodes sont très proches l’une de l’autre. Très peu de livrable, autre que le logiciel résultant. Aucune structure pour l’analyse. En fait, l’extrême programming est la méthodologie du héros, mais en binôme au lieu d’en solitaire. Il suffit de mettre 2 programmeurs qui travaillent en tout temps ensemble pour dire qu’on travaille en XP. Mais est-ce si simple que ça? La réponse est non, XP va un peu plus loin, il y a des règles à respecter.

Règles

  • Toujours travailler en équipe de deux
  • Faire une rotation des équipiers pour ne pas que 2 programmeurs soient trop habitués à travailler ensemble
  • Développer toujours au plus simple en faisant abstraction des demandent futur
  • Ne jamais avoir peur de refaire des sections et même revoir l’architecture développée
  • Dès le début, quand un programme, le 2e doit créer les tests unitaires qui devront être réussis tant que le contrat n’est pas terminé
  • Des phases très courtes de développement et des remises au client très fréquentes
  • Une participation du client active au développement
  • Le programmeur principal se fait appeler : Driver ou Pilote
  • Le 2e qui supervise: Partner ou Copilote
  • Le gestionnaire de projet: coach

Avantages

  • Si un programmeur a un taux de bon code sans erreur de 90%, le fait de le doubler donne des taux de plus de 98% (en théorie)
  • Une meilleure cohésion d’équipe
  • Revue de code en temps réel
  • Tests unitaires obligatoires
  • Remise rapide et retour du client rapide
  • Réponds aux changements du client très rapidement
  • Partage des informations

Désavantages

  • Analyse défaillante
  • On sait quand le projet début, mais impossible de connaitre la fin
  • Difficile à estimer les coûts
  • Si le client ne coopère pas, c’est impossible
  • Sentiment d’être toujours jugé par l’autre
  • Double le salaire des employés par poste
  • Sur le long terme, rends les logiciels très complexes

Pour conclure

Pour répondre à la question que j’ai posée plus tôt: oui XP est une méthode agile par définition. Puisque pour être agile, il faut supporter le changement, faire de petite itération, peu de documentation, mais avec un maximum de qualité, faire participer le client au développement. XP répond à tous les critères.

Mais personnellement, je ne pense pas que ça soit une méthodologie à part entière, mais plutôt une méthode de travail lorsque la situation le demande. J’utilise moi-même les fondements de cette pratique à certains moments avec mon équipe. Code difficile ou remise au client rapproché. Mais faire un projet au grand complet avec cette méthode, j’aimerais bien voir le résultat.

Est-ce que quelqu’un a déjà fait un projet à 100% en XP ?

Maxime Savard

Liste des différentes méthodologies

Advertisements

Une réflexion sur “Réflexion sur la méthodologie eXtreme Programming

  1. Ping : Réflexion sur la Revue de code | Réflexion sur la gestion de projet

Laisser un commentaire

Entrer les renseignements ci-dessous ou cliquer sur une icône pour ouvrir une session :

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l’aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s