Planification et suivi du travail d’une équipe ou d’un projet

Bases de l’utilisation des outils de planification et de suivi de GitHub pour gérer le travail sur une équipe ou un projet.

Dans cet article

Introduction

Vous pouvez utiliser les dépôts, problèmes, projets et autres outils GitHub pour planifier votre travail et en effectuer le suivi, qu'il s'agisse d'un projet individuel ou d'une équipe fonctionnelle croisée.

Dans ce guide, vous allez découvrir comment créer et configurer un dépôt pour collaborer avec un groupe de personnes, créer des modèles de problèmes et des formulaires, ouvrir des problèmes et utiliser des listes de tâches pour diviser le travail, et établir un projet (classique) pour organiser et suivre les problèmes.

Création d’un dépôt

Au début d’un nouveau projet, d’une nouvelle initiative ou d’une nouvelle fonctionnalité, la première étape consiste à créer un référentiel. Les référentiels contiennent tous les fichiers de votre projet. Ils vous permettent de collaborer avec d’autres personnes et de gérer votre travail. Pour plus d’informations, consultez « Création d’un dépôt ».

Vous pouvez configurer des référentiels à différentes fins en fonction de vos besoins. Voici quelques cas d’utilisation courants :

  • Référentiels de produits : les grandes organisations qui effectuent le suivi de leur travail et de leurs objectifs autour de produits spécifiques peuvent posséder un ou plusieurs référentiels contenant le code et d’autres fichiers. Ces référentiels peuvent également être utilisés pour la documentation, les rapports sur l’intégrité du produit ou les plans futurs le concernant.
  • Référentiels de projets : vous pouvez créer un référentiel pour un projet individuel sur lequel vous travaillez ou pour un projet sur lequel vous collaborez avec d’autres personnes. Dans le cas d’une organisation qui effectue le suivi du travail pour des initiatives ou des projets de courte durée (par exemple une société de conseil), il est nécessaire de créer des rapports sur l’intégrité du projet et de déplacer les personnes entre les différents projets en fonction de leurs compétences et des besoins. Le code du projet est souvent contenu dans un seul référentiel.
  • Référentiels d’équipe : dans le cas d’une organisation qui regroupe des personnes dans des équipes et leur apporte des projets (par exemple une équipe d’outils de développement), le code peut être dispersé dans de nombreux référentiels pour le travail dont ils doivent effectuer le suivi. Il peut alors être utile de disposer d’un référentiel unique, propre à l’équipe, pour suivre tout le travail dans lequel elle est impliquée.
  • Référentiels personnels : vous pouvez créer un référentiel personnel pour effectuer le suivi de tout votre travail à un seul endroit, planifier les tâches futures, ou même ajouter des notes ou des informations que vous souhaitez enregistrer. Vous avez également la possibilité d’ajouter des collaborateurs si vous voulez partager ces informations avec d’autres personnes.

Vous pouvez créer plusieurs référentiels distincts pour attribuer des autorisations d’accès différentes au code source ou pour effectuer un suivi des problèmes et des discussions. Pour plus d’informations, consultez « Création d’un dépôt de problèmes uniquement ».

Dans la suite de ce guide, nous allons utiliser un exemple de référentiel appelé Project Octocat.

Communication des informations sur le référentiel

Vous pouvez créer un fichier README.md pour votre référentiel afin de présenter votre équipe ou votre projet et de communiquer des informations importantes à son sujet. Il s’agit souvent du premier élément consulté par les visiteurs de votre référentiel. Vous pouvez donc fournir également des informations pour aider les utilisateurs et les contributeurs à commencer à utiliser le projet et à contacter l’équipe. Pour plus d’informations, consultez « À propos des README ».

Vous pouvez également créer spécifiquement un fichier CONTRIBUTING.md destiné aux utilisateurs et aux contributeurs, qui contiendra des instructions pour contribuer et interagir avec l’équipe ou le projet (par exemple comment ouvrir un problème de résolution de bogue ou demander une amélioration). Pour plus d’informations, consultez « Définition de recommandations pour les contributeurs de dépôt ».

Exemple de fichier README

