SlideShare une entreprise Scribd logo
1  sur  28
Télécharger pour lire hors ligne
”‘‰”ƒƒ–‹‘ ‡–”²‡
                ‡–”‡‡ ”‘‰”ƒ‹‰
                     ^




 ,,zE ^

 ^Z/

/ E
‘ƒ‹”‡
•     /EdZKhd/KE
/     
          D
          D                 s
          D
              W
              h             ,
                      s             D
              W



//                   W                  W        
                               W
          ,
          W               yW
          W



///       
          K                     ,
          Z



/s                                         yW
                                    yW
          W
          s



s                 
          yW          hD


•     KEh^/KE
•   /EdZKhd/KE




         Le développement de logiciels a été pendant longtemps entièrement libre de directives ou
         de contraintes, et il n'y avait aucune méthode pour analyser les besoins, produire une
         solution, ou même évaluer le succès. Mais depuis les débuts de l'informatique
         commerciale dans les années '60,et en 1968, une conférence de l'OTAN a introduit le
         terme « génie logiciel » et suggéré d'utiliser les méthodes rigoureuses et éprouvées du
         génie civil au chaos du développement de logiciels. L'idée était louable, mais une
         différence majeure existe: contrairement à la physique et aux mathématiques,
         l'informatique ne repose sur aucune loi et ne peut être vérifiée scientifiquement. Par après
         plusieurs méthodologies de développement de logiciel ont vu le jour. Le modèle en
         cascade et ses dérivés ont connu un grand succès, mais leur lourdeur et rigidité sont de
         sérieux handicaps. Extreme Programming propose de remplacer certaines notions acquises
         par des idées révolutionnaires, et de rendre le développement de logiciel efficace et agile.




     /       

Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel.
Ces cycles prendront en compte toutes les étapes de la conception d'un logiciel.



                   D

Le modèle en cascade est hérité de l'industrie du BTP1. Ce modèle repose sur les hypothèses
suivantes :

         •   On ne peut pas construire la toiture avant les fondations.
         •   Les conséquences d'une modification en amont du cycle ont un impact majeur sur les
             coûts en aval.




                                          d      W
Les phases traditionnelles de développement sont effectuées simplement les unes après les
autres, avec un retour sur les précédentes, voire au tout début du cycle. Le processus de
développement utilisant un cycle en cascade exécute des phases qui ont pour caractéristiques :

     •   De produire des livrables définis au préalable.
     •   De se terminer à une date précise.
     •   De ne se terminer que lorsque les livrables sont jugés satisfaisants lors d'une étape de
         validation-vérification.2




               D           s

Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en
cascade. Ce modèle est une amélioration du modèle en cascade qui permet en cas d'anomalie,
de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer
de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés afin d'améliorer
le logiciel.

De plus le cycle en V met en évidence la nécessité d'anticiper et de préparer dans les étapes
descendantes les « attendus » des futures étapes montantes : ainsi les attendus des tests de
validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors
de la conception, etc.


 D
Le cycle en V est devenu un standard de l'industrie du développement de logiciel et de la
gestion de projet depuis les années 1980.




              D

   Ce mouvement est apparu au milieu des années '90 il avait pour but de rendre le processus
   de développement plus efficace, en utilisant des concepts très simples et reconnus. Il n'est
   directement relié à aucune méthodologie, mais propose une série de recommandations,
   valeurs, et principes qui sont appliquées dans d'autres méthodes.



                      W




               Les méthodes agiles sont des méthodes de gestion de projets informatiques et
       de développement qui se positionnent en réaction à des méthodes traditionnelles
       jugées trop lourdes. XP fait partie de cette catégorie dont la première idée a été de
       réagir face à la bureaucratie où toute démarche exige une grande quantité de temps.
       C’est aussi la plus populaire des méthodes agiles mais on peut aussi citer : ASD
       (Adaptative Software Development), SCRUM, Crystal, FDD (Feature Driven
       Development) et DSDM (Dynamic System Development Method) qui peuvent
       chacune être adaptée à une situation particulière, fonction de la taille de l’équipe.



                      h        ,
En 1986, Barry W. Boehm présentait un nouveau modèle de développement itératif et
incrémental.

En 1986 également, Hirotaka Takeuchi et Ikujiro Nonaka publient « the new new product
developpement game » dans la Harvard business review. Leur article présente un modèle de
développement basé sur l'aptitude au changement, l'auto organisation, l'imbrication des phases
de développement, et l'itération (on y fait d'ailleurs mention du mot scrum par analogie au
rugby).

En 1991, James Martin (RAD3), s’appuyant sur cette vision d’une évolution continue, proposa
une méthode de développement rapide d’application. Sa structure, base des approches
actuelles, déterminait le phasage essentiel et mettait en œuvre un principe adaptatif fondé sur
la validation permanente des utilisateurs.

À partir de 1994, Jean-Pierre Vickoff en France, notamment avec le Processus RAD publié
par le Gartner Group, et Jennifer Stapleton en Grande-Bretagne, avec DSDM, introduisirent
des compléments tels que :

     •    la spécialisation des rôles,
     •    l’instrumentation des communications,
     •    l’organisation des divers types de réunions,
     •    le groupe de facilitation et de rapport,
     •    les « raccourcis méthodologiques » de modélisation,
     •    l’architecture de réalisation (imbrication des itérations),
     •    la formalisation de processus légers de mise en œuvre.




Dans la seconde moitié des années 1990, une vague d’une dizaine de méthodes (dont Extreme
programming et Scrum sont les principales représentantes) poussa à l’extrême certaines
pratiques de qualité de la construction applicative ainsi que les techniques adaptatives
d’estimation, de planification et de pilotage de projet.
En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sont
réunies pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes
agiles. Les plus connus d'entre eux étaient Ward Cunningham, l'inventeur du Wiki via
WikiWikiWeb, Kent Beck, père de l'extreme programming et cofondateur de JUnit, Ken
Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l'ASD, Alistair
Cockburn pour la méthode Crystal clear, Martin Fowler, et Dave Thomas ainsi que Arie van
Bennekum pour DSDM (Dynamic System Development Method). Ces 17 experts venant tous
d'horizons différents réussirent à extraire de leurs concepts respectifs des critères pour définir
une nouvelle façon de développer des logiciels :4

De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canonique
du développement Agile et de ses principes sous-jacents.5



                           s                     D

Les quatre valeurs fondamentales (entre parenthèses, les citations du manifeste)6:

        •   L'équipe (« Personnes et interaction plutôt que processus et outils ») : Dans l'optique
            agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou
            les procédures de fonctionnement. Il est préférable d'avoir une équipe soudée et qui
            communique, composée de développeurs (éventuellement à niveaux variables), plutôt
            qu'une équipe composée d'experts fonctionnant chacun de manière isolée. La
            communication est une notion fondamentale.

        •   L'application (« Logiciel fonctionnel plutôt que documentation complète ») : Il est
            vital que l'application fonctionne. Le reste, et notamment la documentation technique,
            est une aide précieuse mais non un but en soi. Une documentation précise est utile
            comme moyen de communication. La documentation représente une charge de travail


    D
                               D                            D

    D                                                                                              yW
^ZhD                                                                W            D
yW     h                                                   W            D                    
                                         s                               D      ^           s        E
z                  /^E              y
    D
importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de
         commenter abondamment le code lui-même, et surtout de transférer les compétences
         au sein de l'équipe (on en revient à l'importance de la communication).

     •   La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») :
         Le client doit être impliqué dans le développement. On ne peut se contenter de
         négocier un contrat au début du projet, puis de négliger les demandes du client. Le
         client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du
         logiciel à ses attentes.

     •   L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») :
         La planification initiale et la structure du logiciel doivent être flexibles afin de
         permettre l'évolution de la demande du client tout au long du projet. Les premières
         releases du logiciel vont souvent provoquer des demandes d'évolution.



                         W

Ces quatre valeurs se déclinent en douze principes généraux communs à toutes les méthodes
agiles7 :

     •   « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des
         logiciels utiles »
     •   « Le changement est bienvenu, même tardivement dans le développement. Les
         processus agiles exploitent le changement comme avantage compétitif pour le client »
     •   « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux
         mois, avec une tendance pour la période la plus courte »
     •   « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet »
     •   « Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le
         soutien dont elles ont besoin, et croyez en leur capacité à faire le travail »
     •   « La méthode la plus efficace pour transmettre l'information est une conversation en
         face à face »
     •   « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet »



 d
•   « Les processus agiles promeuvent un rythme de développement durable.
    Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme
    indéfiniment »
•   « Une attention continue à l'excellence technique et à la qualité de la conception
    améliore l'agilité »
•   « La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle
    »
•   « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui
    s'auto-organisent »
•   « À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis
    accorde et ajuste son comportement dans ce sens ».




                        D
Il existe de nombreuses méthodes agiles telles que8 :

       •   Rapid Application Development (RAD, 1991)
       •   Dynamic systems development method (DSDM, 1995, consortium anglais
           commercialisant le RAD)
       •   Scrum (1996)
       •   Feature Driven Development (FDD) (1999)
       •   Extreme programming (XP, 1999)
       •   Adaptive software development (ASD, 2000)
       •   Test Driven Development (TDD, 2002)
       •   Crystal clear (2004)



  //                W            W             
                             W



La programmation eXtrème dite XP (eXtreme Programming) est une méthodologie efficace
de développement rapide de logiciels qui exige que les membres d’une équipe de
développeurs soient physiquement proches les uns des autres.



XP est une méthode de développement dédiée à des petites équipes confrontées à un
environnement changeant ou des besoins mal connus. Cette méthode est née sur le terrain, à
partir des observations et recherches de développeurs expérimentés soucieux de se concentrer
sur les nécessités élémentaires du développement :

           •              Développer vite :



 S’assurer que les changements restent toujours faciles pour conserver une vitesse de
développement soutenue tout au long du projet.



           •              Développer juste :

Se focaliser sur les besoins réels du client.



                           D                   D
