-
Notifications
You must be signed in to change notification settings - Fork 62
Réunion d'équipe août 2018
Il n'y a pas encore d'endroit particulier pour ces journaux, donc temporairement ils seront ici.
Première véritable réunion d'équipe, dans laquelle nous avions besoin d'évoquer les constats que nous partagions depuis quelque temps. L'objectif des suivantes, en plus de leur ordre du jour, sera de critiquer les engagements pris dans la session précédente.
- Livrer désormais tous les trimestres (prochain livrable en octobre)
- Réunir l’équipe au moins une fois par livrable
- Communiquer davantage via le blog sur le métier, le technique, l’humain
- Adapter docker à la production
- Présenter des contributions simples, peu engageantes et à valeur ajoutée (ex : animation de la communauté, test, traduction)
- Réaliser la connexion LDAP dans l’API
- Échanger davantage par mail pour ne pas bloquer la communication en cas de non synchronicité
- Mettre en place et proposer PHPback comme système de ticketing
- Automatiser le déploiement de
developsur la demo - Réaliser des tests automatisés
La première des choses que nous avons évoquées est que puisque nous avons des disponibilités aléatoires, remplir un backlog fixe et réaliser tous les développements pour livrer une nouvelle version n’est pas la meilleure approche. Nous estimons que nous avons un problème de surcharge de travail et sortir les versions à fréquence fixe nous organiserait davantage. Nous avions essayé un rythme d’un mois mais ce ne fut pas tenable. Nous allons désormais tester une fréquence de 3 mois. Ce qui ne sera pas prêt à ce moment-là sera reporté. Afin de montrer ce fait et donner une vision aux utilisateurs, nous proposons de changer la nomenclature des versions après avoir vérifié sa faisabilité (ex : 18.1 pour le premier livrable de 2018).
Avoir un rendez-vous officiel où nous discuterons des points d’amélioration, de ce qui s’est mal ou bien passé pour paraît utile. Nous la calerons sur la fréquence de sortie des versions.
Par manque de temps (et probablement aussi par goût), nous n’accordons pas assez d’amour à la communication. C’est pourtant essentiel : il faut accorder du temps à la communication, que ce soit au rythme des sorties comme nous le faisons déjà, ou via des articles sur le métier, la vie de l’appli ou même sur les personnes qui font LT. Bref, des articles plus fréquents. Il s’agit d’exprimer ce que nous faisons et comment ; c’est un bon moyen de susciter l’adhésion à la communauté et donner envie de participer à l’aventure, sous un manière ou un autre. Parler de l'équipe aussi mettra en lumière les personnes et les succès.
Organisation conflictuelle entre le backlog et les fonctionnalités / bugs qui remontent des utilisateurs
Nombre de tickets pourrissent dans les méandres de Github, soit parce que nous n’y avons pas répondu à l’instant T et l’utilisateur ne répond plus quelques mois après, soit parce que les utilisateurs ne sont pas confortables avec l’outil Github, l’utilisent de la mauvaise manière et nous rendent aveugles. Notre manque de réactivité est dû à un besoin d’étude du code et de documentation métier pour rédiger une fonctionnalité soutenant une demande métier, tout en tenant compte des particularités de chacun et de la loi.
À ce jour, docker n’est qu’un outil de développement. Fort du constat que trop de défauts ou questions arrivent sur la pile logicielle ou l'installation, nous souhaiterions rendre docker « prêt à la production » pour ne plus avoir à répondre à ces questions en fixant la pile logicielle, livrant ainsi Libertempo clé en main. Un avantage de cette pratique est qu’alors, nous pourrons réaliser des tests automatisés de bout en bout.
Ce qui est beaucoup ressorti de nos échanges est le manque de bras. Que ce soit de la communication, du développement, de l’étude à long terme ou du support, nous manquons de personnes. Puisqu’il est difficile de trouver des développeurs (habituellement, ils participent à un logiciel qu’ils utilisent eux-mêmes), il serait préférable de communiquer sur notre besoin de personnes qui seraient en charge du test, de la communication, de l’animation et / ou qui ferait office de niveau 1 : gestion des demandes et proactions métiers.
Nous avons un sujet en suspens à propos de la compatibilité de l’API avec des connecteurs tiers. Les spécifications sont en cours de rédaction pour mettre en place les jalons nécessaires à la réalisation de la totalité de la fonctionnalité, mais la priorité est la création du connecteur LDAP, au vu de la popularité de ce moyen de connexion chez nos utilisateurs. Notre souhait est qu’Akhaten ne sorte pas sans la mise en place de LDAP dans l’API.
Nos disponibilités sont de plus en plus aléatoires, il devient difficile de synchroniser les présences pour communiquer et par suite de s’organiser. À ce jour, notre moyen de communication privilégié est IRC. Nous proposons soit de passer par un full mail, soit de trouver un chat asynchrone. Un nouveau chat devra remplir le cahier des charges :
- asynchrone,
- facilité d’utilisation pour les utilisateurs,
- informel.
Ce présent rapport énonce quelques changements conséquents, aussi nous commencerons par le mail simple, et nous aviserons. Ça aura de plus l’avantage de vérifier la pertinence des autres moyens de communication externe.
Les utilisateurs ont du mal avec Github :
- c’est un outil dédié aux développements, ils ne sont pas naturellement à l’aise avec l’outil,
- dû à notre manque de réactivité immédiate, ils ne reviennent pas quand nous avons des questions. Nous nous retrouvons ainsi dans l’incapacité de résoudre le bug ou discuter de la demande d’amélioration,
- il leur arrive de mettre plusieurs demandes en même temps, réduisant notre capacité à traiter les tickets correctement,
- le rédactionnel n’est pas respecté,
- il y a beaucoup de duplicata,
- il ne nous est pas possible en l’état de hiérarchiser les demandes.
Nous proposons alors de fermer la porte de Github aux utilisateurs normaux et d’en ouvrir une sur un outil de gestion de ticket de type uservoice, ou une version libre. Cet outil a pour principale fonctionnalité de rédiger des rapports de bugs ou des demandes de fonctionnalités / améliorations, mais vient avec un système de vote. Plus simple pour les utilisateurs, hiérarchisant, notre objectif est qu’à terme il remplace Github pour la gestion des tickets. Dans un premier temps, nous pouvons proposer les deux en parallèle et voir si le procédé correspond aux besoins de communication des utilisateurs. Cet outil associé à une livraison à fréquence fixe pourrait mener à la disparition du backlog tel qu’il existe actuellement, et nous baserons ainsi nos développements sur les priorités uservoice et un livrable mensuel (nous conserverons malgré tout un veto).
L’utilité de la beta est tributaire du test fait par les utilisateurs, mais elle n’est pas couverte parfaitement et nous nous sommes retrouvés avec des bugs conséquents sur master avec une urgence de résolution accrue, urgence à laquelle nous ne pouvons pas répondre. La faire durer plus longtemps n’est pas une option, car ce n’est pas la durée qui est en cause, c’est un problème humain : les utilisateurs testent peu la beta. De ce fait, puisqu’il s’agit d’un constat de régression et de vérification de correction de fonctionnalité, nous pouvons chercher la solution selon trois orientations :
- créer des tests automatisés à l’opportunité, calés sur le principe de la pyramide du même nom,
- automatiser le déploiement de
developsur la démo, les défauts seront ainsi découverts plus tôt (Rollbar nous aidant à comprendre leur teneur), - faire tester la démo par une équipe de contributeurs.
Ces trois effets, s’ils sont bien combinés, rendront caduques la beta et nous pourrons alors avancer vers notre objectif à long terme : le déploiement continu.