eXtreme Programming Explained: Embrace Change

Posté par Anonyme le 27 mai 2001 à 22:58. Modéré par Fabien Penso.

Étiquettes :

mai

2001

Extrait:
"Kent Beck, auteur de plusieurs ouvrages autour de SmallTalk et des «design patterns», nous présente dans cet ouvrage une méthode de développement s'addressant à des équipes petites à moyennes qui doivent développer du logiciel aux spécifications vagues et/ou changeantes."

Note du modérateur : l'on entend de plus en plus souvent parler d'eXtreme Programming ; aussi, si vous avez des expériences bonnes ou mauvaises avec cette méthode ce serait sympa de les faire partager aux lecteurs du site via les commentaires de cette critique. Pas de troll SVP. Argumentez de manière objective vos opinions

eXtreme Programming Explained: Embrace Change
Auteur	Kent Beck
Editeur	Addison-Wesley
ISBN	0-201-61641-6
Pages	190
Prix	244FF
Rédacteur	Laurent Guerby

Kent Beck, auteur de plusieurs ouvrages autour de SmallTalk et des
«design patterns», nous présente dans cet ouvrage une méthode de
développement s'addressant à des équipes petites à moyennes qui
doivent développer du logiciel au spécifications vagues et/ou
changeantes.

Le choix d'un intitulé provoquant : «eXtreme Programming»
(«Programmation Extrême» abrégé en «XP» dans l'ouvrage et cette revue)
ne doit pas cacher l'ingéniosité et le sérieux des techniques
présentées, on retrouve beaucoup de bon sens et d'attention à la
réalité de ce type de projets souvent absent des processus de
développement employés en pratique (quand il y en a un ...).

Pourquoi «eXtreme» alors ? Simplement parce que l'idée de la méthode
est de pousser les bonnes idées connues («Best Practices»), comme par
exemple les revues de code, à un niveau d'emploi extrême, comme
toujours écrire le code à deux programmeurs («Pair Programming»),
de-facto obligeant tout code écrit à être vérifié par au moins une
personne autre que l'auteur au moment de sa création.

Trois ouvrages ont été publiés à ce jour dans la collection «The XP
Series» : celui couvert par cette revue, «eXtreme Programming
Installed» par Ron Jeffries & al., et «Planning eXtreme Programming»
par Kent Beck et Martin Fowler. Tous ont en commun d'être relativement
courts (entre 150p et 250p), de suivre un style succint et direct et
d'être agréables à lire.

Le premier ouvrage («Explained») couvre la méthode dans son ensemble
et est celui à lire pour se faire une idée de la méthode avant d'aller
plus loin avec les ouvrages suivants.

Le deuxième («Installed») détaille les étapes survolées par le premier
ouvrage, les problèmes que les programmeurs XP vont sûrement
rencontrer ainsi que des conseils pour les résoudre basés sur
l'expérience des auteurs. C'est le plus épais des trois.

Le troisième («Planning») insiste sur les activités de plannification,
estimation des coûts, des priorités, et gestion des ressources
humaines. Quelques situations inextricables sont aussi passées en
revue.

«eXtreme Programming Explained: Embrace Change» est consitué de
nombreux chapitres, chacun étant bref, introduisant un ou des élèments
typiques d'un projet et comment ils s'intègrent dans la méthode XP.
Un grand nombre d'aspect d'un projet typique sont abordés : discussion
avec le client, management, changement des spécifications, conception,
codage, tests, livraisons, environnement physique de travail, conflits
humains et autres sont abordés par l'ouvrage.

Les grandes lignes de la méthode XP sont dévoilées et illustrées peu à
peu au cours de l'ouvrage. On peut en extraire les principales :

Cycles de livraison les plus courts possibles, typiquement de une à
quatre semaine, avec une cible bien définie sous forme de petits
scénarios chacun décrivant une caractéristique utile du logiciel,
écrits en commun par le client et les développeurs.
Le client suit et oriente le projet en supprimant, redéfinissant ou
ajoutant des caractéristiques et les développeurs estiment le coût des
demandes de manière réactive et font les choix techniques.
Les participants aux projets sont conscients des relations entre les

quatres variables du développement logiciel : coût, délais, qualité et
étendue. Le client choisi trois variables, et l'équipe de
développement détermine la quatrième.
Les caratéristiques les plus prioritaires sont codées d'abord et le
plus simplement possible sans chercher à généraliser immédiatement.
En gardant un cycle court on peut arriver à garder un coût des
changement dans le logiciel qui n'est pas exponentiel avec le temps.
Quand la conception d'une partie du code montre ses limites, les
développeurs identifient le problème et affinent la conception au cours
d'une itération («Continuous Refactoring»).
Les tests unitaires sont écrits avant le code, et tous les tests
écrits, anciens et nouveaux, sont lancés le plus fréquement possible.
Les temps de développement des caractéristiques sont suivis
précisément ce qui permet d'avoir des estimations de plus en plus
fiables pour les nouvelles caractéristiques au fur et à mesure de
l'avancement projet.
Le code est toujours écrit par deux personnes travaillant en paire.
Le code est écrit par petit incrément et intégré au logiciel en
quelques jours au plus. Tout le monde peut modifier du code partout
dans le logiciel, sans domaine réservés et ce tant que les tests
unitaires passent.

Rien de vraiment révolutionnaire, mais le tout mis ensemble définit
une méthode qui parait robuste et bien adaptée à sa cible. D'autres
points de la méthode et des conseils pour sa mise en oeuvre sont aussi
décrits.

La présentation du livre est sobre et efficace, le style direct et au
final c'est un ouvrage relativement court mais très dense en
information. Un glossaire et une bibliographie annotée intéressante
pour compléter votre bibliothèque terminent le livre.

En conclusion, si vous vous interessez aux méthodes de développement,
ne manquez pas cet ouvrage, même si vous n'adoptez pas l'intégralité
des techniques décrites, vous pourrez sûrement bénéficier de certaines
d'entre elles avec un minimum d'effort sur vos projets actuels et
futurs.

Table des matières

Foreword by Erich Gamma
Chapter 1 Risk: The Basic Problem
Chapter 2 A Development Episode
Chapter 3 Economics of Software Development
Chapter 4 Four Variables
Chapter 5 Cost of Change
Chapter 6 Learning to Drive
Chapter 7 Four Values
Chapter 8 Basic Principles
Chapter 9 Back to Basics
Chapter 10 Quick Overview
Chapter 11 How Could This Work?
Chapter 12 Management Strategy
Chapter 13 Facilities Strategy
Chapter 14 Splitting Business and Technical Responsability
Chapter 15 Planning Strategy
Chapter 16 Development Strategy
Chapter 17 Design Strategy
Chapter 18 Testing Strategy
Chapter 19 Adapting XP
Chapter 20 Retrofiting XP
Chapter 21 Lifecycle of an Ideal XP Project
Chapter 22 Role for People
Chapter 23 20-80 Rule
Chapter 24 What Makes XP Hard
Chapter 25 When You Shouldn't Try XP
Chapter 26 XP at Work
Chapter 27 Conclusion
Annotated Bibliography
Glossary
Index

Références

Aller plus loin

Critique Complète (9 clics)

# Pas de trolls SVP.

Posté par Anonyme le 28 mai 2001 à 01:17. Évalué à 0.

eXtreme Programming:, c'est le genre d'expression qui me donne la nausée: ça sent le marketting qui pue...

l'eXtreme trolling a certainement beaucoup plus d'avenir.
- [^] # Re: Pas de trolls SVP.
  
  Posté par gwenn cumunel (site web personnel) le 28 mai 2001 à 08:53. Évalué à 1.
  
  Le terme semble effectivement pure "ringard marketing (tm)".
  
  Mais la méthode en elle-même, est-elle aussi du vent ou correspond t'elle à qque chose de réel (et d'efficace) ?
  
  Qqu'un l'ayant déjà essayé peut-il nous renseigner ?
  - [^] # Déjà vu ?
    
    Posté par François Désarménien le 28 mai 2001 à 09:43. Évalué à 1.
    
    Ca évoque les principes de développement de
    certains logiciels libres :
    
    - Publier fréquemment (au pire, accès CVS en RO)
    - L'utilisateur détermine la direction
    du dévelopement
    - Travail coopératif des équipes
    - Pour les gros projets : division en
    sous-projets
    - Batterie de tests de régression (genre Perl)
    - etc...
    
    Qu'en pensez vous ?
    
    François -- qui n'arrive pas à se loguer :(
    - [^] # Re: Déjà vu ?
      
      Posté par Anonyme le 28 mai 2001 à 10:27. Évalué à 0.
      
      Mettre deux coders par PC, ça pue ça pue ça pue !!!
      - [^] # Re: Déjà vu ?
        
        Posté par Mokona le 28 mai 2001 à 12:13. Évalué à 2.
        
        Il ne s'agit pas de mettre deux "coders" par PC, mais de construire le code à deux.
        
        Tu écrits une partie, et lorsqu'elle est finie (ou avant, ou régulièrement) tu la montre à ton binôme qui le lit et le commente.
        
        Tu fais de même pour son code.
        
        Ca se fait aussi en "boucle" (A commente B, B commente C,...).
        
        Cela force à avoir du code "clean". C'est extrêmement pratique, surtout sur du code qui doit durer plus longtemps que la présence du programmeur dans la boite. Il y a un minimum d'assurance que ce qu'il a fait peut être relu, compris et modifié par ses successeurs sur le projet.
        
        [^] # Re: Déjà vu ?
        
        Posté par pasBill pasGates le 28 mai 2001 à 12:38. Évalué à 1.
        
        Non non, ce que tu decris c'est des code reviews standard, XP c'est reellement ecrire du code a 2.
        
        [^] # Re: Déjà vu ?
        
        Posté par Anonyme le 28 mai 2001 à 13:27. Évalué à 0.
        
        Moi, une boite qui me mets avec qq'un d'autre sur une machine, je l'envoie chier bien loin !! Heureusement là où je bosse ce ne sont pas des marketing-fashion-victims et on ne risque pas voir ce genre de débilités arriver !! ouf !
        
        [^] # Re: Déjà vu ?
        
        Posté par Anonyme le 28 mai 2001 à 14:27. Évalué à 0.
        
        Oui mais toi tu est un vrai guru, un vrai as de la programmation et tu n'as rien à apprendre, pas plus que tu ne souhaites perdre ton temps à former les autres. Dire que tu pourrais faire le travail de dix si on te laisser faire et que au lieu de cela on t'impose une équipe. Quelle poisse !
        
        [^] # Re: Déjà vu ?
        
        Posté par Anonyme le 28 mai 2001 à 16:28. Évalué à 0.
        
        Là je suis mort de rire :-) Dans le genre commentaire qui n'a rien a voir !! J'ai jamais dit que j'étais un guru ou que je n'aimais pas bosser en équipe !! Simplement, deux par machine, c'est RI-DI-CULE ! Et je refuserais de bosser ainsi ! J'ai pas envie de me battre avec un collègue pour avoir le clavier :p
        
        [^] # Re: Déjà vu ?
        
        Posté par Anonyme le 28 mai 2001 à 16:44. Évalué à 0.
        
        Bien sûr, bien sûr...
        
        Dis-nous donc ce que tu as contre XP... Parce que dire que tu ne veux pas te battre avec un collègue pour avoir le clavier, ça ne veut rien dire ou alors que tu n'as aucun savoir-vivre.
        
        Tu me fais penser aux petits enfants qui n'aiment pas leurs haricots, et qui n'y ont jamais goûté.
        
        Gnwak !
        
        [^] # Re: Déjà vu ?
        
        Posté par Anonyme le 28 mai 2001 à 16:52. Évalué à 0.
        
        Pkoi mettre DEUX personnes devant UNE machine ?? Je n'y vois vraiment aucuns interet (économie de matos peut etre :p) ... Moi je supporterai pas d'avoir qq'un planté a coté de moi ou d'etre planté a coté de qq'un qd je dois bosser ... Y'a rien de mal à ça qd meme ? :-)
        
        [^] # Re: Déjà vu ?
        
        Posté par Anonyme le 28 mai 2001 à 17:04. Évalué à 0.
        
        Code plus clair, moins buggé, que plusieurs personnes connaissent (personne dont on ne puisse se passer), qui correspond mieux aux requirements...
        
        Tu n'y vois pas d'avantages ?
        
        [^] # Re: Déjà vu ?
        
        Posté par Anonyme le 28 mai 2001 à 23:10. Évalué à 1.
        
        Pour ma part, je préfère le developpement en équipe 'classique' où chacuns code une partie définie du système et utilise les classes des autres pour sa partie ... Le code est clair et relu par plusieurs personnes aussi et je trouve ce mode de développement bien plus convivial ...
        
        Enfin ça n'engage que moi ... Si tu préfère l'XP tant mieux pour toi ;-)
      - [^] # Re: Deux par machine !?!
        
        Posté par Anonyme le 28 mai 2001 à 17:35. Évalué à 0.
        
        "Le binôme travaille sur une seule machine : un développeur se concentre sur l'écriture du code, l'autre travaille davantage au niveau du design ou de la fonctionnalité en cours. En termes militaires, celui qui est au clavier travaille au niveau tactique, et l'autre au niveau stratégique. Les binômes changent fréquemment, de sorte que chacun est amené à travailler avec tous les autres membres de l'équipe."
        
        j'ai survolé cet eXtrem Programing, et je trouve tout plein de trucs biens dedans.
        Mais alors la! 2 par clavier, j'avoue ne pas très bien adhérer.
        
        Sur le principe: 100% d'accord
        
        ==> passer du temps a se gratter la tete (niveau strategique)
        
        Sur la pratique: ?!?
        
        Ben moi pour me gratter la tete, j'ai besoin au minimum d'un papier et d'un crayon. Au mieux mon modeleur UML favoris, et pour ca, j'ai besoin d'un clavier ! et puis j'ai besoin d'voir ma boite a mail pas loin pour savoir que la prochaine reunion a ete décalée, et puis je garde toujours un oeil sur linuxfr, et puis et puis ...
        
        Conclusion:
        
        binomes, 90% d'accord!
        
        formation des jeunots, 100% d'accord!
        
        passer du temps sur le niveau "strtegique", 200% d'accord
        
        ----------------
        
        deux par machine, 400% PAS D'ACCORD!
        
        ca me semble tomber sous le sens (mais ou que c'est que ca va rebondir tout ca ?)
        
        Globalement je trouve XP pleins d'enseignements positifs:
        "You may love XP, or you may hate it, but Extreme Programming Explained will force you to take a fresh look at how you develop software."
        
        voila ce que j'en pense.
        
        [^] # Re: Deux par machine !?!
        
        Posté par Anonyme le 28 mai 2001 à 18:18. Évalué à 0.
        
        Déjà qu'à la fac c'est pénible d'être à deux sur la même bécane (pour celui qui regarde, soit il a quelque chose à dire toutes les deux lignes et c'est vite chiant, soit il passe son temps à glander) une fois la résolution des principaux problèmes faite à deux. Il faudrait mieux se forcer à relire le code après.
        
        [^] # Re: Deux par machine !?!
        
        Posté par Mokona le 29 mai 2001 à 10:05. Évalué à 1.
        
        Oui c'est bien ça qui me bloque aussi dans le "deux par machine". Cela suppose que le binome bosse sans aucune pause, sans aucune information sur ce qui se passe dans la boite, rien.
        
        Dans une équipe, chacun travaille à son rythme, certains ont besoin d'aller se dégourdir les jambes, il faut penser à se reposer les yeux fréquemment.
        
        Et à moins de tomber sur une paire qui colle bien, je ne vois venir que des soucis.
        
        (c'est sans compter les escapades sur le net, souvent nécessaire à l'information, mais pas toujours :) ).
        
        Comme il est préconisé un changement fréquent de binôme, je vois "globalement" un groupe désynchronisé. Surtout que par expérience, quand on est deux sur un clavier, celui qui a le clavier fait 80% du boulot.
    - [^] # Re: Déjà vu ?
      
      Posté par Mike Krus le 28 mai 2001 à 10:28. Évalué à 2.
      
      oui, ca ressemble pas mal aux projets open sources, sauf:
      - il faut un client, qqu'un pour prendre rapidement un décision sur ce qu'il faut développer, etc. Et il faut qu'il assume ces décisions (moyennant le fait que les développeurs lui donne des évaluations de coût et de risque de développement).
      - c'est basé enormement sur la communication et l'échange très rapide d'information, ainsi que sur le "pair programming". Donc ca marche mieux si tout le monde est au même endroit (pas sur 5 continents)...
      
      On s'en sert partiellement au boulot, et ça marche assez bien, ça s'intègre en fait aussi bien avec d'autres trucs, genre RUP.
      
      J'ai pas lu ce livre, mais les autres sont assez pénible pour moi européen, faut faire abstraction du côté "just do it" et du système très américain de valeurs...
      
      Mais au quotidien, ça responsabilise tout le monde et ça crée une dynamique de communication très interressante!
