"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 |
<!-- Ceci est a mettre comme texte de la news annoncant la revue<br/> du livre -->
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.
<!-- Fin du texte de la news -->
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
# Pas de trolls SVP.
Posté par Anonyme . Évalué à 0.
l'eXtreme trolling a certainement beaucoup plus d'avenir.
[^] # Re: Pas de trolls SVP.
Posté par gwenn cumunel (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 0.
[^] # Re: Déjà vu ?
Posté par Mokona . Évalué à 2.
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 . Évalué à 1.
[^] # Re: Déjà vu ?
Posté par Anonyme . Évalué à 0.
[^] # Re: Déjà vu ?
Posté par Anonyme . Évalué à 0.
[^] # Re: Déjà vu ?
Posté par Anonyme . Évalué à 0.
[^] # Re: Déjà vu ?
Posté par Anonyme . Évalué à 0.
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 . Évalué à 0.
[^] # Re: Déjà vu ?
Posté par Anonyme . Évalué à 0.
Tu n'y vois pas d'avantages ?
[^] # Re: Déjà vu ?
Posté par Anonyme . Évalué à 1.
Enfin ça n'engage que moi ... Si tu préfère l'XP tant mieux pour toi ;-)
[^] # Re: Deux par machine !?!
Posté par Anonyme . Évalué à 0.
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:
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 . Évalué à 0.
[^] # Re: Deux par machine !?!
Posté par Mokona . Évalué à 1.
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 . Évalué à 2.
- 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 . Évalué à 0.
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 . Évalué à 0.
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 . Évalué à 1.
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 . Évalué à 0.
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.