Comment organiser son travail avec GitLab ?
Tags: kanban, gitlab
Published: 2021-03-09 14:20:44


# 💡 **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](https://trello.com/fr), [Easynote](https://easynote.com/), [Notion](https://www.notion.so/), [Google Keep](https://keep.google.com/), [Microsoft Teams](https://www.microsoft.com/fr-fr/microsoft-teams/group-chat-software), [Todoist](https://todoist.com/fr), 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. 

<img src="http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-visu-trello-etiquettes.png"  width="400" >

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. 

<img src="http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-visu-trello.png"  width="400" >

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*.

![Mes milestones](http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-milestones.png)


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"...

![Mes milestones](http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-labels.png)


## 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é.

![Une issue](http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-one-issue.png)


## 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". 

![Board par défaut ](http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-board-default.png)

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.

![Board par défaut ](http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-board-week.png)

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 :

![Board par défaut ](http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-board-milestone-filter.gif)

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 :

<img src="http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-service-desk.png"  width="400" >
 
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".

![Issue create by service desk ](http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-service-desk-issue-no-milestone.png)

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

![Service Desk - issues ](http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-service-desk-issue-menu-sd.png)

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

![Service Desk - detail issues ](http://jeanphi-baconnais.gitlab.io/img/orga-gitlab-service-desk-issue-detail.png)

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](https://docs.gitlab.com/ee/user/project/service_desk.html#using-customized-email-templates).

**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.