Le terme analyse est mal adapte. Ce dont on parle, c'est l'idee que se font certains professionnels du metier que a partir du moment ou tu as les specs, tu peux faire ta conception UML, et a partir du moment ou ta conception UML marche, le produit est pratiquement developpe. Je pense que cette approche ignore de nombreux facteurs importants, comme le fait que le client ne sait pas ce qu'il veut, qu'il change d'avis, que les specs ne sont pas parfaites et que les bugs sont incontrolables.
> si tu codes pendant 6 mois et que le client change d'avis ?
Et bien comme tu as privilegie des releases courtes, on va dire de trois mois, le client a deja eu deux versions sous les yeux. Donc il a eu beaucoup plus le temps de se faire son avis. Notamment apres la permiere version, il a probablement change un peu d'avis et oriente la version suivante differamment. C'est le client qui choisit les fonctionnalites les plus prioritaires.
Comme tu as privilegie dans tes premieres versions les fonctionnalites qui avaient le plus de valeurs pour le client, il y a aussi toutes les chances que meme si il arrete le projet au bout de 6 mois pour raisons variees (budget en general), ce que tu as developpe est utilisable pour lui donc il va probablement le payer. Ca fait une grosse difference avec la methode UML ou le client sera peu enclin a te payer pour tes diagrammes UML.
Pour ce qui est de l'analyse, elle se fait dans un bureau avec tous les developpeurs et tous les clients. En revanche, la conception complete se fait plus tard. Dans la mesure ou on avance par iteration, ceratines parties de l'analyse n'ont pas besoin d'etre extermement pousee pour la premiere iteration ce qui allege la charge initiale et laisse plus de marge au client pour se faire une idee apres la premiere version.
Donc non seulement, le client peut changer d'avis au bout de 6 mois, mais meme on l'encourage.
Note aussi que comme tu as des suites de tests blindees, unitaires et fonctionelles, tu es beaucoup plus cool face au changement. Si la moitie des fonctionnalites change, l'autre moitie sera surement impactee mais tu seras en mesure de faire tourner les suites de tests deja developpee pour remettre l'ancienne moitie en etat avec les nouvelles fonctionnalites.
Globalement, XP te rend plus zen face aux problemes classiques de developpement. Si tu trouves un bug 1h avant de livrer la version finale au client, tu n'as pas peur de patcher comme un malade et de toute peter, car tu as tes suites de tests qui sont la pour te dire quand tu fais une connerie. Evidemment, dans ce cas, ca suppose aussi d'avoir un processus automatique de generation de release, ce qui, meme si il n'est pas presente dans la medhode, s'inscrit tout a fait dans l'esprit.
[^] # 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é à 1.
> si tu codes pendant 6 mois et que le client change d'avis ?
Et bien comme tu as privilegie des releases courtes, on va dire de trois mois, le client a deja eu deux versions sous les yeux. Donc il a eu beaucoup plus le temps de se faire son avis. Notamment apres la permiere version, il a probablement change un peu d'avis et oriente la version suivante differamment. C'est le client qui choisit les fonctionnalites les plus prioritaires.
Comme tu as privilegie dans tes premieres versions les fonctionnalites qui avaient le plus de valeurs pour le client, il y a aussi toutes les chances que meme si il arrete le projet au bout de 6 mois pour raisons variees (budget en general), ce que tu as developpe est utilisable pour lui donc il va probablement le payer. Ca fait une grosse difference avec la methode UML ou le client sera peu enclin a te payer pour tes diagrammes UML.
Pour ce qui est de l'analyse, elle se fait dans un bureau avec tous les developpeurs et tous les clients. En revanche, la conception complete se fait plus tard. Dans la mesure ou on avance par iteration, ceratines parties de l'analyse n'ont pas besoin d'etre extermement pousee pour la premiere iteration ce qui allege la charge initiale et laisse plus de marge au client pour se faire une idee apres la premiere version.
Donc non seulement, le client peut changer d'avis au bout de 6 mois, mais meme on l'encourage.
Note aussi que comme tu as des suites de tests blindees, unitaires et fonctionelles, tu es beaucoup plus cool face au changement. Si la moitie des fonctionnalites change, l'autre moitie sera surement impactee mais tu seras en mesure de faire tourner les suites de tests deja developpee pour remettre l'ancienne moitie en etat avec les nouvelles fonctionnalites.
Globalement, XP te rend plus zen face aux problemes classiques de developpement. Si tu trouves un bug 1h avant de livrer la version finale au client, tu n'as pas peur de patcher comme un malade et de toute peter, car tu as tes suites de tests qui sont la pour te dire quand tu fais une connerie. Evidemment, dans ce cas, ca suppose aussi d'avoir un processus automatique de generation de release, ce qui, meme si il n'est pas presente dans la medhode, s'inscrit tout a fait dans l'esprit.