Nous pouvons créer un fichier README.md pour présenter notre nouveau projet, Project Octocat.

Capture d’écran du fichier README.md du dépôt octo-org/project-octocat, avec des détails sur le projet et la façon de contacter l’équipe.

Création de modèles de problème

Vous pouvez utiliser des problèmes pour effectuer le suivi des différents types de travail couverts par votre équipe fonctionnelle croisée ou votre projet, ainsi que pour recueillir des informations auprès de personnes extérieures à votre projet. Voici quelques cas d’usage courants pour les problèmes.

  • Suivi des versions : vous pouvez utiliser un problème pour suivre la progression d’une version ou la procédure à appliquer le jour du lancement.
  • Grandes initiatives : vous pouvez utiliser un problème pour suivre la progression d’une grande initiative ou d’un projet, qui est ensuite lié à des problèmes de moindre envergure.
  • Demandes de fonctionnalités : votre équipe ou vos utilisateurs peuvent créer des problèmes pour demander une amélioration à votre produit ou projet.
  • Bogues : votre équipe ou vos utilisateurs peuvent créer des problèmes pour signaler un bogue.

Selon le type de référentiel et de projet sur lequel vous travaillez, vous pouvez classer les problèmes par ordre de priorité. Une fois que vous avez identifié les types de problèmes les plus courants pour votre équipe, vous avez la possibilité de créer des modèles de problèmes et des formulaires pour votre dépôt. Les modèles de problèmes et les formulaires vous permettent de créer une liste standardisée de modèles parmi lesquels un contributeur peut choisir lorsqu’il ouvre un problème dans votre dépôt. Pour plus d’informations, consultez « Configuration des modèles de problème pour votre dépôt ».

Exemple de modèle de problème

Nous allons créer un modèle de problème permettant de signaler un bogue dans Project Octocat.

Capture d’écran du formulaire pour créer un modèle de problème. Les champs sont remplis pour créer un modèle nommé « Rapport de bogues pour Project Octocat ».

Maintenant que nous avons créé le modèle de problème de rapport de bogues, vous pouvez le sélectionner lors de la création d’un problème dans Project Octocat.

Capture d’écran de la page « Nouveau problème » pour octo-org/project-octocat, avec la possibilité d’utiliser le modèle « Rapport de bogues pour Project Octocat ».

Ouverture de problèmes et utilisation de listes de tâches pour effectuer le suivi du travail

Vous pouvez organiser votre travail et en effectuer le suivi en créant des problèmes. Pour plus d’informations, consultez « Création d’un problème ».

Exemple de problème

Voici un exemple de problème créé pour une grande initiative, un travail front-end, dans Project Octocat.

Capture d’écran d’un problème appelé « Travail front-end pour Project Octocat ». Le corps du problème comprend une liste de tâches à effectuer.

Exemple de liste de tâches

Vous pouvez utiliser des listes de tâches pour décomposer les problèmes volumineux en tâches plus petites et effectuer le suivi des problèmes dans le cadre d’un objectif plus large. Pour plus d’informations, consultez À propos des listes de tâches.

Nous avons ajouté une liste de tâches à notre problème Project Octocat, le décomposant ainsi en problèmes plus petits.

Capture d’écran d’un problème appelé « Travail frontal pour project Octocat ». Le corps du problème contient une liste des tâches, avec une case à cocher précédant chaque lien de problème.

Prise de décisions en équipe

Vous pouvez utiliser des problèmes et des discussions pour communiquer et prendre des décisions en équipe sur les améliorations planifiées et les priorités de votre projet. Les problèmes sont utiles lorsqu’ils sont créés pour discuter de détails spécifiques (par exemple des rapports de bogues ou de performances), de la planification du trimestre suivant ou de la conception d’une nouvelle initiative. Les discussions servent pour le brainstorming et les commentaires ouverts, en dehors du codebase et sur plusieurs référentiels. Pour plus d’informations, consultez « Communication sur GitHub ».

