Discussion :

[tikomoon]

Bonjour,

Je travail pour un domaine de 30pers. d'une grosse boîte. l'équipe est pluri-disciplinaire (nouveaux projets/maintenance, développements internes -java j2ee/C/COBOL-UNIX/MVS, développements spé pour des progiciels).

Actuellement, les acteurs travaillent de manière séparées. Chacun son projet, chacun son code, chacun son équipe, Chacun ses méthodes.

Dans ce contexte, nous souhaitons augmenter notre agilité. je dis augmenter, car nous souhaitons utiliser la méthode des petits pas (ou de la roue de Deming -PDCA- pour ceux qui connaissent) pour évoluer vers les valeurs, les principes, les méthodes et les outils Agiles.
De plus, mon sentiment et que notre façon de travailler a déjà de l'agilité, mais nous ne savons pas identifier ni généraliser les bonnes pratiques.

Il nous manque un guide, un objectif commun...

En interne, un consensus semble émerger autour des méthodes agile - pour
l'instant très diffus.

D'où ma question :
Je cherche à mesurer les écarts entre l'existant et la cible "agile", puis à régulièrement mesurer notre évolution vers la cible (à 6 mois puis 1 an ...etc...).

Avez-vous déjà tenté de mesurer rationnellement vos écarts avec les méthodes du style agiles? comment avez vous construit vos outils de mesure?
quels ont été les résultats et les retours?

[souviron34]

je peux me montrer,mais il ne me semble pas y avoir à proprement parler de "cible", puisque, mis à part certaisn formalismes style RUP, le propre de la définition d'agile est d'être en cycles rapides...

Mais c'est mon sentiment..

Après, on peut toujours tenter de mesurer un peu n'importe quoi, mais si une nouvelle fonctionalité représente 1 an de réunion de mise au point->test, c'est pas agile

[tikomoon]

Oui, je suis d'accord

En faite, Nous sommes multi projet et multi équipes. Sur certains projets nous avons mis en place des cycles rapides (pour l'instant quand même 2 à 3 mois= 40 à 60 jours). Nous avons constaté des bénéfices pour nous et pour nos clients.

Nos cycles n'étaient pas guidés par des valeurs et des principes de gestion ancrés dans l'équipe. Dès que la pression client est retombée nous avons repris nos automatismes - cycles long - étude, spec fonctionnelle, spec détaillées, tests unitaires...etc... et relation MOA/MOE distantes.

En suivant ce process on sait parfaitement ou l'on met les pieds mais la méthode est moins satisfaisante pour nos clients en terme de réactivité.
Et pour nous en terme d'implication et de gestion des ressources (congés astreintes départ).

C'est pas toujours facile de motiver quelqu'un sur une application qui est en train de mourir... il serait plus facile de motiver sur du multi projet avec un peu de maintenance...

Nous n'avons pas vraiment de méthode lorsque nous faisons des cycles rapides. (ou plutôt chacun fait à sa sauce...)

C'est vraiment dans nos façons de gérer les projets et la maintenance que l'on ne sait pas évoluer vers de l'agilité (régulière et soutenable...)

D'où mon idée de mesurer par rapport au standards de l'agilité.

je pense mettre en place une échelle du type CMMi pour aller de initial jusqu'à optimisé sur des critères comme la gestion d'équipe, le pilotage de projet, l'intégration du changement...