Commentaires sur : Agilité pour MOA http://www.agilex.fr/2010/03/agilite-pour-moa/ Agile, Lean, Scrum et informations diverses Tue, 07 Feb 2012 11:38:14 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Par : Emilie http://www.agilex.fr/2010/03/agilite-pour-moa/comment-page-1/#comment-1429 Emilie Wed, 13 Apr 2011 09:56:49 +0000 http://www.agilex.fr/?p=912#comment-1429 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. 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.

]]> Par : Fefal http://www.agilex.fr/2010/03/agilite-pour-moa/comment-page-1/#comment-1101 Fefal Thu, 11 Mar 2010 11:07:36 +0000 http://www.agilex.fr/?p=912#comment-1101 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... 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…

]]> Par : Fefal http://www.agilex.fr/2010/03/agilite-pour-moa/comment-page-1/#comment-1097 Fefal Mon, 08 Mar 2010 17:38:44 +0000 http://www.agilex.fr/?p=912#comment-1097 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? <blockquote>Alexandre : Le travail est découpé en petites activités (User Story) qui sont implémentées complétement les unes après les autres. Si 40 points sont implémentés (codé+testé+Déployé) en 2 itérations et que le Product Backlog fait 100 points, on estime que les 60 points restants seront implémentés durant les 3 itérations suivantes. A la différence d'un projet dont l'avancement est de 70% car le codage de l'ensemble des exigences est terminé, mais dont on ne peut estimer avec précision la fin réelle car la durée des tests n'est pas prévisible avec fiabilité puisque cela dépend fortement de la qualité du code produit.</blockquote> 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?

Alexandre : Le travail est découpé en petites activités (User Story) qui sont implémentées complétement les unes après les autres. Si 40 points sont implémentés (codé+testé+Déployé) en 2 itérations et que le Product Backlog fait 100 points, on estime que les 60 points restants seront implémentés durant les 3 itérations suivantes. A la différence d’un projet dont l’avancement est de 70% car le codage de l’ensemble des exigences est terminé, mais dont on ne peut estimer avec précision la fin réelle car la durée des tests n’est pas prévisible avec fiabilité puisque cela dépend fortement de la qualité du code produit.

]]> Par : thierry http://www.agilex.fr/2010/03/agilite-pour-moa/comment-page-1/#comment-1096 thierry Sun, 07 Mar 2010 10:57:53 +0000 http://www.agilex.fr/?p=912#comment-1096 Tout est dit. J'utiliserai l'argumentaire. Merci ;-) Thierry Tout est dit.
J’utiliserai l’argumentaire. Merci ;-)
Thierry

]]> Par : Cédric http://www.agilex.fr/2010/03/agilite-pour-moa/comment-page-1/#comment-1093 Cédric Sat, 06 Mar 2010 17:09:18 +0000 http://www.agilex.fr/?p=912#comment-1093 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 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

]]>