Suite à l’article de ManU, j’ai acheté et lu l’article de programmez sur « le développeur devient agile » et sans remettre en cause l’article de Raphaël sur le fond, j’en ai un peu ASSEZ de la façon dont XP est présenté … et je le dis !
Messieurs les XPistes, cela suffit !
Que XP soit une méthode –> C’est évident
Que vous préfériez XP à Scrum –> C’est votre choix
Que vous n’aimiez pas Scrum (enfin pour certain d’entre vous) –> C’est également votre choix
Que Scrum n’intègre pas de pratiques d »ingénierie –> C’est évident, tout est dans le DONE !
Mais il y en a assez que vous récupériez toutes les pratiques d’ingénierie à votre compte !
Depuis 20 ans que je navigue dans le monde du logiciel, je n’ai constaté que 2 pratiques que je labelliserais « XP practices NEW »
- Le TDD (Test Driven Development) ou développement piloté par les tests
- Le Pair Programming (développement en binôme) ou inspection en continue
Pour le reste, les pratiques, dites XP, existaient bien avant que Kent leur donne un nom.
- Le test automatique existe depuis l’origine du développement logiciel. A titre personnel, j’ai commencé à développé en 1989 et j’ai écrit mes premiers tests automatiques en 1989 (tiens donc, la même année !)
- L’intégration continue dispose maintenant d’outils (open source ou payant) dont nous ne disposions pas il y a 20 ans … mais nous en faisions quand même ! Je me rappelle mes développements sur des calculateurs embarqués ou l’environnement du développeur était mis automatiquement à jour à partir de la gestion de configuration lorsque celui-ci voulait jouer un test unitaire. Bon, je suis d’accord que ce n’était pas exactement ce que nous appelons maintenant « Intégration Continue » … mais enfin cela y ressemblait vraiment !
- Le refactoring est un étape incontournable de XP … mais nous n’avons pas attendu Kent pour le faire ! Je me rappelle également mes sessions de brainstorming pour simplifier notre code et notre architecture. Au bout de quelques sessions, nous avions même fini par supprimer l’OS temps réel pour le remplacer par un simple scheduler et des routines d’interruptions directement écrites en assembleur pour optimiser le temps de traitement.
Lorsque je présente SCRUM, j’ai pour habitude de dire ceci :
« SCRUM est un essemble de règles intelligemment agencées permettant de gérer un projet plus efficacement que les méthodes traditionnelles »
Rien d’extraordinaire la dedans … juste du bon sens.
Messieurs les XPistes … ne l’oubliez pas !!!
PS : J’ai vraiment apprécié l’article de Laurent Laslaz dans Programmez … et cela bien avant que je découvre qu’il en était l’auteur, merci Laurent 🙂
Ah la la, tu aurais dû lire « Extreme Programming Explained » (XP v1) !
Ken Beck y explique que, pour construire son système complet et auto-renforcé de développement logiciel, il a choisi parmi des pratiques d’ingénierie logicielle qui marchent et qui ont fait leurs preuves depuis longtemps !
*Aucune* récupération donc, si ce n’est qu’il propose de les employer toutes ensemble et de tourner le curseur vers le maximum (d’où le nom de la méthode).
Désolé, mais je crois que tu vas encore nous entendre parler de ces pratiques pendant longtemps !! :-p
Moi je le sais … mais j’ai l’impression que pas mal de personnes l’oublie lorsqu’elles portent un message du type « Sans les pratiques XP, Scrum ne marche pas ».
Le vrai message est « Scrum n’intègre pas de pratiques d’ingénierie, il faut donc aller chercher ailleurs ce qui marche ».
Faire des tests automatiques consiste à réutiliser une pratique qui a fait ses preuves depuis longtemps et non à « implanter une pratique XP »
Alexandre, tu as mon soutien face aux extrémistes de tout poil.
Alexandre
d’accord qu’il faut combattre les sectarismes, mais est-il utile de le faire de façon si… sectaire? Tu me connais, je gagne ma vie en prêchant & en pratiquant Scrum, mais je rajouterais simplement que le tout est plus que la somme de ses parties, et que c’est peut-être là le mérite de Kent et les Beckiens 🙂
A une symbiose encore meilleure!