XP définit une discipline de développement qui permet de diminuer le coût du changement
dans le logiciel, à tel point qu'il devient plus avantageux de prendre la décision le plus tard
possible, en attendant les résultats concrets issus du développement lui-même.

Les spécifications peuvent alors être élaborées progressivement tout au long du
développement en enchaînant des itérations rapides de spécification / développement /
livraison. Le client peut ainsi guider le développement tout au long du projet.

La méthodologie a été établie pour livrer le logiciel dans les délais impartis. Les développeurs
sont préparés aux changements des besoins du client, même dans la fin du cycle de
développement.

Managers, clients et développeurs font partie de la même équipe dont le but est de fournir un
logiciel de qualité. XP rend possible simplement et efficacement le développement en groupe
de travail.

XP est basé sur des principes essentiels :



 Une forte réactivité au changement des besoins du client au plus tôt dans le cycle de vie du
logiciel

 Un travail d'équipe (développeurs / chefs de projets / clients)

 La qualité du code : elle garantit un gain d'argent pour le client

 La qualité des tests effectués au plus tôt

 Une intégration permanente


XP : (une méthodologie allégée)

Une méthodologie logicielle est un ensemble de règles et de pratiques mises en œuvre pour la
création de programmes. Ces règles sont trop difficiles à suivre, les procédures complexes et
mal comprises et la quantité de documentation à produire hors de contrôle.

Pour essayer de rester dans le planning, il est nécessaire de simplifier les règles, garder celles
qui contribuent à la qualité et laisser de côté celles qui ralentissent le projet.

L'XP est une méthodologie allégée car elle est constituée de peu de règles et de mises en
pratique. Le travail en équipe, la réactivité, la concision et l'efficacité s'en trouvent renforcés.
XP est une méthode basée sur des principes simples, que tout le monde pratique déjà sans le
savoir. Mais alors, où est la « révolution » ?



Rendre moins lourdes les démarches

Le but d’XP est de trouver des solutions plus ou moins simples, basées sur des principes
éprouvés, pour tenter de diminuer les risques pour respecter les délais et la qualité du produit
commandé.
Cela, en trouvant un compromis équilibré entre pas de démarche et trop de démarche, tout
en respectant le minimum de discipline nécessaire pour attendre un retour sur investissement
en temps et en effort immédiat et intéressant.
Ainsi, on souhaite réduire radicalement la production de documents en se focalisant sur un
code bien commenté plutôt que sur des documentations techniques très formelles.
XP évite donc avec cela les lourdeurs des méthodes classiques et est donc un habile
compromis entre une méthode traditionnelle et le développement « cow boy », sans règles
précises. Par conséquent le travail des informaticiens est totalement tourné vers la technique
où ils se sentiront vraisemblablement plus à l’aise.



Changer les principes

En outre, XP, en tant que méthode agile, se veut adaptative plutôt que prédictive. C’est à dire
qu’à l’inverse des méthodes lourdes qui tentent de dresser un plan au début du projet, XP
indique qu’il vaut mieux agir sur le court terme. Cela, tout simplement parce qu’il n’existe pas
de projet figé où le prédicat de base ou le contexte ne changent pas du tout. Dans ce cas, le
coût du changement a une croissance logarithmique en fonction du temps.
Le simple fait de ne pas être réticente aux changements permet dans un premier temps de
mieux s’y adapter mais permet aussi une meilleure relation avec le client et la livraison d’un
produit conforme totalement aux exigences de ce dernier.
Enfin, le dernier but d’XP est de se vouloir orienter sur les personnes plutôt que sur les
processus. Alors, le développement tentera d’être une activité agréable plutôt qu’un
cauchemar bureaucratique.


              ,

La naissance d’une nouvelle méthode arrive rarement sans raisons. Elle fait plutôt suite à une
période difficile...




D’après une étude américaine menée en 1994 sur 8000 projets, 16 % n’ont pas respecté les
délais et le budget initial et, pire, 32 % n’ont jamais abouti.
Ainsi, dans le monde de l’ingénierie logicielle, trois plaies pourtant bien connues enveniment
le développement d’applications.
La première concerne le planning difficilement maîtrisé ou impliquant de nombreuses heures
sup. Le deuxième est issue des besoins souvent mal identifiés ou mal compris en raison d’un
cahier des charges mal étudié ou incomplet.
Tout cela implique des changements au cours du développement, d’autant plus si le client
décide de modifier le produit, après une première maquette par exemple. Enfin, le dernier
problème concerne la livraison finale du produit qui est parfois buguée.

XP est né lors d’une récente vague de création de nouvelles méthodes parallèlement à
l’explosion de l’informatique dans les entreprises et de l’émergence du freeware.
Lors de cette vague, sont essentiellement apparues des méthodes qualifiées d’agile dont XP
fait partie.

                                                                                      y
W                                                               W
                  yW




              W         yW

    La méthode est très attentive à l’activité en dernière analyse essentielle dans un projet de
    logiciel : la programmation. Le codage produit la documentation principale : les fichiers
    sources. Pourquoi « extrême » programming ?

    Kent Beck, qui structure et présente XP, explique que les pratiques sur lesquelles est bâtie
    XP sont autant de boutons de contrôle… qu’il pousse au maximum. De ce point de vue,
    XP est la réunion cohérente de pratiques efficaces, telles que le test omniprésent, l’esprit
    d’équipe, le rôle prépondérant du client dans l’équipe, etc.

                               Le bon sens est poussé à son extrême !



              W


    Petites à moyennes équipes écrivant des logiciels dont les besoins sont vagues ou
    changent rapidement
///   
                K             ,




                                               W


                          
                                                                                    d


                    A. Programmeur  Développeur :
                                       • Responsabilisation
      Retour du programmeur comme rôle central
       A la fois : codeur, testeur, concepteur et analyste
       Apprentissage      Qualités humaines nécessaires
       XP : Ecole de l’excellence
       Responsabilisés pour donner le meilleur d’eux même
      ex. : estimation des charges et délais
                                         • Pratiques XP

      Programmation en binôme                                Responsabilité collective du code
      Tests unitaires                                        Règles de codage
      Conception simple                                      Intégration continue
      Remaniement                                            Rythme durable
                    B. Client :
                                       • Responsabilisation
          Description informelle d’une fonctionnalité ou d’une interaction avec l’utilisateur
          Le plus simple possible
Des scénarios initiaux sont dégagés et Présentés, classés par priorité et répartis en
itérations
                                 • Pratiques XP
 Planification itérative
 Rédaction des scénarios clients
 Séances de planification
 Tests de recette
 Intégration continue
 Rythme durable



           C. Testeur :
                              • Responsabilisation
Définit et automatise les tests de recette
       Conseille le client sur la testabilité d’une Fonctionnalité.
       Utilisation d’outils différents pour scripter.
Garant du sentiment de réussite sur le projet
       Test fonctionnel réussi→ Progression.
       Communiquer pour motiver (graphique de progression...).
                                 • Pratiques XP
Suivi des tests (planification itérative)
Tests de recette
Intégration continue
Rythme durable



           D. Tracker :

                             • Responsabilisation
Pas un supérieur hiérarchique
Quelqu’un a qui on peut se confier
De préférence pas un programmeur, mais quelqu’un d’extérieur
Pour éviter les discussions techniques
A défaut, ce rôle peut tourner entre les programmeurs à chaque itération
                                • Pratiques XP
Planification itérative



           E. Manager :
                              • Responsabilisation
Il s’occupe matériellement de l’équipe
 Il demande des comptes (sur les engagements pris)
 Interface avec l’extérieur (dans le cadre d’un sous-projet)
•   Pratiques XP
     Scénarios client
     Planification itérative
     Rythme durable



                 F. Coach, le chef de projet :

                                    •    Responsabilisation
     Il réunit tout les autres rôles
     Vérifie que chaque rôle est respecté
     Ses buts ultimes :
                         o Equipe autonome
                         o Chaque programmeur est en amélioration continue
     Ses qualités
                         o Expert de la méthode XP
                         o Expert technique
                         o Programmeur chevronné
                         o Architecte
                         o Pédagogue et sensible
                         o Sang-froid
                                      • Pratiques XP
     Toutes !

             Z

             W



                     d
                     ^



             W
                    W
                    d
                    
                    D
                          d
/s                           yW
                               yW
                 i. Planification et gestion :
Écrire des scénarios utilisateur «user stories» avec le client
Segmenter le projet en itérations (exemple: livraisons aux X semaines)
Débuter chaque jour par une réunion d’équipe debout !
Déplacer les personnes (inter changer les paires)
Le code appartient à toute l’équipe ( egoless prog., Weinberg, 1971)
Ne pas faire de temps supplémentaire «ideal week»


       ii. Conception :


KIS = «keep it simple»: utiliser des cartes CRC (ou léger UML)
Représenter une histoire utilisateur à la fois
Adopter un codage uniforme: noms, standards…
Ne jamais ajouter de fonctionalité trop tôt
Encourager la reconstruction avant une nouvelle itération




       iii. Les activités et processus.


Le client (expert disponible) priorise les histoires
La vitesse du projet est mesurée (et adapte les itérations)
Le test unitaire est produit avant le code (+1 par bogue)
Le code pour livraison est programmé par binômes (paire)
L’intégration est fréquente et se fait séquentiellement
Les tests d’acceptation sont exécutés souvent et publiés
b. Les pratiques de l’XP


                                                   K
   K                                                                                              d
                                                    d


               W                                                                                         d
                                         D
                   '                                                                   ^               h


                                                                                                      d
                                                                             Z
                                                                 


               Z                                                               /
                                         ^   h               
           ^                                                                       



               Dans cette partie nous aller présenter les treizes pratiques «canoniques» dont XP
définit, et que nous classons en trois grandes catégories: celles relatives à la programmation,
celles relatives au fonctionnement interne de l’équipe et celles qui sont liées à la planification
et aux relations avec le client.




                           W


                                                  K
   K                                                                                         d
                                                   d


                                                                          
       W               '                 D                                                    d        h
                                                                                   ^



                                                                                                  d
                                                                         Z
                                                                 


               Z                                                           /
                                         ^   h              
           ^                                                                   




               Dans cette partie nous aller présenter les treizes pratiques «canoniques» dont XP
