Je crois qu'il te manque un peu de compréhension plutôt.
Waterfall. En recueillant les infos et besoins, on commence par l'analyse et conception. Quelques semaines après les nouveaux besoins sont arrivé. On reviens. Quelques semaines après on reviens encore. Quelque mois plus tard le périmètre semble exact et les besoins semblent non-contradictoires. On y va, le dév ! Et pendant plusieurs mois le client ne voit rien.
Agile. On se base sur les besoins courtes (cas d'utilisation au meilleur) et bien compréhensibles. Petit analyse, l'archi "standard", on y va le dév ! Quelques semaines après les nouveaux besoins de type "breaking chages" sont arrivés. Zut, pas du temps généraliser le modèle fonctionnel (s'il existe bien sur) et l'archi, puisque le jeudi on livre quelque chose. On y va, le dév, refactorisez le code à la volée ! Et pendant plusieurs mois le client voit comme les étages surajoutés sont construit sur le même fondation, et que le coût d'évolution monte de plus en plus.
C'est comme ça les boucles existent sans ou avec des itérations formelles dans la méthodologie.
Le scénario suivant est typique dans l'agile.
C'est une blague, mais dans chaque blague il n'y a qu'une partie de blague.A partir des cas d’utilisations les gars généralisent les vaches et les tables car elles ont 4 pattes et puis passent tout le reste du temps en restructuration permanent de son code en utilisant les « patternes », « closures », « interceptors », « aspects » et les instruments du codage super-puissante afin de résoudre de manière « ad hoc » certains contradictions dans le modèle métier.
Partager