Was ist der Unterschied / die Beziehung zwischen GitHub-Projekten und Meilensteinen?


163

Das jüngste Update von GitHub hat dem GitHub-Workflow etwas hinzugefügt, das als Projekte bezeichnet wird , und da ich keine besonderen Erfahrungen mit Projektverfolgungstools wie Jira oder Trello habe (hey, zumindest habe ich die Ähnlichkeit bemerkt) , könnte jemand dies bitte näher erläutern zu den (Schlüssel-) Unterschieden zwischen GitHubs Meilensteinen und den neuen Projekten ?

Wenn ich das richtig verstehe, sind Meilensteine eine Möglichkeit, Probleme in kleinere "Unterprojekte" zu organisieren - kleiner als das gesamte "Projekt" (das meiner Ansicht nach durch das Repository dargestellt wird ). Wenn alle Probleme erledigt / abgeschlossen sind, kann der Meilenstein als vollständig angesehen werden .

Die neu eingeführten Projekte sind meines Erachtens auch eine Möglichkeit, Probleme in "Unterprojekten" zu organisieren, die kleiner als das Repository sind (obwohl sie als Projekte bezeichnet werden ). Ich verstehe, dass der Workflow etwas anders und feinkörniger sein soll als bei "bloßen" Meilensteinen .

Sind Projekte also etwas, das Meilensteine ergänzt (oder eher Meilensteine, die Projekte jetzt ergänzen ?), Oder sollte ich Projekte lieber als Ersatz für Meilensteine ​​betrachten ?

Wo genau machen die Projekte tatsächlich in dierepository[-milestone]-issueHierarchie?

Leider GitHubs Blogeintrag über die Einführung der Projekte keine Beziehung ( https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and- Funktionen ).

Ich habe irgendwie das Gefühl, dass es einen gibt, aber ich kann keinen Finger darauf legen.


Ich stimme dafür, diese Frage als nicht zum Thema gehörend zu schließen, da sie nichts mit Programmierung zu tun hat.
Doppel-Piepton

20
Da das Hilfezentrum klar sagt: "[...] wenn Ihre Frage im Allgemeinen [...] Softwaretools abdeckt, die häufig von Programmierern verwendet werden, und es sich um ein praktisches, beantwortbares Problem handelt, das nur bei der Softwareentwicklung auftritt ... dann sind Sie es am richtigen Ort, um Ihre Frage zu stellen! " Ich sehe keinen Grund dafür.
Smuuf

Antworten:


155

Ich frage mich genau das Gleiche. Folgendes habe ich mir ausgedacht.

Lassen Sie uns zunächst die wichtigsten Ähnlichkeiten und Unterschiede untersuchen:

  • Ein Problem kann zu mehreren Projekten gehören, aber nur zu einem Meilenstein.
  • Projekte sind niemals abgeschlossen . Es gibt keine Fortschrittsanzeige oder Frist. Projekte haben keine Fortschrittsanzeige oder Frist, können aber jetzt geschlossen werden (wie von @Sheen hervorgehoben).
  • Meilensteine ​​hingegen haben all das, aber es fehlt jede Form der Organisation. Ein Problem befindet sich entweder in einem Meilenstein oder nicht. (Sie können bestellt werden, wie von @Nick McCurdy angegeben)
  • Probleme können nach Meilenstein gefiltert werden, nicht jedoch nach Projekt. Wie von @cmonkey hervorgehoben, können Probleme jetzt sowohl nach Projekt als auch nach Meilenstein gefiltert werden.
  • Projekte können Notizen enthalten (die als Probleme konvertiert werden können), sodass der Issue Tracker nicht mit vagen Ideen verschmutzt wird
  • Ein Projekt kann sich über mehrere Meilensteine ​​erstrecken, und ein Meilenstein kann Teile verschiedener Projekte enthalten.
  • Eine Organisation kann auch Projekte haben. Diese Projekte können Tickets aus jedem Repository in der Organisation enthalten, was es sehr nützlich macht.

