Discussion :

[rad_hass]

Peu être que c'est vrai, mais a ma vision des choses, faire de la conception au fur et a mesure de développement peut agir mal sur la qualité du produit.

Ah bon ? Je serais curieux que tu m'explique comment il peut nuire à la qualité du produit, si une vrai conception est mise en place.

Le problème d'un cycle classique en V c'est qu'on fait une conception initial sur un besoin qu'on croit fixe et fini dans le temps, en ignorant toute problématique qui se présentera dans le future ... Alors que d'accepter qu'on ne peut pas dicter la conduite d'un projet de A à Z avant d'avoir commencer, c'est se donner la liberté de faire évoluer l'architecture, la conception et l'implémentation du projet ... Et ceux pour mieux répondre au besoin du client, du projet et des problématiques qu'on rencontre ...

Es tu d'accord qu'un projet se construit en amant, pendant et même après son implémentation ?
XP ne dit pas qu'il ne faut pas faire de la conception, il dit que comme la conception est une étape importante d'un projet, on le fera tout le temps ...
Ne pas faire de la conception c'est ne pas pratiquer XP.

peut être que c'est vrai...mais pourquoi cela arrive beaucoup lors de l'application de l'XP??!!!

Qu'entends tu de l'application de l'XP ?
A 10%, à 20% à 50% ou à 100% ? Combien de ces équipes faisait un refactoring régulier de l'application ? Combien avait une couverture de code supérieur à 60% par le test ? Combien pratiquer un vrai développement itératif et incrémental ?

[h472009]

Ah bon ? Je serais curieux que tu m'explique comment il peut nuire à la qualité du produit, si une vrai conception est mise en place.

Je pense que cela nous permettra moins de gérer l'interaction entre les différents modules conçus, car on aura pas une vision global sur le tout, et l'équipe de test/intégration aura beaucoup de boulot a faire, et surtout beaucoup d'allées/retours, pour garantir la maturité du produit.

Qu'entends tu de l'application de l'XP ?
A 10%, à 20% à 50% ou à 100% ? Combien de ces équipes faisait un refactoring régulier de l'application ? Combien avait une couverture de code supérieur à 60% par le test ? Combien pratiquer un vrai développement itératif et incrémental ?

là tu as raison, dire que j'applique une méthode, ou je suis certifié telle certif, ne veux absolument pas dire que tu respecte dans tous tes projets l'intégralité des processus de cette méthodologie.

En tout les cas, je me documenterai plus a propos de l'XP, afin de voire de prés comment ses auteurs prévoientt réellement le cycle de vie du projet...en attendant portez vous bien

[Heziva]

Bonjour,

Il y a un passage qui me fait bondir quand je te lis...

l'équipe de test/intégration aura beaucoup de boulot a faire

L'xp recommande l'intégration continue et le test driven developpement. J'ai du mal à comprendre comment tu applique XP avec une équipe de test/intégration séparée. A moins que ce soit elle qui ait la charge de détailler les specs et d'écrire les tests de recette automatisés.

