Discussion :

[rad_hass]

Bonjour à tous,

Je travail actuellement sur un projet de petite taille (seul), je suis encore à la phase de conception et je dois faire un planning (estimation de charges ...) et je ne suis pas un pro dans ce domaine (en plus d'être débutant lol) ... J'ai bien évidemment eu à faire ce genre de chose mais jamais seul et sans vraiment utiliser une vraie méthodologie en utilisant entre autre. Je me suis un peu documenté et j'ai vu quelques processus qui me semblent parfois un peu complexe pour un petit projet (en calculant les points de fonctions ...).

Alors peut on adapter une méthodologie à un petit projet, avez vous une métho adapté à ce que je cherche ? Sinon comment faites vous en général ?

J'essaie d'avoir une démarche qualité dans mon projet alors toutes vos idées me seront d'une grande utilité.

Merci d'avance pour toutes documentations ou informations.

PS : Le projet en question est un site intranet développer en ASP.NET.

[ced600]

Alors peut on adapter une méthodologie à un petit projet, avez vous une métho adapté à ce que je cherche ? Sinon comment faites vous en général ?

Le piffomètre

Très difficille le travail d'estimation de réalisation d'une application.
Cela dépend de tellement de paramètre (performance des développeurs, entente de l'équipe, capacité du chef de projet, vacance, matériel disponible, ....)
Quelque soit la méthode utilisé tu va devoir faire une estimation au piffomètre à un moment ou un autre, ou demander à un de tes développeurs de le faire à ta place.

Tu es en phase de conception, et je suppose que tu veux estimer la charge de travail pour le codage de l'application.
Cela dépendra de plusieurs choses comme le dégré de détail dans la conception, le niveau des développeurs, leurs nombres, ...
Mais pour que tu puisses gérer cela il faut que tu ailles voir tes développeurs.
Prend conseil au près des séniors, ils ont plus d'expérience, et demande leur combien de temps ils mettraient, et combien de temps mettrais un débutant pour faire telle portion de code.
Double les deux temps donnés.

Répartis les taches à chacun des développeurs, et en fonction de leur niveau, de leur expérience, et grâce à ce que t'on dit les séniors, estime la chage pour chaque développeur.
Va voir ton développeur et demande lui son estimation.
Fait la moyenne entre son estimation et la tienne.
Multiplie par 2 cette moyenne, et si on vous laisse pas mal de temps pour le projet, rajoute à ton temps calculé 20% de sa valeur.

Bon je ne suis pas bien placé, je ne sors pas de l'école depuis longtemps, et je n'ai pas ce genre de formalisme à appliquer travaillant seul du coté développement. Mais je ferais un truc comme je t'ai cité.

Après il y a des choses comme le diagramme de GANT et de PERT qui sont utiles. Enfin pour ce que je m'en souviens, ils sont surtout utile pour prendre en compte les vacances, et de voir la différences entre ce que tu as estimé et la réalité.
Cela te permet de réajuster pour tenir les délais.
Enfin ils servent aussi à déterminer le chemin critique.
C'est à dire les composants à dévelloper dont un retard de dév impactera forcément un retard sur le planning.
Bon wikipédia doit mieux définir que moi les termes.

[rad_hass]

Merci pour ta réponse.

Je suis en faite développeur et mon propre chef de projet sur ce projet. Donc pas de développeur sous ma responsabilité ...

Je dois faire un planning (normal, pour toute application) qui m'est demande par le directeur de projet et la MOA ... Et donc pour que mon planning soit cohérant je dois un minima le justifier par une réel étude et méthodologie ...

Le planning est par def prévisionnel donc y a toujours des approximations, mais en utilisant une méthodologie en limite l'effet pifomètre, qui sans expérience ne veux plus rien dire ...

[tomlev]

Répartis les taches à chacun des développeurs, et en fonction de leur niveau, de leur expérience, et grâce à ce que t'on dit les séniors, estime la chage pour chaque développeur.
Va voir ton développeur et demande lui son estimation.
Fait la moyenne entre son estimation et la tienne.
Multiplie par 2 cette moyenne, et si on vous laisse pas mal de temps pour le projet, rajoute à ton temps calculé 20% de sa valeur.

Ca ce n'est malheureusement pas valable dans tous les contextes... si tu réponds à un appel d'offre et que ta proposition est 2 fois plus chere que le concurrent, c'est perdu d'avance !

[theMonz31]

salut

une méthodologie pour faire une estimation :

1 : Faire une estimation du logiciel à developper (il faut "avoir une idée de la future architecture du logiciel et essayer d'identifier les différentes parties qui doivent etre developper ou reutiliser

2 : Evaluer le temps à consacrer aux tests

3 : Evaluer le temps pour l'integration du logiciel en condition de livraison

4 : Evaluer le temps de réunion pour gérer le projet, valider avec le client, etc...

5 : Appliquer un ratio de type 1.25 ou 1.50 pour réévaluer le chiffrage

6 : Si tu as un budget en face de ton chiffrage, voir si ton chiffrage explose le budget ou pas

7 : Tenir compte de l'expérience du developpeur, etc. pour réévaluer le chiffrage (si t'es expert Base de données, il y a fort à parier que tu seras
"optimal" sur cette partie

8 : Appliquer un ratio correspondant à la marge du projet ( 40 % par exmple)

9 : Faire relire ton chiffrage par d'autres personnes compétentes

Voila

The Monz, Toulouse

[Bluedeep]

Ca ce n'est malheureusement pas valable dans tous les contextes... si tu réponds à un appel d'offre et que ta proposition est 2 fois plus chere que le concurrent, c'est perdu d'avance !

Mieux vaut perdre d'avance que perdre du pognon une fois que c'est signé. Dans tous les cas on perd, mais dans le premier au moins on ne bosse pas pour rien. (ce qui sera peut être le cas du concurrent).

[rad_hass]

Merci beaucoup pour vos réponses.

Me reste à savoir comment estimer le temps de développement (ce qui pour moi constitue la partie la plus critique) ...

Merci the Monz pour ton plan, concernant le point 1 j'ai definie mon architecture logiciel, mais avec le peu de recule que j'ai, je suis incapable de dire en combien de temps je peux le faire ... Et il me semble que le faire au pif c'est un peu risqué, même quand on a du recule. Vous trouvez pas ?

[ced600]

Ca ce n'est malheureusement pas valable dans tous les contextes... si tu réponds à un appel d'offre et que ta proposition est 2 fois plus chere que le concurrent, c'est perdu d'avance !

@tomlev : Oui mais si tu taillades le temps, que tu bacles, ou que tu ne fournis pas le soft à temps, on peut te réclamer du fric, c'est pas mieux

ha bah je connais aussi des SSII qui dise :

Nous sommes moins cher que le voisin et on le fait deux fois plus rapidement

Bah il décroche le contrat, pour augmenter les gains, la boite met des débutants là où il faut des experts. Les gars se démerdent comme ils peuvent, suant jours et nuits, en applicant la méthode "à l'arrache sans test car je n'ai pas le temps".
Au final ils respectent la deadline en fournissant un soft qui fonctionne 5 minutes, super méga buggués, et soit tu dis :

boite de merde je vais voir ailleurs

et il faut tout recommencer.
Ou soit tu prends du retard en attendant que la boite débug pour toi

Je crois le pire c'est lorsque tu demandes à une SSII de ce genre d'industrialiser le code d'un prototype.
Tu te retrouves avec un soft qui est plus buggué que le prototype !!!

[theMonz31]

a quand le jour ou les SSI comprendront que :

Developpeur Expérimenté bien payé => Logiciels developpés rapidemment =>
Gain reel au final....

Et quand on comprendra que le developpemenet logiciel est quelque part un art et demande une vraie compétence , passion et interet.. on arrivera peut-etre
à ne plus envoyer les dev en Inde... et créer du chomage chez nous...

Mais bon, dans une société ou l'ouvrier est devalorisé, quand serat-il du developpeur ?

The Monz, Toulouse

[Chubyone]

@tomlev : Oui mais si tu taillades le temps, que tu bacles, ou que tu ne fournis pas le soft à temps, on peut te réclamer du fric, c'est pas mieux


C'est pas une méthode, mais un outil :
http://ganttproject.sourceforge.net/fr/

Ca peut t'aider a aller plus vite déjà.


Comme la dit en Ced, ce que tu prévois est TOUJOURS en deça de la réalité. Moi même quand on me demande une date, je "gonfle" automatiquement...
et là on me dit "quoi tant de temps que ça?!!!"
et là je dois toujours ressortir les même arguments... Je m'assure en général de l'avoir fait à la moitié du temps mais il arrive toujours un moment ou il faut bosser à 200%, parce que c'est dans 2 jours, parce qu'il y a eu un "os"...


[edit] bon The Monz a donné la bonne formule magique