Comment Organiser Son Travail Avec GitLab ?

• 2021/3/2
• 7-minute read

💡 Comment organiser son travail ?

Vous vous posez souvent cette question autour de votre organisation ? Pour ma part c’est une remise en cause perpétuelle depuis que j’ai commencé à travailler. Notre mode de fonctionnement à un instant donné n’est pas forcément le même à un autre moment. Cela peut dépendre de plein de choses, de notre rôle qui évolue, de l’équipe avec laquelle on travaille, de votre entreprise, de la volonté de faire des choses en parallèle de notre métier, de notre vie privée, etc.

Une multitude d’outils de todo list existe comme Trello, Easynote, Notion, Google Keep, Microsoft Teams, Todoist, etc. Il n’est pas simple de choisir celui qui nous convient le mieux du premier coup.

Au début de ma carrière, je travaillais souvent dans l’outil de gestion de tâches appartenant à l’entreprise où j’étais, et donc sur un réseau fermé à l’entreprise. Dans un sens, pour isoler nos actions de tous les jours et celles du travail, c’est le top. Au moins vous n’êtes pas tenté de revoir / repenser votre activité professionnelle pendant vos week-ends et vos vacances. Mais à partir du moment où j’ai commencé à développer dans ma vie personnelle, j’ai dû revoir une première fois ma copie.

De premiers outils testés…

J’ai donc opté pour une option de type Trello (je n’ai plus le nom en tête !). Puis après quelques années, j’ai basculé sur une solution plus solide, Trello. CCela m’a permis de créer plusieurs tableaux pour distinguer vie professionnelle et vie personnelle. Mais certaines activités de veille, effectuées sur ma vie personnelle, ont basculé sur mon quotidien professionnel, et oui, faire de la veille, c’est aussi le quotidien de la vie professionnelle.

Me voilà donc avec un seul tableau, avec au départ une colonne todo, une colonne par jour travaillé et une colonne done.

La colonne todo a été rapidement surchargée, ce qui complique la visualisation globale de l’activité à réaliser. Pour essayer de m’y retrouver j’ai créé des étiquettes pour identifier visuellement le type de mes cartes.

Rapidement je me suis retrouvé avec une vingtaine d’étiquettes, et avec les codes couleur, ça me donnait rapidement une idée des tâches à réaliser.

Mais après quelques mois d’utilisation, j’ai voulu dégrossir la colonne todo et je l’ai divisée en plusieurs colonnes, une par projet ou par activité. Me voilà avec un nombre incroyable de colonnes et de cartes positionnées dans tous les sens. Très dur de s’y retrouver et de prioriser les différentes cartes.

Mon dernier changement d’outil, GitLab 🦊

Manipulant GitLab au quotidien dans mon activité professionnelle et très régulièrement aussi côté personnel, j’avais une liste d’issues sur chacun de mes projets pour déclarer des incidents ou des évolutions. J’avais déjà ressenti ce besoin de centraliser toutes ces issues sur un seul écran et avais initié un “énième” side project. Et c’est en définissant la backlog des features de ce projet que je me suis vu dupliquer ces issues… Sur Twitter, j’avais vu que plusieurs personnes géraient leur activité dans un Kanban GitLab, ce qui m’a rapidement amené à cette conclusion : c’est parti pour un rapatriement de mes cartes Trello dans un projet GitLab.

La configuration

Dans la version gratuite de GitLab, il est à l’heure actuelle permis de faire de la gestion de projet grâce à ces terminologies :

• des milestones pour définir des périodes / jalons de travail
• des labels pour classifier les issues
• des issues pour déclarer des tickets
• des boards pour avoir une visualisation Kanban de nos issues

Les milestones

Les milestones permettent de définir des périodes d’activités. Les issues peuvent être rattachées à une et une seule milestone.

En ce qui concerne les jalons de mon projet, j’en ai défini plusieurs :

• un jalon par semaine
• un jalon d’informations pour stocker et pouvoir récupérer rapidement des informations utiles à mon entreprise et aux langages de développement par exemple
• un jalon de waiting pour référencer les tâches à réaliser, ma todo list.

