Temoignages sur les méthodes agiles [Résolu]

[KGonzalez]

Bonjour à tous,

Je réalise actuellement un mémoire sur les méthodes agiles.
Le but étant de montrer l’intérêt de ces méthodes par rapport aux méthodes classiques. Cependant une partie de mon mémoire ce parle des difficultés que l'on peut rencontré avec ces méthodes. En cherchant sur internet j'ai trouvé divers éléments comme le possible manque de documentation, le passage de compétence qui pouvait être difficile etc.
Cependant je n'ai pas trouvé beaucoup d’éléments.
Pour rendre cette partie moins "théorique" j'aurais voulu le témoignage de personne qui ont expérimenté un ou plusieurs de ces méthodes, sur les difficultés ou de façon plus générale l'expérience que vous avez avec ces méthodes. Ce serait juste un questionnaire par exemple de moins d'une dizaine de question

Si des personnes seraient intéressés je vous en serait reconnaissant.

En vous remerciant.
KGonzalez

[rad_hass]

Bonjour,

J'ai fais un retour d'expérience après ma première mission agile (ou j'ai effectué une transformation au niveau d'une équipe) : http://rad-hass.developpez.com/tutor...ur-experience/

La première difficulté qu'on rencontre lors d'un passage à l'agilité c'est la résistance aux changements... Mais ça ce n'est pas propre à l'agilité.

Pour réussir un projet, l'agilité mise beaucoup sur l'humain, donc si y a des personnes pas motivé ou pas passionnée ça peut apporter un lot de difficulté.

Y a des gens qui croit que faire de l'agile c'est déjà une solution et une garantie de réussite... Non c'est juste une méthode qui essai de ressortir le potentiel humain... Donc la mauvaise compréhension est un vrai fléau.

Etre totalement agile n'est pas une chose simple, il faut beaucoup d'investissement pour être agile. Car ça ne concerne pas juste l'équipe de développement mais toute la structure.

Voilà quelques généralités

Un lien intéressant : http://www.bouzin-agile.fr/?post/201...n-de-l-Agilite

[KGonzalez]

Bonjour,

Tout d'abord merci pour ta réponse rad_hass. Ton retour d'expérience couvre tous les éléments que je traite. Concernant ta publication sur ton retour d'expérience si tu n'y vois pas d’inconvénient je m'en servirais pour le mémoire. Bien sur j'indiquerais dans ma bibliographie les éléments nécessaires.

Également merci pour le second lien qui me sera utile.

Si d'autres personnes veulent partager leurs expérience, n'hésitez pas. Notamment des personnes développant en utilisant des méthodes telles que Crystal ou ASD méthodes ou j'ai pu trouver peu de témoignage.

Dans mon premier post j'avais parlé d'un questionnaire.
Il s'agit d'une dizaine de question que voici :

Depuis quand connaissez-vous les méthodes agiles ?
Si vous avez développé avec les méthodes classiques (modèle en cascade ou
cycle en v) :
Quels apports avez-vous constatez suite à l’utilisation des méthodes agiles ?
Quelles difficultés avez-vous pu rencontrer avec les méthodes agiles ?

Pour l’entreprise
Quels projets sont ou ne sont pas développés avec les méthodes agiles, et
pour quels raisons ?
Si les méthodes agiles n’étaient pas appliqués dans entreprise comment le
changement de méthode de travail à été vécu par les développeurs ?
Avez-vous des indicateurs ou des statistiques qui mesurent le gain de
temps ou de productivité grâces à ces méthodes ? Si cela est possible
pouvez-vous me les communiquer ?

Concernant la gestion de projet avec les méthodes agiles
Quel logiciel utilisez-vous pour le suivie de sprint, la création
d’user-story ?
Qu’est ce qui a motivé le choix de ce logiciel ?

Si jamais vous avez du temps je vous en remercie.

Cordialement

[calagan99]

Bonjour,

