Quelle est la différence / relation entre les projets GitHub et les jalons?


164

La récente mise à jour de GitHub a ajouté quelque chose appelé Projets dans le flux de travail GitHub, et parce que je n'ai pas d'expérience particulière avec les outils de suivi de projet tels que Jira ou Trello (hé, au moins j'ai remarqué la similitude) , quelqu'un pourrait-il, s'il vous plaît, élaborer sur les différences (clés) entre les jalons de GitHub et les nouveaux projets ?

Si je comprends bien, les jalons sont une façon d'organiser les problèmes en «sous-projets» plus petits - plus petits que le «projet» dans son ensemble (qui, dans ma vision du monde, est représenté par le référentiel ). Lorsque tous les problèmes sont terminés / fermés, le jalon peut être considéré comme terminé .

Les projets nouvellement introduits sont aussi, comme je le vois, une façon d'organiser les problèmes en "sous-projets" plus petits que le référentiel (bien que appelés Projets ). Je comprends que le flux de travail est censé être légèrement différent et plus fin qu'avec de «simples» jalons .

Alors, les projets sont-ils quelque chose qui complète les jalons (ou plutôt les jalons complètent les projets maintenant?) Ou devrais-je plutôt considérer les projets comme un remplacement des jalons ?

Où exactement les projets se situent-ils réellement dans la repository[-milestone]-issuehiérarchie?

Malheureusement, l'entrée de blog de GitHub sur l'introduction des projets ne mentionne aucune relation ( https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and- fonctionnalités ).

J'ai l'impression qu'il y en a un, mais je ne peux pas mettre le doigt dessus.


Je vote pour clore cette question comme hors sujet car cela n'a rien à voir avec la programmation.
double bip le

20
Puisque le centre d'aide dit clairement: «[...] si votre question couvre généralement [...] les outils logiciels couramment utilisés par les programmeurs; et qu'il s'agit d'un problème pratique, auquel il est possible de répondre, propre au développement logiciel ... alors vous êtes au bon endroit pour poser votre question! " , Je ne vois aucune raison à cela.
Smuuf

Réponses:


155

Je me demande exactement la même chose. Voici ce que j'ai trouvé.

Tout d'abord, passons en revue les principales similitudes et différences:

  • Un problème peut appartenir à plusieurs projets, mais à un seul jalon.
  • Les projets ne sont jamais terminés . Il n'y a pas de barre de progression ni de date limite. Les projets n'ont pas de barre de progression ni de date limite, mais peuvent maintenant être clôturés (comme indiqué par @Sheen)
  • Les jalons, par contre, ont tout cela, mais ils manquent de toute forme d'organisation. Un problème est soit dans un jalon, soit non. (Ils peuvent être commandés comme indiqué par @Nick McCurdy)
  • Les problèmes peuvent être filtrés par jalon, mais pas par projet. Comme indiqué par @cmonkey, les problèmes peuvent désormais être filtrés par projet ainsi que par jalon.
  • Les projets peuvent contenir des notes (qui peuvent être converties en problèmes) afin de ne pas polluer le suivi des problèmes avec des idées vagues
  • Un projet peut s'étendre sur plusieurs jalons et un jalon peut contenir des parties de différents projets.
  • Une organisation peut également avoir des projets. Ces projets peuvent inclure des tickets de n'importe quel référentiel de l'organisation, ce qui le rend très utile.

Donc, d'après moi, les projets sont un moyen complètement séparé de visualiser et d'organiser votre travail à un niveau supérieur (pensez à la "gestion de projet", à plusieurs équipes, à plusieurs référentiels, etc.), tandis que les jalons sont un moyen d'organiser votre les délais et les versions à un niveau plus basique (pensez à la «gestion des versions», aux «versions», etc.). Dans cet esprit, il est logique qu'un problème n'appartienne qu'à un seul jalon (il n'est publié ou mis en production qu'une seule fois), mais peut faire partie de différents projets.

Je suis sûr qu'il existe d'autres façons de voir les choses, et je suis intéressé d'entendre d'autres opinions.

Edit décembre 2017

Il y a quelque temps, après avoir travaillé avec Milestones and Projects pendant plus d'un an, j'ai réalisé qu'il y avait un autre aspect important que j'avais complètement négligé.

  • Milestones est un outil pour la méthodologie Scrum . Les jalons sont bons pour les itérations temporisées et pour travailler dans des sprints avec des lots de problèmes.
  • Projects est un outil pour la méthodologie Kanban . Les projets sont bons pour une livraison continue et un flux de travail régulier.

3
Merci pour le résumé, je me suis posé cette question moi-même. Je pense que je vais rester à l'écart de l'ensemble des projets car ce n'est pas très applicable pour mes ... projets. Github Projects semble (pour moi) être "à l'envers" parce que j'ai généralement plusieurs référentiels pour 1 projet, et non l'inverse.
KEK

1
@KEK, dans GitHub Enterprise, j'utilise une organisation avec un référentiel éponyme qui n'a pas de code, mais qui permet de centraliser tous les projets et leurs problèmes. Les demandes d'extraction contre les référentiels qui contiennent du code ont une brève référence au problème du référentiel central.
yegeniy

Mon sentiment est que les jalons sont principalement pour les semaines / mois suivants où tous les problèmes sont plus ou moins connus, et les projets durent des mois à un an, où tous les problèmes ne sont pas encore connus. Une intégration plus étroite entre les deux réduisant le chevauchement pourrait en fait valoir la peine.
Trilarion

1
Les projets ont maintenant des barres de progression si vous utilisez des préréglages d'automatisation de colonne.
emlai

C'est fantastique. Cependant, je ne sais toujours pas si l'on doit utiliser les jalons et les projets ensemble ou si l'on ne doit utiliser que l'un des deux. Qu'est-ce que tu penses?
chrisdembia

41

Mon avis:

  • Un projet concerne un processus et les personnes .
  • Un jalon concerne un produit .

Un projet est le meilleur moyen d'obtenir un aperçu d'un processus utilisé par les membres du groupe. Un meilleur nom pour cela serait "workflow" ou "processus". Il y a plus de frais généraux impliqués dans la création d'un nouveau projet que dans la création d'un nouveau jalon. Donc, vous ne voulez vraiment créer un nouveau projet que lorsqu'il y a un nouveau processus dans votre équipe: les voies doivent être choisies, configurées et ordonnées. Ils peuvent également être très différents dans chaque projet. Je repense à l'utilisation originale de Kanban par Toyota: gérer les gens et leur charge de travail.

Un projet répond à la question: "Sur quoi travaillons-nous en ce moment?"

Deux grands exemples de projets: le développement de logiciels et les blogs. Les configurations pour chacun prendraient en charge les processus de personnes des différents groupes; comment ils travaillent ensemble et approuvent les choses.

Les jalons, en revanche, fonctionnent tous de la même manière. Il s'agit d'une liste ordonnée de tâches qui doivent toutes être fermées pour que le produit de travail soit considéré comme terminé. En option, une date d'échéance peut être définie, ce qui fournit simplement des rappels, mais ne change pas le fonctionnement du jalon.

Un jalon répond à la question "Que reste-t-il pour terminer ce produit?"


14

Une bonne chose à propos des projets est qu'ils sont plus de forme libre que des jalons. Vous pouvez simplement y ajouter des notes et créer des liens vers des problèmes, et les organiser comme bon vous semble. Ils sont parfaits pour noter des idées, créer des feuilles de route et répertorier les ressources et les dépendances. Dans le passé, j'ai utilisé les problèmes et le wiki pour les mêmes choses, mais j'ai trouvé que les deux étaient trop formels et transactionnels (c'est-à-dire des frais généraux plus élevés).


