Dernièrement un client m’a demandé un court argumentaire pour inciter une MOA (le représentant du client) à se renseigner sur l’agilité. La problématique était présentée de la façon suivante : « La MOA veut savoir ce qu’est l’agilité avant de consentir à se la faire présenter ! » et il fallait donc proposer quelque chose de court, concis et percutant.
Après quelques jours de réflexion, j’ai proposé le questionnaire suivant :
- Votre besoin fonctionnel est-il parfois incomplet au T0 du projet ?
- Identifiez-vous de nouveaux besoins en cours de réalisation ?
- Attendez-vous longtemps pour voir une première version ?
- Avez-vous des difficultés à vous faire comprendre de la MOE ?
- Voyez-vous vos planning dériver avec le temps ?
- Vous demandez-vous parfois ce que fait la MOE ?
- Découvrez-vous beaucoup de bugs en fin de cycle ?
- Souhaitez-vous augmenter votre productivité ?
Si vous avez répondu OUI à l’une de ces questions, alors les méthodes Agiles peuvent vous aider à mieux faire car
- La possibilité de changer le besoin fonctionnel est intégré structurellement dans la méthode
- Une version démontrable est livrée régulièrement (tous les 2 ou 3 semaines)
- Les échanges entre MOA et MOE sont permanents et riches d’enseignements
- La prédictibilité de la MOE est basée sur le travail réellement terminé et non sur une estimation de la progression
- La visibilité est totale et permanente sur toutes les activités
- Les tests sont faits en continu pour éviter les effets « Big Bang » de fin de cycle
- Les gains de temps sur l’ensemble du cycle (de l’expression de besoin au déploiement) sont très significatifs
Avec quelques recommandations pour passer à l’Agilité
- Se former, car même si la méthode semble simple, c’est plus complexe qu’il n’y parait
- Se faire accompagner, car c’est plus difficile qu’il n’y paraît et les bénéfices seront obtenus plus rapidement
- Démarrer au plus tôt en mode Agile, c’est-à-dire dès la collecte des besoins, car tous les acteurs sont concernés et pas seulement la MOE
- Accepter et mettre en œuvre les changements induits par la méthode (réunions en présentiel, disponibilité en continu …)
- Comprendre que l’agilité est avant tout un état d’esprit et non juste une « autre méthode »
Qu’en pensez-vous ?
C’est percutant! Rien à redire pour ma part sur le contenu.
Mais vu le contenu et si on cherche à se projeter dans la présentation, peut-être qu’un jeu agile mettant en scène MOA et MOE serait le bienvenu, ce qui sous-entendrait d’avoir quelques représentants de la MOE pour augmenter l’effet. Suggestion qui, j’en convient, pourrait coûter trop de temps à une MOA qui semble peu disponible.
Ced
Tout est dit.
J’utiliserai l’argumentaire. Merci 😉
Thierry
Excellent argumentaire. Il a juste un point qui n’est pas clair pour moi.
« La prédictibilité de la MOE est basée sur le travail réellement terminé et non sur une estimation de la progression ».
Pas trés clair pr moi, une estimation se fait quand même sur une fonctionnalité à fournir. C’est donc tjrs une estimation.
Prédictibilité sur le travail terminé??? Pourquoi estimer le travail à fournir ds ce cas?
Merci d’avoir pris le temps pour répondre à mes interrogations.
Beaucoup plus clair…les itérations de 2-3 semaines permettent vraiment une meilleur visibilité et productivité sur le projet.
Bon courage pr la suite…
Très bon argumentaire, j’achète !
Pour compléter votre réponse à Fefal :
Dans un projet « cascade », on mesure l’avancement par rapport à la consommation du budget – en gros, avancement = effort.
Dans un projet agile, grâce aux démonstrations, on constate l’avancement effectif de la construction du logiciel. De plus, si on estime la complexité des user stories en points de « complexité fonctionnelle » (proportionnelle au nombre de règles de gestion ou d’assertions dans les tests de recette), la vélocité et le burndown chart nous donnent un indicateur reflétant l’avancement du logiciel.
Bien sûr, il faut suivre en parallèle le budget consommé pour ne pas le dépasser, mais la consommation du budget n’est plus l’indicateur principal d’avancement.