Dans votre équipe, vous pouvez également communiquer des informations sur les tâches quotidiennes au sein des problèmes afin que tout le monde connaisse l’état du travail. Créez par exemple un problème pour une fonctionnalité volumineuse sur laquelle plusieurs personnes travaillent : chaque membre de l’équipe pourra ainsi ajouter des mises à jour de son état ou ouvrir des questions dans ce problème.

Exemple de problème avec des collaborateurs de projet

Voici un exemple de collaborateurs de projet qui donnent un état d’avancement de leur travail sur le problème Project Octocat.

Capture d’écran d’un problème appelé « Travail front-end pour Project Octocat ». Les commentaires de @codercat et de @octocat fournissent des actualisations sur l’état du travail.

Mise en évidence des objectifs et de l’état du projet à l’aide d’étiquettes

Vous pouvez créer des étiquettes pour un référentiel afin de catégoriser les problèmes, les demandes de tirage (pull request) et les discussions. GitHub fournit également des étiquettes par défaut pour chacun des nouveaux référentiels que vous modifiez ou supprimez. Les étiquettes sont utiles pour effectuer le suivi des objectifs du projet, des bogues, des types de travail et de l’état d’un problème.

Pour plus d’informations, consultez « Gestion des étiquettes ».

Une fois que vous avez créé une étiquette dans un référentiel, vous pouvez l’appliquer à tous les problèmes, à toutes les demandes de tirage et à toutes les discussions du référentiel. Cela vous permettra de filtrer les problèmes et les demandes de tirage par étiquette pour trouver tout le travail associé. Par exemple, recherchez tous les bogues front-end de votre projet en ajoutant un filtre sur les problèmes avec les étiquettes front-end et bug. Pour plus d’informations, consultez « Filtrage et recherche de problèmes et de demandes de tirage ».

Exemple d’étiquette

Voici un exemple d’étiquette front-end qui a été créée et ajoutée au problème.

Capture d’écran d’un problème appelé « Travail front-end pour Project Octocat ». Dans la barre latérale droite, dans la section « Étiquettes », l’étiquette « front-end » est appliquée.

Ajout de problèmes à un projet (classique)

Vous pouvez utiliser projects sur GitHub pour planifier et suivre le travail de votre équipe. Un projet consiste en une feuille de calcul personnalisable qui s’intègre à vos problèmes et demandes de tirage sur GitHub et reste automatiquement à jour des informations présentes sur GitHub. Vous pouvez personnaliser la disposition en filtrant, en triant et en regroupant vos problèmes et demandes de tirage. Pour commencer à utiliser des projets, consultez Démarrage rapide avec les Projects.

Exemple de projet

Voici la disposition du tableau d’un exemple de projet, remplie avec les problèmes Project Octocat créés.

Capture d’écran de la vue tableau du projet « Project Octocat », contenant une liste de problèmes, avec les colonnes « Titre », « Destinataires », « État », « Étiquettes » et « Notes ».

Il est également possible d’afficher le même projet sous forme de panneau.

Capture d’écran de la vue panneau du projet « Project Octocat », avec les problèmes organisés en colonnes « Aucun état », « À faire », « En cours » et « Terminé ».

Vous pouvez aussi utiliser les projects (classic) existants sur GitHub pour planifier et suivre votre travail ou celui de votre équipe. Les Projets (classique) sont constitués de problèmes, de demandes de tirage et de notes classés comme des cartes dans les colonnes de votre choix. Vous pouvez créer des projets (classique) pour un travail de fonctionnalités, des feuilles de route générales ou même des check-lists de mise en production. Pour plus d’informations, consultez « À propos des projects (classic) ».

Exemple des Projet (classique)

Voici un projet (classique) pour l'exemple Project Octocat avec le problème créé, auquel ont été ajoutés les problèmes plus petits dans lesquels il a été décomposé.

Capture d'écran d'un projet (classique) appelé « Project Octocat Board », avec les problèmes organisés en colonnes « À faire », « En cours » et « Terminé ».

Étapes suivantes

Vous avez découvert les outils proposés par GitHub pour la planification et le suivi de votre travail, et vous avez commencé à configurer le référentiel de votre équipe fonctionnelle croisée ou de votre projet ! Voici quelques ressources utiles pour personnaliser davantage votre référentiel et organiser votre travail.