définit, et que nous classons en trois grandes catégories: celles relatives à la programmation,
celles relatives au fonctionnement interne de l’équipe et celles qui sont liées à la planification
et aux relations avec le client.



             1. Les pratiques de programmation

    Au cœur des pratiques XP, les pratiques de programmation que nous présentons ci-après
permettent d’améliorer continuellement la conception et le code de l’application pour qu’elle
reste toujours aussi claire et simple que possible :

    •   Conception simple (simple design) : les développeurs implémentent toujours la
        solution la plus simple qui puisse fonctionner. En particulier, ils n’inventent pas de
        mécanismes génériques si le besoin immédiat ne l’exige pas.
    •    Remaniement (refactoring) : les développeurs n’hésitent pas à revenir sur le code
        écrit pour le rendre plus «propre», le débarrasser d’éventuelles parties inutilisées, et le
        préparer à l’ajout de la fonctionnalité suivante. D’une manière plus générale, cette
        pratique propose une démarche de conception continue qui fait émerger la structure
        de l’application au fur et à mesure du développement.
    •    Développement piloté par les tests unitaires (test-first programming, unit tests,
        developer tests) : les développeurs écrivent des tests automatiques pour le code qu’ils
        produisent, et ce au moment même d’écrire le code en question. Cela leur permet
        d’une part de mieux cerner le problème avant d’écrire le code, et d’autre part de
        constituer progressivement une batterie de tests qui les autorise ensuite à apporter
        rapidement des changements dans l’application, tout en conservant une certaine
        sérénité.
    •   Tests de recette (acceptance tests, customer tests) : le client précise très explicitement
        ses besoins et les objectifs des programmeurs – en participant à la rédaction de tests
        de recette. Comme les tests unitaires, les tests de recette doivent être automatiques
        afin de pouvoir vérifier tous les jours la non-régression du produit.




             2. Les pratiques de collaboration

        Dans une équipe XP, tous les développeurs travaillent ensemble (voir chapitre 5) et
interviennent sur la totalité de l’application. Cela garantit la qualité de cette dernière à travers
les relectures croisées que cela engendre, mais cela rend également le travail plus motivant et
offre une plus grande souplesse dans l’affectation des tâches. Les pratiques qui régissent cette
organisation sont les suivantes :

           •    Programmation en binôme (pair programming) : lorsqu’ils écrivent le code de
               l’application, les développeurs travaillent systématiquement à deux sur la
               même machine – il s’agit là d’une forme «extrême» de relecture de code, dans
               laquelle les deux développeurs collaborent activement pour résoudre les
               problèmes qu’ils rencontrent. Les binômes changent fréquemment, ainsi
               chacun est amené à travailler tôt ou tard avec tous les autres membres de
               l’équipe.
           •    Responsabilité collective du code (collective code ownership) : tous les
               développeurs de l’équipe peuvent être amenés à travailler sur toutes les parties
               de l’application. De plus, ils ont le devoir d’améliorer le code sur lequel ils
               interviennent, même s’ils n’en sont pas les auteurs initiaux.
           •    Règles de codage (coding standards) : les développeurs se plient à des règles
               de codage définies par l’équipe elle-même, de manière à garantir
               l’homogénéité de leur code avec le reste de l’application, et ainsi à faciliter
               l’intervention d’autres développeurs.
           •    Métaphore (metaphor) : les développeurs n’hésitent pas à recourir aux
               métaphores pour décrire la structure interne du logiciel ou ses enjeux
               fonctionnels, de façon à faciliter la communication et à assurer une certaine
               homogénéité de style dans l’ensemble de la conception, l’idéal étant de décrire
               le système dans son ensemble par une métaphore unique.
           •    Intégration continue (continuous integration) : les développeurs synchronisent
               leurs développements aussi souvent que possible – au moins une fois par jour.
               Cela réduit la fréquence et la gravité des problèmes d’intégration, et permet de
               disposer à tout moment d’une version du logiciel qui intègre tous les
               développements en cours.


            3. Les pratiques de gestion de projet

       Les pratiques de programmation et de collaboration (voir chapitre 6) permettent de
créer un contexte dans lequel une démarche de spécification et de conception purement
itérative devient viable. Les pratiques suivantes montrent comment XP exploite cet avantage
afin de s’assurer que l’équipe et son client restent en phase tout au long du projet, de façon à
converger au plus tôt vers un produit adapté aux besoins du client :

                •   Livraisons fréquentes (frequent releases) : l’équipe livre des versions du
                    logiciel à un rythme régulier, aussi élevé que possible – la fréquence
                    précise étant fixée par le client. Cela permet à l’équipe comme au client de
                    s’assurer que le produit correspond bien aux attentes de ce dernier et que le
                    projet est sur la bonne voie.
                •   Planification itérative (planning game) : la planification du projet est
                    réalisée conjointement par le client et l’équipe de développement, au cours
                    de séances dédiées, organisées régulièrement tout au long du projet.
                •   Client sur site (on-site customer, whole team) : le client est littéralement
                    intégré à l’équipe de développement pour arbitrer les priorités, et définir
                    précisément ses besoins,notamment en répondant en direct aux questions
                    des programmeurs et en bénéficiant du feedback immédiat d’une
                    application aux livraisons fréquentes.
                •   Rythme durable (sustainable pace) : l’équipe adopte des horaires qui lui
                    permettent de conserver tout au long du projet l’énergie nécessaire pour
                    produire un travail de qualité et mettre en œuvre efficacement les autres
                    pratiques.




              s
Z




                                                                  ^
                                     

NB : La valeur ‘Respect’ existe dès la deuxiéme version d’XP on se contente d’étudier quatre
autres valeurs.

       Après si elles sont indispensables aujourd’hui pour mettre l’Extreme Programming en
œuvre, les pratiques que nous venons de présenter ne suffisent pas pour autant à le définir. Il
ne s’agit en définitive que de techniques, destinées à faire émerger un environnement de
travail marqué par les quatre qualités érigées en valeurs par XP et qui en font l’essence : la
communication, la simplicité, le feedback et le courage.



                  1) La communication pour une meilleure visibilité

   Du point de vue d’XP, un projet de développement est avant tout un effort collectif de
création, dont le succès dépend d’une part de la capacité de ses différents intervenants à
s’accorder sur une vision commune de ce qui doit être produit, et d’autre part de leur capacité
à synchroniser leurs actions individuelles pour atteindre l’objectif commun. Or, ces deux
conditions dépendent en majeure partie de la qualité de la communication qui lie ces
intervenants entre eux. Mais sur le fond, il n’y a finalement pas grand-chose de spécifique à
XP sur ce point.

   Ce qui démarque l’approche XP dans ce domaine, c’est l’accent mis sur la communication
directe, sur le contact humain. Certes, la communication orale présente des faiblesses en
termes de structuration de l’information et de traçabilité, mais elle tire sa force de sa
simplicité et des interactions rapides entre les interlocuteurs qui permettent de converger
rapidement sur les informations essentielles. En outre, le contact direct permet de véhiculer
des informations beaucoup plus personnelles cela donne ainsi l’occasion d’identifier et de
résoudre des blocages qui relèvent de positions individuelles, qui sans cela pourraient
compromettre les chances de succès du projet.

    Au quotidien, la communication directe permet donc d’obtenir une «bande passante»
nettement supérieure à l’écrit, et XP exploite largement cet avantage dans la plupart de ses
pratiques. Ainsi, qu’il s’agisse de l’identification des besoins, de la planification, de la
répartition des tâches ou encore de la programmation proprement dite, la plupart des pratiques
d’XP sont conçues pour amener les intervenants du projet à communiquer directement et
résoudre les problèmes ensemble.



Remarque
Cette approche constitue l’une des forces majeures d’XP, mais c’est aussi d’un certain point de
vue sa principale faiblesse. D’une part, ce besoin de communication est le principal facteur
limitatif au regard de la taille de l’équipe et, d’autre part, cela rend XP très sensible au type de
relations humaines qui ont cours dans le projet : appliquer XP dans un projet marqué par des
antagonismes internes forts, c’est courir à la catastrophe – mais on peut légitimement se
demander comment un tel projet peut bien réussir, indépendamment du processus adopté.



    Cependant, si l’accent est placé sur la communication directe, la communication écrite
n’est pas laissée de côté pour autant. Mais elle apparaît sous une forme différente : toutes les
informations ayant trait à l’implémentation et la conception se retrouvent dans le code lui
même – dont la clarté fait l’objet de nombreux efforts – et dans la batterie de tests qui
l’accompagne, et celles relatives aux besoins du client sont consignées d’une manière on ne
peut plus formelle, sous la forme de tests de recette automatiques. Si le client souhaite obtenir
des documents supplémentaires, il lui suffit de définir et de planifier les tâches
correspondantes comme pour tout autre besoin.




                       2)      La simplicité comme garantie de productivité
Une personne qui arrive sur un projet XP ne doit pas s’étonner de s’entendre répéter les
quelques «mantras» suivants : «La chose la plus simple qui puisse marcher» (The simplest
thing that could possibly work), «Tu n’en auras pas besoin» ( You ain’t gonna need it – et
son acronyme YAGNI), ou encore «Une fois et une seule» (Once and only once). Tous trois
sont l’expression d’une même valeur : la simplicité.

   Cette simplicité touche d’abord à la réalisation même du logiciel, dans laquelle un soin
particulier est apporté au code pour le débarrasser de toute complexité superfiue. En
particulier,les mécanismes de généricité – le «péché mignon» des développeurs – ne sont
encouragés que lorsqu’ils servent un besoin concret et immédiat, et en aucun cas un besoin
futur plus ou moins imaginaire. Les développeurs sont donc invités à implémenter la chose la
plus simple qui puisse marcher et, en ce qui concerne ces fameux mécanismes génériques, ou
encore ces outils «magiques» qui en font plus que ce qu’on leur demande, ils n’auront pas
besoin! En revanche, simple ne veut pas dire simpliste : les solutions adoptées doivent être
aussi simples que possible, mais toutes les duplications doivent être éliminées de sorte que
chaque information, chaque mécanisme ne soit exprimé qu’une fois et une seule – ce principe
est garant de la facilité de modification du code sur le long terme.

   Cet effort de simplicité s’applique également au client, à qui l’équipe demandera de