dans mon entreprise actuelle (plus pour longtemps ), nous sommes passés il y a plusieurs mois d'une non-organisation à une tentative de mise en place de SCRUM.
Pour les équipes de développeurs, cela s'est avéré très fructueux :
- meilleure cohésion d'équipe, meilleure collaboration, etc.
- visibilité à court, moyen et long terme
- qualité en hausse
- fin du mode tunnel, etc.

Par contre, après 4 mois d'application, une chose semble difficile à gérer pour les "décideurs" de l'entreprise : les devis.
En effet, dans SCRUM, finis le jour(s)/homme. Or, il est compréhensible que lorsqu'un commercial vend une prestation, il ait besoin d'un chiffrage en jours/homme pour déterminer une partie de son prix de vente.
Les équipes sensées déterminer la faisabilité et le chiffrage du projet n'utilisant pas cette mesure, il est parfois difficile, pour le commercial, de savoir où il va.
C'est selon moi une limite rencontrées chez nous dans l'adoption de cette méthode.

D'autre part, seconde difficulté à mon sens : l'identification claire, nette, précise et sur la durée de deux rôles essentiels au fonctionnement des projets agiles avec SRUM :
- le ProductOwner et le ScrumMaster.
Ces deux rôles sont nécessaires au bon déroulement d'un projet et chacun d'entre eux doit réellement maîtriser son rôle et les tâches qui lui incombent.
Si ce n'est pas le cas, on rencontre très rapidement des blocages et on a vite tendance à revoir les problèmes de type "c'est bien, mais ce n'est pas ce qu'on avait demandé" repointer le bout de leur nez...

D'autres personnes utilisant SCRUM ont-elles rencontré ces difficultés ?

[Drawingrom]

Réponse globale.

J'entends parler de méthodes Agile depuis 2007. On peut dire que j'ai été converti à la lecture de "Coder proprement" de Robert Martin.

Apports : c'est plus direct. L'utilisateur a un besoin, on le l'intègre dans le logiciel. On fait de la doc bien sûr, mais elle est reléguée au second plan. La priorité est la réponse rapide au besoin.

La difficulté par rapport à une conduite de projet plus classique est qu'on est toujours à fond, il n'y a pas de creux de charge. Quand on est sur un projet scrum pendant 6 mois / un an sans pause, je trouve cela assez fatiguant.

Les projets agiles ne sont pas la norme dans mon entreprise, même si je pense que c'est un argument de vente dans certains cas. Il n'y a pas de process défini pour faire un projet agile (de toute façon, le concept de process est anti agile ). Deux raisons :

*La demande client reste marginale (je suis en SSII). La plupart du temps un forfait classique est encore demandé afin d'avoir l'illusion de déplacer le risque côté fournisseur.
*C'est difficile à vendre dans un contrat de type forfait, puisque qu'on réduit l'engagement.

Gains liés à l'agilité :
* L'utilisateur est content car on n'hésite pas à refaire une fonctionnalité si ce n'est pas ce qu'il attend. Il peut utiliser le logiciel rapidement et en tirer de la valeur même si toutes les fonctionnalités ne sont pas intégrées. Mine de rien, c'est rare qu'on vous dise merci en temps qu'équipe de développement. Ca fait plaisir.
* Les pratiques de dev, liées au tests et à l'intégration continue sont bénéfiques pour la qualité du produit et la maintenance (mais pas besoin d'être en scrum pour faire du TDD )

Outils utilisés
* Excel
* Tableau blanc et post-it
* JUnit, Hudson / Jenkins

[apieum]

Si cela t'intéresse Seiki a rédigé un mémoire qui est vraiment complet :
http://www.developpez.net/forums/d72...thodes-agiles/

et si ça peut aider une ressource sur les contrats :
http://agilesoftwaredevelopment.com/...gile-contracts

[KGonzalez]

Bonjour à tous,

J'ai juste lu en diagonale mais votre aide m'est très utile. Ça va rendre mon rapport plus "vivant".

Merci d'avoir pris le temps de me répondre

[ssate36]

Bonjour ,

je traite le même sujet . pouvez vous m'aider svp .