Ce mode de fonctionnement impose une rigueur dans la surveillance des issues. En début et fin de semaine, il est important de regarder quels éléments de la todolist peuvent être planifiés dans une semaine, que ce soit celle en cours ou une à venir. À la fin de chaque semaine, toutes les issues doivent être fermées dans l’objectif de clôturer la milestone. Les issues non réalisées dans la semaine peuvent être repositionnées sur un autre jalon.

Les labels

Les labels se construisent au fur et à mesure de la création de nos issues. Pour le démarrage, j’ai classé mes issues :

• avec des typologies : dev, formation, talk, articles de blog
• avec une notion de priorité : urgent, pas urgent
• par projets concernant mes sides projects
• et par jour de la semaine : “lundi”, “mardi”…

Les issues

Les issues permettent de déclarer une tâche à réaliser ou pour stocker de l’information en format Markdown. On peut ensuite l’identifier en lui attribuant des étiquettes.

Et ce qui est également pratique, c’est de pouvoir relier l’issue de ce projet d’organisation, avec l’issue ou la merge request d’un autre projet GitLab (de la même instance). J’arrive donc à faire le lien rapidement entre les issues de mes projets GitLab et celles de mon projet de gestion d’activité.

Les boards

Les boards vont permettre d’avoir une représentation graphique de vos issues. Par défaut, un board est affiché avec deux colonnes d’issues, celles “Open” et celles “Closed”.

Mais il est possible d’ajouter des listes d’issues associées à un label spécifique. C’est de cette façon que j’ai pu me créer un board pour une semaine. J’ai donc une colonne pour les issues taguées “To Do”, une autre pour celles en cours (“Doing”) et une colonne par jour.

Avec l’interface GitLab, le drag and drop est bien entendu fonctionnel et ajoute automatiquement le label associé à la colonne. C’est bien pratique au quotidien quand on prévoit de décaler une issue.

À ce stade-là, j’aperçois les issues de toutes mes milestones, ce qui n’est pas forcément l’objectif puisque je veux travailler et avoir une visualisation de mon activité à la semaine. Pour “contrer” cela, il suffit d’ajouter un filtre de recherche sur ma milestone :

Cette recherche est disponible via une url classique que je peux enregistrer et adapter en fonction des différentes semaines : https://gitlab.com/jeanphi.baconnais/xxxx/-/boards/xxxxxx?scope=all&utf8=✓&milestone_title=S09 et le tour est joué.

Le Service Desk

 Le Service Desk est un outil qui met à disposition une adresse mail du type incoming+jeanphi-baconnais-organizer-xxxxxx-issue-@incoming.gitlab.com et va, dès réception d’un mail, enregistrer le contenu du mail (avec les pièces jointes s’il vous plaît !) dans une nouvelle issue. Cela peut être utile pour éviter de surcharger les boîtes mails communes et préférer créer un ticket dans GitLab. PPour l’utilisation de ma propre backlog, cela m’est utile pour éviter d’oublier de traiter des mails, surtout quand on prévoit de traiter le mail quelques jours plus tard.

Dès que le mail est traité par GitLab, un mail de retour est renvoyé à l’utilisateur :

La non-assignation d’issue à une milestone me permet de repérer les nouvelles issues que j’aurais pu oublier. Je vérifie de temps en temps qu’aucune issue ne possède une milestone à “None”.

Dans le menu “Service Desk”, il est également possible de récupérer toutes les issues créées par ce service.

Et l’issue contient bien les informations de mon mail ainsi que la pièce jointe :

Il est possible de personnaliser le message du retour ainsi que le format de l’issue créé à partir de template. Pour plus d’informations, c’est par ➡️ ici.

NB : Lors de la création ou de l’édition d’issue, l’affectation à une milestone ou à des labels peut se faire de manière textuelle, par exemple /milestone %S09 . Lors de l’envoi de mail au service desk, ce genre de texte n’est pour le moment pas encore pris en charge.

Mon retour 🚀

Après plusieurs mois d’utilisation, je trouve que cette gestion m’a permis de trouver une organisation qui m’est personnellement plus adaptée. Sur mon exemple, on ne voit qu’une quarantaine d’issues, mais dans un pic d’activité, je suis monté à plus de 150 issues à gérer, déplacer, temporiser, retrouver rapidement et le board de GitLab a largement répondu à mes attentes.