Retour d'expérience sur la méthode de dév XP

Retour d'expérience sur la méthode de dév XP - Divers - Programmation

Marsh Posté le 22-09-2006 à 15:06:52    

Bonjour,
 
Pour un nouveau projet en PHP/MySQl/XHTML, je compte utiliser comme méthode de développement XP (eXtreme Programming). Pour l'instant, je suis seul dans l'équipe de dév mais, ça peut évoluer (mais on sera pas plus de 3 ou 4 au max).
 
Je souhaitais avoir un retour d'expérience de ceux qui avaient utilisés cette méthode de développement. Merci.

Reply

Marsh Posté le 22-09-2006 à 15:06:52   

Reply

Marsh Posté le 22-09-2006 à 15:27:57    

AMHA d'la bouse :D Mais je pense que c'est plus lié à la façon dont on l'a fait que la méthode en elle-même:

  • Revue de code: rarement faite, pas le temps, pas facturable, toujours à la bourre.  
  • tests unitaires avant l'implémentation: jamais fait correctement, le problème venant plus des "fonctionnels" incapables de faire une spec "finale" avant que le developpement soit fini donc scénarii changés entre le début et la fin.
  • refactoring: jamais fait, pas le temps, pas facturable, toujours à la bourre
  • choix de la solution la plus simple: ok
  • intégration rapide des modifications: ok mais ouala les merdes qui ça génèrent de temps en temps, genre regression sur un module constatée 6 semaines plus tard et 10 livraisons entre temps ( et non les tests unitaires n'étaient pas parfaits).


Après sur le cycle de developpement c'est jouable mais tout seul tu vas avoir du mal a bosser en binome :o

Reply

Marsh Posté le 22-09-2006 à 16:30:34    

les tests unitaires, je les fais avec SimpleTest
 
Bonnser en binôme quand on est tout seul, c'est clair, c'est pas facile :D

Reply

Marsh Posté le 22-09-2006 à 16:34:50    

Reply

Marsh Posté le 22-09-2006 à 16:41:32    


 
J'avais lu ce topic...Disons que mon sujet est consacré à XP exclusivement, ce qui n'est pas le cas de l'autre topic.

Reply

Marsh Posté le 22-09-2006 à 17:00:22    

rufo a écrit :

J'avais lu ce topic...Disons que mon sujet est consacré à XP exclusivement, ce qui n'est pas le cas de l'autre topic.


 
ok, c'était au cas où  (comme les topics sur les méthodes courent pas les rues ...)


---------------
Töp of the plöp
Reply

Marsh Posté le 22-09-2006 à 17:21:58    

En quoi ça consiste exactement ?


---------------
Posté depuis des chiottes, sales. Me gusta.
Reply

Marsh Posté le 23-09-2006 à 00:00:39    

anapajari a écrit :

AMHA d'la bouse :D Mais je pense que c'est plus lié à la façon dont on l'a fait que la méthode en elle-même:

  • Revue de code: rarement faite, pas le temps, pas facturable, toujours à la bourre.  
  • tests unitaires avant l'implémentation: jamais fait correctement, le problème venant plus des "fonctionnels" incapables de faire une spec "finale" avant que le developpement soit fini donc scénarii changés entre le début et la fin.
  • refactoring: jamais fait, pas le temps, pas facturable, toujours à la bourre
  • choix de la solution la plus simple: ok
  • intégration rapide des modifications: ok mais ouala les merdes qui ça génèrent de temps en temps, genre regression sur un module constatée 6 semaines plus tard et 10 livraisons entre temps ( et non les tests unitaires n'étaient pas parfaits).


Après sur le cycle de developpement c'est jouable mais tout seul tu vas avoir du mal a bosser en binome :o


+1 , on dirait carrément une description de mon équipe de dev ... Tous ces points que tu cites serait possible, si les "fonctionnels" optaient pour un livraison dite "de consolidation" et où il n'y a aucun ajout "fonctionnel", du moins pour ce qui est de la revue de code et du refactoring.
Pour le test driven, tout dépends du projets et d'un minimum de discipline. Actuellement, je bosse sur deux projets chez le même client :  

  • la couche d'intégration d'une banque, avec du code datant de 2000 avec un turn over d'un vingtaine dévellopeurs/architectes >> les test unitaires sont difficile à mettre en place.
  • L'autre projet est "from the scratch", on a decidé de partir sur du test driven. Bilan après 4 mois : efficace pour amorcer le projet et créer de "bonnes fondations" mais difficle de tenir cette méthodologie quand les premières dead line arrivent ...

Reply

Marsh Posté le 23-09-2006 à 12:42:30    

et votre avis sur les cycles courts de dév/livraisons, c'est-à-dire on développe 1 ou 2 fcts et on livre => il s'écoule 2-3 semaines entre chaque livraison?

Reply

Marsh Posté le 25-09-2006 à 08:53:30    

ça c'est surement le plus "facile"!!! pour le délai entre deux livraisons ça dépend mais nous s'était plus court que ça. Entre 4 et 6 livraisons par mois en gros!

Message cité 1 fois
Message édité par anapajari le 25-09-2006 à 08:53:51
Reply

Marsh Posté le 25-09-2006 à 08:53:30   

Reply

Marsh Posté le 25-09-2006 à 08:59:52    

anapajari a écrit :

ça c'est surement le plus "facile"!!! pour le délai entre deux livraisons ça dépend mais nous s'était plus court que ça. Entre 4 et 6 livraisons par mois en gros!


ça vous faisait pas perdre trop de temps à Packager? C'était en quel langage?

Reply

Marsh Posté le 25-09-2006 à 09:36:35    

En perl. On se servait de SVN, une branche "livrable" et zou.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed