J'ai fait un résumé du résumé, il va de soit que je suis plus que simpliste... mais je pointe un lien vers l'article qui détaille tout et que je t'engage à lire.
Si tu me dis que parmi les points préconisés par XP il y a des trucs pas trop mauvais, voire bons, je suis d'accord (personnellement, je suis plus nuancé que le lien que je pointe).
Mais nul besoin de faire d'XP pour faire des tests. Ceci doit etre inclus dans un cycle de développement plus traditionnel.
De même, les releases courtes sur les fonctions clés, cela peut exister aussi sous une autre forme dans le développement "traditionnel", on appelle ça le maquettage, et c'est aussi préconisé sur les gros projets.
La transparence, c'est aussi conseillé en mode de développement traditionnel, mais il vaut mieux la faire en général sur les points que le client a une chance de comprendre, et il faut lui expliquer clairement, dans les termes de son métier, pas en utilisant de métaphores stupides (ou alors ce sont des points absolument pas métier, mais très techniques, et en ce cas, aucune métaphore ne permettra de lui expliquer de manière suffisament pertinente les choses).
En revanche, le système des fiches de tâches, du développement en binome (bien en théorie, ridicule en pratique), l'absence de design général de l'application (XP déconseille l'utilisation d'interfaces - au sens java du terme, au profit du refactoring permanent, ce qui rejoint aussi le fait que l'optimisation ne doit s'effectuer qu'à la fin), appropriation collective du code (souvent au détriment de sa documentation, et même lorsqu'un projet fait plusieurs dizaines de milliers de lignes de code), et la gestion de la relation avec le client (présence permanente, tests, planning game). Tout ça c'est absolument n'importe quoi, et encore, j'oublie des trucs.
Bref, en général, XP c'est une méthode qui est poussée par des gens qui n'y comprennent rien au développement logiciel, et qui ont trouvé une bonne occasion de glander un peu plus (ben oui, parce que du coup le boulot des chefs et directeurs de projet est très sensiblement allégé, puisque la majeure partie des taches qui leur incombent est effectué par les développeurs directement, avec la qualité qu'on imagine).
Reste que, dans certains cas particuliers (développeur indépendant, etc.), ça peut présenter certains intérêts.
Dernière remarque: sur le codage proprement dit (pas la gestion de la relation avec le client, qui est pourtant une des parties les plus importantes d'un projet logiciel), XP propose finalement quelque chose qui se rapproche (pas complètement toutefois) de la méthode de développement "bazar" utilisé par la plupart des LL. Comme quoi, tout n'est pas forcément à jeter dans XP, mais je vous incite à la plus grande prudence !
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par anonyme512 . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 1.
Si tu me dis que parmi les points préconisés par XP il y a des trucs pas trop mauvais, voire bons, je suis d'accord (personnellement, je suis plus nuancé que le lien que je pointe).
Mais nul besoin de faire d'XP pour faire des tests. Ceci doit etre inclus dans un cycle de développement plus traditionnel.
De même, les releases courtes sur les fonctions clés, cela peut exister aussi sous une autre forme dans le développement "traditionnel", on appelle ça le maquettage, et c'est aussi préconisé sur les gros projets.
La transparence, c'est aussi conseillé en mode de développement traditionnel, mais il vaut mieux la faire en général sur les points que le client a une chance de comprendre, et il faut lui expliquer clairement, dans les termes de son métier, pas en utilisant de métaphores stupides (ou alors ce sont des points absolument pas métier, mais très techniques, et en ce cas, aucune métaphore ne permettra de lui expliquer de manière suffisament pertinente les choses).
En revanche, le système des fiches de tâches, du développement en binome (bien en théorie, ridicule en pratique), l'absence de design général de l'application (XP déconseille l'utilisation d'interfaces - au sens java du terme, au profit du refactoring permanent, ce qui rejoint aussi le fait que l'optimisation ne doit s'effectuer qu'à la fin), appropriation collective du code (souvent au détriment de sa documentation, et même lorsqu'un projet fait plusieurs dizaines de milliers de lignes de code), et la gestion de la relation avec le client (présence permanente, tests, planning game). Tout ça c'est absolument n'importe quoi, et encore, j'oublie des trucs.
Bref, en général, XP c'est une méthode qui est poussée par des gens qui n'y comprennent rien au développement logiciel, et qui ont trouvé une bonne occasion de glander un peu plus (ben oui, parce que du coup le boulot des chefs et directeurs de projet est très sensiblement allégé, puisque la majeure partie des taches qui leur incombent est effectué par les développeurs directement, avec la qualité qu'on imagine).
Reste que, dans certains cas particuliers (développeur indépendant, etc.), ça peut présenter certains intérêts.
Dernière remarque: sur le codage proprement dit (pas la gestion de la relation avec le client, qui est pourtant une des parties les plus importantes d'un projet logiciel), XP propose finalement quelque chose qui se rapproche (pas complètement toutefois) de la méthode de développement "bazar" utilisé par la plupart des LL. Comme quoi, tout n'est pas forcément à jeter dans XP, mais je vous incite à la plus grande prudence !