# Site intéressantsur XP

Posté par Anonyme le 28 mai 2001 à 08:25. Évalué à 0.

Je vous conseille de lire le site suivant:
http://www.design-up.com(...)
C'est en français et il y a un dossier très complet sur XP.
- [^] # Re: Site intéressantsur XP
  
  Posté par Anonyme le 28 mai 2001 à 10:07. Évalué à 0.
  
  Cool, beaucoup d'informations sur ce site. Je le met en bookmark et je rajoute ce lien qu'y n'y était pas:
  http://www.idealx.org/fr/doc/xp-synthese/book1.html(...)
  C'est un document de synthése d'XP écrit par Jérome Marant.
# De Tekool : XP en pratique

Posté par Anonyme le 28 mai 2001 à 10:45. Évalué à 1.

J'utilise XP depuis plusieurs mois sur des projets perso et pro. XP n'est pas à proprement parler une méthode mais plutôt une approche réaliste et humaine du développement logiciel qui admets que les changements de spécification sont une réalité (notamment).

XP edicte des principes connus de tous les développeurs mais pas toujours mis en oeuvre comme l'approche "user-centric", la relecture du code, le travail en binôme, le découpage en tâches de courtes durée (1 à 3 jours), l'importance des tests.

Je ne saurais trop conseiller aux développeurs de s'intéresser à cette "technique". La connaissance des principes XP permets de mettre des mots sur des intuitions et donc de mieux comprendre son métier.

En somme,XP n'est pas du tout un produit marketing mais plutôt une approche saine et objective du développement logiciel. On y retrouve certains points proche du modèle bazaar comme le fait qu'il faut releaser souvent et que le projet appartient à tous les développeurs de l'équipe et pas au guru du coin.

Je signale que le magazine Développeur Référence consacre chaque mois un article à XP et que leur lecture est des plus instructive.

Enfin pour ceux qui doutent, voici deux petits points que je trouve particulièrement sympa :
- en XP, le code fait foi, pas la doc
- en XP, si le client fixe l'étendue, le développeur fixe le délai et inversement.

Tekool qu'est pas loggé
http://www.tekool.com(...)
- [^] # Re: De Tekool : XP en pratique
  
  Posté par Anonyme le 29 mai 2001 à 09:48. Évalué à 0.
  
  Oups j'avais pas pensé que mon URL apparaitrâit dans la liste des liens.
  
  Y'a rien à voir sur XP, désolé

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.