NAVER Boostcamp Web·Mobile 10 — Rétrospective du projet de groupe (Semaines 1 à 3)

링크 정보를 불러오는 중...

Le week-end de la troisième semaine de projet touche à sa fin. Initialement, je comptais écrire une rétrospective finale à la fin du projet, mais les articles des autres participants partageant leurs bilans hebdomadaires m'ont tellement aidé que j'ai décidé de laisser un témoignage à mi-parcours.

Voici le déroulement du projet jusqu'à présent :

• Semaine 1 : Team building et planification
• Semaine 2 : Création du prototype et revue senior
• Semaine 3 : Conception du backlog et implémentation du MVP

Semaine 1 — Team Building et Planification

Premier jour : Rencontre avec l'équipe

Le premier jour a été consacré aux présentations. Nous avons créé le dépôt et effectué les configurations de base, mais comme d'autres sessions occupaient la journée, nous nous sommes limités à des salutations et à une direction générale, remettant le choix définitif du sujet au lendemain.

Deuxième jour : Sélection de l'idée

Chacun a partagé ses idées. J'en avais préparé quatre, mais la plupart étaient ambiguës pour les raisons suivantes :

• Plus adaptées à une startup qu'à un projet de Boostcamp.
• Déjà réalisées avec une grande qualité dans d'autres camps.
• Sujets trop complexes rendant l'aboutissement incertain dès la conception.
• Plus adaptées à une application mobile qu'au web.

Avec l'abondance de services existants, j'ai réalisé qu'il est de plus en plus difficile de choisir un sujet de projet original.

Ce que je voulais pour cette période, c'était créer un service utile avec de vrais utilisateurs, mais aussi expérimenter un projet permettant des "tentatives audacieuses". Je ne voulais pas d'un projet qui se termine sans sens après l'implémentation ; je cherchais une direction satisfaisant ces deux critères.

Une seule de mes idées initiales remplissait ces conditions. Le thème et l'extensibilité étaient bons, mais j'avais peur qu'elle soit trop simple pour les capacités de notre équipe sur un mois de travail. Finalement, pendant une pause, une nouvelle idée a surgi et mes coéquipiers y ont réagi positivement.

En m'inspirant de deux applications que j'utilise fréquemment, j'ai recombiné des mots-clés et des contextes pour notre situation. Sur cette base, nous avons étendu et organisé l'idée selon les documents fournis et finalisé le sujet. Ce n'est pas un service totalement révolutionnaire, mais c'est un choix en accord avec les objectifs de chacun, et tout le monde en est satisfait.

Troisième jour : Définition des conventions

링크 정보를 불러오는 중...

Nous nous sommes concentrés sur les conventions. En nous basant sur les méthodes de mes sprints précédents et les avantages/inconvénients ressentis, j'ai proposé un brouillon que nous avons affiné ensemble.

Nous avons organisé tout cela sur le Wiki de l'équipe, ce qui fut un excellent choix dès la première semaine pour la gestion documentaire. Nous avons aussi introduit Husky pour automatiser les tests de conventions et de linting avant chaque PR, ce qui s'est avéré très efficace pour maintenir la qualité du code.

Quatrième jour : Feedback inter-équipes

Nous avons eu une session de démo et de feedback avec les autres équipes. Leurs retours nous ont permis de pointer des perspectives utilisateurs que nous n'avions pas envisagées. Personnellement, je pensais avoir bien défini ma cible, mais le point de vue des utilisateurs réels a montré qu'il y avait encore de la marge pour affiner le ciblage et assurer une expansion solide.

Bilan Semaine 1

Points positifs :

• Bonne ambiance d'équipe, intégration rapide.
• Flux fluide entre sélection de l'idée, planification et conventions.
• Effort pour refléter toutes les opinions.

Points à améliorer :

• J'aurais dû préparer plus d'idées dès le début. Le temps passé avant que l'idée finale ne surgisse me laisse un petit regret.

Semaine 2 — Prototype et Revue Senior

Implémentation du prototype

Pendant la deuxième semaine, je me suis concentré sur l'implémentation du prototype basé sur mes designs et j'ai préparé un document de synthèse pour le feedback senior.

J'ai utilisé Figma Make pour la première fois et j'ai été bluffé par la qualité. Auparavant, je designais chaque écran manuellement, mais là, j'ai obtenu des résultats bien structurés en React et Tailwind.

J'ai même pensé un instant : "Le métier de développeur frontend est-il encore nécessaire ?". Cependant, pour les parties ne correspondant pas à mes attentes, j'ai d'abord établi un guide visuel avec Gemini, puis je suis passé par Figma Make avant de faire mes propres ajustements. Pour aller vite, j'ai utilisé Cursor AI, ce qui fut très efficace pour transformer rapidement des idées en formes visibles.

Première rencontre en présentiel

