Bien sur, on t'enseigne dans toutes les ecoles qu'il faut faire des tests. Mais combien prennent le temps d'introduire des methodologies de tests ? Combien montrent par la pratique ce que c'est qu'un bon test ? Combien t'introduisent a des bibliotheques de tests ? Combien font la difference entre un test exhaustif et juste un test a la con ? Combien font la difference entre un test et un test automatise que tu dois lancer toutes les 5 minutes de developpement ?
Au dela du blabla sur les tests, la methodologie XP a fait naitre ou renaitre des bibliotheques permettant de faire des suites de tests. Si tu cherches sur sourceforge, toutes les libs de test que tu trouveras font references a XP: cppunit, junit, javaunit, mock, easymock, mockobjects, pyunit, ...
Pour ce qui est de l'analyse, il faut mettre ca en relation avec les nombreux projets professionnels ou tu dois pondre 6 mois de diagrammes UML avant de commencer la moindre ligne de code. Pas de bol, au bout de 7 mois, le client a change d'avis et tu peux mettre tous tes diagramme a la poubelle. C'est en ce sens la qu'il faut lire la priorite au code.
XP prone plutot que de faire 6 mois de diagramme, de faire une conception rapide et de trouver ensuite la fonctionnalite qui a le plus de valeur pour le client, et qu'on peut delivrer le plus rapidement. C'est celle la qui aura la priorite pour les premieres iterations.
Dans ton exemple de compte en banque, non, on ne commencerai pas par faire la gestion des comptes. On discuterai avec le client pour voir ce dont il a le plus besoin. Ca pourrait etre par exemple que le GUI de leur application actuelle est horrible et que c'est ce qui a motive la demande pour un nouveau systeme. Dans ce cas, on commencerai par refaire le GUI tout en s'appuyant sur l'ancien systeme, pour apporter un benefice immediat. Tu as un chance sur 10 avec une telle approche que le client te dise que finalement, avec le nouveau GUI, plus besoin de changer le systeme...
C'est pas bon pour ton job :-), mais le client a eu ce qu'il voulait. Ce que ca risque d'induire, c'est pas qu'on ne change pas le systeme, mais qu'on fasse des modifications moins drastiques que ce qui etait prevu.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 2.
Au dela du blabla sur les tests, la methodologie XP a fait naitre ou renaitre des bibliotheques permettant de faire des suites de tests. Si tu cherches sur sourceforge, toutes les libs de test que tu trouveras font references a XP: cppunit, junit, javaunit, mock, easymock, mockobjects, pyunit, ...
Pour ce qui est de l'analyse, il faut mettre ca en relation avec les nombreux projets professionnels ou tu dois pondre 6 mois de diagrammes UML avant de commencer la moindre ligne de code. Pas de bol, au bout de 7 mois, le client a change d'avis et tu peux mettre tous tes diagramme a la poubelle. C'est en ce sens la qu'il faut lire la priorite au code.
XP prone plutot que de faire 6 mois de diagramme, de faire une conception rapide et de trouver ensuite la fonctionnalite qui a le plus de valeur pour le client, et qu'on peut delivrer le plus rapidement. C'est celle la qui aura la priorite pour les premieres iterations.
Dans ton exemple de compte en banque, non, on ne commencerai pas par faire la gestion des comptes. On discuterai avec le client pour voir ce dont il a le plus besoin. Ca pourrait etre par exemple que le GUI de leur application actuelle est horrible et que c'est ce qui a motive la demande pour un nouveau systeme. Dans ce cas, on commencerai par refaire le GUI tout en s'appuyant sur l'ancien systeme, pour apporter un benefice immediat. Tu as un chance sur 10 avec une telle approche que le client te dise que finalement, avec le nouveau GUI, plus besoin de changer le systeme...
C'est pas bon pour ton job :-), mais le client a eu ce qu'il voulait. Ce que ca risque d'induire, c'est pas qu'on ne change pas le systeme, mais qu'on fasse des modifications moins drastiques que ce qui etait prevu.