Réunion Sprints Dev SemApps 29 janvier 2021

Review

Mathilde a fait une démo de son exercice React d'affichage d'utilisateurs Archipel
Sébastien a fait une démo du futur menu hiérarchique sur Archipel

râlages
- Pas a l'aise avec cet exercice. J'aime parler de ce qui ne va pas au moment où ça ne va pas.
- Je n'aime pas devoir repondre à ce type de question à un moment où je ne suis pas prêt pour ca.
  - Ok pour faire un retour sur ce qui ne va pas dans ces réunions de sprint, mais que les idées peuvent être stoquées à tout moment de la semaine.
- Invitation à l'auto-responsablilisation pour dire ce qui ne vas pas et demander de l'aide.
- Je n'ai pas assez de temps personnel pour avancer sur Semapps et les tâches qui me sont affectées (chiffrage carto dans Semapps).
- Aimerait participer à la montée en compétence des nouveaux, mais pour ça, il faudrait que je sois moi-même formé :)
régalages
- Je trouve cool de voir les mêmes têtes en réunion
- entre-aide, à la fois entre les nouveaux et entre certains anciens et certains nouveaux

marche pas
- beaucup de canaux de communication et beaucoup de personne travaillent sur plusieurs projets : certaines question restent sans réponse alors que je suis bloqué.
- être seul avec mon ordi chez moi.
marche
- des locaux utiliseable. super de se voir en présentiel
- j'apprends beaucoup et je suis contente de ca.

marche pas
- probleme de migration : breacking change. pas de systeme de versionning sufisament avancé.
- tests automatiques insuffisants pour éviter les regressions (casser du code existant)
- difficile de ne pas avoir de daily meeting pour savoir qui fait quoi
marche
- la gestion des sprint se met en place et semble fonctionner
- contribution exterieur
- pair programming : toujours plus sympa que prévu, il faut en faire plus souvent

marche
- j'aime beaucoup les point de 15H le lundi pour les débutants et expliciter les technos

marche
- Régularité des réunions, process des sprints qui a l'air de fonctionner
- Maintenance, bugs ont été corrigés. On va pouvoir faire de la "peinture sèche". Réfléchir en release, milestone, versions stables.
marche pas
- breaking changes mal gérés

Décisions

Matérialiser les breaking changes par des numéros de version mineur : 0.X.0
- Voir comment faire sur Github pour noter les breaking changes directement sur les releases https://github.com/assemblee-virtuelle/semapps/releases (ne faire ça que pour les releases 0.X.0 dans un premier temps ?)
- Attention à regrouper les breaking changes et à attendre un peu avant de les intégrer, afin que le numéro de version n'augmente pas trop vite.
Faire quelques nouveaux tests à chaque sprint, se responsabiliser collectivement là-dessus.
Prevenir sur le salon SemApps-Dev quand un commence ou continue une tâche, afin que tout le monde sache ce qui avance.
Imaginer / trouver un rythme pour se retrouver en physique
- Capucine est responsable de proposer quelque chose de ce côté.

Pistes à explorer pour la usite

Lors du développement d'une nouvelle fonctionnalité, obligation d'ajouter des tests

Voir kanban : https://github.com/assemblee-virtuelle/semapps/projects/3
Sébastien va demander à Guillaume de trouver une classe à ajouter à ajouter à Archipel, pour que Capucine puisse le faire.