On dirait que tu as déjà eu une mauvaise expérience et maintenant te voilà devenu réticent lorsque tu entends parler d'agilité. Et ce n'est pas moi qui vais te blâmer pour ça.
Personnellement je n'ai jamais eu l'occasion de mettre en pratique de méthodes agiles mais j'avais reçu il y a bien longtemps un formation sur les techniques SCRUMM. Et le peu dont je me souviens c'est que, si on prend du recul sur le vocabulaire nouveau, en fait il s'agirait pour l'essentiel d'appliquer des mini-cycles en V sur des intervalles de temps courts, entre 2 et 6 semaines.
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.
En pratique j'ai pu observer de loin de nombreux projets menés en "mode agile" et bien souvent, le choix de mode agile était surtout utilisé comme de la poudre aux yeux du client. Mais j'ai eu aussi des retours positifs de plusieurs projets donc ça me parait absurde de rejeter les méthodes agiles en bloc.
Il faut juste rester méfiant selon la personne qui emploie ces termes.
[^] # Re: Agile... comment casser le charme!
Posté par seveso . En réponse à la dépêche Formation « Développeur d’applications full stack » à l’INP de Toulouse, épisode 2. Évalué à 3. Dernière modification le 28 juin 2018 à 08:16.
On dirait que tu as déjà eu une mauvaise expérience et maintenant te voilà devenu réticent lorsque tu entends parler d'agilité. Et ce n'est pas moi qui vais te blâmer pour ça.
Personnellement je n'ai jamais eu l'occasion de mettre en pratique de méthodes agiles mais j'avais reçu il y a bien longtemps un formation sur les techniques SCRUMM. Et le peu dont je me souviens c'est que, si on prend du recul sur le vocabulaire nouveau, en fait il s'agirait pour l'essentiel d'appliquer des mini-cycles en V sur des intervalles de temps courts, entre 2 et 6 semaines.
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.
En pratique j'ai pu observer de loin de nombreux projets menés en "mode agile" et bien souvent, le choix de mode agile était surtout utilisé comme de la poudre aux yeux du client. Mais j'ai eu aussi des retours positifs de plusieurs projets donc ça me parait absurde de rejeter les méthodes agiles en bloc.
Il faut juste rester méfiant selon la personne qui emploie ces termes.