Quatrième de couverture :

Software development projects can be fun, productive, and even daring. Yet they can consistently value to a business and remain under control. Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically over the course of time. XP recognizes that projects have to work to achieve this reduction in cost and exploit the savings once they have been earned. \[…\]

Dans Extreme Programming Explained: Embrace Change, Kent Beck décrit en détail ce qu’est ‘‘eXtreme Programming (XP)’’, méthode de développement logiciel dont il est à l’origine.

Le livre est classiquement décomposé en trois sections : 1/le problème, 2/La solution, 3/La mise en pratique. Beck s’adresse directement à son lecteur, et celui-ci est clairement un développeur ou quelqu’un ayant directement les mains du coté technique des choses. Mêlant théorie, pratique, retour d’utilisateurs et expérience personnelle, Beck explique tous les détails de la méthode et en justifie ses force et son intérêt. Il ne néglige pas non plus de faire le tour des faiblesses : XP n’est pas la panacée du dev, il y a des cas où ça ne marchera pas et cela implique une réelle volonté de changer les choses.

Ce livre est vraiment une mine d’info, même si certains points¹ nécessitent d’avantage d’éléments pour aller au bout des choses.

Si, je pense, le ton de ce bouquin peut vraiment parler à quelqu’un qui à un rapport direct avec du code, il peut avoir l’effet inverse sur des managers qui n’ont plus les mains dedans. Ce livre ne leur est pas destiné et peut même probablement leur faire peur (par son côté technique et la remise en cause d’une partie de leur job).

Dans les grandes lignes, XP se base sur quatre valeurs :

• communication
• simplicité
• feedback
• courage

Les trois premières sont assez classiques, la dernière est plus surprenante, et pourtant, elle est tout à fait justifiée. Pour faire un code simple, accepter de remettre son travail en cause régulièrement et que les autres le remettent aussi en cause, prendre le recul nécessaire, …, ça demande du courage.

À ces valeurs s’ajoutent des bonnes pratiques :

• planning game
• de petites livraisons : livrer peu mais souvent
• métaphore
• design simple : KISS² et YAGNI³
• tests
• refactoring
• programmation en binôme : binôme qui changent régulièrement, crée selon les besoins
• propriété collective : tout le monde peut intervenir sur toute partie du code
• intégration continue :
• 40 heures par semaine⁴
• client sur site : pour rester au plus près de ses attentes
• coding standards : avoir un socle commun de règles valable pour tout le monde

L’idée est que si, prises séparément, ces bonnes pratiques ont des avantages et des inconvénients, prises toutes ensemble, elles se renforcent et s’auto entretiennent si bien qu’on en oublie les inconvénient pour ne garder que les avantages. Toutes ces pratiques forment une cadre complet qui couvre l’intégralité du cycle de vie d’un logiciel : de la collecte des besoins de l’utilisateur, à la mise en production en passant par l’analyse, la planification et le développement bien sur :)

Après avoir lu ce livre, j’ai l’impression que Scrum en est essentiellement une réécriture destinée aux décideurs, avec un vocabulaire et un cadre qui leur parle et en cachant tous les détails trop techniques qui peuvent faire peur.

Achetez le sur amazon : Extreme Programming Explained: Embrace Change de Kent Beck