The Hacking Final Project
Après 2 mois d’apprentissage intense et de réalisation de projets variés, nous y voilà… le projet final de THP. L’objet de cet article est de faire part de mon retour d’expérience aux futurs moussaillons et de transmettre quelques conseils avant de se lancer dans ce projet. Tout au long de la formation, les moussaillons ont été guidés par des cours, tutos, vidéos et autres bonnes astuces avec toujours la même consigne : « n’appliquez pas bêtement et essayez de comprendre ce que vous faites !». Avec le projet final cette consigne prend toute sa valeur.
La première étape du projet final : le mercato. Les équipes (4 à 6 moussaillons) ont 2 semaines pour se constituer autour d’un projet. Et comme au foot, les dernières heures sont agitées pour ceux qui n’ont pas encore trouvé chaussure à leur pied. Le projet final est un exercice d’équipe avant tout et les échecs sont plus souvent liés à des problèmes de fonctionnement au sein de l’équipe qu’à des lacunes en Ruby ou en css. D’où l’importance du mercato et de s’assurer que tous les membres de l’équipe 1) sont motivés pour travailler sur le projet choisi 2) ont des « compétences techniques » ou plutôt appétences complémentaires et 3) s’entendent bien. Ayant une bonne entente et une bonne complémentarité au sein de notre groupe de travail tout au long de la formation, nous avons décidé de poursuivre ensemble en choisissant un projet qui convienne à chacun. Pour les moussaillons porteurs de projets « réels », vous augmenterez vos chances de former l’équipe idéale en communiquant sur votre projet en amont de l’ouverture du mercato. Certains porteurs de projets de notre session ont malheureusement dû l’abandonner pour rejoindre d’autres groupes car n’ont pas pu réunir une équipe complète…
Une fois la dream team constituée, commence le vrai travail. Avant tout, il est nécessaire de passer du temps sur la définition d’un MVP raisonnablement accessible et de prioriser les fonctionnalités qui pourront ensuite être ajoutées en deuxième semaine. Les 9 semaines de formations THP permettent de voir de nombreuses gems et fonctionnalités qui permettent de bâtir un socle solide qui peut être complété par 2 ou 3 fonctionnalités non étudiées pendant THP. Une erreur commune (et que nous avons faite) est de sous-estimer le temps nécessaire à mettre en place une gem « structurante » ou une api que nous n’avons encore jamais testée, et pour lesquelles nous n’avons pas toujours des ressources aussi complètes et détaillées que celles proposées par THP. Cela est particulièrement vrai pour les groupes qui travaillent sur un projet « réel », en fonction du projet et de la complexité qu’il représente, il faut accepter de ne pas avoir le site « rêvé » au bout des 2 semaines mais plutôt envisager une version robuste qui pourra être complétée par la suite. Avant de se lancer dans le code, il est aussi indispensable de prendre le temps de chercher les bonnes ressources et le cas échéant d’adapter le MVP. Coté back, il s’agit bien entendu d’identifier les gems qui vont nous faciliter la tache et/ou les API qui vont rendre notre site interactif. Dans notre cas, nous étions prêts à coder un forum de conversation à la main quand nous avons découvert la gem Thredded ; autant dire que cela a profondément modifié notre plan de travail. Idem pour le front, le choix d’un template bootstrap le cas échéant et surtout la revue et le partage d’exemples de sites permettant de se faire une idée commune du style que l’on souhaite et trouver l’inspiration est un investissement dont vous tirerez les bénéfices tout au long des 2 semaines. En résumé, il est important de passer du temps sur la phase préparatoire, de mesurer la prise de risque dans un premier temps (MVP) avant si tout se passe bien d’ajouter des fonctionnalités plus funs.
Une autre difficulté du projet final est la répartition et la gestion du travail en équipe. Chacun chez THP dispose d’expériences et de qualités différentes mais quasiment tout le monde débute dans le monde du développement web. Ce manque d’expérience pose 3 problèmes essentiels dans la gestion du projet : la mesure du temps nécessaire à chaque tache, la répartition optimale des taches entre les membres de l’équipe et la prise de décision en cas de conflit au sein de l’équipe. Après avoir élaboré des « user stories » pour notre site, nous avons défini l’ensemble des tâches à réaliser et les avons réparties entre nous de manière un peu rapide sans bien anticiper toutes les corrélations entre les tâches et le fait que certains se retrouvaient bloqués en attendant le travail des autres. Attention donc à essayer de répartir au mieux les tâches afin d’éviter de trop perdre de temps, notamment au début du projet et à bien communiquer de manière très régulière sur où en est chacun pour réallouer les tâches si nécessaire et éviter les situations de blocage pour l’ensemble du groupe.
La question de la prise de décision est particulièrement sensible. La magie du code est que l’on peut arriver à des résultats identiques (ou similaires !) en empruntant des chemins très différents. La majorité du temps, les choix techniques se font assez facilement en évaluant les avantages et inconvénients de chaque option ou en se renseignant sur les bonnes pratiques. Mais il surgit parfois des conflits entre membres du groupe sur des choix techniques ayant des répercussions importantes. Contrairement au monde professionnel où il existe généralement un décideur (chef de projet, CTO, client etc.) dont l’autorité est acceptée, à défaut d’être forcément reconnue, un groupe de travail THP doit s’organiser pour prendre des décisions : soit en désignant un responsable en général si un membre du groupe a une légitimité technique supérieure aux autres soit en faisant jouer la démocratie au sein du groupe mais ce n’est pas toujours simple (notamment pour les groupes pairs !). Dans tous les cas, il est important que les choix techniques soient discutés et validés au sein du groupe notamment entre les personnes orientées front et back afin de responsabiliser chacun et d’éviter des tensions ultérieures.
Le dernier défi auquel nous avons été confrontés est la gestion du timing et l’adaptation de notre projet afin de respecter l’échéance. Comme déjà évoqué, le plus sûr est de commencer par une base solide que l’on complète progressivement avec de nouvelles fonctionnalités. Quand tout se déroule bien, il arrive cependant un moment où différents chantiers ont été lancés en parallèles avec une échéance qui se rapproche… et si dans la vie réelle les développeurs prennent parfois du retard 😉, pour un projet d’étude pas de délais supplémentaires ! Afin de présenter un projet « fini », nous avons été conduits à abandonner certaines fonctionnalités sur lesquelles nous avions commencé à travailler afin de réallouer nos ressources sur d’autres tâches plus urgentes. D’où l’importance de faire un point d’équipe tous les matins afin de valider le plan de travail et les priorités de chacun pour la journée.
En conclusion, le projet final THP est bien plus qu’une mise en pratique des connaissances acquises tout au long de la formation. La liberté donnée dans le choix des projets et la totale autonomie qui en découle impliquent de travailler de manière collective pour produire un résultat satisfaisant avec peu de marge de manœuvre en termes de temps.
