Discussion :

[freyn]

Bonjour,

J'ai eu l'occasion, par le passé, d'utiliser une méthode que je trouvais sympa. Mais je n'ai pas encore eu l'occasion de la réutiliser.

Cette méthode d'estimation, consistait en plusieurs points:
1. Séparation de l'application à programmer en "modules/fonctions" qui peuvent être programmés de manières indépendantes.
2. Parmi ces modules, on reprends 1, 2 ou 3 modules de références (étalons).
3. Pour chacun des étalons, on réalise une estimation de développement (nombre de jours) pour les points suivants (C'est une liste indicative, bien évidemment):
- Analyse,
- Conception,
- Réalisation,
- Test Informatique,
- Test Utilisateurs,
- Formation Utilisateurs,
- Documentation Utilisateurs,
- Démarrage de l'application.

On peut aussi ajouter (pour les cas plus complexes) une estimation de temps pour chacun des rôles (Directeur de projet, Chef de projet, Ingénieur de projet, utilisateur). Mais dans ton cas, je suppose qu'un rôle suffira.

4. Ensuite, pour chacun des "modules/fonctions", on associe un étalon semblable (d'où l'utilité de bien choisir ses étalons, qu'ils soient bien représentatif de l'ensemble du projet), et on le corrige d'un coéfficient de difficultés (2x plus dur, 0.5x plus dur).

5. On additionne le tout, et on a une première estimation du projet en jour/homme.

6. On peut ajouter au total certains correctifs, suivant le projet :
% pour une réserve (typiquement 10-20%)
% pour le suivi du projet (réunion, discussion, entrevue avec le client) (typiquement 15%)
% pour un controle de qualité (5%)
% pour le setup général du projet (5%)

Voilà, le résultat est assez surprennant. Mais la seule fois où j'ai eu l'occasion de l'utiliser, il a été assez précis.

On peut aussi réévaluer le planning une fois que les fonctions/modules étalons ont été réalisé.

[ced600]

Cela me paraît pas mal.
Etant totalement dépendant d'une estimation correcte des étalons, je me demande s'il ne serait pas déjà intéressant d'appliquer un correctif à l'estimation des étalons en fonction de la difficulté à les estimer.

Cette méthode resemble au méthode de dosage que je faisais en biologie.
Mais en biologie nos étalons étaient "parfait".
Par exemple lorsque l'on utilisais les spectromètre de masse (pour déterminer la quantité d'un élément dans une solution liquide), on cherhait en premier à déterminer un ensemble de delta erreurs à appliquer à nos résultats, dont le delta erreur du à la machine.
Pour cela on utilisais des solutions dont ont connaissais au par avance le résultat que donnerait le spectromètre de masse. Et on les mesurait avec ce spectro. Et l'écart obtenu se trouve être notre delta erreur.

Je pense que l'idée est là. En suivant la méthode de freyn, on détermine des étalons en fonction aussi de notre propre expériences, les modules que l'on sera mieux estimé.
Puis on applique un delta erreur important (genre 20%).
On obtiens deux résultats :
- Un avec le delta erreur, qui sera notre temps max.
- Un sans le delta erreur, qui sera notre minimum.
On ne communique que le temps max du projet (pour que la direction ne transforme pas notre temps mnimum en temps max ).

Et ensuite on réestime notre delta erreur une fois que l'on a codé un ou plusieurs étalons (avoir des étalons que l'on code au début c'est donc pas mal aussi) et on obtiens le nouveau temps max que l'on peut communiquer à ses supérieurs.

[theMonz31]

salut

et ced600, tu veux pas non plus appliquer un filtre de kalmann pour ré-évaluer tes coefficients en fonction du résultat obtenu ?

The Monz, Toulouse

[rad_hass]

Bonjour,

J'ai eu l'occasion, par le passé, d'utiliser une méthode que je trouvais sympa. Mais je n'ai pas encore eu l'occasion de la réutiliser.

