JIs 2018 à Port-Bail du 1er au 4 octobre

La réunion précédente a permis de faire le point sur les contributions du LAL
Il y a actuellement 14 inscrits du LAL.
Tous les contributeurs n’ont pas encore reçu de retour des organisateurs pour savoir si leur contribution était acceptée.

Board-GitLab

Antoine présente le tableau de ticket (board) utilisé dans le contexte SVOM-MXT.
L’équipe est répartie dans plusieurs endroits, principalement au LAL et à Toulouse (CNES).
L’idée est de fournir une nouvelle version du logiciel, incomplet mais qui fonctionne, toutes les 2 à 4 semaines, en suivant la méthode agile Scrum.
Une seule liste de priorités est faite, nommée backlog.
Les jeux d’essais sont fait en internes par l’équipe, et les tests d’intégration sont fait par le responsable (CNES)

Une mêlée journalière est effectuée. Elle se fait d’habitude debout quand elle réunit tout le monde dans le même lieu. Dans le cas de SVOM, où mes développeurs sont géographiquement répartis, on utilise un outil externe : slack (l’outil Mattermost a été déployé au LAL pour test, et une instance framateam est disponible sur framasoft). Les questions qui sont posées dans ces mêlées sont brèves :

• qu’ais-je fait depuis hier ?
• que fais-je aujourd’hui ?
• quelles sont les difficultés auxquelles je me heurte ?

Slack est aussi utilisé pour les communications régulières entre membres de l’équipe.
Les tickets utilisent des étiquettes :

• 1, 3, 5, 10, 20, 40, 100 qui est le nombre de jours affecté à la tâche selon le temps nécessaire estimé, ordonné par durée croissante (de couleur verte) ;
• le type de tâche : bug et critical, de couleur rouge ; doc, de couleur jaune ;
• le nom de la colonne qui peut être à faire (to do), en cours  (doing) avec une couleur dédiée aussi, relecture (review), ou fait (done).

On décompose le projet en tâches au début.
Le backlog est ensuite mis à jour à tout moment.
Une colonne « review » demande la relecture par les autres développeurs, pour ensuite être basculée dans « done » ou « à faire » selon le résultat de la relecture.
En théorie, le responsable produit (product owner) est indépendant de l’équipe. Dans SVOM, il est membre de l’équipe et il arbitre les choix si besoin.
Le projet est décomposé en étapes (milestones), auxquelles sont affectuées les tâches.
Le déplacement d’une tâche d’une colonne à une autre change le label autiomatiquement, il n’y a a priori pas d’autre automatisation possible.
Julien indique que Github ne permet pas encore l’automatisation du changement de label sur changement de colonne, Philippe indique que kanboard permet une automatisation plus complète sur chaque action, y compris en intégrant des actions externes, c’est cependant moins simple qu’un outil intégré à une forge sociale comme GitLab.

La gestion des exigences se fait dans le wiki gitlab, pour alimenter l’outil Rectify du CNES, grâce à des balises XML. L’écriture se fait dans un clone de la branche master, et le test dans un fork personnel.
Le responsable scrum (scrum master) a pour tâche d’aider au fonctionnement de la méthode de développement SCRUM.

GSoC

2 étudiants ont échoué (pas du LAL!), c’est-à-dire que le mentor indique qu’ils ont abandonné le projet en cours : ils n’ont plus interagi avec eux ni envoyé de code.
Ce pourrait être dû à des difficultés techniques rencontrées.
La rémunération est versée mensuellement, ce qui maintient la motivation, et un des étudiants qui a abandonné avait pourtant validé la première partie sans souci.
Les mentors semblent tenter de trouver des solutions humaines lorsque des soucis apparaissent.

CHEP 2018

Michel, Guy, Hadrien et peut-être Grigory sont allés à CHEP à Sophia