sebi | anapajari a écrit :
AMHA d'la bouse 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
|
+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 ...
|