définir ses besoins et ses priorités avec une grande précision pour éviter d’implémenter des
choses inutiles et pour pouvoir se focaliser sur les besoins réellement importants. La
simplicité est également recherchée dans le choix des outils (de programmation ou de gestion
de projet) et dans la méthode de travail elle-même.

   En définitive, XP est fondé sur un pari : «faire simple un jour, avec la possibilité de
revenir en arrière le lendemain si un besoin différent apparaît. L'éventuel coût supplémentaire
induit sera, d’une part réduit parce que l’application est restée assez simple pour évoluer
facilement, et d’autre part sera bien peu de choses au regard des économies réalisées à ne pas
faire ce qui n'aurait servi à rien. » C’est au succès de ce pari qu’une équipe XP doit sa vitesse
de développement et son ouverture au changement.



                       3)     Le feedback comme outil de réduction du risque

   Malgré ce que peuvent laisser supposer son nom et ses apparences immédiates, l’Extreme
Programming est avant tout un processus de réduction du risque dans le projet. Le risque est
en effet soigneusement contrôlé à tous les niveaux, par la mise en place de boucles de
feedback qui permettent à l’équipe de développement, comme à son client, de savoir à tout
moment dans quel état se trouve réellement le projet, et de pouvoir rectifier le tir au fur et à
mesure pour mener le projet à son terme avec succès.

    L’exemple le plus saillant de ce principe concerne la pratique des livraisons fréquentes,
qui donne à tous les intervenants du projet un feedback régulier sur l’état d’avancement du
projet et l’état réel du produit. Mais le feedback ne se borne pas à l’observation : la pratique
de la planification itérative permet de tirer parti des informations recueillies pour, à la fois,
améliorer la planification elle-même et faire converger le produit vers une solution mieux
adaptée aux besoins réels du client.

    L’activité de programmation fait également l’objet de divers mécanismes de feedback,
tout d’abord à travers les tests unitaires mis en place, qui donnent aux développeurs des
indications immédiates sur le fonctionnement du code qu’ils écrivent. Le feedback est
également intégré à l’activité de conception, qui est menée tout au long de la réalisation pour
s’appuyer sur l’état réel de l’application plutôt que sur l’idée que l’on pourrait en avoir a
priori. Enfin,les développeurs s’appuient en permanence sur le feedback de leur binôme pour
s’assurer de la validité et de la qualité du code qu’ils produisent.

    Ce feedback permanent est un facteur de qualité, puisque les intervenants du projet
améliorent sans cesse leur travail à partir de l’expérience qu’ils accumulent. Mais c’est
également un facteur de vitesse : une équipe XP peut programmer vite, tout en restant sereine
parce qu’elle sait qu’elle dispose de nombreux mécanismes pour s’assurer que le projet reste
sur la bonne voie.



                       4)      Le courage de prendre les bonnes décisions

    L’expérience fait apparaître que la mise en œuvre des pratiques XP requiert une certaine
dose de cran. En effet, il faut du courage pour se lancer dans un projet sans avoir au préalable
tout spécifié et conçu dans le détail, même si l’on sait que le processus suivi comporte de
nombreux mécanismes de feedback.

    Il faut également du courage pour se borner à réaliser des choses simples, se focaliser
uniquement sur les besoins du moment en se disant qu’on pourra adapter l’application à de
nouveaux besoins, le moment venu. Il en faut aussi pour accepter de jeter une partie du code
qui est devenue inutile, ou récrire une partie de code jugée trop complexe.

     Enfin, il faut du courage pour appliquer les principes de communication et de feedback, en
particulier lorsqu’il s’agit de maintenir une transparence complète, même lorsque les
nouvelles ne sont pas bonnes, ou encore lorsqu’il s’agit de travailler ouvertement avec son
binôme en acceptant de lui montrer nos propres limites ou lacunes.

     Plus généralement, nous avons pu constater qu’il faut du courage pour mettre en place des
méthodes nouvelles sur des projets dont les enjeux sont toujours stratégiques.




 s             
               yW   hD

UML est un langage graphique de modélisation des besoins des utilisateurs, des concepts
métier, des concepts techniques dans le cadre d’un développement informatique. UML est
généralement associé à une méthodologie globale de gestion de projets fondée, si possible, sur
les grandes activités : spécification, analyse, conception et développement, éventuellement
itérative comme par exemple l’eXtreme Programming, selon les besoins et la maturité des
équipes. UML peut aussi aider à organiser le travail des équipes.




                     Points forts                             Points faibles
                                                  - XP n'est pas adapté pour les équipes
            - Simplicité de la mis en œuvre          de développement de plus de dix
               - Adapté aux changements                          personnes
          - Favorise la communication entre      - Un client doit être disponible à temps
          développeurs et développeur/client      complet pour répondre aux questions
                                                             des développeurs
•   Le client étant présent dans l’équipe, l’importance des documents liés au projet est
       réduite.
   •   Grande satisfaction du client et efficacité plus importante.
   •   Le code source est la principale production du projet.
   •   Le programmeur est un acteur essentiel, il accède à une certaine reconnaissance et il
       n’est pas seulement un simple exécutant.
   •   Présence d’un coach potentiel afin de former une équipe capable de travailler.
   •   Hiérarchie consentante.
   •   Culture d’entreprise adaptée, pas de mérite basé sur les heures supplémentaires et pas
       d’attachement aux méthodes linéaires et aux tonnes de documents comme reflet de la
       qualité.
                                  /
   •   Méthodologie déroutante.
   •   Trop d’anarchie.
   •   Pas assez de documentation.
   •   Concerne les petits et moyens projets seulement.
   •   Elle nécessite une forte implication du client.




   •   KEh^/KE



       L’eXtreme Programming, ou XP, est basé sur des principes très simples, mais souvent
ignorés par l'industrie. Une des idées révolutionnaires est que le coût du changement n'est pas
variable mais plutôt constant; XP accepte donc le changement comme une réalité et l'intègre
dans le processus de développement. Aussi, la programmation en paire, où deux
programmeurs travaillent ensemble sur le même ordinateur, permet d'augmenter la qualité à
des niveaux encore jamais vus. Une autre idée consiste à mettre l'emphase sur la
communication constante entre l'équipe de développement et le client, par le biais de boucles
rapides développement-test-feedback. Certaines de ces idées ne sont pas nouvelles, mais elles
sont assemblées dans XP pour former une méthodologie efficace et qui présente des résultats
concrets, plutôt que des résultats sur papier.
Rapport exposé eXtreme Programming XP

Contenu connexe

Tendances

Presentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'EtudesPresentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'EtudesTahani RIAHI
 
Architectures 3-tiers (Web)
Architectures 3-tiers (Web)Architectures 3-tiers (Web)
Architectures 3-tiers (Web)Heithem Abbes
 
Présentation PFE (Conception et développement d'une application web && mobile...
Présentation PFE (Conception et développement d'une application web && mobile...Présentation PFE (Conception et développement d'une application web && mobile...
Présentation PFE (Conception et développement d'une application web && mobile...Ramzi Noumairi
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesSirine Barguaoui
 
T1 corrections-qcm
T1 corrections-qcmT1 corrections-qcm
T1 corrections-qcminfcom
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UMLAmir Souissi
 
Cours Base de données relationnelles
Cours Base de données relationnellesCours Base de données relationnelles
Cours Base de données relationnellesAymen Kasmi
 
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiqueOussama Yoshiki
 
Systèmes d'Exploitation - chp1-introduction
Systèmes d'Exploitation - chp1-introductionSystèmes d'Exploitation - chp1-introduction
Systèmes d'Exploitation - chp1-introductionLilia Sfaxi
 
Bases de données réparties
Bases de données répartiesBases de données réparties
Bases de données répartiesAbdelouahed Abdou
 
Soutenance Elhadj Bah | Diplôme d'ingénieur de conception en Informatique | E...
Soutenance Elhadj Bah | Diplôme d'ingénieur de conception en Informatique | E...Soutenance Elhadj Bah | Diplôme d'ingénieur de conception en Informatique | E...
Soutenance Elhadj Bah | Diplôme d'ingénieur de conception en Informatique | E...Elhadj Mamadou Aliou BAH
 
Presentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequencesPresentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequencesStéphane Di Cioccio
 
Conception et réalisation d’une application web (1).pptx
Conception et réalisation d’une application web (1).pptxConception et réalisation d’une application web (1).pptx
Conception et réalisation d’une application web (1).pptxSouadZid
 
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...Mohamed Cherkaoui
 
BigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-ReduceBigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-ReduceLilia Sfaxi
 

Tendances (20)

Scrum
ScrumScrum
Scrum
 
Presentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'EtudesPresentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'Etudes
 
Architectures 3-tiers (Web)
Architectures 3-tiers (Web)Architectures 3-tiers (Web)
Architectures 3-tiers (Web)
 
Présentation PFE (Conception et développement d'une application web && mobile...
Présentation PFE (Conception et développement d'une application web && mobile...Présentation PFE (Conception et développement d'une application web && mobile...
Présentation PFE (Conception et développement d'une application web && mobile...
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiques
 
T1 corrections-qcm
T1 corrections-qcmT1 corrections-qcm
T1 corrections-qcm
 
Modèle en cascade
Modèle en cascadeModèle en cascade
Modèle en cascade
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UML
 
Scrum xp
Scrum xpScrum xp
Scrum xp
 
Cours Base de données relationnelles
Cours Base de données relationnellesCours Base de données relationnelles
Cours Base de données relationnelles
 
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatique
 
Systèmes d'Exploitation - chp1-introduction
Systèmes d'Exploitation - chp1-introductionSystèmes d'Exploitation - chp1-introduction
Systèmes d'Exploitation - chp1-introduction
 
Bases de données réparties
Bases de données répartiesBases de données réparties
Bases de données réparties
 
Soutenance Elhadj Bah | Diplôme d'ingénieur de conception en Informatique | E...
Soutenance Elhadj Bah | Diplôme d'ingénieur de conception en Informatique | E...Soutenance Elhadj Bah | Diplôme d'ingénieur de conception en Informatique | E...
Soutenance Elhadj Bah | Diplôme d'ingénieur de conception en Informatique | E...
 
Presentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequencesPresentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequences
 
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka StreamsTraitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
 
Mise en oeuvre des framework de machines et deep learning v1
Mise en oeuvre des framework de machines et deep learning v1 Mise en oeuvre des framework de machines et deep learning v1
Mise en oeuvre des framework de machines et deep learning v1
 
Conception et réalisation d’une application web (1).pptx
Conception et réalisation d’une application web (1).pptxConception et réalisation d’une application web (1).pptx
Conception et réalisation d’une application web (1).pptx
 
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
 
BigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-ReduceBigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-Reduce
 

Similaire à Rapport exposé eXtreme Programming XP

Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)David VALLAT
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Pyxis Technologies
 
Management de projet 2
Management de projet 2Management de projet 2
Management de projet 2David VALLAT
 
ppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdfppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdfimenhamada17
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SINouhaila ALAMI
 
Gestion de projet #2 : méthodes
Gestion de projet #2 : méthodesGestion de projet #2 : méthodes
Gestion de projet #2 : méthodesJean Michel
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logicielMajid CHADAD
 
Chapitre 1:gestion de projet pour les informatiques
Chapitre 1:gestion de projet pour les informatiquesChapitre 1:gestion de projet pour les informatiques
Chapitre 1:gestion de projet pour les informatiquesAbdiKhani
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxtestuser715939
 
E-business - développement
E-business - développementE-business - développement
E-business - développementManon Cuylits
 
Présentation des Méthodes Agiles pour l'association AnnexEthique
Présentation des Méthodes Agiles pour l'association AnnexEthiquePrésentation des Méthodes Agiles pour l'association AnnexEthique
Présentation des Méthodes Agiles pour l'association AnnexEthiqueDavid Brocard
 
Démystifions l'Agile - Actency Paris Open Source Summit 2019
Démystifions l'Agile - Actency Paris Open Source Summit 2019Démystifions l'Agile - Actency Paris Open Source Summit 2019
Démystifions l'Agile - Actency Paris Open Source Summit 2019Actency
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Erradi Mohamed
 
Gestion_de_projetOK.pptx
Gestion_de_projetOK.pptxGestion_de_projetOK.pptx
Gestion_de_projetOK.pptxOlyvierNzighou1
 

Similaire à Rapport exposé eXtreme Programming XP (20)

Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)
 
Project management for young IT engineer
Project management for young IT engineerProject management for young IT engineer
Project management for young IT engineer
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
 
Management de projet 2
Management de projet 2Management de projet 2
Management de projet 2
 
ppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdfppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdf
 
Rad
RadRad
Rad
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SI
 
Gestion de projet #2 : méthodes
Gestion de projet #2 : méthodesGestion de projet #2 : méthodes
Gestion de projet #2 : méthodes
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logiciel
 
Project Management for MBA (in French)
Project Management for MBA (in French)Project Management for MBA (in French)
Project Management for MBA (in French)
 
Chapitre 1:gestion de projet pour les informatiques
Chapitre 1:gestion de projet pour les informatiquesChapitre 1:gestion de projet pour les informatiques
Chapitre 1:gestion de projet pour les informatiques
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
 
E-business - développement
E-business - développementE-business - développement
E-business - développement
 
Présentation des Méthodes Agiles pour l'association AnnexEthique
Présentation des Méthodes Agiles pour l'association AnnexEthiquePrésentation des Méthodes Agiles pour l'association AnnexEthique
Présentation des Méthodes Agiles pour l'association AnnexEthique
 
Introduction au Web
Introduction au WebIntroduction au Web
Introduction au Web
 
Démystifions l'Agile - Actency Paris Open Source Summit 2019
Démystifions l'Agile - Actency Paris Open Source Summit 2019Démystifions l'Agile - Actency Paris Open Source Summit 2019
Démystifions l'Agile - Actency Paris Open Source Summit 2019
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Lecon 1.1
Lecon 1.1Lecon 1.1
Lecon 1.1
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 
Gestion_de_projetOK.pptx
Gestion_de_projetOK.pptxGestion_de_projetOK.pptx
Gestion_de_projetOK.pptx
 

Plus de Sarah

Tanjaouiates au Rallye Aicha des Gazelles
Tanjaouiates au Rallye Aicha des GazellesTanjaouiates au Rallye Aicha des Gazelles
Tanjaouiates au Rallye Aicha des GazellesSarah
 
Délégation
Délégation Délégation
Délégation Sarah
 
Identification des empreintes digitales
Identification des empreintes digitalesIdentification des empreintes digitales
Identification des empreintes digitalesSarah
 
Slides ubiquité et intelligence ambiante
Slides ubiquité et intelligence ambianteSlides ubiquité et intelligence ambiante
Slides ubiquité et intelligence ambianteSarah
 
Ubiquité et intelligence ambiante
Ubiquité et intelligence ambianteUbiquité et intelligence ambiante
Ubiquité et intelligence ambianteSarah
 
Configuration des services web sous centOS 5
Configuration des services web sous centOS 5Configuration des services web sous centOS 5
Configuration des services web sous centOS 5Sarah
 
Présentation TOra
Présentation TOraPrésentation TOra
Présentation TOraSarah
 
Configuration des services web sous CentOS
Configuration des services web sous CentOSConfiguration des services web sous CentOS
Configuration des services web sous CentOSSarah
 
Initiation au langage python
Initiation au langage python Initiation au langage python
Initiation au langage python Sarah
 
Chiisme
ChiismeChiisme
ChiismeSarah
 
Présentation python
Présentation pythonPrésentation python
Présentation pythonSarah
 
Chiisme
ChiismeChiisme
ChiismeSarah
 

Plus de Sarah (12)

Tanjaouiates au Rallye Aicha des Gazelles
Tanjaouiates au Rallye Aicha des GazellesTanjaouiates au Rallye Aicha des Gazelles
Tanjaouiates au Rallye Aicha des Gazelles
 
Délégation
Délégation Délégation
Délégation
 
Identification des empreintes digitales
Identification des empreintes digitalesIdentification des empreintes digitales
Identification des empreintes digitales
 
Slides ubiquité et intelligence ambiante
Slides ubiquité et intelligence ambianteSlides ubiquité et intelligence ambiante
Slides ubiquité et intelligence ambiante
 
Ubiquité et intelligence ambiante
Ubiquité et intelligence ambianteUbiquité et intelligence ambiante
Ubiquité et intelligence ambiante
 
Configuration des services web sous centOS 5
Configuration des services web sous centOS 5Configuration des services web sous centOS 5
Configuration des services web sous centOS 5
 
Présentation TOra
Présentation TOraPrésentation TOra
Présentation TOra
 
Configuration des services web sous CentOS
Configuration des services web sous CentOSConfiguration des services web sous CentOS
Configuration des services web sous CentOS
 
Initiation au langage python
Initiation au langage python Initiation au langage python
Initiation au langage python
 
Chiisme
ChiismeChiisme
Chiisme
 
Présentation python
Présentation pythonPrésentation python
Présentation python
 
Chiisme
ChiismeChiisme
Chiisme
 

Rapport exposé eXtreme Programming XP

  • 1. ”‘‰”ƒƒ–‹‘ ‡–”²‡ ‡–”‡‡ ”‘‰”ƒ‹‰ ^ ,,zE ^ ^Z/ / E
  • 2. ‘ƒ‹”‡ • /EdZKhd/KE / D D s D W h , s D W // W W W , W yW W /// K , Z /s yW yW W s s yW hD • KEh^/KE
  • 3. /EdZKhd/KE Le développement de logiciels a été pendant longtemps entièrement libre de directives ou de contraintes, et il n'y avait aucune méthode pour analyser les besoins, produire une solution, ou même évaluer le succès. Mais depuis les débuts de l'informatique commerciale dans les années '60,et en 1968, une conférence de l'OTAN a introduit le terme « génie logiciel » et suggéré d'utiliser les méthodes rigoureuses et éprouvées du génie civil au chaos du développement de logiciels. L'idée était louable, mais une différence majeure existe: contrairement à la physique et aux mathématiques, l'informatique ne repose sur aucune loi et ne peut être vérifiée scientifiquement. Par après plusieurs méthodologies de développement de logiciel ont vu le jour. Le modèle en cascade et ses dérivés ont connu un grand succès, mais leur lourdeur et rigidité sont de sérieux handicaps. Extreme Programming propose de remplacer certaines notions acquises par des idées révolutionnaires, et de rendre le développement de logiciel efficace et agile. / Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel. Ces cycles prendront en compte toutes les étapes de la conception d'un logiciel. D Le modèle en cascade est hérité de l'industrie du BTP1. Ce modèle repose sur les hypothèses suivantes : • On ne peut pas construire la toiture avant les fondations. • Les conséquences d'une modification en amont du cycle ont un impact majeur sur les coûts en aval. d W
  • 4. Les phases traditionnelles de développement sont effectuées simplement les unes après les autres, avec un retour sur les précédentes, voire au tout début du cycle. Le processus de développement utilisant un cycle en cascade exécute des phases qui ont pour caractéristiques : • De produire des livrables définis au préalable. • De se terminer à une date précise. • De ne se terminer que lorsque les livrables sont jugés satisfaisants lors d'une étape de validation-vérification.2 D s Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en cascade. Ce modèle est une amélioration du modèle en cascade qui permet en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés afin d'améliorer le logiciel. De plus le cycle en V met en évidence la nécessité d'anticiper et de préparer dans les étapes descendantes les « attendus » des futures étapes montantes : ainsi les attendus des tests de validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors de la conception, etc. D
  • 5. Le cycle en V est devenu un standard de l'industrie du développement de logiciel et de la gestion de projet depuis les années 1980. D Ce mouvement est apparu au milieu des années '90 il avait pour but de rendre le processus de développement plus efficace, en utilisant des concepts très simples et reconnus. Il n'est directement relié à aucune méthodologie, mais propose une série de recommandations, valeurs, et principes qui sont appliquées dans d'autres méthodes. W Les méthodes agiles sont des méthodes de gestion de projets informatiques et de développement qui se positionnent en réaction à des méthodes traditionnelles jugées trop lourdes. XP fait partie de cette catégorie dont la première idée a été de réagir face à la bureaucratie où toute démarche exige une grande quantité de temps. C’est aussi la plus populaire des méthodes agiles mais on peut aussi citer : ASD (Adaptative Software Development), SCRUM, Crystal, FDD (Feature Driven Development) et DSDM (Dynamic System Development Method) qui peuvent chacune être adaptée à une situation particulière, fonction de la taille de l’équipe. h ,
  • 6. En 1986, Barry W. Boehm présentait un nouveau modèle de développement itératif et incrémental. En 1986 également, Hirotaka Takeuchi et Ikujiro Nonaka publient « the new new product developpement game » dans la Harvard business review. Leur article présente un modèle de développement basé sur l'aptitude au changement, l'auto organisation, l'imbrication des phases de développement, et l'itération (on y fait d'ailleurs mention du mot scrum par analogie au rugby). En 1991, James Martin (RAD3), s’appuyant sur cette vision d’une évolution continue, proposa une méthode de développement rapide d’application. Sa structure, base des approches actuelles, déterminait le phasage essentiel et mettait en œuvre un principe adaptatif fondé sur la validation permanente des utilisateurs. À partir de 1994, Jean-Pierre Vickoff en France, notamment avec le Processus RAD publié par le Gartner Group, et Jennifer Stapleton en Grande-Bretagne, avec DSDM, introduisirent des compléments tels que : • la spécialisation des rôles, • l’instrumentation des communications, • l’organisation des divers types de réunions, • le groupe de facilitation et de rapport, • les « raccourcis méthodologiques » de modélisation, • l’architecture de réalisation (imbrication des itérations), • la formalisation de processus légers de mise en œuvre. Dans la seconde moitié des années 1990, une vague d’une dizaine de méthodes (dont Extreme programming et Scrum sont les principales représentantes) poussa à l’extrême certaines pratiques de qualité de la construction applicative ainsi que les techniques adaptatives d’estimation, de planification et de pilotage de projet.
  • 7. En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sont réunies pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles. Les plus connus d'entre eux étaient Ward Cunningham, l'inventeur du Wiki via WikiWikiWeb, Kent Beck, père de l'extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l'ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler, et Dave Thomas ainsi que Arie van Bennekum pour DSDM (Dynamic System Development Method). Ces 17 experts venant tous d'horizons différents réussirent à extraire de leurs concepts respectifs des critères pour définir une nouvelle façon de développer des logiciels :4 De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canonique du développement Agile et de ses principes sous-jacents.5 s D Les quatre valeurs fondamentales (entre parenthèses, les citations du manifeste)6: • L'équipe (« Personnes et interaction plutôt que processus et outils ») : Dans l'optique agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de fonctionnement. Il est préférable d'avoir une équipe soudée et qui communique, composée de développeurs (éventuellement à niveaux variables), plutôt qu'une équipe composée d'experts fonctionnant chacun de manière isolée. La communication est une notion fondamentale. • L'application (« Logiciel fonctionnel plutôt que documentation complète ») : Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse mais non un but en soi. Une documentation précise est utile comme moyen de communication. La documentation représente une charge de travail D D D D yW ^ZhD W D yW h W D s D ^ s E z /^E y D
  • 8. importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication). • La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes. • L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d'évolution. W Ces quatre valeurs se déclinent en douze principes généraux communs à toutes les méthodes agiles7 : • « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles » • « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client » • « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte » • « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet » • « Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail » • « La méthode la plus efficace pour transmettre l'information est une conversation en face à face » • « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet » d
  • 9. « Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment » • « Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité » • « La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle » • « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent » • « À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ». D
  • 10. Il existe de nombreuses méthodes agiles telles que8 : • Rapid Application Development (RAD, 1991) • Dynamic systems development method (DSDM, 1995, consortium anglais commercialisant le RAD) • Scrum (1996) • Feature Driven Development (FDD) (1999) • Extreme programming (XP, 1999) • Adaptive software development (ASD, 2000) • Test Driven Development (TDD, 2002) • Crystal clear (2004) // W W W La programmation eXtrème dite XP (eXtreme Programming) est une méthodologie efficace de développement rapide de logiciels qui exige que les membres d’une équipe de développeurs soient physiquement proches les uns des autres. XP est une méthode de développement dédiée à des petites équipes confrontées à un environnement changeant ou des besoins mal connus. Cette méthode est née sur le terrain, à partir des observations et recherches de développeurs expérimentés soucieux de se concentrer sur les nécessités élémentaires du développement : • Développer vite : S’assurer que les changements restent toujours faciles pour conserver une vitesse de développement soutenue tout au long du projet. • Développer juste : Se focaliser sur les besoins réels du client. D D
  • 11. XP définit une discipline de développement qui permet de diminuer le coût du changement dans le logiciel, à tel point qu'il devient plus avantageux de prendre la décision le plus tard possible, en attendant les résultats concrets issus du développement lui-même. Les spécifications peuvent alors être élaborées progressivement tout au long du développement en enchaînant des itérations rapides de spécification / développement / livraison. Le client peut ainsi guider le développement tout au long du projet. La méthodologie a été établie pour livrer le logiciel dans les délais impartis. Les développeurs sont préparés aux changements des besoins du client, même dans la fin du cycle de développement. Managers, clients et développeurs font partie de la même équipe dont le but est de fournir un logiciel de qualité. XP rend possible simplement et efficacement le développement en groupe de travail. XP est basé sur des principes essentiels : Une forte réactivité au changement des besoins du client au plus tôt dans le cycle de vie du logiciel Un travail d'équipe (développeurs / chefs de projets / clients) La qualité du code : elle garantit un gain d'argent pour le client La qualité des tests effectués au plus tôt Une intégration permanente XP : (une méthodologie allégée) Une méthodologie logicielle est un ensemble de règles et de pratiques mises en œuvre pour la création de programmes. Ces règles sont trop difficiles à suivre, les procédures complexes et mal comprises et la quantité de documentation à produire hors de contrôle. Pour essayer de rester dans le planning, il est nécessaire de simplifier les règles, garder celles qui contribuent à la qualité et laisser de côté celles qui ralentissent le projet. L'XP est une méthodologie allégée car elle est constituée de peu de règles et de mises en pratique. Le travail en équipe, la réactivité, la concision et l'efficacité s'en trouvent renforcés.
  • 12. XP est une méthode basée sur des principes simples, que tout le monde pratique déjà sans le savoir. Mais alors, où est la « révolution » ? Rendre moins lourdes les démarches Le but d’XP est de trouver des solutions plus ou moins simples, basées sur des principes éprouvés, pour tenter de diminuer les risques pour respecter les délais et la qualité du produit commandé. Cela, en trouvant un compromis équilibré entre pas de démarche et trop de démarche, tout en respectant le minimum de discipline nécessaire pour attendre un retour sur investissement en temps et en effort immédiat et intéressant. Ainsi, on souhaite réduire radicalement la production de documents en se focalisant sur un code bien commenté plutôt que sur des documentations techniques très formelles. XP évite donc avec cela les lourdeurs des méthodes classiques et est donc un habile compromis entre une méthode traditionnelle et le développement « cow boy », sans règles précises. Par conséquent le travail des informaticiens est totalement tourné vers la technique où ils se sentiront vraisemblablement plus à l’aise. Changer les principes En outre, XP, en tant que méthode agile, se veut adaptative plutôt que prédictive. C’est à dire qu’à l’inverse des méthodes lourdes qui tentent de dresser un plan au début du projet, XP indique qu’il vaut mieux agir sur le court terme. Cela, tout simplement parce qu’il n’existe pas de projet figé où le prédicat de base ou le contexte ne changent pas du tout. Dans ce cas, le coût du changement a une croissance logarithmique en fonction du temps. Le simple fait de ne pas être réticente aux changements permet dans un premier temps de mieux s’y adapter mais permet aussi une meilleure relation avec le client et la livraison d’un produit conforme totalement aux exigences de ce dernier. Enfin, le dernier but d’XP est de se vouloir orienter sur les personnes plutôt que sur les processus. Alors, le développement tentera d’être une activité agréable plutôt qu’un cauchemar bureaucratique. , La naissance d’une nouvelle méthode arrive rarement sans raisons. Elle fait plutôt suite à une période difficile... D’après une étude américaine menée en 1994 sur 8000 projets, 16 % n’ont pas respecté les délais et le budget initial et, pire, 32 % n’ont jamais abouti.
  • 13. Ainsi, dans le monde de l’ingénierie logicielle, trois plaies pourtant bien connues enveniment le développement d’applications. La première concerne le planning difficilement maîtrisé ou impliquant de nombreuses heures sup. Le deuxième est issue des besoins souvent mal identifiés ou mal compris en raison d’un cahier des charges mal étudié ou incomplet. Tout cela implique des changements au cours du développement, d’autant plus si le client décide de modifier le produit, après une première maquette par exemple. Enfin, le dernier problème concerne la livraison finale du produit qui est parfois buguée. XP est né lors d’une récente vague de création de nouvelles méthodes parallèlement à l’explosion de l’informatique dans les entreprises et de l’émergence du freeware. Lors de cette vague, sont essentiellement apparues des méthodes qualifiées d’agile dont XP fait partie. y W W yW W yW La méthode est très attentive à l’activité en dernière analyse essentielle dans un projet de logiciel : la programmation. Le codage produit la documentation principale : les fichiers sources. Pourquoi « extrême » programming ? Kent Beck, qui structure et présente XP, explique que les pratiques sur lesquelles est bâtie XP sont autant de boutons de contrôle… qu’il pousse au maximum. De ce point de vue, XP est la réunion cohérente de pratiques efficaces, telles que le test omniprésent, l’esprit d’équipe, le rôle prépondérant du client dans l’équipe, etc. Le bon sens est poussé à son extrême ! W Petites à moyennes équipes écrivant des logiciels dont les besoins sont vagues ou changent rapidement
  • 14. /// K , W d A. Programmeur Développeur : • Responsabilisation Retour du programmeur comme rôle central A la fois : codeur, testeur, concepteur et analyste Apprentissage Qualités humaines nécessaires XP : Ecole de l’excellence Responsabilisés pour donner le meilleur d’eux même ex. : estimation des charges et délais • Pratiques XP Programmation en binôme Responsabilité collective du code Tests unitaires Règles de codage Conception simple Intégration continue Remaniement Rythme durable B. Client : • Responsabilisation Description informelle d’une fonctionnalité ou d’une interaction avec l’utilisateur Le plus simple possible
  • 15. Des scénarios initiaux sont dégagés et Présentés, classés par priorité et répartis en itérations • Pratiques XP Planification itérative Rédaction des scénarios clients Séances de planification Tests de recette Intégration continue Rythme durable C. Testeur : • Responsabilisation Définit et automatise les tests de recette Conseille le client sur la testabilité d’une Fonctionnalité. Utilisation d’outils différents pour scripter. Garant du sentiment de réussite sur le projet Test fonctionnel réussi→ Progression. Communiquer pour motiver (graphique de progression...). • Pratiques XP Suivi des tests (planification itérative) Tests de recette Intégration continue Rythme durable D. Tracker : • Responsabilisation Pas un supérieur hiérarchique Quelqu’un a qui on peut se confier De préférence pas un programmeur, mais quelqu’un d’extérieur Pour éviter les discussions techniques A défaut, ce rôle peut tourner entre les programmeurs à chaque itération • Pratiques XP Planification itérative E. Manager : • Responsabilisation Il s’occupe matériellement de l’équipe Il demande des comptes (sur les engagements pris) Interface avec l’extérieur (dans le cadre d’un sous-projet)
  • 16. Pratiques XP Scénarios client Planification itérative Rythme durable F. Coach, le chef de projet : • Responsabilisation Il réunit tout les autres rôles Vérifie que chaque rôle est respecté Ses buts ultimes : o Equipe autonome o Chaque programmeur est en amélioration continue Ses qualités o Expert de la méthode XP o Expert technique o Programmeur chevronné o Architecte o Pédagogue et sensible o Sang-froid • Pratiques XP Toutes ! Z W d ^ W W d D d /s yW yW i. Planification et gestion :
  • 17. Écrire des scénarios utilisateur «user stories» avec le client Segmenter le projet en itérations (exemple: livraisons aux X semaines) Débuter chaque jour par une réunion d’équipe debout ! Déplacer les personnes (inter changer les paires) Le code appartient à toute l’équipe ( egoless prog., Weinberg, 1971) Ne pas faire de temps supplémentaire «ideal week» ii. Conception : KIS = «keep it simple»: utiliser des cartes CRC (ou léger UML) Représenter une histoire utilisateur à la fois Adopter un codage uniforme: noms, standards… Ne jamais ajouter de fonctionalité trop tôt Encourager la reconstruction avant une nouvelle itération iii. Les activités et processus. Le client (expert disponible) priorise les histoires La vitesse du projet est mesurée (et adapte les itérations) Le test unitaire est produit avant le code (+1 par bogue) Le code pour livraison est programmé par binômes (paire) L’intégration est fréquente et se fait séquentiellement Les tests d’acceptation sont exécutés souvent et publiés
  • 18. b. Les pratiques de l’XP K K d d W d D ' ^ h d Z Z / ^ h ^ Dans cette partie nous aller présenter les treizes pratiques «canoniques» dont XP définit, et que nous classons en trois grandes catégories: celles relatives à la programmation, celles relatives au fonctionnement interne de l’équipe et celles qui sont liées à la planification et aux relations avec le client. W K K d d W ' D d h ^ d Z Z / ^ h ^ Dans cette partie nous aller présenter les treizes pratiques «canoniques» dont XP définit, et que nous classons en trois grandes catégories: celles relatives à la programmation, celles relatives au fonctionnement interne de l’équipe et celles qui sont liées à la planification
  • 19. et aux relations avec le client. 1. Les pratiques de programmation Au cœur des pratiques XP, les pratiques de programmation que nous présentons ci-après permettent d’améliorer continuellement la conception et le code de l’application pour qu’elle reste toujours aussi claire et simple que possible : • Conception simple (simple design) : les développeurs implémentent toujours la solution la plus simple qui puisse fonctionner. En particulier, ils n’inventent pas de mécanismes génériques si le besoin immédiat ne l’exige pas. • Remaniement (refactoring) : les développeurs n’hésitent pas à revenir sur le code écrit pour le rendre plus «propre», le débarrasser d’éventuelles parties inutilisées, et le préparer à l’ajout de la fonctionnalité suivante. D’une manière plus générale, cette pratique propose une démarche de conception continue qui fait émerger la structure de l’application au fur et à mesure du développement. • Développement piloté par les tests unitaires (test-first programming, unit tests, developer tests) : les développeurs écrivent des tests automatiques pour le code qu’ils produisent, et ce au moment même d’écrire le code en question. Cela leur permet d’une part de mieux cerner le problème avant d’écrire le code, et d’autre part de constituer progressivement une batterie de tests qui les autorise ensuite à apporter rapidement des changements dans l’application, tout en conservant une certaine sérénité. • Tests de recette (acceptance tests, customer tests) : le client précise très explicitement ses besoins et les objectifs des programmeurs – en participant à la rédaction de tests de recette. Comme les tests unitaires, les tests de recette doivent être automatiques afin de pouvoir vérifier tous les jours la non-régression du produit. 2. Les pratiques de collaboration Dans une équipe XP, tous les développeurs travaillent ensemble (voir chapitre 5) et interviennent sur la totalité de l’application. Cela garantit la qualité de cette dernière à travers les relectures croisées que cela engendre, mais cela rend également le travail plus motivant et
  • 20. offre une plus grande souplesse dans l’affectation des tâches. Les pratiques qui régissent cette organisation sont les suivantes : • Programmation en binôme (pair programming) : lorsqu’ils écrivent le code de l’application, les développeurs travaillent systématiquement à deux sur la même machine – il s’agit là d’une forme «extrême» de relecture de code, dans laquelle les deux développeurs collaborent activement pour résoudre les problèmes qu’ils rencontrent. Les binômes changent fréquemment, ainsi chacun est amené à travailler tôt ou tard avec tous les autres membres de l’équipe. • Responsabilité collective du code (collective code ownership) : tous les développeurs de l’équipe peuvent être amenés à travailler sur toutes les parties de l’application. De plus, ils ont le devoir d’améliorer le code sur lequel ils interviennent, même s’ils n’en sont pas les auteurs initiaux. • Règles de codage (coding standards) : les développeurs se plient à des règles de codage définies par l’équipe elle-même, de manière à garantir l’homogénéité de leur code avec le reste de l’application, et ainsi à faciliter l’intervention d’autres développeurs. • Métaphore (metaphor) : les développeurs n’hésitent pas à recourir aux métaphores pour décrire la structure interne du logiciel ou ses enjeux fonctionnels, de façon à faciliter la communication et à assurer une certaine homogénéité de style dans l’ensemble de la conception, l’idéal étant de décrire le système dans son ensemble par une métaphore unique. • Intégration continue (continuous integration) : les développeurs synchronisent leurs développements aussi souvent que possible – au moins une fois par jour. Cela réduit la fréquence et la gravité des problèmes d’intégration, et permet de disposer à tout moment d’une version du logiciel qui intègre tous les développements en cours. 3. Les pratiques de gestion de projet Les pratiques de programmation et de collaboration (voir chapitre 6) permettent de créer un contexte dans lequel une démarche de spécification et de conception purement itérative devient viable. Les pratiques suivantes montrent comment XP exploite cet avantage
  • 21. afin de s’assurer que l’équipe et son client restent en phase tout au long du projet, de façon à converger au plus tôt vers un produit adapté aux besoins du client : • Livraisons fréquentes (frequent releases) : l’équipe livre des versions du logiciel à un rythme régulier, aussi élevé que possible – la fréquence précise étant fixée par le client. Cela permet à l’équipe comme au client de s’assurer que le produit correspond bien aux attentes de ce dernier et que le projet est sur la bonne voie. • Planification itérative (planning game) : la planification du projet est réalisée conjointement par le client et l’équipe de développement, au cours de séances dédiées, organisées régulièrement tout au long du projet. • Client sur site (on-site customer, whole team) : le client est littéralement intégré à l’équipe de développement pour arbitrer les priorités, et définir précisément ses besoins,notamment en répondant en direct aux questions des programmeurs et en bénéficiant du feedback immédiat d’une application aux livraisons fréquentes. • Rythme durable (sustainable pace) : l’équipe adopte des horaires qui lui permettent de conserver tout au long du projet l’énergie nécessaire pour produire un travail de qualité et mettre en œuvre efficacement les autres pratiques. s
  • 22. Z ^ NB : La valeur ‘Respect’ existe dès la deuxiéme version d’XP on se contente d’étudier quatre autres valeurs. Après si elles sont indispensables aujourd’hui pour mettre l’Extreme Programming en œuvre, les pratiques que nous venons de présenter ne suffisent pas pour autant à le définir. Il ne s’agit en définitive que de techniques, destinées à faire émerger un environnement de travail marqué par les quatre qualités érigées en valeurs par XP et qui en font l’essence : la communication, la simplicité, le feedback et le courage. 1) La communication pour une meilleure visibilité Du point de vue d’XP, un projet de développement est avant tout un effort collectif de création, dont le succès dépend d’une part de la capacité de ses différents intervenants à s’accorder sur une vision commune de ce qui doit être produit, et d’autre part de leur capacité à synchroniser leurs actions individuelles pour atteindre l’objectif commun. Or, ces deux conditions dépendent en majeure partie de la qualité de la communication qui lie ces intervenants entre eux. Mais sur le fond, il n’y a finalement pas grand-chose de spécifique à XP sur ce point. Ce qui démarque l’approche XP dans ce domaine, c’est l’accent mis sur la communication directe, sur le contact humain. Certes, la communication orale présente des faiblesses en termes de structuration de l’information et de traçabilité, mais elle tire sa force de sa
  • 23. simplicité et des interactions rapides entre les interlocuteurs qui permettent de converger rapidement sur les informations essentielles. En outre, le contact direct permet de véhiculer des informations beaucoup plus personnelles cela donne ainsi l’occasion d’identifier et de résoudre des blocages qui relèvent de positions individuelles, qui sans cela pourraient compromettre les chances de succès du projet. Au quotidien, la communication directe permet donc d’obtenir une «bande passante» nettement supérieure à l’écrit, et XP exploite largement cet avantage dans la plupart de ses pratiques. Ainsi, qu’il s’agisse de l’identification des besoins, de la planification, de la répartition des tâches ou encore de la programmation proprement dite, la plupart des pratiques d’XP sont conçues pour amener les intervenants du projet à communiquer directement et résoudre les problèmes ensemble. Remarque Cette approche constitue l’une des forces majeures d’XP, mais c’est aussi d’un certain point de vue sa principale faiblesse. D’une part, ce besoin de communication est le principal facteur limitatif au regard de la taille de l’équipe et, d’autre part, cela rend XP très sensible au type de relations humaines qui ont cours dans le projet : appliquer XP dans un projet marqué par des antagonismes internes forts, c’est courir à la catastrophe – mais on peut légitimement se demander comment un tel projet peut bien réussir, indépendamment du processus adopté. Cependant, si l’accent est placé sur la communication directe, la communication écrite n’est pas laissée de côté pour autant. Mais elle apparaît sous une forme différente : toutes les informations ayant trait à l’implémentation et la conception se retrouvent dans le code lui même – dont la clarté fait l’objet de nombreux efforts – et dans la batterie de tests qui l’accompagne, et celles relatives aux besoins du client sont consignées d’une manière on ne peut plus formelle, sous la forme de tests de recette automatiques. Si le client souhaite obtenir des documents supplémentaires, il lui suffit de définir et de planifier les tâches correspondantes comme pour tout autre besoin. 2) La simplicité comme garantie de productivité
  • 24. Une personne qui arrive sur un projet XP ne doit pas s’étonner de s’entendre répéter les quelques «mantras» suivants : «La chose la plus simple qui puisse marcher» (The simplest thing that could possibly work), «Tu n’en auras pas besoin» ( You ain’t gonna need it – et son acronyme YAGNI), ou encore «Une fois et une seule» (Once and only once). Tous trois sont l’expression d’une même valeur : la simplicité. Cette simplicité touche d’abord à la réalisation même du logiciel, dans laquelle un soin particulier est apporté au code pour le débarrasser de toute complexité superfiue. En particulier,les mécanismes de généricité – le «péché mignon» des développeurs – ne sont encouragés que lorsqu’ils servent un besoin concret et immédiat, et en aucun cas un besoin futur plus ou moins imaginaire. Les développeurs sont donc invités à implémenter la chose la plus simple qui puisse marcher et, en ce qui concerne ces fameux mécanismes génériques, ou encore ces outils «magiques» qui en font plus que ce qu’on leur demande, ils n’auront pas besoin! En revanche, simple ne veut pas dire simpliste : les solutions adoptées doivent être aussi simples que possible, mais toutes les duplications doivent être éliminées de sorte que chaque information, chaque mécanisme ne soit exprimé qu’une fois et une seule – ce principe est garant de la facilité de modification du code sur le long terme. Cet effort de simplicité s’applique également au client, à qui l’équipe demandera de définir ses besoins et ses priorités avec une grande précision pour éviter d’implémenter des choses inutiles et pour pouvoir se focaliser sur les besoins réellement importants. La simplicité est également recherchée dans le choix des outils (de programmation ou de gestion de projet) et dans la méthode de travail elle-même. En définitive, XP est fondé sur un pari : «faire simple un jour, avec la possibilité de revenir en arrière le lendemain si un besoin différent apparaît. L'éventuel coût supplémentaire induit sera, d’une part réduit parce que l’application est restée assez simple pour évoluer facilement, et d’autre part sera bien peu de choses au regard des économies réalisées à ne pas faire ce qui n'aurait servi à rien. » C’est au succès de ce pari qu’une équipe XP doit sa vitesse de développement et son ouverture au changement. 3) Le feedback comme outil de réduction du risque Malgré ce que peuvent laisser supposer son nom et ses apparences immédiates, l’Extreme Programming est avant tout un processus de réduction du risque dans le projet. Le risque est
  • 25. en effet soigneusement contrôlé à tous les niveaux, par la mise en place de boucles de feedback qui permettent à l’équipe de développement, comme à son client, de savoir à tout moment dans quel état se trouve réellement le projet, et de pouvoir rectifier le tir au fur et à mesure pour mener le projet à son terme avec succès. L’exemple le plus saillant de ce principe concerne la pratique des livraisons fréquentes, qui donne à tous les intervenants du projet un feedback régulier sur l’état d’avancement du projet et l’état réel du produit. Mais le feedback ne se borne pas à l’observation : la pratique de la planification itérative permet de tirer parti des informations recueillies pour, à la fois, améliorer la planification elle-même et faire converger le produit vers une solution mieux adaptée aux besoins réels du client. L’activité de programmation fait également l’objet de divers mécanismes de feedback, tout d’abord à travers les tests unitaires mis en place, qui donnent aux développeurs des indications immédiates sur le fonctionnement du code qu’ils écrivent. Le feedback est également intégré à l’activité de conception, qui est menée tout au long de la réalisation pour s’appuyer sur l’état réel de l’application plutôt que sur l’idée que l’on pourrait en avoir a priori. Enfin,les développeurs s’appuient en permanence sur le feedback de leur binôme pour s’assurer de la validité et de la qualité du code qu’ils produisent. Ce feedback permanent est un facteur de qualité, puisque les intervenants du projet améliorent sans cesse leur travail à partir de l’expérience qu’ils accumulent. Mais c’est également un facteur de vitesse : une équipe XP peut programmer vite, tout en restant sereine parce qu’elle sait qu’elle dispose de nombreux mécanismes pour s’assurer que le projet reste sur la bonne voie. 4) Le courage de prendre les bonnes décisions L’expérience fait apparaître que la mise en œuvre des pratiques XP requiert une certaine dose de cran. En effet, il faut du courage pour se lancer dans un projet sans avoir au préalable tout spécifié et conçu dans le détail, même si l’on sait que le processus suivi comporte de nombreux mécanismes de feedback. Il faut également du courage pour se borner à réaliser des choses simples, se focaliser uniquement sur les besoins du moment en se disant qu’on pourra adapter l’application à de
  • 26. nouveaux besoins, le moment venu. Il en faut aussi pour accepter de jeter une partie du code qui est devenue inutile, ou récrire une partie de code jugée trop complexe. Enfin, il faut du courage pour appliquer les principes de communication et de feedback, en particulier lorsqu’il s’agit de maintenir une transparence complète, même lorsque les nouvelles ne sont pas bonnes, ou encore lorsqu’il s’agit de travailler ouvertement avec son binôme en acceptant de lui montrer nos propres limites ou lacunes. Plus généralement, nous avons pu constater qu’il faut du courage pour mettre en place des méthodes nouvelles sur des projets dont les enjeux sont toujours stratégiques. s yW hD UML est un langage graphique de modélisation des besoins des utilisateurs, des concepts métier, des concepts techniques dans le cadre d’un développement informatique. UML est généralement associé à une méthodologie globale de gestion de projets fondée, si possible, sur les grandes activités : spécification, analyse, conception et développement, éventuellement itérative comme par exemple l’eXtreme Programming, selon les besoins et la maturité des équipes. UML peut aussi aider à organiser le travail des équipes. Points forts Points faibles - XP n'est pas adapté pour les équipes - Simplicité de la mis en œuvre de développement de plus de dix - Adapté aux changements personnes - Favorise la communication entre - Un client doit être disponible à temps développeurs et développeur/client complet pour répondre aux questions des développeurs
  • 27. Le client étant présent dans l’équipe, l’importance des documents liés au projet est réduite. • Grande satisfaction du client et efficacité plus importante. • Le code source est la principale production du projet. • Le programmeur est un acteur essentiel, il accède à une certaine reconnaissance et il n’est pas seulement un simple exécutant. • Présence d’un coach potentiel afin de former une équipe capable de travailler. • Hiérarchie consentante. • Culture d’entreprise adaptée, pas de mérite basé sur les heures supplémentaires et pas d’attachement aux méthodes linéaires et aux tonnes de documents comme reflet de la qualité. / • Méthodologie déroutante. • Trop d’anarchie. • Pas assez de documentation. • Concerne les petits et moyens projets seulement. • Elle nécessite une forte implication du client. • KEh^/KE L’eXtreme Programming, ou XP, est basé sur des principes très simples, mais souvent ignorés par l'industrie. Une des idées révolutionnaires est que le coût du changement n'est pas variable mais plutôt constant; XP accepte donc le changement comme une réalité et l'intègre dans le processus de développement. Aussi, la programmation en paire, où deux programmeurs travaillent ensemble sur le même ordinateur, permet d'augmenter la qualité à des niveaux encore jamais vus. Une autre idée consiste à mettre l'emphase sur la communication constante entre l'équipe de développement et le client, par le biais de boucles rapides développement-test-feedback. Certaines de ces idées ne sont pas nouvelles, mais elles sont assemblées dans XP pour former une méthodologie efficace et qui présente des résultats concrets, plutôt que des résultats sur papier.