10

Les jalons sont des sortes d'étiquettes qui marquent et regroupent les billets qui devraient être livrés à un moment donné. La Milestonespage à laquelle vous pouvez accéder à partir de la Issuespage l'indique clairement: vous pouvez voir le pourcentage de tickets terminés pour un jalon particulier et la date d'échéance. Vous pouvez également trier les jalons par date d'échéance et hiérarchiser les tickets au sein d'un jalon particulier.

Le stress ici est sur les dates de livraison et le suivi des progrès.

Les projets , d'autre part, sont implémentés dans GitHub sous forme de tableaux Kanban avec quelques cloches et sifflets. Vous pouvez spécifier un certain nombre de colonnes ( et de couloirs - comme @Doug l'a dit ci-dessous, les couloirs ne sont pas encore pris en charge) pour créer des flux de travail simples. Vous pouvez ensuite ajouter des tickets à partir d'un ou plusieurs référentiels, les hiérarchiser, puis les faire progresser d'une colonne à une autre au fur et à mesure de leur travail. Vous pouvez, par exemple, avoir les colonnes "Backlog", "En cours", "En cours de révision", "En cours de test" et "Terminé" et déplacer les tickets de gauche à droite ou de droite à gauche si, par exemple, un le ticket est renvoyé de «En test» à «Backlog».

L'accent est mis ici sur l'organisation et la gestion du travail.

Ensuite, la façon dont vous organisez et partitionnez ce travail dépend de vous. Vous pouvez créer un projet par jalon ou avoir plusieurs jalons dans un seul projet, ou diviser les jalons en sprints plus courts . Vous pouvez également avoir plusieurs projets couvrant différents aspects du travail sur le produit, par exemple un pour les développeurs et un pour les testeurs.


les couloirs ne sont pas des colonnes dans Kanban. Ce sont des rangées. Github ne prend actuellement pas en charge les couloirs en tant qu'entité de première classe.
Doug le

Merci pour la correction @Doug. Pourriez-vous clarifier ce que signifie la fonction de première classe dans ce contexte? Est-il disponible en version bêta ou quelque chose du genre?
Johnny Baloney
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.