So wie ich das sehe, sind Projekte eine völlig separate Möglichkeit, Ihre Arbeit auf einer höheren Ebene zu visualisieren und zu organisieren (denken Sie an "Projektmanagement", mehrere Teams, mehrere Repositorys usw.), während Meilensteine eine Möglichkeit sind, Ihre Arbeit zu organisieren Fristen und Releases auf einer grundlegenderen Ebene (denken Sie an "Release-Management", "Versionen" usw.). Vor diesem Hintergrund ist es sinnvoll, dass ein Problem nur zu einem Meilenstein gehört (es wird nur einmal veröffentlicht oder in die Produktion verschoben), aber Teil verschiedener Projekte sein kann.

Ich bin mir sicher, dass es andere Möglichkeiten gibt, es zu betrachten, und ich bin daran interessiert, andere Meinungen zu hören.

Bearbeiten Dezember 2017

Vor einiger Zeit, nachdem ich über ein Jahr mit Meilensteinen und Projekten gearbeitet hatte, wurde mir klar, dass es einen weiteren wichtigen Aspekt gibt, den ich völlig übersehen hatte.

  • Milestones ist ein Tool für die Scrum- Methodik. Meilensteine ​​eignen sich gut für Iterationen mit Zeitboxen und für Sprints mit zahlreichen Problemen.
  • Projects ist ein Werkzeug für die Kanban- Methodik. Projekte sind gut für eine kontinuierliche Lieferung und einen stetigen Arbeitsfluss.

3
Danke für die Zusammenfassung, ich habe mich das selbst gefragt. Ich denke, ich werde mich von der ganzen Sache mit den Projekten fernhalten, da sie für meine ... Projekte nicht sehr zutreffend ist. Github Projects scheint (für mich) "verkehrt herum" zu sein, da ich normalerweise mehrere Repositorys für ein Projekt habe, nicht umgekehrt.
KEK

1
@KEK, in GitHub Enterprise verwende ich eine Organisation mit einem gleichnamigen Repository, das keinen Code enthält, aber verwendet wird, um alle Projekte und ihre Probleme zentral zu halten. Die Pull-Anforderungen für die Repositorys, die Code enthalten, enthalten einen kurzen Verweis auf das Problem des zentralen Repositorys.
yegeniy

Mein Gefühl ist, dass Meilensteine ​​hauptsächlich für die folgenden Wochen / Monate gelten, in denen alle Probleme mehr oder weniger bekannt sind, und Projekte für Monate bis zu einem Jahr, in denen noch nicht alle Probleme bekannt sind. Eine engere Integration zwischen den beiden, die die Überlappung verringert, könnte sich tatsächlich lohnen.
Trilarion

1
Projekte haben jetzt Fortschrittsbalken, wenn Spaltenautomatisierungsvoreinstellungen verwendet werden.
Emlai

Das ist fantastisch. Es ist mir jedoch immer noch unklar, ob man Meilensteine ​​und Projekte zusammen oder nur einen der beiden verwenden soll. Was denken Sie?
Chrisdembia

41

Meine Meinung:

  • Ein Projekt handelt von einem Prozess und den Menschen .
  • Ein Meilenstein handelt von einem Produkt .

Ein Projekt ist am besten geeignet, um einen Einblick in einen Prozess zu erhalten, der von den Personen in der Gruppe verwendet wird. Ein besserer Name dafür wäre "Workflow" oder "Prozess". Das Erstellen eines neuen Projekts ist mit mehr Aufwand verbunden als das Erstellen eines neuen Meilensteins. Sie möchten also wirklich nur dann ein neues Projekt erstellen, wenn es in Ihrem Team einen neuen Prozess gibt : Fahrspuren müssen ausgewählt, konfiguriert und bestellt werden. Sie können auch in jedem Projekt sehr unterschiedlich sein. Ich denke an die ursprüngliche Verwendung von Kanban durch Toyota zurück: das Management der Menschen und ihrer Arbeitsbelastung.

