Le Guide Agile par Wishtack
  • Le Guide Agile par Wishtack
  • Sans Agilité
    • Bottom-up vs Top-down
    • Exemple de Régression Naturelle
  • Agile Manifesto
  • Scrum
    • Théorie et Piliers du Scrum
    • Valeurs du Scrum
    • Scrum Team
    • Artefacts
      • Product Backlog
      • Sprint Backlog
      • Increment
      • User Story
      • Epic
      • Expression du Besoin
      • Definition of Done
      • Definition of Ready
    • Evénements
      • Sprint
      • Sprint Planning
      • Stand-Up Meeting ou Daily Scrum
      • Sprint Review
      • Sprint Retrospective
      • Backlog Refinement
      • Timeboxing
    • Mesures & Outils
      • Story Points vs Temps
      • Valeur, Bugs et Chores
      • Vélocité
      • Scrum Board
      • Burn Down Chart
      • Burn Up Chart
      • Technical Debt
  • Priorisation & Planning
    • Le Modèle de Kano
    • La Méthode MoSCoW
    • Release Planning
    • User Story Mapping
  • eXtreme Programming
    • Apprendre à Conduire
    • Valeurs de l'eXtreme Programming
    • Pratiques de l'eXtreme Programming
    • Testing
    • Intégration Continue, Livraison Continue et Déploiement Continu
      • Intégration Continue
      • Livraison Continue
      • Déploiement Continu
      • Review Apps
  • Indicateurs
  • Kanban
    • Principes du Kanban
    • Workflow
    • Indicateurs et Paramètres
    • Classes of Service
  • Transformation Agile
    • Projet Pilote
    • Plan de Passage à l'Agilité
    • Le Changement
    • Contractualisation
    • Management
    • Scrum of Scrums
  • Agile at Scale
  • Transformation Etape par Etape
  • Outils
  • Quelques Liens
  • Bonus
    • The "Rong" Way to do Agile
    • Agile Causal Relations
    • Talks
Powered by GitBook
On this page
  1. eXtreme Programming

Apprendre à Conduire

PreviouseXtreme ProgrammingNextValeurs de l'eXtreme Programming

Last updated 6 years ago

Dans son livre eXtreme Programming Explained, Kent BECK raconte comment il a appris à conduire pour expliquer les valeurs de l'eXtreme Programming.

Tout commence avec le de la mère de Kent BECK qui le laisse tenir le volant depuis son siège passager en lui indiquant simplement qu'il faut "maintenir le véhicule au milieu de la voie".

Au premier virage et dès le premier contact avec le gravier, la mère de Kent BECK met sa main sur le volant pour remettre délicatement la voiture sur la voie (Cf. ) en lui expliquant que pour conduire, il ne s'agit pas de rouler tout droit mais plutôt de rester attentif et de corriger la direction du véhicule en permanence (Cf. ).

A cela, Kent BECK ajoute qu'il en est de même pour le développement d'un produit ; la ligne droite sans obstacle n'existe pas. Même quand la voiture semble avancer parfaitement au centre de la voie, nous ne sommes jamais à l'abris d'un changement. Le changement est l'unique constante.

Cycle en V vs. eXtreme Programming

Le fantasme du Cycle en V est de calculer et de réfléchir pendant des années à comment pousser une voiture pour qu'elle roule toute seule jusqu'au bout de la route.

Cela a de moins en moins de sens dans un écosystème ou la durée de vie de certaines technologies est des quelques mois. On ne planifie pas le changement, on s'y adapte.

Selon Kent BECK, le rôle de l'équipe de développement est de fournir au client un volant et le Feedback le plus proche du temps réel de la position sur la route.

L'eXtreme Programming permet en quelque sorte d'optimiser la manoeuvrabilité de l'équipe.

Pair Programming
courage
Feedback