Nous nous sommes réunis physiquement pour la première fois. Habitué à la collaboration en ligne, je n'en ressentais pas forcément le besoin, mais j'ai constaté qu'un travail prenant 5 heures en ligne pouvait être bouclé en 2 heures en présentiel. La concentration et la vitesse sont incomparables.

Feedback Senior

Le point central du feedback senior fut : "Le plan global est encore trop flou."

Nous pensions avoir assez discuté, mais il s'est avéré que les priorités et les directions d'implémentation de chaque membre divergeaient. Up jusqu'à présent, nous nous concentrions sur la qualité des quiz CS et les pages de base (Accueil, Quiz, Explications, Profil, Paramètres). Pour nous, la qualité des questions faisait la crédibilité du service.

Cependant, le senior nous a dit :
"On dirait que vous choisissez la facilité en ne prenant que ce que vous savez implémenter."
Ce n'était pas un reproche sur les fonctions de base, mais une remarque sur le fait que notre focus actuel ne nous différenciait pas assez des services existants et semblait peu ambitieux pour nos capacités.

C'est une question que je me posais aussi : choisissions-nous des fonctions faciles au détriment du potentiel de l'équipe ? Le senior nous a conseillé de trouver un "Wow Point" — quelque chose d'attractif et techniquement stimulant, même si ce n'est pas "indispensable".

Plutôt que de faire un profil ou des réglages (que l'on peut faire plus tard), il vaut mieux s'attaquer aux défis techniques complexes tant que l'énergie est haute. Personnellement, je pensais à l'utilisation de personnages. C'est un domaine qui me passionne (venant du design), mais j'hésitais à y investir du temps. Le feedback senior m'a encouragé : si c'est notre facteur de différenciation, il faut l'exploiter. Même s'ils ne sont pas "essentiels", ils servent à distinguer le service et à élever le niveau de défi de l'équipe.

Bilan Semaine 2

Points positifs :

• Réalisation du prototype pour la démo.
• Documentation détaillée des exigences fonctionnelles.
• Renforcement de la cohésion d'équipe en présentiel.

Points à améliorer :

• J'ai fait presque tout le design et le prototype seul. J'ai peur d'avoir privé mes coéquipiers d'une opportunité d'apprentissage.
• J'ai voulu aller trop vite sur le prototype, ce qui a causé des retouches et fait attendre l'équipe.
• Besoin de mieux documenter les réunions (scripts Huddle, résumés IA).

Intermission

Je n'ai pas eu autant de temps que prévu pendant l'intermission à cause de divers engagements. Difficile d'étudier en profondeur.

Heureusement, j'ai pu suivre un cours sur Three.js. Transformer en code ce que je ne voyais que sur Blender était une expérience très fraîche. Comme c'est mon domaine, j'ai investi du temps pour essayer de donner forme à des personnages 2D et 3D pour les montrer à l'équipe. En voyant le dynamisme des autres équipes sur Slack, j'ai réalisé ma chance d'être ici et cela m'a motivé à travailler plus dur.

Semaine 3 — Backlog et MVP

Redéfinition de la direction

En début de semaine 3, il a fallu se remettre dans le bain. Nous avons réajusté la direction du projet en synthétisant les feedbacks et clarifié les priorités. J'ai proposé d'organiser le système de récompenses pour que tout le monde ait la même vision de la structure du service.

J'ai aussi introduit la gestion des scripts de Slack Huddle pour garder une trace des discussions, ce qui a grandement facilité le suivi du contexte.

Implémentation du MVP

Nous avons passé deux jours à implémenter les priorités du MVP. C'était ma première expérience d'utilisation active de tests et de Storybook ; c'était un peu déroutant mais fascinant.

Personnellement, j'ai encore constaté que mes commits dans une seule PR sont trop volumineux. Je mélange souvent refactoring et petites corrections diverses. Je dois apprendre à rendre mes PR plus concises et ciblées. La division des tickets (issues) reste aussi un dilemme : trop diviser coupe le contexte, trop fusionner alourdit la PR.

Intégration, déploiement et démo

Le dernier jour, nous avons lié le frontend et le backend. Beaucoup de problèmes sont survenus juste avant la démo, nous obligeant à travailler jusqu'à une minute avant le début. J'étais très nerveux et ma présentation ne m'a pas satisfait. J'ai été déstabilisé par un problème d'écran et le flux n'était pas fluide. C'est un grand regret.

Perspectives après la Semaine 3

Pour la suite, je veux améliorer :

• La finesse de priorisation du backlog.
• La gestion du planning calculée à rebours de la démo.
• Une préparation de démo stable, pas dans le rush final.

Questions en suspens :

• Comment mieux partager les apprentissages individuels.
• Comment mieux comprendre le code backend.
• Comment quantifier les exigences et les expliquer plus clairement.

Après avoir vu un projet d'équipe s'effondrer par le passé, je tiens absolument à mener celui-ci jusqu'à un résultat complet et réussi.

• #Rétrospective
• #Naver Boostcamp