Ein Projekt beantwortet die Frage: "Woran arbeiten wir gerade?"

Zwei großartige Projektbeispiele: Softwareentwicklung und Bloggen. Die Konfigurationen für jede würden die Personenprozesse der verschiedenen Gruppen unterstützen. wie sie zusammenarbeiten und Dinge abzeichnen.

Im Gegensatz dazu funktionieren Meilensteine ​​alle gleich. Es handelt sich um eine geordnete Liste von Aufgaben, die alle geschlossen sein müssen, damit das Arbeitsprodukt als vollständig betrachtet werden kann. Optional kann ein Fälligkeitsdatum festgelegt werden, das nur Erinnerungen enthält, aber die Milestone-Funktion nicht ändert.

Ein Meilenstein beantwortet die Frage: "Was bleibt noch übrig, um dieses Produkt fertigzustellen?"


14

Eine schöne Sache an Projekten ist, dass sie mehr Freiform als Meilensteine ​​sind. Sie können einfach Notizen in sie einfügen und sie mit Themen verknüpfen und sie so organisieren, wie es Ihnen passt. Sie eignen sich hervorragend, um Ideen aufzuschreiben, Roadmaps zu erstellen und Ressourcen und Abhängigkeiten aufzulisten. In der Vergangenheit habe ich Probleme und das Wiki für die gleichen Dinge verwendet, aber ich fand beide zu formal und transaktional (dh höheren Overhead).


10

Meilensteine sind Etiketten, die Tickets markieren und gruppieren, die voraussichtlich zu einem bestimmten Zeitpunkt geliefert werden. Die MilestonesSeite, auf die Sie zugreifen könnenIssues Seite macht dies deutlich: Sie können den Prozentsatz der für einen bestimmten Meilenstein abgeschlossenen Tickets und das Fälligkeitsdatum anzeigen. Sie können Meilensteine ​​auch nach Fälligkeitsdatum sortieren und Tickets innerhalb eines bestimmten Meilensteins priorisieren.

Der Schwerpunkt liegt hier auf Lieferterminen und der Verfolgung des Fortschritts.

Projekte hingegen werden in GitHub als Kanban- Boards mit einigem Schnickschnack implementiert . Sie können eine Reihe von Spalten angeben ( und Swimlanes - wie @Doug unten sagte, werden Swimlanes noch nicht unterstützt), um einfache Workflows zu erstellen. Sie können dann Tickets aus einem oder mehreren Repositorys hinzufügen, sie priorisieren und sie dann während der Bearbeitung von einer Spalte in eine andere verschieben. Sie können beispielsweise die Spalten "Backlog", "In Bearbeitung", "In Bearbeitung", "In Test" und "Fertig" haben und Tickets von links nach rechts oder von rechts nach links verschieben, wenn beispielsweise ein Defekt vorliegt Das Ticket wird von "In Testing" zurück zu "Backlog" zurückgeschickt.

Der Schwerpunkt liegt hier auf der Organisation und Verwaltung der Arbeit.

Dann liegt es an Ihnen, wie Sie diese Arbeit organisieren und partitionieren. Sie können ein Projekt pro Meilenstein erstellen oder mehrere Meilensteine ​​in einem einzelnen Projekt haben oder Meilensteine ​​in kürzere Sprints aufteilen . Sie können auch mehrere Projekte durchführen, die verschiedene Aspekte der Arbeit an dem Produkt abdecken, z. B. eines für Entwickler und eines für Tester.


Schwimmbahnen sind in Kanban keine Säulen. Sie sind Reihen. Github unterstützt derzeit keine Schwimmbahnen als erstklassiges Feature.
Doug

Danke für die Korrektur @Doug. Können Sie klarstellen, was erstklassiges Feature in diesem Zusammenhang bedeutet? Ist es in der Beta oder so verfügbar?
Johnny Baloney
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.