72 lines
3.7 KiB
TeX
72 lines
3.7 KiB
TeX
\part*{Remerciements}
|
|
Je tiens particulièrement à remercier \\
|
|
|
|
\begin{itemize}
|
|
\item Vicent \textsc{Charvillat}, pour m'avoir donné l'occasion de faire un
|
|
stage intéressant, et pour toute l'aide qu'il a pu me fournir
|
|
\item Geraldine \textsc{Morin}, pour sa disponibilité
|
|
\item Axel \textsc{Carlier}, pour son aide sur les points plus techniques
|
|
\item Wei Tsang \textsc{Ooi}, pour ses suggestions souvent pertinentes
|
|
\end{itemize}
|
|
|
|
\paragraph{}
|
|
mais je me dois aussi de remercier \\
|
|
|
|
\begin{itemize}
|
|
\item Thierry \textsc{Malon} et Émilie \textsc{Jalras}, pour avoir joué le
|
|
rôle de canard en plastique \footnote{\emph{La méthode du canard en
|
|
plastique consiste à expliquer méticuleusement le code source que l'on
|
|
a écrit à un collègue, à un simple passant, ou même à un objet inanimé
|
|
comme un canard en plastique. Le simple fait d'exprimer ses pensées à
|
|
voix haute est censé aider à trouver les erreurs de programmation.
|
|
Comme les réactions de l'interlocuteur ou son niveau de compréhension
|
|
du problème n'ont aucune importance dans ce processus, on peut le
|
|
remplacer par un canard en plastique.} --- Contenu soumis à la licence
|
|
CC-BY-SA 3.0 (\url{http://creativecommons.org/licenses/by-sa/3.0/deed.fr})
|
|
Source : Article Méthode du canard en plastique de Wikipédia en
|
|
français
|
|
(\url{http://fr.wikipedia.org/wiki/M\%C3\%A9thode\_du\_canard\_en\_plastique})}.
|
|
et plus encore,
|
|
\item Julien \textsc{Fayer}, qui nous a accompagné durant les derniers mois
|
|
de nos stages
|
|
\item Bastien \textsc{Durix},
|
|
\item Vincent \textsc{Angladon},
|
|
\end{itemize}
|
|
|
|
\newpage
|
|
\part*{Conclusion}
|
|
Peu avant ce stage, nous avons eu le projet long qui nous a permi
|
|
d'expérimenter les projets d'envergure en groupe, et la façon dont on devait
|
|
les gérer.
|
|
|
|
\paragraph{}
|
|
Ce stage, pendant lequel j'ai développé le programme (\emph{plus ou moins})
|
|
seul m'a permi de compléter les expériences que j'avais eu lors du projet long.
|
|
En effet, la plupart des projets étudiants à l'ENSEEIHT sont de très petite
|
|
taille (si l'on devait passer 35h par semaine sur ces projets, je crois qu'il
|
|
n'y en aurait pas un qui durerait plus de trois jours), et on ne se rend en
|
|
fait pas compte que certaines des techniques de gestion de projet que nous
|
|
avons du mettre en application pendant le projet long sont tout aussi
|
|
importantes dans le cas d'un projet seul.
|
|
|
|
\paragraph{}
|
|
Dès nos premiers cours à l'ENSEEIHT, on nous enseignait l'importance des
|
|
commentaires qui rendaient compréhensible un programme à quelqu'un d'autre, ou
|
|
parfois, à soi-même mais dans le futur. Mais sur un projet de quelques jours,
|
|
il est évident que l'on comprendra toujours ce qu'on a fait avant. Cependant
|
|
dès que le projet devient suffisament important, on se rend compte qu'il est
|
|
impossible de maîtriser parfaitement le code d'un bout à l'autre, et que c'est
|
|
là que les commentaires prennent tout leur sens.
|
|
|
|
\paragraph{}
|
|
Ce projet a été très agréable pour moi, puisqu'il m'a permi de me consacrer à
|
|
temps plein, et pendant une longue durée, sur un programme qui part de zéro.
|
|
Lors d'un projet en groupe, ou d'un sous-projet qui permet de constituer une
|
|
brique d'un plus gros bâtiment, on peut ressentir la fierté d'avoir participé à
|
|
un si grand projet, mais il y a aussi cette sensation qu'au final, l'impact que
|
|
l'on a eu sur ce projet n'est pas si grande que ça. Lors d'un projet fait seul
|
|
(ou en petite équipe), et qui part de zéro, on voit le programme grandir au fur
|
|
et à mesure, ses fonctionnalités s'améliorer, ses bugs se corriger et de
|
|
nouveaux apparaître, et regarder le projet une fois terminé est nettement plus
|
|
flatteur pour l'ego.
|