Cette charte guide l'équipe tech/produit (iTeam) dans ses choix et a vocation à informer l’équipe Frello sur le mode de fonctionnement adopté ; au-delà des simples concepts de sprints.
L'apprenant avant tout
La finalité de nos développements est et doit rester les apprenants (en dehors de fonctionnalités d’administration). Nos mises en place, notre tech, tout ce que l’on propose doit être pensé en se mettant à la place des apprenants.
Pour cela :
les maquettes proposées doivent faire preuve d’empathie pédagogique
dans son parcours d’apprentissage, l’apprenant ne doit jamais être mis face à une absurdité, par souci de gagner du temps sur du développement
un souci tout particulier sera accordé aux fonctionnalités d’apprentissage
les fonctionnalités côté enseignants devront avoir une finalité pour l’apprenant : meilleure gestion des classes = gain de temps, meilleur suivi apprenant
chaque membre de l’iTeam doit passer ½ journée minimum par trimestre au contact d’apprenants (on en est encore loin !).
Transparent
Ce qu’être transparent implique pour nous :
Informer sur les problèmes et bugs présents sur les différentes applications
Indiquer lorsqu’une erreur a été commise et comment nous allons la résoudre & à quelle échéance
Review : informer sur les tâches réalisées durant l’itération
Planning : informer sur la roadmap produit à court terme (prochaine itération) et sur la roadmap plus moyen terme (OKR)
Transverse
Avoir une vision transverse se traduit par :
Alignement OKR : les projets priorisés doivent être alignés avec la mission et les objectifs de Frello
Co-construction : les projets doivent être validés sur le principe auprès des responsables de département “métier” (Pédagogie, Sales, Suivi clients, IT). Avant de lancer le développement, ces responsables doivent valider la solution envisagée et apporter leur avis en fonction de l’impact que la fonctionnalité aura pour leur activité et Frello au global.
Feedback : sur la chaîne Slack “tech_product”, tout membre Frello peut partager des idées et du feedback. Les suggestions ne sont pas vues comme des critiques mais comme des informations constructives. Toute suggestion doit s’accompagner d’une raison, qu’elle soit d’ordre pédagogique, commercial, suivi client ou autre.
Documentation : dans la mesure du possible, les nouveautés doivent s’accompagner de documentation sur le centre d’aide public ou sur notre centre d’aide interne. Ces informations serviront à la communication en interne & auprès des clients de manière à faire gagner du temps à toute l’équipe
Progress over perfect
Notre objectif est de finaliser les développements lancés. Mais il faut aussi garder en tête qu’aucune fonctionnalité ou interface n’est jamais totalement terminée, elle sera toujours amenée à évoluer ; pour en améliorer le design ou ajouter une brique fonctionnelle, et toujours pour répondre aux besoins des utilisateurs.
Light but working : nous avons vocation à faire des mises en production régulières et fonctionnelles, toutes les 3 semaines. Les projets peuvent être améliorés (leur design par exemple) mais s’ils sont livrés, ils doivent fonctionner.
Focus : les suggestions de l’équipe ne modifient pas la roadmap à court terme. Quand un sprint est en cours, les seuls développements réalisés sont les projets définis dans le sprint. Sauf en cas de bug ; auquel cas le sprint peut être modifié pour répondre au problème (en fonction du niveau de sévérité du bug). Ex. si les drag & drop ne fonctionnaient plus, la résolution devient la priorité pour toute l’iTeam.
Finished : si un projet n’a pas été finalisé, il est décalé au sprint suivant, de manière à avoir des chantiers terminés et mis en production.
Pourquoi fonctionner en mode MVP ?
A chaque nouvelle fonctionnalité, son lot de bugs, d’aller-retours avec les équipes métiers. Ces complications ne sont pas forcément liées à un problème d’appréciation en amont ou à un manque de tests, ils peuvent aussi relever de la maintenance. Plus nous avons d’environnements à maintenir, plus il y a de complexité, de casse potentielle et donc de temps qui doit être dédié à maintenir une qualité de produit. Fonctionner en MVP permet de s’adapter rapidement, en forçant malgré tout à délivrer.
A notre stade de développement, Frello n’a pas les moyens d’avoir des ressources spécialisées en design et dédiées à ces problématiques, à temps plein.
Notre objectif est d’offrir des designs épurés pour proposer une expérience d’enseignement / apprentissage simple. Les informations de chaque page doivent être facilement accessibles.
Nous cherchons tout de même à progresser au fur et à mesure sur les aspects de design, notamment grâce à un designer qui fait du mécénat de compétences avec nous.
Nous souhaiterions allouer des ressources dédiées au design à partir du moment où nous aurons 1 personne dédiée au produit à temps plein, au moins 3 personnes sur le développement.
Ci-après quelques concepts de notre approche :
Material design inspired : on s'inspire de la librairie de composants material-ui créée par Google pour enrichir notre design system (exemple). L’objectif est :
d’unifier le style graphique de nos applications, peu importe le support
d’offrir des ressources déjà prêtes aux dev et aux designers d’interfaces
de gagner du temps en spécification : piocher plutôt que créer.
Component library approach : l’objectif est que lorsqu’on implémente un élément ou composant, il suffit de modifier ce composant pour mettre à jour toutes ses instances (gain de temps, réactivité). Ce n’est pas encore possible car nous avons plusieurs interfaces qui utilisent des technos différentes.
Orienté expériences d’apprentissage et d'enseignement : l’amélioration du design des interfaces d’apprentissage et d’enseignement prévaut sur le design de fonctionnalités d’administration. L’objectif est aussi de ne pas réinventer la roue : nous utilisons, dans la mesure du possible, ce qui existe déjà afin de gagner du temps sur des tâches à faible valeur ajoutée.
Priorisation
Répartition des tâches : en fonction des préférences tech de chacun et en fonction de l’historique. S’il faut améliorer une fonctionnalité existante, cette amélioration sera plutôt assignée à celui qui l’a dev.
En fonction des dispos de chacun. Puis le premier dispo prend le ticket le plus prioritaire.
Recettage
Idéalement, il nous faudrait une personne dans l’équipe dédiée au recettage pour vérifier la conformité des développements avec les spécifications. Sans cette phase de recettage (ou test), il est très compliqué de débusquer des bugs.
N’ayant pas cette ressource actuellement, nous procédons comme suit :
un premier recettage au sein de l’iTeam
un second recettage, délégué à l’équipe Frello : vers les personnes concernées
une troisième étape peut être lancée : l’implication de clients. Nous tentons ce mode de fonctionnement pour la première fois en 2021 avec la sortie de la school-admin.
Pour réduire les risques de bug et assurer un temps de recettage suffisant, les nouvelles fonctionnalités devront être recettées pendant une itération avant de passer en production et d’être dévoilées à nos clients.
Mise en production
Toutes les 3 semaines, une mise en production est faite (sorte de mise à jour). Les mises à jour sont faites le lundi soir, à partir de 18h ou 18h30. Si jamais une mise à jour n'est pas faite un lundi (ex. si elle n'a pas marché ou qu'un bug a été détecté peu de temps avant le créneau), nous nous laissons le droit de la faire le mercredi suivant en fin de journée. Si cela ne marche pas non plus, la mise en production est décalée au lundi suivant, et ainsi de suite.
Tous les environnements ne sont pas forcément mis à jour ; ça dépend des chantiers priorisés sur l’itération.
Par exemple, on peut mettre en production le module-viewer-web-app (les interfaces qu’on voit quand on fait des modules) sans mettre en production la main-web-app.
Pour en savoir plus sur les différents environnements, voir cette page.
Bêta tests
Pour les fonctionnalités importantes, nous proposons à des clients de bêta tester.
La définition des participants aux bêta tests est faite par l’équipe Sales (organisation des bêta tests Frello).
Les clients ont accès à la fonctionnalité pendant 3 semaines, ils ont une documentation de la fonctionnalité et un formulaire de satisfaction qui leur permet de s’exprimer sur notre réponse au besoin et leur permet de définir des pistes d’améliorations.
Documentation
Documenter les nouvelles fonctionnalités et les processus est chronophage mais peut créer de la valeur côté utilisateurs (en interne mais aussi pour nos clients).
Nous enrichissons au fur et à mesure notre centre d'aide ainsi que ce site d'onboarding pour indiquer les spécificités de chaque outil utilisé ainsi que les bonnes pratiques.
Toute nouvelle fonctionnalité est documentée.
Communication produit
Nous communiquerons à propos des améliorations et nouvelles fonctionnalités suivantes :
nouvelle fonctionnalité qui change l’usage des enseignants, administrateurs ou apprenants. Ex : la possibilité pour les enseignants d’afficher un programme en priorité dans une classe, nouvel outil de suivi de devoirs.
transformation et amélioration significative d’une fonctionnalité existante. Exemple : amélioration du processus d’inscription, changement des tableaux de bords, amélioration du front.
amélioration, même légère, d’une fonctionnalité liée à l’apprentissage : objectif, montrer que c’est notre focus, Frello est orienté apprenants.
amélioration peu significative d’une fonctionnalité existante, demandée par de nombreux clients.
Nous ne communiquons pas à propos des fonctionnalités suivantes :
améliorations peu significatives, continues, qui apportent de légers changements à la plateforme.
La communication se fera via mail pour les fonctionnalités les plus importantes. Le mail contiendra un lien vers notre site de statut Frello, qui détaillera les autres nouveautés.
Communication interne à propos des nouvelles fonctionnalités qui impliquent un changement de pratiques
Lorsqu’il y a un changement de pratiques (ex. formation des clients), les personnes concernées par le changement sont prévenues en amont. Elles ont au moins 3 semaines (une itération - le temps du bêta test) pour faire des modifications sur leurs supports / pratiques.
Gestion des bugs
La gestion des bugs est un aspect critique de nos missions. Nous suivons 3 étapes pour y répondre :
Qualifier 3 niveaux de bugs
Il est normal d’avoir des bugs, toutes les applications en ont, il faut déjà l’accepter.
L’enjeu est de les réduire bien sûr mais aussi de les qualifier en leur associant un niveau de criticité, qui entraînera une décision quant à la résolution et l’échéance de la résolution.
Trois critères de criticité :
l’importance de la fonctionnalité impactée
le niveau de gravité du bug
le nombre d’occurrences (ou la fréquence) du bug
Plus la fonctionnalité impactée s’approche des “core features” ; c’est-à-dire des fonctionnalités d’apprentissage et d’enseignement, plus le niveau de criticité augmente. S’il s’agit d’une fonctionnalité périphérique, le niveau de criticité diminue.
Nous avons défini 3 niveaux de criticité :
Critique
Intermédiaire
Mineur
Cas concrets & criticité
“Les sauts de ligne des contenus de texte ont tous disparu en production”
Importance : très élevée
Niveau de gravité : très élevé
Nombre d’occurrences : très important
⇒ Bug Critique car la fonctionnalité ne peut pas être utilisée et impacte tous les utilisateurs.
⇒ Criticité de niveau Intermédiaire : la fonctionnalité ne peut pas être utilisée directement mais un contournement est possible pour réaliser l’action
“Toutes les classes de l’école s’affichent dans la liste déroulante des classes gérées par le professeur”
Importance : faible
Niveau de gravité : faible
Nombre d’occurrences : très important
⇒ Criticité de niveau Mineur : la fonctionnalité peut être utilisée mais n’est pas tout à fait conforme à ce qui était prévu
Communication sur les bugs
Dans le cas d’un bug Critique
La résolution du bug devient la priorité absolue. Tous les développements en cours sont stoppés pour y répondre.
En interne
une personne de l’équipe indique le bug sur la chaîne Product en taggant @channel.
Si iTeam n'a pas mis un mot ou réagi sur slack dans les 3 minutes, alors passer un appel à JB (la personne qui a vu le bug) pour prévenir.
Sinon, un membre de l’iTeam indique qu’on a vu le bug et qu’on commence à investiguer. Si possible, proposition d’une solution alternative (ex. utiliser l’intégration).
Création d’une chaîne slack dédiée par membre iTeam, avec iTeam + 1 ou plusieurs personnes de Frello si besoin.
Si pas de solution à donner au bout de 20 minutes, copier coller le texte du ticket sur la page de statut Frello.
Côté clients
au bout de 20 minutes, création d’un petit widget (alert-widget) en bas à droite de l’écran pour informer tous les enseignants et administrateurs qui utilisent Frello. L’alert-widget permet aux utilisateurs d’entrer en contact avec l’équipe tech via mail, en cas de problème urgent.
Quand le bug est résolu, mise à jour du alert-widget pour informer les utilisateurs du retour à la normale. Envoi d’un mail aux clients qui nous ont contactés, pour les tenir au courant.
Dans le cas d’un bug Intermédiaire
L'apprentissage est gêné mais reste possible. Le problème n’impacte pas les typologies d’exercices.
Exemple : un enseignant ne peut plus assigner de devoirs, les recommandations ne fonctionnent pas, la barre d'avancement est bloquée, le site est lent.
Dans ce cas, la résolution du bug est reportée à la prochaine mise en production.
En interne
Message de l’iTeam sur la chaîne product du Slack Frello pour informer l’équipe.
Création d’un ticket par iTeam
Côté clients
Pas de communication par mail
Indication du problème sur frello, via alert-widget
indication a posteriori de l’information sur frello-status.
Dans le cas d’un bug Mineur
Dans le cas d’un bug Mineur, la résolution du bug peut être reportée à plus tard. Le bug concerne la conception pédagogique ou une fonctionnalité / page peu utilisée ou une fonctionnalité dont l’usage peut être contourné par une autre manière de faire.
En interne
Communication de l’information sur slack afin d’avertir l’équipe du problème qui peut être rencontré (en démo, en formation ou autre).
Création d’un ticket par iTeam
Côté clients
Pas de communication généralisée
Résoudre les bugs
Quand la décision a été prise de résoudre le problème, il faut pouvoir le reproduire : un bug ne peut être corrigé que s’il peut être reproduit.
D’où l’importance de rassembler dans un document unique les informations de contexte et les étapes nécessaires à la reproduction du bug.
En gros, les informations qui doivent ressortir sont :
Que s’est-il passé ?
Qu’aurait-il dû se passer ?
La réponse à ces deux questions permet de valider le bug, de le reproduire, de dénicher le problème et donc de le résoudre.
Pour homogénéiser les retours et gagner du temps, un formulaire de remontée d’information est disponible ici.
Sprint review : what went well, what needs improvement, next steps
Pondérer les features
Réfléchir la priorisation en fonction de la matrice (luxe, grande valeur…)
Des Bots pour remonter les commentaires des utilisateurs (pas prio)
Règle des 80/20
Outils de conception d’interfaces à benchmarker : figma, miro,
Formaliser les avancées pour avancer
Quand on est sur un ticket, le mettre dans le bon workflow GitLab, assigné à la bonne personne. Quand le ticket passe en Q&A, l'assigner à un PO.
En cas de problème en phase de Q&A : PO l'assigne au dev qui a fait le dev + met un commentaire expliquant ce qui ne fonctionne pas / pose question, en mettant le plus de contexte possible.
A chaque tâche son ticket
Quand on travaille sur une tâche qui n'était pas prévue dans le sprint, créer le ticket correspondant pour que la tâche entraîne un recettage et passe les mêmes étapes que n'importe quel développement.
Toute tâche ajoutée au sprint doit porter le label "offsprint" pour tracker le nombre de tâches non prévues qui sont finalement traitées.
Pas d'amélioration sans communication
Pour modifier un processus existant, il faut d'abord en parler en points FF ou demander un point dédié. Ne pas mettre en place de nouveaux processus sans que ça soit validé en équipe, sinon on perd en homogénéité, on ne parle plus des mêmes éléments.
Un grand chantier implique de grandes responsabilités
Pour les grands chantiers (ex. évaluations, school-admin...), prévoir un point de lancement pour valider le parcours, le design.
Normalement, cette validation est faite au fur et à mesure en points de spec focus.
Communiquer est mère de sûreté
En cas de bug impliquant plusieurs membres de l'équipe (PO & Dev), si une réunion a lieu entre seulement quelques membres impliqués, écrire un compte-rendu de la situation et des décisions prises pour tenir les autres au courant. Sans ça, on ne sait pas où en est l'équipe, ce qu'il en est de la résolution ; ce n'est pas agréable.
En cas de bug post-MEP :
récupérer les retours via la chaine tech_product (tout membre iteam doit être abonné et être notifié sur ce canal)
fonctionner en thread pour que les membres hors iteam ne soient notifiés que sur les threads
si gros bug => chaîne dédiée
sinon, on reste sur tech_product
Mieux vaut prévenir que guérir
Capitaliser sur les known issues : pour tout bug rencontré et non résolu, créer un ticket et le tagger en bug avec le bon niveau de sévérité.
Ne pas prendre à la légère les problèmes qu'on nous remonte ou qu'on voit. Jusqu'à maintenant, à chaque fois qu'il y a eu un bug qu'on ne comprenait pas, ça s'est traduit par un vrai bug plus tard. Tout bug latent non résolu est un problème à venir.
Laisser les testeurs tester et se tromper
En cas de test à faire réaliser par une équipe métier (ex. sur l'outil auteur), ne pas trop guider, leur laisser de l'autonomie dans les tests pour leur permettre de faire comme ils le feraient en situation réelle en production avec leurs habitudes.
Idéalement : leur donner un objectif (ex. créer une nouvelle version de module et la publier) sans trop leur dire comment faire.
a
a