planning dans rapport de stage

[gloglo]

Salut,

Je me demandais si dans le rapport de stage de fin d'étude il etait nécessaire de mettre le planning qu'on a fait.
En fait dans mon stage j'avais un projet à faire de A à Z et mon responsable m 'a demandé de faire un planning ainsi qu'un diagramme de gantt.
Est-il utile de le mettre dans le rapport ou non ?

[nebule]

Envoyé par gloglo

Salut,

Je me demandais si dans le rapport de stage de fin d'étude il etait nécessaire de mettre le planning qu'on a fait.
En fait dans mon stage j'avais un projet à faire de A à Z et mon responsable m 'a demandé de faire un planning ainsi qu'un diagramme de gantt.
Est-il utile de le mettre dans le rapport ou non ?

Moi je dirai oui, ca montre que tu as respecté un certain planning (donc gestion de projet), que tu as respecté un % de temps imparti pour chaque tache

Edit : mets pas 75% du temps en dev, sinon tu vas te faire descendre

[gloglo]

Me faire descendre ? pourquoi ? c'est la vérité, j'ai passé 75 % de mon temps en dev et les autres 25 % à écrire de la doc et faire des tests.

[joquetino]

Envoyé par gloglo

Me faire descendre ? pourquoi ? c'est la vérité, j'ai passé 75 % de mon temps en dev et les autres 25 % à écrire de la doc et faire des tests.

Je ne connais pas ta formation, mais souvent les responsables de formation souhaite que le stage recouvre les grandes phases d'un projet : analyse, développement et recettes, à fortiori pour un Bac +5. Si tu n'as pas travaillés sur la phase d'analyse, les professeurs vont forcément juger ton rapport en conséquence. C'est en tout cas de cette façon que mes professeurs voyaient le stage.

[nebule]

Envoyé par gloglo

Me faire descendre ? pourquoi ? c'est la vérité, j'ai passé 75 % de mon temps en dev et les autres 25 % à écrire de la doc et faire des tests.

ouai bah un conseil laisse tomber le planning!

Si tu avais "vraiment" respecter le cycle de vie du projet, ca aurait été 25% de dev et 75% pour le reste (analyse, conception, test, intégration, docs, ...)

[viena]

Envoyé par nebule

ouai bah un conseil laisse tomber le planning!

Si tu avais "vraiment" respecter le cycle de vie du projet, ca aurait été 25% de dev et 75% pour le reste (analyse, conception, test, intégration, docs, ...)

Un projet en mono ressource avec 75% en non dev... C'est franchement exagéré. En général, on penche sur du 50/50 quand on estime un projet pluri ressource. Et logiquement, quand on bosse tout seul, on passera moins de temps sur les phases amont. Donc meme si 75% c'est beaucoup, c'est plus proche de la réalité que 25% en dev !!

[questionneuse]

Envoyé par joquetino

Si tu n'as pas travaillés sur la phase d'analyse, les professeurs vont forcément juger ton rapport en conséquence. C'est en tout cas de cette façon que mes professeurs voyaient le stage.

ben on a travillé l'analyse mais on a pas mis 50% du temps a comprendre ce qu'on nous demandait de faire et encore heureux sinon mon maitre de stage aurait été lassé et nous aurait c'est bien beau votre blabla mais vous en etes ou dans l'avancement du projet.

De plus on a du mettre du temps aussi dans le choix des outils, dans la découverte du framework qu'on utilisait (lecture et compréhension de l'outil).

Donc je dirais 35% analyse, conception, choix des outils, maquette, doc et gestion de projet
50% de dév et 15% de test

Je vois mal l'employeur accepter plus de 35% d'analyse et de conception, généralement il est intéressé surtout par le produit fini sur lequel il peut cliquer partout (si tu met 70% a analyser se besoins il va finir par penser que t'es con )

[joquetino]

Envoyé par questionneuse

ben on a travillé l'analyse mais on a pas mis 50% du temps a comprendre ce qu'on nous demandait de faire et encore heureux sinon mon maitre de stage aurait été lassé et nous aurait c'est bien beau votre blabla mais vous en etes ou dans l'avancement du projet.

De plus on a du mettre du temps aussi dans le choix des outils, dans la découverte du framework qu'on utilisait (lecture et compréhension de l'outil).