Cette méthode d'estimation, consistait en plusieurs points:
1. Séparation de l'application à programmer en "modules/fonctions" qui peuvent être programmés de manières indépendantes.
2. Parmi ces modules, on reprends 1, 2 ou 3 modules de références (étalons).
3. Pour chacun des étalons, on réalise une estimation de développement (nombre de jours) pour les points suivants (C'est une liste indicative, bien évidemment):
- Analyse,
- Conception,
- Réalisation,
- Test Informatique,
- Test Utilisateurs,
- Formation Utilisateurs,
- Documentation Utilisateurs,
- Démarrage de l'application.

On peut aussi ajouter (pour les cas plus complexes) une estimation de temps pour chacun des rôles (Directeur de projet, Chef de projet, Ingénieur de projet, utilisateur). Mais dans ton cas, je suppose qu'un rôle suffira.

4. Ensuite, pour chacun des "modules/fonctions", on associe un étalon semblable (d'où l'utilité de bien choisir ses étalons, qu'ils soient bien représentatif de l'ensemble du projet), et on le corrige d'un coéfficient de difficultés (2x plus dur, 0.5x plus dur).

5. On additionne le tout, et on a une première estimation du projet en jour/homme.

6. On peut ajouter au total certains correctifs, suivant le projet :
% pour une réserve (typiquement 10-20%)
% pour le suivi du projet (réunion, discussion, entrevue avec le client) (typiquement 15%)
% pour un controle de qualité (5%)
% pour le setup général du projet (5%)

Voilà, le résultat est assez surprennant. Mais la seule fois où j'ai eu l'occasion de l'utiliser, il a été assez précis.

On peut aussi réévaluer le planning une fois que les fonctions/modules étalons ont été réalisé.

Merci, bcp pour ton retour d'expérience, le travail que je commence à faire part dans ce sens, tu me donne des compléments et des idées qui me seront fort précieuse, je t'en remercie. Mais j'ai une question, est ce une méthode standard que tu as découverts dans les docs ou est ce une méthode que tu as mis toi même en place ?

Encore merci.

[rad_hass]

Cela me paraît pas mal.
Etant totalement dépendant d'une estimation correcte des étalons, je me demande s'il ne serait pas déjà intéressant d'appliquer un correctif à l'estimation des étalons en fonction de la difficulté à les estimer.

Cette méthode resemble au méthode de dosage que je faisais en biologie.
Mais en biologie nos étalons étaient "parfait".
Par exemple lorsque l'on utilisais les spectromètre de masse (pour déterminer la quantité d'un élément dans une solution liquide), on cherhait en premier à déterminer un ensemble de delta erreurs à appliquer à nos résultats, dont le delta erreur du à la machine.
Pour cela on utilisais des solutions dont ont connaissais au par avance le résultat que donnerait le spectromètre de masse. Et on les mesurait avec ce spectro. Et l'écart obtenu se trouve être notre delta erreur.

Je pense que l'idée est là. En suivant la méthode de freyn, on détermine des étalons en fonction aussi de notre propre expériences, les modules que l'on sera mieux estimé.
Puis on applique un delta erreur important (genre 20%).
On obtiens deux résultats :
- Un avec le delta erreur, qui sera notre temps max.
- Un sans le delta erreur, qui sera notre minimum.
On ne communique que le temps max du projet (pour que la direction ne transforme pas notre temps mnimum en temps max ).

Et ensuite on réestime notre delta erreur une fois que l'on a codé un ou plusieurs étalons (avoir des étalons que l'on code au début c'est donc pas mal aussi) et on obtiens le nouveau temps max que l'on peut communiquer à ses supérieurs.

lol, y a des méthodes qui existent qui fonctionne ainsi, mais par contre à chaque fois tu fait des petites stats avec des formules mathématiques (utilisant des coeff, propre à chaque méthode) ... Mais bon, j'ai vu un comparatif ou la méthodes est dédié à des projets complexe et on arrivai à des tps plus de 5 fois plus grand que le temps réel lol ...

[ced600]

salut

et ced600, tu veux pas non plus appliquer un filtre de kalmann pour ré-évaluer tes coefficients en fonction du résultat obtenu ?

The Monz, Toulouse

Pouquoi pas! Je ne connaissais pas, mais cela semble intéressant

lol, y a des méthodes qui existent qui fonctionne ainsi, mais par contre à chaque fois tu fait des petites stats avec des formules mathématiques (utilisant des coeff, propre à chaque méthode) ... Mais bon, j'ai vu un comparatif ou la méthodes est dédié à des projets complexe et on arrivai à des tps plus de 5 fois plus grand que le temps réel lol ...

Les erreurs de calculs ne pardonnent pas