Retour sur les 6 semaines de sprint de groupe : défis d'architecture, dynamiques de collaboration et progression technique suite aux retours seniors.
Le mot de passe saisi sert à ouvrir, modifier et supprimer les commentaires secrets.
Aucun commentaire pour le moment.
Première chose à faire dès le 1er janvier : Écrire la rétrospective du sprint !
Après le sprint d'apprentissage de 10 semaines, le sprint de groupe de 6 semaines est passé en un clin d'œil. Comme il s'agissait de mon premier projet d'équipe depuis longtemps, j'étais très nerveux au début, mais j'ai pu vivre une expérience précieuse en rencontrant des coéquipiers talentueux et partageant les mêmes idées.
En abordant le sprint de groupe, je ressentais une pression énorme. Durant les phases de challenge et d'apprentissage, je n'avais jamais réussi à terminer complètement une tâche, et je m'inquiétais de ma capacité à suivre le rythme de mes coéquipiers sur la partie backend.
Heureusement, j'ai rencontré des coéquipiers qui étaient d'accord pour se concentrer sur le processus de collaboration lui-même plutôt que sur le résultat final. Nous avons vécu un sprint axé sur l'apprentissage mutuel et la compréhension du code de chacun.
Nous avons eu de longues discussions, du matin jusqu'à l'aube, pour concevoir et réviser ensemble chaque sujet. On peut débattre de l'efficacité de cette méthode, mais c'était une expérience significative dans la mesure où chaque membre partageait le même contexte et a pu s'exercer à expliquer les conflits techniques directement.
Bien que l'équipe soit composée de quatre aspirants développeurs frontend, le projet comportait une part importante de backend. Le rôle du frontend était principalement de présenter l'interface utilisateur (UI), tandis que la logique centrale était traitée côté serveur. Cela a rendu la phase de conception particulièrement difficile. Étant non-initié au domaine (de formation design) et manquant d'expérience en conception, les tâtonnements ont été fréquents.
Rétrospectivement, je pense que nous aurions pu éviter bien des détours si nous avions défini les exigences plus clairement au préalable et mis en œuvre une modularisation plus stricte. Néanmoins, avoir pu constater par moi-même quels choix de conception posaient problème et ce qu'il faudrait changer a été un gain majeur.
Pour le prochain projet, je souhaite investir davantage de temps dans la phase de conception initiale afin de bloquer les problèmes structurels, tels que les dépendances circulaires entre modules.
Ce projet exigeait des connaissances plus approfondies en informatique fondamentale (CS) que les précédents. Mon manque d'expérience en architecture et de compréhension en CS m'a laissé un sentiment de regret, car je n'ai pas pu contribuer aussi activement que je l'aurais souhaité aux discussions de l'équipe sur la conception.
L'équipe étant composée de développeurs frontend, nous avons accordé une grande importance non seulement à l'UI, mais aussi aux conventions générales : Lint, Prettier, GitHub Project, et les règles de Pull Request (PR). C'était un aspect que j'espérais voir bien respecté dans un projet d'équipe, et je suis satisfait que nous ayons pu établir ces standards efficacement.
En voyant d'autres équipes utiliser Husky ou GitHub Actions pour automatiser les commits, le linting et les tests, j'ai eu envie d'adopter ces outils lors du prochain projet afin de réduire la charge mentale de l'équipe.
J'ai été touché de voir que les organisateurs ont laissé des commentaires encourageants sur notre canal d'apprentissage CS. Durant ce sprint de groupe, le format des quiz CS est passé d'un rythme hebdomadaire à un cycle de trois semaines. Nous avons discuté en équipe de la manière d'exploiter ce changement :
En examinant les mêmes questions sous des angles différents chaque semaine, nous avons pu élargir notre réflexion et nous interroger naturellement sur l'intention derrière chaque quiz.
Bien que je regrette de ne pas avoir fait cet apprentissage avant la phase de conception, ce fut globalement une expérience très positive. Sans cet objectif clair, nous n'aurions probablement pas approfondi ces sujets autant.
Jusqu'au sprint précédent, j'étais tellement concentré sur l'implémentation que je négligeais la documentation. Cependant, j'ai réalisé dans ce projet d'équipe à quel point il est crucial que chaque membre puisse comprendre l'état d'avancement et s'y référer si besoin.
Nous avons documenté les comptes rendus de scrum, les procès-verbaux de réunion, les conventions et les détails des PR. Au début, nous utilisions principalement Notion.
Par la suite, en nous inspirant d'autres équipes, nous avons introduit les résumés via Notion AI et les rapports de décision d'architecture (ADR). Les ADR m'ont particulièrement impressionné par la clarté du contexte de décision qu'ils apportent, et je compte les utiliser activement dès le début de mon prochain projet.
Pendant la période de refactorisation, j'ai été chargé d'intégrer des fonctionnalités d'IA au projet et j'ai partagé cette expérience 링크 정보를 불러오는 중...
L'implémentation étant complexe, la rédaction a pris beaucoup de temps. On m'a fait remarquer que je devrais expliquer plus clairement le "Pourquoi" plutôt que le "Comment".
🤔 Réflexion
Je me demande encore comment produire une documentation qui soit à la fois concise et facile à comprendre dans son contexte.
Depuis mes années universitaires, j'ai toujours préféré résoudre les problèmes par de longues discussions collectives. Cependant, j'avais peur que cette méthode ne soit pesante si mes coéquipiers étaient de nature introvertie.
Heureusement, dans cette équipe, les longues réunions n'ont pas posé de problème majeur. Cela m'a néanmoins poussé à réfléchir à des modes de communication plus efficaces pour de futures collaborations avec des personnalités différentes.
Parmi les retours de mes coéquipiers, on m'a suggéré que lorsque je n'ai pas encore de conclusion en tête, il vaut mieux exprimer mon état d'esprit (ex: "Je suis en train de réfléchir" ou "Peu m'importe") plutôt que de rester silencieux. Bien que je sois moi-même quelqu'un qui s'inquiète du silence des autres, j'ai réalisé que j'avais manqué à cette règle à plusieurs reprises.
J'ai réaffirmé l'idée qu'une expression claire des intentions est nécessaire pour un projet d'équipe fluide et flexible.
Grâce à mon expérience des présentations à l'université, la préparation de la démo a été relativement simple. Mes coéquipiers ont participé activement et la création des supports s'est bien déroulée.
Cependant, au moment de rédiger le rapport final, j'ai regretté de ne pas avoir inclus plus de données chiffrées et quantitatives. D'autres équipes ont adopté des formats proches de rapports d'entreprise professionnels. Bien que notre équipe ait reçu des retours positifs lors de la Master Class, je pense que dans le domaine du développement, un rapport contenant des indicateurs quantitatifs est plus persuasif. S'entraîner à ce format sera sans aucun doute bénéfique pour la recherche d'emploi.
De plus, au fil des semaines, les tâches accomplies s'accumulaient sans que les autres équipes n'en aient connaissance. Je me suis demandé s'il valait mieux partager tout notre travail ou sélectionner les parties les plus percutantes. Malgré la préparation de questions précises pour obtenir du feedback, nous n'avons pas toujours reçu les réponses espérées. Cela m'a amené à penser que nous n'avions peut-être pas partagé le contexte du problème assez clairement.
Jusqu'à présent, je percevais la refactorisation principalement comme du nettoyage de code : suppression des doublons, séparation des composants (SRP), et amélioration de l'accessibilité. Cependant, en voyant les démos des autres équipes, j'ai remarqué que leur refactorisation portait souvent sur l'optimisation des performances.
Pendant ces deux semaines, nous nous sommes souvent demandé : "Que voulons-nous retirer de ce processus ?" Notre équipe ayant déjà de bonnes conventions et revues de code, il y avait peu de problèmes structurels ou de style. En revanche, dans d'autres projets, il y avait beaucoup de marge pour améliorer la cohérence et la réutilisabilité.
Ce travail est significatif sur le long terme, mais difficile à quantifier en seulement deux semaines. Finalement, après une phase initiale de nettoyage structurel, nous avons pivoté vers des tâches apportant un apprentissage concret et des résultats visibles pour nous.
Bien que la règle de base de la refactorisation soit d'améliorer le code sans modifier la logique, notre équipe a choisi de compléter la conception inaboutie du projet précédent en ajoutant quelques fonctionnalités. Ce fut une expérience de choix pour augmenter la qualité globale du projet dans un temps limité.
À la fin de la refactorisation, nous avons eu la chance de recevoir un feedback de la part d'un senior. J'ai résumé nos problèmes et doutes dans un document avant d'aborder la séance avec appréhension.
Cette session m'a fait réaliser que si je sais identifier les situations problématiques, je manque de capacité à les expliquer avec précision en utilisant des termes techniques. Mes explications de résolution de problèmes tendaient à être abstraites et manquaient de spécificité professionnelle.
C'est sur la conception et les bases informatiques (CS) que je me sentais le plus faible, et le fait que cela soit souligné par un senior a été à la fois déstabilisant et éclairant. Cela a clarifié ce que je dois apprendre à l'avenir. J'ai ressenti le besoin impérieux de m'exercer à expliquer mes décisions et mes processus de manière logique, en m'appuyant sur un vocabulaire technique commun.
Cette session portait davantage sur les préoccupations de projet d'équipe et les orientations d'apprentissage personnel. En voyant d'autres participants échanger sur des points techniques profonds, j'ai senti que je devais redoubler d'efforts. Même si je n'aurais pas pu répondre à de telles questions aujourd'hui, mon objectif est de devenir un développeur capable d'expliquer avec assurance non seulement le frontend, mais aussi divers domaines technologiques.
En me basant sur les lacunes identifiées, je compte approfondir mes compétences en conception en choisissant des ouvrages spécialisés. Jusqu'ici, les cours universitaires me laissaient peu de temps, mais je peux désormais me consacrer entièrement au Boostcamp. Je vais combler ces lacunes de manière systématique chaque semaine.
Pendant le projet, j'ai souvent travaillé tard pour ne pas être un fardeau pour l'équipe. Cependant, j'ai réalisé que cela nuisait à ma concentration en journée et à l'efficacité globale. Si je pouvais tenir pendant la phase de 'Challenge', j'ai vu que pendant la phase 'Membership', l'épuisement de la veille impactait directement la collaboration du lendemain. Je veux trouver un mode de travail durable, alliant contribution à l'équipe et équilibre de vie.
Ces 6 semaines en équipe ont été à la fois longues et très rapides. J'ai pu ressentir ce qui me manquait et comment m'améliorer pour devenir un coéquipier avec qui l'on a envie de travailler. Je n'oublierai pas les leçons de cette rétrospective pour ma croissance future. Merci aux membres de l'équipe F4 Team 7 de m'avoir guidé et d'avoir grandi avec moi.