L'approche "bottom-up" d'xp est souvent critiquée, expliquant que cela mène à une architecture incohérente. C'est vrai, chaque pratique d'XP prise indépendamment a de gros défauts. Pour éviter cette explosion, xp propose :
- Intégration continue
On ne repousse pas l'intégration d'une fonctionnalité. On l'intègre dès que possible. Comme celle ci est testé automatiquement, il ne doit pas y avoir de régression forte.
- Keep It Simple and Stupid (ou You Ain't Gonna Need It)
On garde le code le plus simple possible. Aucune duplication n'est acceptée.
- Constant refactoring
Test Driven Developpement, c'est test, code, refactor. On refactorise à chaque étape, pour s'assurer de garder un tout cohérent. C'est peut être ici que la valeur "Courage" est la plus marquée.
- Pair programing et Collective Code Ownership
Pour s'assurer que toute partie du code est strictement simple, on effectue une revue de code permanente.

Ces pratiques ont également des défauts, qui sont compensés par d'autres pratiques. La première chose qui bloque rapidement lors de l'adoption d'XP, c'est souvent les cycles de développements très courts qu'elle adopte. On se retrouve rapidement avec de nombreuses régressions. On se rend compte que l'intégration n'est pas continue et que les tests ne sont pas si automatisés que ça...

[lepinekong]

Bien sur, on peut toujours adapter les process, que ce soit SCRUM ou XP.

Mais tout de meme, SCRUM est basé sur l'existence d'un Backlog "Produit" (sous entendu complet) qui va être trié par priorité. Donc toute modification sur le CDC produit va necessiter de modifier le backlog, et potentiellement de devoir recoder certaines parties du logiciel qui ont déjà été codées. On se rapproche de l'idée de "constant refactor" de XP.

Je pense juste qu'il faut eviter de choisir une méthode comme SCRUM si on sait d'avance que le CDC est instable. A l'inverse, il faut éviter de choisir une méthode comme XP si on sait d'avance qu'on doit garantir une date de sortie.

La prémisce même de toute méthode agile, quelle qu'elle soit, est justement de s'opposer au Waterfall en disant que les requirements ne peuvent pas être connus à l'avance. Le Backlog Produit n'a pas à être complet, on doit tendre à ce qu'il soit le plus complet possible car Manager par définition c'est Gérer et Gérer c'est Prévoir. Les Stakeholders du Projet qui tiennent le porte-monnaie sont essentiellement intéressés par le coût / délai. Ce n'est pas parce que c'est agile qu'on a l'éternité

[pseudocode]

La prémisce même de toute méthode agile, quelle qu'elle soit, est justement de s'opposer au Waterfall en disant que les requirements ne peuvent pas être connus à l'avance.

Les 2 méthodes XP et Scrum s'inspirent de l'enchainement Besoin->Exigence->Design->Code->Test du Waterfall. L'agilité vient du fait que ces 2 méthodes font des boucles "très courtes" et "corrigent le tir" avant de faire la boucle suivante

Les Exigences sont forcément connues à l'avance, sinon comment faire pour coder ?

Mais c'est vrai qu'il n'est pas nécessaire d'avoir l'intégralité des besoins/exigences pour coder. Cela dit, on accepte le risque que l'arrivée de nouveaux besoins/exigences puisse bouleverser le projet (architecture, planning, ...)

[lepinekong]

Les 2 méthodes XP et Scrum s'inspirent de l'enchainement Besoin->Exigence->Design->Code->Test du Waterfall. L'agilité vient du fait que ces 2 méthodes font des boucles "très courtes" et "corrigent le tir" avant de faire la boucle suivante

Le Manifeste Agile s'oppose explicitement à la méthode Waterfall: ils avaient même créé un site de parodie contre. En vérité la méthode Waterfall n'a jamais existé (je ferai un article là-dessus mais ceux qui ont lu l'article originel de l'auteur devrait le relire). La philosophie du Waterfall est 0 BOUCLE: tout en ligne droite, on est capable de tout planifier et figer après chaque étape. A la rigueur le cycle en V c'est UNE boucle parce que la remontée du cycle en V permet des corrections. Mais une boucle c'est très insuffisant, il faut n boucles.

Les méthodes agiles admettent fondamentalement l'incertitude, le waterfall la nie. Pour image un peu tiré par les cheveux sans doute dire que l'une s'inspire de l'autre c'est comme si tu disais la mécanique quantique s'inspire de la mécanique de Newton alors que la mécanique quantique introduit le principe d'incertitude

[pseudocode]

Le Manifeste Agile s'oppose explicitement à la méthode Waterfall: ils avaient même créé un site de parodie contre. En vérité la méthode Waterfall n'a jamais existé (je ferai un article là-dessus mais ceux qui ont lu l'article originel de l'auteur devrait le relire). La philosophie du Waterfall est 0 BOUCLE: tout en ligne droite, on est capable de tout planifier et figer après chaque étape. A la rigueur le cycle en V c'est UNE boucle parce que la remontée du cycle en V permet des corrections. Mais une boucle c'est très insuffisant, il faut n boucles.

Les méthodes agiles admettent fondamentalement l'incertitude, le waterfall la nie. Pour image un peu tiré par les cheveux sans doute dire que l'une s'inspire de l'autre c'est comme si tu disais la mécanique quantique s'inspire de la mécanique de Newton alors que la mécanique quantique introduit le principe d'incertitude

Je ne sais pas l'experience que tu as dans le domaine du dev logiciel.

Personnellement, je n'ai jamais rencontré de méthodologie qui permette de coder sans avoir réfléchi au préalable a la structure du code (design). Cette structure émanant d'une vue d'ensemble du programme (architecture). Cette vue d'ensemble répondant à des exigences fonctionnelles (specification). Ces exigences fonctionnelles permettant l'accomplissement de scénarios (besoins).

J'ai beau regarder tous les documents sur les méthodologies agiles, aucune ne contredit ce que j'ai marqué ci-dessus. Pour moi, ces méthodologies révolutionnent surtout la "gestion de projet", et pas tellement celle d' "analyse et conception". D'ailleurs, à la lecture de ton message je vois que tu parles surtout du "processus projet".