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.
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.
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.
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.
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.
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.
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.
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.
Il est également possible d’afficher le même projet sous forme de panneau.
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é.
É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.
- À propos des dépôts pour plus d’informations sur la création de référentiels
- Suivi de votre travail avec des problèmes pour en savoir plus sur les différentes façons de créer et de gérer les problèmes
- À propos des modèles de problème et de demande de tirage pour en savoir plus sur les modèles de problème
- Gestion des étiquettes pour savoir comment créer, modifier et supprimer des étiquettes
- À propos des listes de tâches pour en savoir plus sur les listes de tâches - À propos des Projects pour en savoir plus sur les projets
- Modification de la disposition d’une vue pour apprendre à personnaliser les affichages des projets - À propos des projects (classic) pour apprendre à gérer projets (classique)