Donc je dirais 35% analyse, conception, choix des outils, maquette, doc et gestion de projet
50% de dév et 15% de test

Je vois mal l'employeur accepter plus de 35% d'analyse et de conception, généralement il est intéressé surtout par le produit fini sur lequel il peut cliquer partout (si tu met 70% a analyser se besoins il va finir par penser que t'es con )

Où est-ce que j'ai parlé de 70% d'analyse?
J'ai juste préciser que la partie analyse est certainement aussi important (voir plus) pour le prof que la partie développement. Même si tu as passé qu'un dizième de ton temps sur cette phase du projet, il me semble intéressant d'insister sur ce travail dans ton rapport de stage.

[questionneuse]

oui je suis d'accord avec toi joquenito

[nebule]

Envoyé par joquetino

Où est-ce que j'ai parlé de 70% d'analyse?
J'ai juste préciser que la partie analyse est certainement aussi important (voir plus) pour le prof que la partie développement. Même si tu as passé qu'un dizième de ton temps sur cette phase du projet, il me semble intéressant d'insister sur ce travail dans ton rapport de stage.

+1, voir élargir un peu ...
car sincérement si tu as bien fait ton analyse (en profondeur) le dev doit etre "trés" rapide ... même si c'est de la théorie (sortie des bouquin) les profs adorent ça

Ok pour le 50 / 50 viena quand tu bosses seul mais bon, de la à passer à 75 (de dev)/25 c'est pas bien proportionné du tout pour un prof

Donc réparti mieux ton planning pour dire que tu as fait du 50 / 50 : (schématiquement : 25 d'analyse, conception, 50 de dev, 25 de test, intégration, docs)...

[JolyLoic]

Perso, je prefère quelqu'un qui me dirais "on n'a pas bien fait l'analyse, et ça s'est traduit par ça et ça dans le projet", ou alors, "vu qu'on était dans telle et telle conditions, l'analyse a été rapide", voire "l'analyse a été ralisée par une autre équipe, avec laquelle j'ai eu tels et tels rapports" plutôt que quelqu'un qui ment et me recopie le guide du parfait cycle en V. Et quelqu'un qui ment, ça se voit facilement...

[viena]

Envoyé par JolyLoic

Perso, je prefère quelqu'un qui me dirais "on n'a pas bien fait l'analyse, et ça s'est traduit par ça et ça dans le projet", ou alors, "vu qu'on était dans telle et telle conditions, l'analyse a été rapide", voire "l'analyse a été ralisée par une autre équipe, avec laquelle j'ai eu tels et tels rapports" plutôt que quelqu'un qui ment et me recopie le guide du parfait cycle en V. Et quelqu'un qui ment, ça se voit facilement...

+1000 !

[joquetino]

Envoyé par JolyLoic

Perso, je prefère quelqu'un qui me dirais "on n'a pas bien fait l'analyse, et ça s'est traduit par ça et ça dans le projet", ou alors, "vu qu'on était dans telle et telle conditions, l'analyse a été rapide", voire "l'analyse a été ralisée par une autre équipe, avec laquelle j'ai eu tels et tels rapports" plutôt que quelqu'un qui ment et me recopie le guide du parfait cycle en V. Et quelqu'un qui ment, ça se voit facilement...

Il ne s'agit pas de mentir, mais seulement d'insister sur la partie analyse même si cette tâche t'a occupé 1/10 de ton temps : c'est en quelque sorte une valeur ajoutée aux yeux des profs.
Maintenant, si cette étape du projet a été réalisé par une autre équipe, c'est un autre problème.

[gloglo]

Envoyé par JolyLoic

Perso, je prefère quelqu'un qui me dirais "on n'a pas bien fait l'analyse, et ça s'est traduit par ça et ça dans le projet", ou alors, "vu qu'on était dans telle et telle conditions, l'analyse a été rapide", voire "l'analyse a été ralisée par une autre équipe, avec laquelle j'ai eu tels et tels rapports" plutôt que quelqu'un qui ment et me recopie le guide du parfait cycle en V. Et quelqu'un qui ment, ça se voit facilement...

En fait j'ai fait une analyse mais rapide car j'ai tres vite compris ce qu'il faut faire exactement et en plus on leurs a fait des propositions. Et comme eux ils ne comprennent rien au gestion de projet, ils s'enfoutaient de l'analyse et de la conception. Tous ce qu'ils voulaient cest voir du code qui marche.

[viena]

Envoyé par gloglo

En fait j'ai fait une analyse mais rapide car j'ai tres vite compris ce qu'il faut faire exactement et en plus on leurs a fait des propositions. Et comme eux ils ne comprennent rien au gestion de projet, ils s'enfoutaient de l'analyse et de la conception. Tous ce qu'ils voulaient cest voir du code qui marche.

On ne fait une analyse ni pour faire plaisir au client, ni pour comprendre ce qu'il faut faire, mais pour définir comment le faire.
Quoi qu'il en soit, maintenant que ton stage se termine, tu ne peux plus rien changer à la facon dont tu y ais pris. Donc ton rapport et ta soutenance doivent présenter ce que tu as fait et pas ce qu'il aurait fallut faire.

[questionneuse]

Envoyé par viena

On ne fait une analyse ni pour faire plaisir au client, ni pour comprendre ce qu'il faut faire, mais pour définir comment le faire.

Je ne suis pas d'accord analyse c'est quoi faire et conception c'est comment le faire.

[viena]

Envoyé par questionneuse

Je ne suis pas d'accord analyse c'est quoi faire et conception c'est comment le faire.

J'ai dit analyse par abus de langage en englobant l'analyse et la conception.

Le quoi faire, c'est le cahier des charges. Le quoi faire est défini par la personne qui sait quoi faire, ce qu'elle veut : le client. L'analyse est sensé mettre en phase le client et le "realisateur". On peut tres bien comprendre "quoi faire" mais partir à coter dans le "comment faire" car on est pas en phase avec le client. En gros, l'analyse est le pont entre le quoi et le comment, mais ce n'est pas QUE le comment.

Bref, c'est pas parce qu'on a compris que le client voulait un produit X qu'on peut se passer de l'analyse.

[Scorpyosis]

Envoyé par gloglo

En fait j'ai fait une analyse mais rapide car j'ai tres vite compris ce qu'il faut faire exactement et en plus on leurs a fait des propositions. Et comme eux ils ne comprennent rien au gestion de projet, ils s'enfoutaient de l'analyse et de la conception. Tous ce qu'ils voulaient cest voir du code qui marche.

Faire du code qui marche c'est joli et c'est bien, mais si il faut qu'il change quelque chose après dans ce code, pour X raisons (nouvelles volontés du client...) et que l'analyse préalable a été fait à la va-vite, ils vont s'amuser à maintenir le projet. L'analyse (j'entends qui englobe la conception) permet avant tout à une personne qui ne connait rien au projet de rentrer dedans en comprennant ce qui a été fait (les choix pris). Si cela n'est pas fait correctement, il doit essayer de comprendre comment tout s'imbrique rien qu'à partir du code, et c'est une perte de temps énorme. J'ai aussi eu ce probleme avec un de mes stages ou les personnes ne comprennaient pas le principe même de conception et qui était plus adepte de coder vite et immédiatement. En comparaison avec un autre stagiaire, j'ai biensur commencer à coder plus tard, mais j'ai fini largement plus tôt que lui, et le programme répondait aux cahiers des charges que j'avais pris le soin d'écrire et de faire valider ! Au final, ils ont reconnu que ma façon de travailler était mieux que la leur (et c'était pas gagné au début !), donc même si on nous mets la pression pour aller vite, ne jamais négliger la conception, sinon tu ne perdras que plus de temps après !!!!!!!

[nebule]

Envoyé par Scorpyosis

sinon tu ne perdras que plus de temps après !!!!!!!

La phrase préférée d'un de mes profs de maths : "Prendre son temps c'est aller vite" ...

A méditer

[Hephaistos007]

Tu ne seras pas pénalisé par un mauvais planning si tu en tires les bonnes conclusions dans ton rapport. Si tu conclues que la phase d'analyse a été trop courte et qu'elle a impactée négativement sur le developpement du projet et qu'à l'avenir tu privilégieras cette phase, alors le but du stage est parfaitement atteint. Un stage est un coup d'essai duquel il faut tirer des enseignements. Et cela les enseignants le prenne en compte.