Process Trello / Slack / Github

NB : Nous devons tou-te-s nous discipliner pour privilégier le contact incluant toutes les personnes du channel == du projet, plutôt qu’en one-to-one. Que ce soit sur Slack, via mail ou ailleurs, penser à toujours mettre à dispo les infos à tout le monde concerné, de près comme de loin.

Rôle de chacun des outils

Slack : via le channel dédié au projet, communiquer entre tous les membres de l'équipe : poser des questions, informer, etc. Éventuellement mentionner des ressources sur le channel (si le tableau Trello n'existe pas encore par exemple), mais il faudra penser à les rabattre également dans la liste dédiée sur le tableau Trello du projet (parce que malgré la possibilité d'épingler des messages, ça peut rapidement devenir laborieux de devoir scroller indéfiniment pour retrouver un élément).

Trello : via le tableau dédié au projet, lister les ressources, les tâches et les attribuer aux personnes concernées. Espace non technique accessible à tous les membres de l'équipe, descriptions rédigées en langage profane. Penser à bien mettre à jour les statuts des cards, en fonction de l'avancement de chacun, pour qu'on puisse facilement déterminer qui fait quoi et où telle tâche en est.

Github : via le repository dédié au projet, répondre aux besoins / tâches exprimés dans le tableau Trello (cards et ressources), les formuler en langage technique. Espace technique à destination de l'équipe de devs, descriptions et listings éventuels de tâches à cocher rédigés en langage technique. L'anglais étant la langue par défaut pour coder, ça sera également celle de prédilection pour cette plateforme, au moins pour les commits.

Description détaillée des processus

• Un tableau Trello / un channel Slack par projet ; tous les documents, dont l'expression du besoin, la deadline, les éventuels contacts, etc., doivent figurer / être mentionnés / listés sur le tableau Trello (dans une liste de type "Infos projet"). Il est donc théoriquement ouvert bien avant le repository Github, idéalement en même temps ou juste après le channel Slack associé au projet. En fin de projet, le tableau peut être archivé (il me semble que les tableaux archivés sont encore consultables, à confirmer), par contre il serait pertinent de garder ouvert le channel, car il est souvent arrivé qu'il y ait HOTFIX de dernière minute ou fonctionnalités à rajouter post livraison, parfois même plusieurs semaines après.

NB : Les documents / ressources externes fournies sur Trello peuvent : soit être uploadées dans la card impliquée, en PJ ; soit être indiquées en lien dans sa description. Nous avons une Dropbox sur laquelle nous pouvons stocker des éléments, pour ne pas noyer la conversation d'une card sous les documents, ou pour les éléments très lourds / importants.

• Une tâche à effectuer = une card sur Trello (qui rassemble TOUTES les data la concernant - quitte à y référencer d'autres cards informatives) langage marketing / besoin / demande du client) assignée à la ou aux personnes concernées (afin qu'elles puissent toutes être notifiées des échanges) dans une liste de type À faire (impliquant donc une action, un verbe) ; puis une issue sur Github (tâche traduite en langage et implications techniques), avec ping sur le channel de la / des personnes assignées, pour les prévenir (c'est quand même plus poli). Sur l'issue Github, préférer assigner la personne devant agir en priorité dessus ; exemple : question en attente de la réponse de telle personne, ou inté en attente de dev, etc. (dans cette logique, sur Gitlab par exemple, on ne peut assigner qu'une seule personne à la fois sur une issue - ou PR).

NB : Une tâche = une card sur Trello, mais une card Trello n'égal pas forcément une tâche / une issue ; cf la colonne (ou liste) intitulée 'Infos projet' sur plusieurs tableaux, qui rassemble par card à thématique, tous les documents et data / explications / descriptions globales aux projet et nécessaires aux membres de l'équipe. Une issue impliquant un ou plusieurs commits pour la résoudre, qui la fermeront, tout ce qui relève de l'informatif (arborescence, documents, CDC, expression du besoin, etc.) concernera plutôt et d'abord une card Trello, moins qu'une issue Github. À noter qu'une card impliquant une tâche à effectuer doit être formulée clairement comme telle, avec un verbe d'action (créer, mettre à jour, modifier, faire, etc.).

• Une card Trello correspondant à une tâche à effectuer, peut équivaloir à plusieurs issues Github : il peut parfois être pertinent de la découper en plusieurs issues, chacune impliquant différents membres de l'équipe technique par exemple, ou alors tout simplement pour une itération plus rapide car ce que la card implique est vaste. A contrario, une issue peut tout à fait équivaloir à plusieurs cards ; penser simplement à bien mentionner l'issue sur toutes les cards concernées.
  • Sur Trello, lister la ou toutes les issues en lien avec la card, via le power-up Github elles seront mises en avant et leur nom / état figueront dans la card.
  • Sur Github, si la tâche est très rapide == un seul commit qui cite l’ID de l’issue (si oubli, tag du SHA-1 du commit sur l’issue ; sinon PR qui référence elle-même l’issue en description. Il est impératif qu’une issue, si résolue, mentionne le commit ou la PR sur laquelle elle l’a été.

NB : Pour ce qui est de la création des issues, charge au chef de projet, éventuellement aidé des devs, de retranscrire les fonctionnalités (expression du besoin) décrites dans les cards en issues (spécifications techniques). Cependant, en cas de détection éventuelle de bug, hotfix ou évolution nécessaire, charge à n'importe qui l'ayant détecté d'ouvrir une issue, avec toutes les infos nécessaires pour la résoudre (description précise du problème, screen, etc.) et de l'assigner au techos concerné. Ne pas hésiter à écrire sur le channel Slack pour demander / confirmer quelle est la personne la plus à même de résoudre telle issue.

• Utiliser les tags appropriés, pour que les collègues comprennent ce qu’il se passe : notion de priorité sur les issues (tags question, wontflix, bug, priority...), notion d’avancement sur les PR (tags work in progress, ready for review, standby - qui renvoie au label de l’issue concernée - etc.)

NB : Une issue ne doit JAMAIS être fermée sans raison : fixed by SHA-1, fixed by #id_PR, tag wontfix... Ja-mais fermée sans raison ni commentaire ni rien ! Dans la même logique, une issue ou une PR, ne doivent jamais être fermées / mergées avec des tâches à cocher non cochées ! A moins de mentionner pourquoi et où ces tâches restantes seront résolues.

• Sur Trello, les membres non techos de l'équipe, ne figurant donc pas sur Github, peuvent également suivre l’avancement des cards des tableaux, car celles-ci peuvent être organisées par colonnes (appelées listes) à thématique. Si on fait des listes (entre autres) par avancement (En cours, À review, À déployer...), en un coup d’oeil tout le monde peut voir qui travaille sur quoi à l’instant T. Autre avantage, on peut suivre l’après push/merge, jusqu’au déploiement. Après déploiement, on peut archiver la card terminée. Charge aux personnes concernées de systématiquement mettre à jour le statut des cards dont leur travail a modifié le statut.

NB : Sur Trello, il y a aussi un système de tags, qui lui peut plutôt servir à l’aspect RC.

• Chaque commit ou PR de commits, sont push / merge sur ce qui est appelé sur Github la base branch. Par sécurité, ce n'est pas master mais une branche de transition, communément appelée staging qui, lors de la création du repository, doit être créée et réglée en base branch dans les settings du repo du projet. Cette branche, si utilisée convenablement, doit toujours être égale ou en avance d'un ou plusieurs commits, sur master. Mais pas en retard.

NB : Dans le cas d'un HOTFIX éventuel urgentissime post livraison, il se peut qu'un commit ait été fait directement sur master. Mais ceci doit rester excessivement rare et le commit en question doit dans la foulée être rapatrié sur staging (merge ou cherry-pick). Mieux vaut s'en abstenir, pour faire simple.

• Idéalement, staging doit régulièrement être mergée avec master (une fois par semaine, par exemple, à un créneau régulier également de préférence) après s'être assuré, via une preprod par exemple, que tout y est 100% en ordre pour la merge sur master. Car c'est master qui est vouée à être déployée en production. C'est notamment pour ça qu'il ne faut pas push un travail pas fini (dev incomplet ou manquant l'inté) sur staging. Normalement, staging devrait à n'importe quel moment pouvoir être merge sur master + déployé en l'état, et l'application existante fonctionner correctement. Cette branch sert de garde-fou, pas de brouillon (coucou la loi de Murphy). Ce sont les branches / PR qui font office de brouillons.

NB : Les deploy irréguliers et très récurrents se produisent souvent en toute fin de projet, le client ayant hâte d'avoir accès aux dernières fonctionnalités manquantes. Mais c'est un rythme à éviter pour ne pas surcharger ni interrompre le développeur en charge de gérer master et de deploy.

• BONUS : En particulier pour les projets de longue haleine (Bestove, WIP, etc.) penser à mettre à jour le README.md du repository, avec toutes les explications, étapes et commandes nécessaires pour faire tourner le projet sur sa bécane en local.

---

Il s'agit d'une proposition de standards, ce document est amené à évoluer ! Si vous avez la moindre suggestion ou modification que vous voudriez apporter à ces étapes, n'hésitez pas à m'en parler ! Vous pouvez bien entendu modifier ce document, mais c'est quand même plus chouette d'en parler ensemble avant.