Et c'est loin d'être une hérésie car cela permet d'éviter l'effet tunnel : plusieurs mois de dév pour découvrir qu'en fait on avait mal compris le besoin du client et ce, malgré de magnifiques cahiers des charges et spécifications fonctionnelles.
Avec des cycles courts le client s'implique plus souvent et peut débusquer ce genre de malentendus assez tôt, ce qui limite les dégâts.
La méthode agile est très efficace pour débusquer des soucis disons mineurs. Ou éviter de prendre une mauvaise voie qui ne sera jamais corrigée. En effet une limitation dans la conception initiale difficile à corriger devrait être identifiée le plus tôt possible.
Mais cela n'est pas une méthode miracle. La méthode agile implique un minimum de spécifications à la base (ce qui est souvent passé à la trappe, car on est agile). Certains clients ou managers aussi sont convaincus que l'agilité autorise tout et n'importe quoi comme remettre en question quelque chose fondamentale dans la conception sur la fin du projet. Alors qu'en réalité ce n'est pas si simple.
Il faut comprendre que dans l'agilité, si on se rend compte que la conception de base est mauvaise (cela arrive), il faut du temps pour y remédier. Ce n'est pas au sprint suivant qu'on corrige ce genre de défauts.
[^] # Re: Agile... comment casser le charme!
Posté par Renault (site web personnel) . En réponse à la dépêche Formation « Développeur d’applications full stack » à l’INP de Toulouse, épisode 2. Évalué à 4.
La méthode agile est très efficace pour débusquer des soucis disons mineurs. Ou éviter de prendre une mauvaise voie qui ne sera jamais corrigée. En effet une limitation dans la conception initiale difficile à corriger devrait être identifiée le plus tôt possible.
Mais cela n'est pas une méthode miracle. La méthode agile implique un minimum de spécifications à la base (ce qui est souvent passé à la trappe, car on est agile). Certains clients ou managers aussi sont convaincus que l'agilité autorise tout et n'importe quoi comme remettre en question quelque chose fondamentale dans la conception sur la fin du projet. Alors qu'en réalité ce n'est pas si simple.
Il faut comprendre que dans l'agilité, si on se rend compte que la conception de base est mauvaise (cela arrive), il faut du temps pour y remédier. Ce n'est pas au sprint suivant qu'on corrige ce genre de défauts.