Résumé coaching 6.b

ORGANISATION DU GROUPE [A COMPLETER CI-DESSOUS]
+ Le groupe présente sur le wiki la manière dont le groupe s'organise : planification des échanges et rencontres, déroulement et timing des réunions et séances de travail, outils de communication utilisés, …
+ Le groupe applique au quotidien l'organisation décrite dans le wiki
+ L'ambiance est bonne dans le groupe et chacun a l'occasion de s'exprimer et de s'investir.

WIKI ET COACHING [A VERIFIER]
+ Le wiki est correctement complété au fur et à mesure
+ Les coachings sont bien préparés à l'avance, pour rapidement présenter les points prioritaires du jour et poser les bonnes questions
+ Le fichier de suivi est bien complété par tous les membres du groupe avant chaque coaching
+ La bibliographie est bien présentée, présente des liens intéressants et montre que les étudiants se sont bien documentés. 
+ Les ressources sont directement référencées dans le texte lorsque cela fait sens. 
+ Le groupe n'attend pas : s'il a des questions techniques, il les pose d'abord directement sur le chat.

GIT [A VERIFIER]
+ Le groupe applique concrètement le workflow git prévu

GESTIONNAIRE DE TACHES [A COMPLETER CI-DESSOUS ET VERIFIER]
+ Les colonnes du gestionnaire de tâches sont appropriées (Backlog, todo, doing, to review, Done...)
+ Les tâches dans le gestionnaire sont appropriées et dans le bon état
+ Chacun s'assigne lui-même ses tâches et les place dans les bonnes colonnes.
+ Tout travail réalisé par un étudiant se trouve bien en tant que tâche dans le gestionnaire.
+ On peut facilement faire la différence entre les US et les tâches techniques ou autres.

TEMPS [A VERIFIER]
+ Pour ce projet il est possible de savoir combien de temps a été passé sur quelles parties du projet (backend, DB, API, frontend, test, analyse, + + + réunion, formation, rédaction, ...)
+ Il est possible de savoir combien de temps chaque membre a travaillé sur le projet.

OUTILS communication, développement, partage et autres [A COMPLETER CI-DESSOUS]
+ Le groupe présente les outils qu'il utilise pour communiquer, partager des fichiers, assurer les réunions, etc…
+ Le groupe présente les outils qu'il utilise pour développer
+ Le groupe présente éventuellement d'autres outils utilisés et présente leur utilisation

QUALITE DU CODE [A COMPLETER CI-DESSOUS]
+ Un linter est connu, utilisé et maitrisé
+ Une convention de codage a été définie et documentée sur le wiki
+ Le code respecte la convention de codage, le style est uniforme
+ Le code respecte les bonnes pratiques de programmation (nommage des variables, limitation du niveau d'imbrication, etc.)
+ Le code est adéquatement documenté, éventuellement selon la programmation par contrat (pré/post conditions)
+ Le code est lisible et facilement compréhensible par un développeur non impliqué dans le projet
+ Le groupe a mis en place des reviews de code systématiques et peut le démontrer

1. Organisation du groupe

[Présentation de la manière dont votre groupe s'organise : réunions, communications, planification...]

Notre organisation n'est pas fixe mais nous tachons de communiquer le plus souvent entre nous, que ce soit depuis chez nous ou à l'EPHEC. Nous planifions les tâches à réaliser pour chaque semaine afin que chacun d'entre nous sache les priorités à aborder.

2. Ambiance dans le groupe

[Est-ce que tout se passe bien ? Quels problèmes avez-vous rencontrés ? Comment le avez-vous résolus ? Est-ce que tout le monde a l'impression que le groupe est suffisamment organisé ? Que les autres travaillent suffisamment ? Sinon, quelles solutions aimeriez-vous mettre en place ?]

Il y a une bonne cohésion de groupe, les tâches sont réparties/assignées à chacun. Il a fallu, quelquefois, rappeler les deadlines, néanmoins, après un rappel, les choses étaient réglées. Dans l'ensemble, tout le monde a participé de manière active et autant que nécessaire. Une bonne pratique que nous aurions pu mettre en place aurait été d'organiser des réunions plus régulières, afin de s'assurer que les choses ne soient pas faites à la dernière minute, ou pour voir si certains d'entre nous rencontraient des difficultés.

3. Outils utilisés

3.1 Gestionnaire de tâches

[Explication de comment vous avez organisé votre gestionnaire de tâches. Si vous changez en cours de route, expliquez quoi et pourquoi]

Pour répartir les tâches, des listes étaient affichées en Markdown dans notre serveur Discord et épinglées pour indiquer quelles tâches chacun devait réaliser pour la semaine suivante.

Nous utilisions aussi GitHub Projects pour nous répartir les tâches. Nous créions des issues lorsque nous avions soit des idées de modifications, soit des bugs à corriger. Chacun de nous s'assignait aux issues relatives à la partie à travailler.

3.2 Gestionnaire de temps

Pour gérer le temps, nous n'utilisions pas d'outils en particulier. Nous nous fixions des deadlines pour chaque fonctionnalité à ajouter au projet, et nous nous y tenions.

3.3 Outils de communication et de partage

Pour communiquer, nous utilisions Discord, dans un serveur créé par nos soins et réparti en parties claires et précises pour ne pas trop mélanger les informations.

3.4 Outils de développement

[IDE, extensions, test, etc...]

Selon les préférences, chacun utilise l’éditeur de code de son choix. Par exemple, certains d’entre nous préfèrent utiliser Vim, d’autres préfèrent utiliser VSCode. Le projet a été intégré dès les premières semaines dans des conteneurs Docker, ce qui a grandement facilité le développement. Pour ce qui est des push et commit sur GitHub, nous utilisions tous les commandes Git depuis le terminal la plupart du temps, et certains les utilisaient directement depuis VSCode.

3.5 Autres outils

[Quels autres outils ont été utilisés? Pourquoi?]

/

4. Qualité du code

[Explication des conventions de codage, description des outils de "linting" et de tout ce qui a été mis en place pour s'assurer de la qualité du code produit.]

Nous n'avons pas de conventions de codage à proprement parler, néanmoins, nous essayons de maintenir une certaine conformité et homogénéité dans le code, en ne modifiant pas trop les standards que nous utilisons (par exemple, l’utilisation de const pour créer une fonction en TypeScript).